Re: [w3ctag/design-reviews] Review OffscreenCanvas, including ImageBitmapRenderingContext (#141)

> Do all headsets have this kind of lockstep relation between pose data updates and display refresh rate? Is that desirable?

Not all VR APIs have that requirement, but it's also not and uncommon pattern. In native land it typically looks like `waitForNextPose(&posePtr)` which serves both as the frame throttle and the pose update. And yes, in our case the least latent variant would be your third code sample, where rendering happens before non-pose-dependent simulation logic for the frame.

> I feel we do really need an API that allows one to query what the currently occurring refresh rate on the particular display one is rAFfing at is, in a manner that allows polling if it can change 

Totally agree with this, though recent hardware trends make it trickier. Variable rate displays like GSync monitors or the iPad's 120Hz screen feel like they could become a lot more common in the not so distant future if for no other reason than battery savings. So we'd likely want a way both to determine what the current refresh is with the expectation that it may change *very* frequently (I don't know if an event is appropriate?) but also have a way for developers to specify that they want their content to run at a locked rate that may be less than the screen's fastest.

> I'm still not sure if the while(await) thing is what people want even.

I wondered about that myself, as it's syntactic sugar more than anything else.

-- 
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/141#issuecomment-344768304