0

I am trying to write a basic game loop based on requestAnimationFrame. Callback for requestAnimationFrame is passed with a timestamp argument, which as I understand is a time in milliseconds since the page has been loaded. When building a game loop I have an assumption that with each call to requestAnimationFrame the timestamp value always goes up, based on that I can calculate a time delta between frames. My only worry is that if the application is running for a long time, this timestamp value will reach it's limit at some point.

Is there such a limit? How much of real world time will have to pass for this to happen? What will happen with the timestamp value after the limit is reached?

Michael Radionov
  • 12,859
  • 1
  • 55
  • 72
  • I don't think it returns milliseconds since page load, it returns a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp) "time when `requestAnimationFrame()` starts to execute callback functions.". – zero298 Mar 18 '20 at 14:26
  • What exactly is the "time when requestAnimationFrame() starts to execute callback functions."? From my experiments it is somewhat close to page load. If I call requestAnimationFrame right away - the first timestamp is somewhat close to zero ms, if i call it in 5 seconds since page load - timestamp value will be close to 5000ms. – Michael Radionov Mar 18 '20 at 14:31
  • Info about callback execution start time is down below in [DOMHighResTimeStamp - The time origin](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp#The_time_origin) section – Michael Radionov Mar 18 '20 at 21:22

2 Answers2

0

I don't think it returns milliseconds since page load, it returns a DOMHighResTimeStamp "when requestAnimationFrame() starts to execute callback functions".

From MDN

The function to call when it's time to update your animation for the next repaint. The callback function is passed one single argument, a DOMHighResTimeStamp similar to the one returned by performance.now(), indicating the point in time when requestAnimationFrame() starts to execute callback functions.

That begs the question though so I'll also say that I wouldn't worry about an overflow in this case since that unit is a double and I'm pretty sure that means 64 bits of precision. It took 60 years to hit the year 2038 problem and that had 32 bits of precision. My math is probably off, but I just wouldn't worry about the overflow. When timestamps start breaking down, we probably have bigger issues.

zero298
  • 25,467
  • 10
  • 75
  • 100
  • I see that year 2038 problem is caused by signed 32-bit integer, but here I am dealing with value with a floating point, even though it is 64 bits. I guess it is stored differently, and I am wondering if the max value for timestamp is actually lower with 64-bit float than with 32-bit int. Nevertherless, it has to be pretty big as well. – Michael Radionov Mar 18 '20 at 21:18
0

Do not worry.

What is passed to the requestAnimationFrame callback is a DOMHighResTimestamp, indeed with its origin set to the page load in a window ("the time when the browsing context is first created") and indeed it represents the number of milliseconds since then.

According to the specs, you have about 285,616 years before it starts losing precision.

Community
  • 1
  • 1
Kaiido
  • 123,334
  • 13
  • 219
  • 285
  • If I am reading the specs correctly the years you've highlighted are related to Date object. – Michael Radionov Mar 23 '20 at 20:13
  • @MichaelRadionov You probably missed the sentence "The DOMTimeStamp is defined similarly". Since the origin of the timestamp returned by rAF is the page load time, that's 285K years after page load. The longest DOMHigjResTimestamp one could reasonably have is performance.timeOrigin, which has its origin set to the same epoch as Date, but that doesn't matter here. – Kaiido Mar 23 '20 at 23:03
  • Indeed, after some research it looks like it is the right number. According to [this q/a](https://stackoverflow.com/questions/1848700/biggest-integer-that-can-be-stored-in-a-double) and other sources, max int that can safely be stored in a double is 2^53. If we use it to store milliseconds and convert max value of 2^53 to years, we get the number of years you've provided. – Michael Radionov Mar 29 '20 at 09:40
  • And I guess what happens if this max value is exceeded can be observed by adding numbers to [Number.MAX_SAFE_INTEGER](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER) - results are not as expected. – Michael Radionov Mar 29 '20 at 09:47
  • Yes basically it would loose precision, if there is still some energy plant running by that time to power up the computer which runs this script. – Kaiido Mar 29 '20 at 10:55