[whatwg] Canvas in workers

[Glenn Maynard]

On Wed, Oct 16, 2013 at 8:01 AM, Justin Novosad <junov at google.com> wrote:

> > ... oh... so the UI could be updated even if JS is blocking... the future
>
> is bright :-)
> >
>
> If the UI is all painted in a canvas, then yes.
>
> Let's not get ahead of ourselves though. Browsers that have a compositor in
> a separate thread can present frames without synchronizing with the main
> thread, but updating a regular (DOM-based) UI would likely require style
> and layout calculations to be propagated from the main thread to the
> compositor.


Right, that's the only sort of async update we're talking about here:
changing what gets composited, and not anything that affects layout or is
detectable by scripts.

But actually, there's no disagreement.  I misread Kenneth's mail as saying
"your proposal requires synchronization with the main thread", but he
actually said "this other proposal requires synchronization with the main
thread (but has other benefits)".

I'm not sure how big a problem that synchronization will be.  Posting
messages should be extremely cheap: essentially free, when you're just
transferring an object to a thread in the same process.  The UI thread
should also not be heavily loaded: you shouldn't have to wait long for the
script to receive the object and push it into the canvas.  But, even a cost
of 2ms would be a massive hit, since that's 12% of the time you have
available when rendering at 60 FPS.  In practice it might make it harder to
sustain smooth 60 FPS animation.  For example, if the main thread
occasionally spends 4ms doing GC work, you may have a rendering hitch that
you wouldn't have otherwise.

-- 
Glenn Maynard