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;
render();
function render(){
requestAnimationFrame(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.
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.
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:
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.
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).”
