Need a requestAnimationFrame-style API for OffscreenCanvas

[junov]

In order to produce high-frame rate and low-latency animations, without going into over-draw, we need an API to provide an animation heart beat for OffscreenCanvas.

Initial thoughts:

• Only OffscreenCanvases that use the commit() flow have a direct link to a display, so perhaps OC.rAF should be tied to the use of commit().

• OC.rAF should not be intrinsically tied to the processing model of the browsing context's event loop because we want workers to be able to pump out animation frames while the main thread is busy.

• There is no global graphics update that commit needs to be synchronized with, so the processing model can be quite open-ended, implementation should only have to respect a small set of rules. E.g. does not cause over-draw, minimizes latency (does not accumulate multiframe backlogs), maximizes frame rate.

• It should be possible to drive synchronized animations on multiple OffscreenCanvas objects as long as the OffscreenCanvas objects are in the same worker.

[junov]

@toji Any special considerations for WebVR integration. I was thinking the WebVR rAF API should take over for that use case. Perhaps the regular OffscreenCanvas commit() and rAF() should throw exceptions when the OffscreenCanvas is hooked up to a VR layer. WDYT?

[toji]

It's a good question. I don't think we want commit() to throw an exception, since one of the expected use cases is rendering to the headset AND mirroring to a PC monitor. rAF() is maybe a bit different, though I could maybe see an argument for having a main logic loop that looks like:

canvas.requestAnimationFrame(drawMirroredView); // Draws to main display at 60Hz
vrDisplay.requestAnimationFrame(drawVRView); // Draws to HMD at 90Hz

In a case like this the page would be drawing a different view of the scene (a third person view or "demo driver" view) to the main display, and drawing the first person view to the HMD. Thus far I've been coding such examples to draw to both within the single rAF, but that means that we're producing frames for the external display that are getting dropped on the floor. That's a somewhat odd pattern, though, and will produce an uneven GPU workload across frames, so I'm not sure if it's worth it.

[junov]

Closing this issue in favor of the new one that references a fuller proposal: #2139