2

See Code: http://jsbin.com/amavud/2

Problem: In browsers which implement requestAnimationFrame, when tab with animation is set to background (new tab opened), animation timing is borked.

Question: My understanding of requestAnimationFrame is that animation should stop when moved to a background tab, but from this example, it seems like webkit browsers complete the current animation and THEN stop.

The problem seems to come from the fact that the second and third balls need a delay before moving, requiring a setTimeout. Is there a problem with the way requestAnimationFrame is implemented in jQuery, or am I just coding this wrong?

I've tried to follow the advice on http://api.jquery.com/animate/ using delay() and queue(), but can't seem to get the right effect.

andrewheins
  • 788
  • 2
  • 9
  • 17
  • I've found a temporary solution - use an old version of jQuery before the requestAnimationFrame commit. It doesn't actually solve the problem of how to deal with background animations with the new commit, but it does make this specific animation work. – andrewheins Jul 19 '11 at 13:55

2 Answers2

0

I don't think is the way you're coding but the fact that requestAnimationFrame is NOT working in background, so it stops. Or at least this is what Paul Irish is saying in bold "if you're running the animation loop in a tab that's not visible, the browser won't keep it running". http://paulirish.com/2011/requestanimationframe-for-smart-animating/

Since this js is not even working in any browser I don't know why you want to implement it.

Snowalker
  • 309
  • 1
  • 7
  • 16
0

Using an old version of jQuery before requestAnimationFrame (1.4.2). Seems wrong. I don't think rAF is properly implemented yet.

andrewheins
  • 788
  • 2
  • 9
  • 17