Time leakage bug in anime.js when looping animations

[mrxz]

Description:
Every time an animation loops the excess time is ignored. This leads to "time leakage" which can accumulate over time or cause issues when high delta times occur for a given tick. This can easily be triggered by giving focus to another tab, which causes browsers to reduce or halt the rAF until the user clicks back again.

Real-world case where this bug causes multiple entities with the same looping animations randomly offset from each other to end up synchronized. 3DStreet/3dstreet#364

This is a known bug in anime.js (juliangarnier/anime#561) and is also present in A-Frame's fork. Filing this bug here instead for easier discovery in case other people face this issue.

• A-Frame Version: master
• Platform / Device: any
• Reproducible Code Snippet or URL: https://glitch.com/edit/#!/aspiring-honored-dragonfruit

[Algorush]

I looked at the code a little and discovered that when returning from another tab, the time is not counted, since the activeInstances array (elements with applied animation) is always empty. I still don't understand why this is so. Maybe thats the reason. Here: https://github.com/juliangarnier/anime/blob/3ebfd913a04f7dc59cc3d52e38275272a5a12ae6/src/index.js#L881

And also instance are added to the activeInstances array only inside the instance.play function, which is never called on test scenes: https://github.com/juliangarnier/anime/blob/3ebfd913a04f7dc59cc3d52e38275272a5a12ae6/src/index.js#L1125

[mrxz]

Note that A-frame uses this fork: https://github.com/supermedium/anime/tree/master, which is an older version and contains some custom modifications.

I believe the reason instance.play isn't called and activeInstances remains empty is that A-Frame manually invokes the tick function for animations instead of letting anime.js handle it. Part of the reason is that by default anime.js would use its own requestAnimationFrame loop, which wouldn't work during a WebXR session.

Effectively there are two "issues" at play:

1. Whenever an animation loops, excess delta time is leaked
2. The first tick after a tab regains focus will contain a (very) high delta time which isn't filtered

So it seems anime.js has measures to combat the latter, but due to the way A-Frame uses it, that doesn't apply. Ultimately fixing the former should make the second one a non-issue. And it would ensure other causes for high delta times don't case issues either.

Regardless, it might be a good idea to implement a similar workaround directly in A-Frame.It's difficult to make logic resilient against high delta times and it's not particularly uncommon for users to tab away. Of course such a change has both pros and cons 🤔

[dmarcos]

Any PRs to address super welcome

[vincentfretin]

There is a recent discussion over mrdoob/three.js#30497 about replacing Clock by Timer and Timer reset the delta when you come back to the tab if I understand that correctly. That would fix that issue, right?

[mrxz]

There is a recent discussion over mrdoob/three.js#30497 about replacing Clock by Timer and Timer reset the delta when you come back to the tab if I understand that correctly. That would fix that issue, right?

It would filter out large deltas caused by tabbing in and out. But the underlying time leakage bug would still be there. So if you have an animation that is looping, it will start to drift over time. Or if a large delta is introduce in other ways, you'd still face the same issue.

One common point where this can happen is entering/exiting an immersive session. Ideally we'd switch over to the predictedDisplayTime for immersive sessions in which case it might make sense to suppress the delta caused by the transition in the same way as is done for pageVisibility.

It would still be an improvement to use Timer, as for most scenes a small amount of time leakage isn't an issue. Though there are also cases where you might not want to "skip" large deltas.

[vincentfretin]

#5800 replaces Clock by Timer now that Clock is deprecated in r183