CODEWITHSUNDEEP
javascriptrequestanimationframe
Robo Robok
Robo Robok

Reputation: 22683

Why does millisecond counter keep going in requestAnimationFrame()?

I'm making a game in JavaScript, using the great requestAnimationFrame(callback) function.

Today I learned that the callback passed to requestAnimationFrame() gets a high resolution time measured since we opened that page. Let's call it ms:

function paint(ms) {
    // draw my game
    requestAnimationFrame(paint);
}

requestAnimationFrame(paint);

It's all great, but there's one thing I don't quite get.

Function requestAnimationFrame() doesn't do anything when we go to another tab, so the rendering is paused. On the other hand, the time passed to the callback still goes on when we leave. Because of this, I'm not sure how would I make any use of that value. If it worked proportionally with rendering engine, I could use ms to calculate logical time of my game, because relying on requestAnimationFrame() as a rock stable 60 FPS doesn't sound like the greatest idea.

Am I missing something? What's the purpose of the ms parameter if it continues to count when we leave our tab?

Upvotes: 1

Views: 651

Answers (2)

user128511
user128511

Reputation:

To add to Kaiido's answer. It's also common in apps to limit the time delta. For example a common way framerate independant calculations in apps is to compute the time between frames

let previousTime = 0;

function loop(currentTime) {
  const deltaTime = currenTime - previousTime;
  previousTime = currentTime;

  // use deltaTime in various calculations
  posX = posX + velX * deltaTime;

  requestAnimationFrame(loop);
}
requestAnimationFrame(loop);

But, sometimes collision and or other math can break if deltaTime is too large so games will often add a limiter

  // don't let deltaTime be more than a 1/10 of a second
  const deltaTime = Math.min(currenTime - previousTime, 1000 / 10);

This mostly removes the need for checking for onvisiblitiychange. Especially if you keep your own animation/game clock.

let previousTime = 0;
let clock = 0;
let clockRate = 1;

function loop(currentTime) {
  const deltaTime = Math.min(currenTime - previousTime, 1000 / 10) * clockRate;
  previousTime = currentTime;

  clock += deltaTime;  // update our own clock

  requestAnimationFrame(loop);
}
requestAnimationFrame(loop);

Now not only will or clock not jump if the player hides the tab but we can set clockRate to 0 if we want things to pause.

Why use your own clock? It lets you easily slow down or speed up time for all calculations that depend on that clock (see clockRate above). Also many app (games) have multiple clocks. They'd compute a different deltaTime for each clock. For example one clock for all objects that need to pause vs clocks need to keep going even even with the app/game is pause. Another might be a clock for the player vs one for the enemies so that when the player uses their "slow time super power" the enemies motions go slow but the player's motions remain at the same speed.

Upvotes: 1

Kaiido
Kaiido

Reputation: 136707

That's just a timestamp, it doesn't really count anything. It's indeed generally the same as performance.now() which gives the amount of time since the page is active. As to why, it's just how the DOMHighResTimeStamp's origin has been defined.

We usually use it as a way to know how long time has elapsed since some prior event occurred, that is we store a start_time, then check the current timestamp and we can get the delta time of our animation, regardless of the actual frame-rate.

By the way, no, relying on requestAnimationFrame to be at any fixed frame-rate is really not a good idea, requestAnimationFrame is not tied to any frame-rate by specs, and actually it is recommended to align it with the screen refresh-rate (though only Blink does so).

So you actually need to rely on such a timestamp in order to have a consistent speed across different setups. Doing a simple pos++ at every frame will make your animation run twice faster on a 120Hz monitor than on a 60Hz one (at least in Chrome).

This only makes your idea more complex to perceive how it could be implemented: would your paint-timer go twice faster when the window is moved to a 120Hz monitor?

This timestamp may also help to catch up on long frames, it's not because the system had a hiccup that you necessarily want your animation to last longer.
Similarly, not all cases want the animation logic to stop when the window is blurred. Let's say I have a header with a background animation powered by rAF, I don't really want it to pause when going off-screen, even though it didn't have been painted.

If you want your game logic to pause when the window is blurred, listen for the onvisibilitychange, and save the current timestamp (using performance.now() since we're outside of rAF).

Upvotes: 1

Related Questions