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

Reply via email to