Re: [w3ctag/design-reviews] OffscreenCanvas new commit() and DedicatedWorker.requestAnimationFrame (#288)

CC issue #141 

Hey all,

Took this up again at today's F2F in Paris. 

Thanks for patiently explaining a complex space to us.

While we recognize the scenarios for having an explicit blocking `commit()` (e.g., porting native code to the web with near-zero change), we don't think that the case is yet sufficiently compelling to offset the architectural concerns raised by blocking commit.

Shared Array Buffers and atomics now allow developers to guard critical sections, and that *may* seem in conflict with a rAF-based solution, but the extent to which that is true isn't clear from discussion or the examples we've been able to read.

One of the most complex scenarios we've been pondering has been the need to [run multiple displays at different rates](https://github.com/immersive-web/webxr/blob/master/explainer.md#mirroring), driven from the same GL context. This arises in VR and XR scenarios and we're very happy to see the progress made in providing [`requestAnimationFrame` fused to the `XRSession` object](https://immersive-web.github.io/webxr/#dom-xrsession-requestanimationframe), rather than an implicit higher frame rate (which is what commit appeared to enable in a world where the worker itself might only get a 60fps rAF).

This progress in XR takes a lot of the pressure off of the necessity of `commit()` (in our view) and we'd like to see the community move forward with this model if possible. If not, we'd like to discuss further, perhaps on a future call, to help clarify the (perhaps glaring!) gaps in our understanding.

Cheers -- Alex & Travis

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/288#issuecomment-434668370