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

Received on Wednesday, 19 August 2015 14:14:28 UTC