[whatwg] Canvas in workers

[David Bruant]

Le 16/10/2013 00:12, Robert O'Callahan a écrit :
> On Wed, Oct 16, 2013 at 10:19 AM, Justin Novosad <junov at google.com 
> <mailto:junov at google.com>> wrote:
>
>     rAF doesn't work in a worker, but that is easy to work around. You can
>     have a rAF handler on the main thread that propagates the signal
>     to your
>     workers by posting a "rAF" message to them.
>
>
> That isn't a good solution since it forces the app to drop frames if 
> the main thread is blocked.
If the main thread is blocked, the app drops frames anyway, no?
Anyway, on not-so-good hardware (most mobiles?), workers communication 
cost is non-trivial and eats a bit of the 16,6ms budget.

A friend told me recently that in AS3, objects on the screen can all 
listen to a "beforeframe" event (or something like that). In web 
platform equivalents, they have a per-element requestAnimationFrame 
(instead of only a global one).
I found this idea interesting. Among other things, it allows 
implementors to not emit the event if the object isn't on the screen. It 
feels like it encourages good practices too; if my <canvas> element is 
too low in the document to be on screen, maybe I don't want to draw on 
it... I wonder how many people check if the thing they want to update is 
actually on screen...

In the case of canvas, the UA not only could decide to not dispatch 
events, but could also tell precisely which part of the canvas is 
visible so that if the app cares or is capable or partial canvas paints, 
it can decide to do so.

In case the main thread is blocked, events can be saved in the worker 
and save processing resource/battery.

David