Why is the timestamp passed to requestAnimationFrame in Chrome sometimes in the past?

Viewed 442

Chrome sometimes passes a timestamp into the requestAnimationFrame ("rAF") callback that is before the time rAF is called. How is that possible?

My test case: I first get a timestamp t0 using performance.now(), then request an animation frame, and finally compare the timestamp t1 passed to the callback to t0: https://jsfiddle.net/cy45gdan/3/

How does it make sense for t1 to happen before t0? Is Chrome calling my callback for an ongoing frame and passes the time that frame started?

Firefox and Safari seem to only pass timestamps into the rAF callbacks that are after the time rAF is called.

1 Answers

The DOMHighResTimeStamp is made onload, not when requestAnimationFrame is called.

Using your code (nicely done, by the way), I managed to get two (-) numbers in Firefox out of a plethora of tries, while on Chrome I got mostly negative numbers with only a few positive ones.

That means that sometimes the browsers run code before they make the timestamp onload, which would result in a positive number. I have no idea what the root cause of the fluctuation is, so I won't even speculate.

Related