How to prevent a huge backlog of physics calculations from freezing browser when tabbing out of browser game?

Question

I'm developing a browser game and am using the timestep implementation from the famous Fix your timestep! article.

It works perfectly, but there is one problem. If you tab out of the tab and then come back 5 minutes later or so, it freezes, because it has to execute all the missed physics calculations. That is, this code:

accumulator += frameTime;

while (accumulator >= dt)
{
    previousState = currentState;
    integrate( currentState, t, dt );
    t += dt;
    accumulator -= dt;
}

Seems to have to execute for quite a while because the accumulator has missed so many calculations while the tab was .. sleeping I guess?

I'm confused though. Shouldn't Javascript continue to run while the tab is not active? Why is this happening?

Is there any way to fix this? Ideally the Javascript would continue to run so that it wouldn't cause the tab to freeze for 2 minutes when coming back to it after being in other tabs for a while.

Answer 1

The way the Unity engine solves the problem of freezing the game while physics catches up is to enforce a maximum value the accumulator can ever hit.

You can implement this by replacing

accumulator += frameTime;

with

accumulator = Math.min(accumulator + frameTime, maxDeltaTime);

...for a maximum time delta that you control. It should be at least as large as dt. A good way to pick this value is to consider your lowest acceptable framerate, then invert it. So for instance, if you don't want your game to drop below 15 frames per second, then maxDeltaTime = 1/15.

This way you'll keep pace with real time as long as the browser/CPU is able to keep up. If tabbing away and back, or heavy processor load causes more real time to pass than what you can keep pace with at your minimum acceptable framerate, then instead of stalling (and dropping to an even lower framerate), this code instead allows the game to fall behind real time. So the game runs slow, but keeps updating and showing progress, rather than hard locking.

Answer 2

Looks like I found a decent solution. So while requestAnimationFrame doesn't really seem to run at all when the tab is tabbed out (makes sense), setTimeout and setInterval seem to get throttled to run once a second (good enough for me!)

So the solution is to put all the rendering logic in requestAnimationFrame (so that this doesn't run at all because who cares about rendering when you can't see it), and then put all physics logic in a setTimeout(physics, 0); which calls itself with another setTimeout(physics, 0);

Then every second it processes all the physics and sleeps for another second on repeat. This seems to solve the issue somewhat decent enough, such that when I come back to the tab after being gone for 10 minutes, it only seems to freeze for like half a second, where previously it would freeze for like 10 seconds.

I looked into using WebWorkers but those can't access the DOM so they seem pretty useless in this case, because I'm not going to be cloning the entire state of the game every frame to pass back to the main thread.. it'd be too slow.

Anyways, this seems okay enough as a solution so I'll probably accept my own answer in a couple days if I remember, unless someone comes up with something better in the interim.

Answer 3

Okay, I think I found the actual answer. This prevents all freezing from occurring (because it keeps your game running in the background even if you tab out). Here's how you do it:

First, in your main file, have something like this for drawing:

function drawGame() {
  // Drawing code goes here

  requestAnimationFrame(drawGame);
}

requestAnimationFrame(drawGame);

The reason you put all your drawing code in requestAnimationFrame is because it's not called while the tab is not visible. This is good, because we only want to do physics when the tab is not visible, not rendering.

Next, create a file called worker.js that only contains these 3 lines of code:

setInterval(() => {
  postMessage(1); // IDE complains if we don't pass a useless parameter.
}, 1);

Then in your main file, have something like this:

let prevTime = 0;
let remainingTime = 0;

function gameLoop() {
  const elapsed = performance.now();

  let delta = (elapsed - prevTime) / 1000;
  prevTime = elapsed;

  remainingTime += deltaTime;
 
  while (remainingTime > PHYSICS_TIMESTEP) {
    doPhysics(PHYSICS_TIMESTEP);

    remainingTime -= PHYSICS_TIMESTEP;
  }
}

let intervalWorker = new Worker('./src/worker.js');
intervalWorker.onmessage = gameLoop;

The logic here is that the web worker still sends a "tick" message every 1 millisecond, even if the browser tab is not active. It's basically a hack that allows you to run fast intervals even if the browser tab isn't open. But the game loop will only be executed if it's not already running (the ready variable ensures this)

However, you still use an accumulator in your physics loop. This prevents the physics from running every frame. You still use a fixed timestep and calculate the delta using performance.now() math.

This is a bit complex I know, but it seems to work perfectly.