klausw
commented
6 years ago Hm, according to the explainer this is intentional:
(Timestamp is given for compatibility with window.requestAnimationFrame(). Reserved for future use and will be 0 until that time.)
Why is that, and where are applications supposed to get the expected time-on-screen for animation? Wallclock time isn't a good solution, and I didn't see an obvious timestamp in the frame object.
scene.js does its own timing logic based on performance.now() timestamps.
If I understand it right, it's recommended for applications to use the timestamp supplied to their rAF callback, since this value can be tuned to match the expected time-on-screen for the computed frame with the goal of providing smooth animations. Using a wallclock time bypasses these adjustments, and also isn't helpful for the purpose of testing WebXR implementations.
(I ran into this when I accidentally broke the rAF callback timestamp, making it permanently zero, but initially didn't notice since the CubeSea demo continued animating as expected.)