Feature Request: vrDisplay.requestIdleCallback

[toji]

From @mthiesse on May 4, 2017 14:42

This would mirror window.requestIdleCallback, and run during idle periods for the VR Display. This could be very useful in helping sites schedule non-essential/backgroud tasks, or do prep work for the next frame, etc.

Copied from original issue: immersive-web/webxr#227

[toji]

From @kearwood on May 24, 2017 18:35

This is interesting and may provide some benefit; however, the timing of the idle periods and VRDisplay.requestAnimationFrame callbacks would differ from what is described for window.requestIdleCallback: https://www.w3.org/TR/requestidlecallback/

These differences would also vary from one headset to another due to platform specific optimizations. As an example, with Oculus rendering, the start of the next frame may trigger soon after submitting and before the vsync starts. This "overlapped" rendering would cut into the idleCallback time.

[toji]

From @kearwood on May 24, 2017 18:43

Thinking on this further and considering the recent changes to the WebVR 2.0 spec, I am not certain if a VR specific requestIdleCallback would provide much benefit over using the existing window.requestIdleCallback. I could imagine browsers altering the behavior of window.requestIdleCallback when VR presentation is active to account for the simultaneous display on multiple devices with mixed frame rates.

The latest iteration of the WebVR 2.0 spec redefines the render loop to be promise driven rather than event driven. VRDisplay.requestAnimationFrame has now been eliminated. The safest place to perform idle tasks during VR rendering would be immediately after calling VRCanvasLayer.commit. After the idle tasks are complete, the promise returned by VRCanvasLayer should be resolved to block until the next iteration of the loop. The variations in platform implementation will dictate which API call blocks and throttles the render loop so it doesn't free-run, leading to potential exceptions.

Due to the overlapped rendering described in my prior comment, any work done in the same thread as the render loop has the potential to impact VR rendering. I would propose that doing background tasks, such as culling geometry and performing physics, would ideally be performed in a WebWorker instead.