Provide a way of tying sensor requests to animation frames

[tobie]

Copy pasted from @domenic's original issue rwaldron/sensors#5

For games and other animation frame loop-based situations (off the top of my head, accelerometer-based scrolling comes to mind) you want one value per animation frame.

Chrome is actually doing work specifically to integrate our scheduling of input events and animation frames, see Blink Scheduler design doc.

Off the top of my head, frequency: "animationframe" might be good. The contract being that, if you pass that in to the constructor, then given

requestAnimationFrame(function frame() {
  console.log(mySensor.value);
  requestAnimationFrame(frame);
});

you will get an updated value every frame.

I don't think frequency: 60 is quite the same thing (but I could be wrong; will try to tag in some Blink engineers) since animation frames often vary away from 60 Hz and so you will quickly get out of sync.

Posted to blink-dev: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/fLucJ2QH3fA unsure whether people will follow-up here or there.

Proposed resolution: Enabling developers to tie the frequency of sensor updates to animation framerate is a desirable feature. Further research is needed to see whether or not that is implementable.

Actions:

• research whether sensor update frequency can be tied to animation framerate.
• design the API so that developers can indicate the sensors update frequency must be framerate dependent.

[richtr]

I don't think frequency: 60 is quite the same thing [...] since animation frames often vary away from 60 Hz and so you will quickly get out of sync.

I think you meant frequency: 16 (ms) here.

But yes, I agree they are not the same thing in general. The risk here is that we will actually have stale sensor data that is between 0 to 16 milliseconds old by the time it is rendered to the screen in an animation frame loop. For Device Orientation data that is the difference between a nausea-inducing latency between screen rendering and the real world and a less-sickening experience :D

Thus, we should figure out a way to sync hardware sensor polling with the animation frame interval and always try to deliver the freshest sensor data for the next animation frame loop.

We discussed this in a bit in #6 and further feedback on how we can do this, possibly just using ms intervals that were discussed in that thread would be good.

[tobie]

I don't think frequency: 60 is quite the same thing [...] since animation frames often vary away from 60 Hz and so you will quickly get out of sync.

I think you meant frequency: 16 (ms) here.

Thanks for catching this. I'm an idiot. Fixing issue #6 conversation now, where I continuously referred to ms when I wanted to say Hz. Sorry. :-/

[domenic]

Frequency is measured in Hz, not milliseconds. Period is measured in milliseconds.

[tobie]

@domenic yeah, sorry, I always meant Hertz. No idea why I typed ms all day throwing confusion all over the place.

[rwaldron]

@domenic thanks for providing this distinction.

[richtr]

I was going off what was written in the respective repo issues (which was ms). Thank you for the clarification @domenic.

[tobie]

Enabling developers to tie the frequency of sensor updates to animation framerate is a desirable feature. Further research is needed to see whether or not that is implementable.

Actions:

• research whether sensor update frequency can be tied to animation framerate.
• design the API so that developers can indicate the sensors update frequency must be framerate dependent.

[anssiko]

The WebVR spec attempts to solve the issue with:

getState() Return a VRPositionState dictionary containing the state of this position sensor state for the current frame (if within a requestAnimationFrame context) or for the previous frame. This state may be predicted based on the implementation’s frame scheduling.

The VRPositionState will contain the position, orientation, and velocity and acceleration of each of these properties. Use hasPosition and hasOrientation to check if the associated members are valid; If these are false, those members MUST be null.