[whatwg] Canvas in workers

[Justin Novosad]

On Wed, Oct 16, 2013 at 4:32 AM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 16/10/2013 01:26, Robert O'Callahan a écrit :
>
> On Wed, Oct 16, 2013 at 11:55 AM, David Bruant <bruant.d at gmail.com> wrote:
>
>> If the main thread is blocked, the app drops frames anyway, no?
>>
>
>  Not necessarily. We can allow workers to present frames to the
> compositor without synchronizing with the main thread.
>
> ... 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. So we are still gated by the main thread for a lot of things.
That will most like remain an issue for the foreseeable future. Presenting
frames directly from a worker can be trivially achieved in cases that do
not require updates to the DOM (like canvas contents changed). Some simple
types of changes to the DOM may also be represented directly in the
compositor, thus making it possible to short-circuit the main thread, but
these are a very limited subset of what a typical app might use in its UI.
 The saner approach is still for app devs is to move whatever blocking JS
they have off of the main thread.

   -Justin