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

Overall, I do like @toji's idea of having multiple rAF() providers as a mechanism to tie to multiple different refresh rates. That would map to a scenario where there are multiple canvases that are on different displays, with different refresh rates.

In addition to that, 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 (moving browser from one display to another). The above code examples are the most common ways to render that probably 99% of WebGL pages use, but that kind of code generates horrible microstuttering that WebGL applications are currently experiencing. On small WebGL canvases one might not see this, but on larger displays or on a HMD glued to your face, the stuttering becomes much more apparent. To remedy this, one should lock `dt`s to refresh-rate fixed increments. Then a rAF tick would look like this:

```javascript
var t0;
void rAFTick() {
  var t1 = performance.now();
  var refreshInterval = 1000 / 60; // Or rather, 1000 / display.getRefreshRate();
  var dt = t1 - t0;
  var threshold = 0.5;
  var fixedDt = Math.ceil(dt - threshold) / refreshInterval) * refreshInterval;
  updateSceneSimulation(fixedDt);
  t0 = t1;
  var cameraPose = getHMDPose();
  renderScene(cameraPose);
  requestAnimationFrame(rAFTick);
}
```

But currently since there is no API `display.getRefreshRate()` to ask what the hardware vsync rate is, the above kind of code is brittle since one has to keep benchmarking to discover the refresh rate (which is a bit futile like mentioned above)

This method relies on the knowledge that content is presented exactly on multiples of the vsync refresh interval. On a GSync/FreeSync display, or when rendering in VSync unlocked mode, this kind of code pattern would not be used.

An API to ask the refresh rate would also be ideal to be detached from control flow, i.e. an "imperative" function such as `display.getRefreshRate()` would be preferred over something that is piggybacked on `requestAnimationFrame`, since not all applications would like to use `requestAnimationFrame`.


-- 
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-344607031