Mesh disappears at page refresh when using timeStamp to calculate position in render loop


I have a loop that is just moving a 3d letter by changing it’s position.x on every render. All is ok except, if I use timeStamp to calculate the position, every time I change the active tab in firefox and back again after a while, the mesh is not visible until, it seems, all the renders in the interval are replayed to determine the position again.

The code looks like something like this:

var clock = new THREE.Clock();
var speed = 2; //units a second
var delta = 0;

function render(){

  delta = clock.getDelta();
  object.position.x += speed * delta;

  renderer.render(scene, camera);

It has probably something to do with the way requestAnimationFrame is managed by the browser since I tried with babylonjs and I have exactly the same behavior as soon as I include a timeStamp in the calculation. If I use a constant position.x += 0.1; there is no problem.

Can someone explain what is happening here? I thought the requestAnimationFrame loop would be paused while the tab is not active but it seems it is executed somehow since I included a console.log which continues to log anyway.

Thank you

OK, the problem might be somewhere else since I can’t reproduce it by isolating the code.

When you switch back from an inactive tab, Clock.getDelta() produces a large time delta that often breaks application in various ways. E.g. collision detection fails or object are transformed/animated with extreme values.

Unfortunately, Clock is currently not able to handle this use case. However, I’ve created a PR some time ago with an alternative implementation for a timer class. It utilizes the Page Visibility API to avoid large time delta values. You might want to use THREE.Timer in your application to avoid the above error.

1 Like

When looking at the PRs code, I’ve forgot that I have enhanced one of the official three.js examples some time ago that shows how you can combine Clock with the Page Visibility API to avoid the above issue, too. Check out the code in:

1 Like

Thank you for your responses.

Yes, indeed, I saw in the log the values of timeStamp necessarily gets big but I thought it was not the problem but now I realize my assumption might be wrong (I’m doing a multiplication not a division lol). And since I display the next letter next to the last letter, it might be that I’m displaying in some invisible space.I’m going to check this and your solution.

I have been able to reproduce the case I will publish a repo if the proposed solution doesn’t solve the issue.

Thank you

It was that! Thank you again. I just added a test to ignore the animation process if timeStamp was superior to 1 and it did the trick. I was thinking too complicated when the problem was actually very simple.

@Mugen87, I have had a quick look to the timer solution, and I see why it is a better solution since “The class uses the Page Visibility API to avoid large time delta values when the app is inactive (e.g. tab switched or browser hidden).”

Thank you.


I let the example you gave run in a tab and forgot about it. When I clicked the tab back here is what I get:

There is a bug on how FF handles requestAnimationFram.

Thank you. I was actually investigating performance issues with a blank project and it seems, unfortunately, that FF has real issues.

This is my last post under this thread, since is marked solved.

requestAnimationFram.html (1.9 KB)
Run the attachment with different browsers to see have they implement RAF.

Any ? start a new thread, please.

This thread is marked as solved because I was doing a wrong calculation based on timestamp.

I have another thread on requestAnimationFrame:

I tried the linked test file. With FF I have one red X but none with chrome