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

> Key to that clarification seemed to be highlighting the fact that we're using our rAF variant to not only control timing but deliver pose data in sync with those animation frames.

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

I'd imagine a typical structure of a variable timestep `rAF()` body for VR could look like

```javascript
var t0;
void rAFTick() {
  var t1 = performance.now();
  var dt = t1 - t0;
  updateSceneSimulation(dt); // Physics, game logic, etc. "camera independent", could take several msecs
  t0 = t1;
  var cameraPose = getHMDPose();
  renderScene(cameraPose);
  requestAnimationFrame(rAFTick);
}
```

If delivering the camera pose is tied to the firing of `rAFTick`, I understand the code looks something like this?

```javascript
var t0;
void rAFTick(cameraPose) {
  var t1 = performance.now();
  var dt = t1 - t0;
  updateSceneSimulation(dt);
  t0 = t1;
  renderScene(cameraPose);
  requestAnimationFrame(rAFTick);
}
```

Is that structurally accurate? If so, the second example looks like it could have worse latency compared to the first one, in a scenario where `getHMDPose();` might have an opportunity to grab more fresh live data? In order to ensure the same with the second style of API, one should reverse the order of updating and rendering(?), i.e.

```javascript
var t0;
void rAFTick(cameraPose) {
  renderScene(cameraPose); // Render first so that cameraPose has least time to go stale
  var t1 = performance.now();
  var dt = t1 - t0;
  updateSceneSimulation(dt);
  t0 = t1;
  requestAnimationFrame(rAFTick);
}
```

If this is intended, it would be good to document this "reversal". In general I think I would favor not glueing pose delivery and `rAF()` together, they feel like two separate concepts. Is there a specific reason that getting pose data could not be a good old regular function call, like a VRDevice.captureLatestDevicePose()? That way it would have the advantage of being able to be called outside any rAF() loops so that one is not restricted to be running in a rAF loop. (the Worker has it own sync main loop scenario)



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