Re: [public-houdini] <none>

I agree with the sentiment here - the problem space is over-constrained and
so there doesn't appear to be any perfect answers.  But, IMHO, this is
probably the most important problem facing the web right now so it's
totally appropriate to be pursuing different approaches, building
prototypes, and gathering feedback from real-world developers.

In addition to the classes of solutions discussed here, we're also
exploring a 3rd class on the Chrome team: enabling performance isolation at
frame boundaries, with each frame getting it's own control thread. This has
the advantages of #1 (eg. symmetric API) with less fragility, but lacks the
flexibility and incrementality of #2.  Experiments like Fastbook
<http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/> have
already shown frames to be a powerful performance isolation primitive,
adding asynchrony and preemption could be very compelling.

Regardless, a "worker-control-thread" API approach has a unique and
compelling mix of trade offs that would complement any of these other
possible solutions.  I think we can and should proceed with these different
approaches relatively independently.

Rick

On Sun, Mar 15, 2015 at 11:53 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> 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.
>