Re: [public-houdini] <none>

On Mon, Mar 16, 2015 at 10:17 AM Rick Byers <rbyers@chromium.org> wrote:

> 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?
>>
>
Sure. I have an API sketch here: http://goo.gl/UoeWz0. It's very rough,
high-level, and it's changing regularly, but please do feel free to
comment. I'd appreciate any feedback.

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