[whatwg] Canvas in workers
bruant.d at gmail.com
Tue Oct 15 15:55:22 PDT 2013
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.
More information about the whatwg