Re: [public-houdini] <none>

On Sat, Mar 14, 2015 at 12:17 PM, Ian Vollick <vollick@chromium.org> wrote:

> On Mon, Mar 9, 2015 at 9:02 PM Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
>> With #2, if you think of the control thread being your primary
>> application thread, all the async APIs you could want are available, by
>> postMessaging to the main thread.
>>
>> For #2, we can provide most existing APIs to a control thread Worker ---
>> except DOM manipulation (and by extension, full manipulation of CSS
>> layout). For example, if we want to animate CSS 'width' at 60fps with text
>> wrapping and border redrawing, we need #1. To some extent, #2 leads
>> developers away from using CSS and the DOM. It seems very unappealing to
>> replicate features like editable content, accessibility, text input and
>> rich text layout outside of CSS and the DOM, so if we end up wanting these
>> on the control thread, that's a problem for #2.
>>
>
> This is a fair concern, but I don’t think we’d have to reimplement all
> these features. As I understand it, approach #2 would still permit an
> application to be constructed in terms of components built out of DOM/CSS
> with accessibility, input etc. And as you mentioned earlier, we’ll have
> access to all of these from the control thread, though asynchronously.
>

Right. The question is how much demand there would be for those features to
be accessibly synchronously to a non-main-thread control thread.

A critical question is whether #2 leads to a coherent application
>> development approach which integrates 60fps application rendering with
>> chunks of not-60fps CSS-rendered content, or whether it leads to an
>> architecture which is not compelling to developers, or whether it leads to
>> a bifurcation in the Web where apps and documents use separate APIs (and
>> how bad would that be?).
>>
>> Personally I lean towards #2 currently, but I don't know enough to
>> predict the implications.
>>
>
> Fantastic questions. I don’t think that #2 precludes components, even if
> they disagree about the choice of control thread, provided we’re willing to
> stomach some asynchrony in their interactions.
>
> About the bifurcation -- there will certainly be an asymmetry in
> programming paradigms, but that might actually be a benefit. In an
> application where some code is performance-critical and some isn’t, the way
> you write the fast stuff is often very different (eg, shaders). This is
> handy both because it reminds you that you’re writing performance-critical
> code and because the manner in which you’re forced to write this code can
> make it tough to cause performance problems. It’s designed to be performant
> and to minimize footguns.
>
> As for whether it leads to an architecture which is not compelling to
> developers, it’s really tough to say. The approach should permit
> incremental (pay-to-play) adoption of performance isolation (so if not
> compelling, hopefully not scary) and it seems like it might benefit some
> existing frameworks, but I'd really like to do some experiments, build some
> real, non-toy things, and see how it feels in practice.
>

OK.

I think the animation-timeline proposal is control-thread-agnostic so we
could progress that towards shipping, in parallel with other work, if
people feel it's useful enough.

Meanwhile, I think we should produce a consensus proposal for a minimum
viable Worker-control-thread API. Can you provide a link to your latest
draft?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.