Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pause animation when tab loses focus. Fixes bug #9381 #446

Closed
wants to merge 3 commits into from

Conversation

Projects
None yet
5 participants
@louisremi
Copy link
Contributor

commented Jul 26, 2011

Fixes http://bugs.jquery.com/ticket/9381

Animation frameworks have to deal with the problems that occur when requestAnimationFrame powers the animation loop and the tab loses focus. The general idea is to artificially limit the interval between two animation ticks.
This was illustrated in Seth Ladd's "Intro to HTML5 Game Development" during Google I/O 2011: http://io-2011-html5-games-hr.appspot.com/#36
He calculates the time delta between two animation ticks and limit this value to 60ms

var dT = Math.min( now - prevNow, 60 );

The way jQuery animations work is more complex than Seth's ones, as animations aren't based on the time delta between the previous tick and the current one, but between the beginning of the animation (startTime) and the current one. The only way to limit the interval between two ticks is to move the value of startTime forward in time.

With this 5loc patch, jQuery detects when the interval takes longer than usual and moves startTime accordingly to effectively pause the animation. Once the tab is focused again, the animation continues where it stopped.

@dmethvin

This comment has been minimized.

Copy link

commented on src/effects.js in dc5e7be Jul 26, 2011

Where does the 16 come from?

This comment has been minimized.

Copy link
Owner

replied Jul 26, 2011

16ms is the minimum interval between two frames when using requestAnimationFrame. We are currently using 13ms in our setInterval, but this would work as well. "10 times" is our safety margin, as the animation could be heavy and run at a lower framerate.
So the "abnormal interval" we detect here is anything above 16 * 10 = 160ms
I had to choose a value under 250ms since requestAnimationFrame runs at 4fps in inactive tabs

@jaubourg

This comment has been minimized.

Copy link
Member

commented Jul 26, 2011

Let me get this straight: we change how animations in jQuery are scheduled because Firefox cannot properly handle timeouts when tab is not focussed? I'm sorry but I find that saddening to say the least.

@louisremi

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2011

The problem will be the same in every browser implementing requestAnimationFrame. It's just that switching back to setInterval is not the solution, as it won't work in Firefox (other browsers could adopt the same behavior).
I don't think this raf flag was a good idea anyway. I doubt much developers would have ever heard about it and really understood what it was for.
This patch fixes a problem inherent to requestAnimationFrame, without requiring devs to worry about it :-)

@jaubourg

This comment has been minimized.

Copy link
Member

commented Jul 26, 2011

Sadly they still do: they cannot rely on animations callbacks to be fired after a reasonable amount of time. Even worse, in FF, setTimeout's contract of being called as soon as possible after the delay is over is broken when tab is not focussed which is a bug, not a feature (why on earth would non-rendering tasks be delayed is beyond me): it becomes impossible to schedule anything in a page properly -- at least as properly as we already can -- and this bug will have to be fixed, that much is obvious.

Now, to the task at hand, we're not talking about choosing between raf and setInterval, but about architecturing the animation system properly (that is separate rendering and scheduling). The current situation only demonstrates that raf should be used for rendering alone and scheduling should be done in parallel, with timers, and that FF decision to delay timers is as wrong as it can get. Bad design decisions are occuring right now and it's not time to "guess" a proper threshold to detect if we're being delayed or not, it's time to state that, while raf not being fired is fine and makes sense, delaying timers is a non-sense.

@louisremi

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2011

Apparently Chrome already behaves in the same way: http://code.google.com/p/chromium/issues/detail?id=66078
And the minimum interval in Firefox is actually 1s, not 250ms: https://bugzilla.mozilla.org/show_bug.cgi?id=633421

@jaubourg

This comment has been minimized.

Copy link
Member

commented Jul 26, 2011

Then I give up on web development altogether because it'll become a game of guessing when Mr. Browser will be kind enough to fire my callbacks. Delaying timers should be a choice, not forced down our throat in circumstances the web app has no control over. I've rarely been as infuriated against browser devs as I am right now.

Nothing against you louisremi, mind you, you're just the messenger ;)

@curiousdannii

This comment has been minimized.

Copy link

commented Jul 26, 2011

Yet more evidence that the Chrome devs only care about the web if the web is obedient to them...

Anyone know if worker timers are affected?

@Ivanca

This comment has been minimized.

Copy link

commented Aug 4, 2011

Why do callbacks of animations do -actually- wait for the animation to finish? Inside jQuery it should be just a timeout that stops the animation, move the object to the final position and then executes the callback.

I always do this because animation callbacks are not reliable (specially when using the jQuery easing plugin)

@louisremi

This comment has been minimized.

Copy link
Contributor Author

commented Aug 5, 2011

No, animation callbacks ARE reliable because they are not fired by a setTimeout, but when the animation is actually finished.
Only a reduced test-case could prove this wrong.

@dmethvin

This comment has been minimized.

Copy link
Member

commented Sep 2, 2011

I'm going to close this PR since it's likely we'll need to rethink and rework the animation timer/rAF issue when it finally lands.

@dmethvin dmethvin closed this Sep 2, 2011

@lock lock bot locked as resolved and limited conversation to collaborators Jan 21, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.