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 >