Re: [whatwg] Worker requestAnimationFrame
Sounds great to me. I agree this is an important scenario. *Ian*, thoughts? Is anyone actively working on worker-thread canvas in blink at the moment? Note that Ian's CompositorWorker prototype https://docs.google.com/document/d/18GGuTRGnafai17PDWjCHHAvFRsCfYUDYsi720sVPkws/edit# currently names this method requestCompositorFrame to help make the semantic difference from requestAnimationFrame more clear to developers. But otherwise it's basically the same. Lots of debate could be had on the admission / timing policy, but only data from real apps is likely to resolve this debate so we should probably start with something simple and flexible like you propose. Rick On Tue, Aug 18, 2015 at 10:53 PM, Robert O'Callahan rob...@ocallahan.org wrote: For OffscreenCanvas we need a way for a Worker to draw once per composited frame. I suggest we create DedicatedWorkerGlobalScope.requestAnimationFrame(callback) that works similarly to Window.requestAnimationFrame. To reduce latency for applications such as VR, I'd like to run the callback after vsync and let the compositor wait for some implementation-defined amount of time for the callback to complete before compositing the frame; this will give the callback a chance to finish rendering and get the results composited before the next vsync. If the callback runs too long its updates will be applied to some later frame. I suggest we later extend this for worker-based control of CSS transforms etc (i.e. CompositorWorker). Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] Worker requestAnimationFrame
On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org wrote: Sounds great to me. I agree this is an important scenario. *Ian*, thoughts? Is anyone actively working on worker-thread canvas in blink at the moment? Work not yet started, but it is in my queue. On Tue, Aug 18, 2015 at 10:53 PM, Robert O'Callahan rob...@ocallahan.org wrote: For OffscreenCanvas we need a way for a Worker to draw once per composited frame. I suggest we create DedicatedWorkerGlobalScope.requestAnimationFrame(callback) that works similarly to Window.requestAnimationFrame. To reduce latency for applications such as VR, I'd like to run the callback after vsync and let the compositor wait for some implementation-defined amount of time for the callback to complete before compositing the frame; this will give the callback a chance to finish rendering and get the results composited before the next vsync. If the callback runs too long its updates will be applied to some later frame. Without this API, I think the best one could do is to post a message to the worker from from the main thread rAF callback, which is not very good because it adds unnecessary latency to the signal, and will induce Jank if the main thread is busy. So: +1 to this proposal I suggest we later extend this for worker-based control of CSS transforms etc (i.e. CompositorWorker). Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] Worker requestAnimationFrame
On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick voll...@chromium.org wrote: On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad ju...@google.com wrote: On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org wrote: Sounds great to me. I agree this is an important scenario. *Ian*, thoughts? I would certainly like to see requestAnimationFrame in a worker, but there is more risk of falling out of step with vsync in a vanilla worker that has access to APIs that are dangerous from a performance point of view. It would also be nice to run a worker with rAF on an elevated priority thread (or maybe even the compositor thread), but that would be a bad idea if it can do stuff like synchronous IO. I fear a proliferation of different kinds of restricted Workers that would make it hard to handle multiple kinds of callbacks in a single Worker, so I'd rather not introduce a new restricted kind unless it's absolutely necessary. I think it would be fine to support rAF in a general DedicatedWorker and then later, if absolutely necessary, provide an elevated-priority Worker with restricted API. After implementing rAF for DedicatedWorker, the first slow-script mitigation I'd like to introduce is the you missed your frame deadline event that we've been talking about for a whlie. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] Worker requestAnimationFrame
On Wed, Aug 19, 2015 at 5:14 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick voll...@chromium.org wrote: On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad ju...@google.com wrote: On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org wrote: Sounds great to me. I agree this is an important scenario. *Ian*, thoughts? I would certainly like to see requestAnimationFrame in a worker, but there is more risk of falling out of step with vsync in a vanilla worker that has access to APIs that are dangerous from a performance point of view. It would also be nice to run a worker with rAF on an elevated priority thread (or maybe even the compositor thread), but that would be a bad idea if it can do stuff like synchronous IO. I fear a proliferation of different kinds of restricted Workers that would make it hard to handle multiple kinds of callbacks in a single Worker, so I'd rather not introduce a new restricted kind unless it's absolutely necessary. I think it would be fine to support rAF in a general DedicatedWorker and then later, if absolutely necessary, provide an elevated-priority Worker with restricted API. After implementing rAF for DedicatedWorker, the first slow-script mitigation I'd like to introduce is the you missed your frame deadline event that we've been talking about for a whlie. In the requestIdleCallback proposal ( https://w3c.github.io/requestidlecallback/ ) a deadline argument is passed to the callback. That's an idea we could apply here as well. Not sure whether it is better or worse than using an event. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
