- From: David Bruant <bruant.d@gmail.com>
- Date: Wed, 16 Oct 2013 00:55:22 +0200
- To: robert@ocallahan.org, Justin Novosad <junov@google.com>
- Cc: WHATWG <whatwg@whatwg.org>, Kyle Huey <me@kylehuey.com>
Le 16/10/2013 00:12, Robert O'Callahan a écrit : > On Wed, Oct 16, 2013 at 10:19 AM, Justin Novosad <junov@google.com > <mailto:junov@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
Received on Tuesday, 15 October 2013 22:56:01 UTC