Large time delta values using Timer when page is not visible (in Firefox)

[mrxz]

Description

One of the documented features of the Timer class is to avoid large time deltas when the app/page is inactive using the Page Visibility API. This works fine under Chrome, but using Firefox I still observed large delta times. It turns out that requestAnimationFrame callbacks are still being fired by Firefox even when the page is not visible, albeit at an exponentially increasing interval (1s, 2s, 4s, 8s, etc...).

Obviously there's little the Timer can do about requestAnimationFrame still taking place, but it might be worth considering:

• Not letting any time elapse when it has detected that page is hidden (effectively guaranteeing delta = 0 for those "frames")
• Exposing whether or not the Timer is "running" so the user can skip update logic without having to replicate the visibility tracking logic
• Adding a note/warning to the Timer docs about this browser behaviour (not sure if other browsers beside Firefox do this)

One interesting example is webgl_morphtargets_sphere, which worked fine under Firefox, but actually regressed with the merge of #17912 where it switched to the Timer class.

Reproduction steps

1. Setup a Timer as per the docs (https://threejs.org/docs/index.html?q=Timer#examples/en/misc/Timer)
2. Log the delta time values
3. Switch to another tab for several seconds and return
4. Notice high delta times being logged (>=1s)

Code

const timer = new Timer();

function animate( timestamp ) {
	requestAnimationFrame( animate );

	timer.update();
	console.log(timer.getDelta()); // Reports >1s deltas under Firefox when page is hidden

	renderer.render( scene, camera );
}

Live example

The morphtargets_sphere example demonstrates the issue as it has been updated to use Timer instead of Clock + custom page visibility handling:

• morphtargets_sphere

Screenshots

Version

r160

Device

Desktop

Browser

Firefox

OS

Linux

[LeviPesin]

Not letting any time elapse when it has detected that page is hidden (effectively guaranteeing delta = 0 for those "frames")

Shouldn't this already be like that? 🤔 If not, this definitely should be fixed.

[Mugen87]

Not letting any time elapse when it has detected that page is hidden (effectively guaranteeing delta = 0 for those "frames")

This logic is already in place. The code uses a visibilitychange handler and checks for the document.hidden property.

Maybe the visibilitychange API is broken in Firefox. It shouldn't matter if requestAnimationFrame is executed because when you return to the page, Timer.reset() should be internally called by the visibilitychange handler which ensures a proper time delta.

[mrxz]

Maybe the visibilitychange API is broken in Firefox. It shouldn't matter if requestAnimationFrame is executed because when you return to the page, Timer.reset() should be internally called by the visibilitychange handler which ensures a proper time delta.

The visibilitychange API seems fine, it's really the requestAnimationFrame calls that trip up the Timer. Whenever the visibility changes back to visible it does indeed call Timer.reset() but this only ensures subsequent updates won't see an increased delta time since the last Timer.update(). It's the requestionAnimationFrame happening during the inactivity that show these high delta times.

To illustrate, consider the following sequence:

requestAnimationFrame
 - Timer.update() // delta = ~16ms
requestAnimationFrame
 - Timer.update() // delta = ~16ms
(...) 

[visibilitychange --> hidden]

requestAnimationFrame
 - Timer.update() // delta = ~1s
requestAnimationFrame
 - Timer.update() // delta = ~2s
requestAnimationFrame
 - Timer.update() // delta = ~4s      <--
                                        |
                                        | "skipped"
[visiblitychange --> visible]           |
 - Timer.reset()                      <--

requestAnimationFrame
 - Timer.update() // delta = ~16ms

Basically the Timer.update method behaves the exact same whether the page is visible or not. As such it happily computes elapsed time. The Timer.reset() only "skips" elapsed time since the last call to Timer.update().

[Mugen87]

Thanks for the additional explanation!

I think I would prefer to report this issue to Mozilla instead since the way requestAnimationFrame() behaves in Firefox is quite irritating. Not only for time computations but for other logic as well. It would be easier for developers if browser align their behavior and do not execute requestAnimationFrame() when browser tabs are inactive.

[gkjohnson]

This logic is already in place. The code uses a visibilitychange handler and checks for the document.hidden property.

It doesn't look like this is currently what's happening. Looking at the Timer class the document.hidden property is only checked and the timer is reset when the page is unhidden. There is no protection in the class for rAF calls firing while the page is hidden. So if FF is firing rAF calls while the page is hidden at a throttled rate then the Timer will be reporting large delta values until the page is unhidden and the timer is reset.

A check for document.hidden could be added to the update function so updating the delta is skipped if the page is hidden.

[Mugen87]

A check for document.hidden could be added to the update function so updating the delta is skipped if the page is hidden.

If you think that would work, I'm okay with a PR. I assume the reset() method is no longer required then?

Still, I would like to know from Mozilla why their requestAnimationFrame() differs from other browser.

[mrxz]

If you think that would work, I'm okay with a PR. I assume the reset() method is no longer required then?

I also think that would do the trick, though you'll need both the document.hidden check in update and the current reset(). The former to not count elapsed time while hidden and the latter to reset the point from which elapsed time is measured once visible again.

Still, I would like to know from Mozilla why their requestAnimationFrame() differs from other browser.

A quick search led me to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1548561#c6

[Mugen87]

Thanks for sharing the link to Bugzilla.

Seems it looked like they intended to align the implementation to Chrome but since the bug is stalled for five years, I doubt there will be any changes in the near future 😞 .

Like I said aligning the implementations is favorable. Apart from the mentioned inconsistencies resulting for developers, updating the animation loop in inactive tabs is bad for battery life and thus mobile devices. It's also critical when a tab is running a resource-demanding app (like 3D content) and then gets inactive, it still stresses the system and affects other tabs and applications. The more I think about this, the more I can't believe how Firefox handles inactive tabs. The issue at Bugzilla should have a higher priority.

[gkjohnson]

Like I said aligning the implementations is favorable. Apart from the mentioned inconsistencies resulting for developers,

Regardless of whether or not FF aligns the implementation, the rAF specification seems to allow the behavior that FF is using. So it's best to assume that rAF can run when a page is hidden. From MDN (emphasis mine):

calls are paused in most browsers when running in background tabs or hidden <iframe>s, in order to improve performance and battery life.

[Mugen87]

Yeah, too bad the specification does not explicitly disallow the execution of requestAnimationFrame().