Open tobie opened 9 years ago
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 https://github.com/w3c/sensors/issues/6 and further feedback on how we can do this, possibly just using ms
intervals that were discussed in that thread would be good.
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. :-/
Frequency is measured in Hz, not milliseconds. Period is measured in milliseconds.
@domenic yeah, sorry, I always meant Hertz. No idea why I typed ms
all day throwing confusion all over the place.
@domenic thanks for providing this distinction.
I was going off what was written in the respective repo issues (which was ms
). Thank you for the clarification @domenic.
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:
The WebVR spec attempts to solve the issue with:
getState()
Return aVRPositionState
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. UsehasPosition
andhasOrientation
to check if the associated members are valid; If these are false, those members MUST be null.
ACTION: @mfoltzgoogle will follow up with Blink devs about the feasibility of tying sensor reads to animation frames.
Looking at the underlying APIs on iOS and Android, I don't see how that could be possible, unfortunately.
Copy pasted from @domenic's original issue https://github.com/rwaldron/sensors/issues/5
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: