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 > > >