(Timestamp is given for compatibility with window.requestAnimationFrame(). Reserved for future use and will be 0 until that time.)
Why is that, and how are applications supposed to get an accurate target timestamp for animations that matches the expected time when the frame is going to be displayed? That's important for smooth animations.
Is there a field in the frame data that's supposed to be used for this?
The CubeSea sample uses wallclock time from performance.now() which seems like a hack, and is also inaccurate. You don't base animations on the current time when your rendering starts. If your render loop starts late but still finishes in time for the next VSync equivalent, you're supposed to use that VSync's time, not the late start time. See also https://github.com/immersive-web/webxr-samples/issues/13 .
The explainer's rAF callback section says:
Why is that, and how are applications supposed to get an accurate target timestamp for animations that matches the expected time when the frame is going to be displayed? That's important for smooth animations.
Is there a field in the frame data that's supposed to be used for this?
The CubeSea sample uses wallclock time from performance.now() which seems like a hack, and is also inaccurate. You don't base animations on the current time when your rendering starts. If your render loop starts late but still finishes in time for the next VSync equivalent, you're supposed to use that VSync's time, not the late start time. See also https://github.com/immersive-web/webxr-samples/issues/13 .