Re: [RequestAnimationFrame] Processing model defined

On 7/27/11 2:43 AM, James Robinson wrote:
> I don't think that CSS animation/transition events are really the same
> thing here

The key thing that's the same is whether the animation is progressing or 
not.  If the animation timeline is progressing, then the CSS 
animation/transition events need to get fired.  If it's not, then they 
don't.

So that's the first thing we need to figure out here: is the animation 
timeline progressing in a background tab?  Some of your comments before 
made it sound like in WebKit it's not, except your text below makes it 
sound like it is...  In Gecko, the animation timeline progresses as normal.

If the animation timeline is progressing, then pages presumably would 
like to know when the scripted animation should be "done" just like they 
want to know it for CSS transitions/animations.  Right now the only way 
they can know that is to get a requestAnimationFrame "tick" with a time 
far enough into the animation, since the browser doesn't actually know 
when the page considers the animation to be done.

> T + 0ms: click, click handler registers a requestAnimationFrame callback
> and a 100ms setTimeout

This doesn't seem to be how sites (and jQuery) are using 
requestAnimationFrame in practice; instead they're looking at what time 
it is when the requestAnimationFrame callback is called and just not 
calling requestAnimationFrame again in their callback if that time is 
far enough in the future.

> If CSS animations/transitions or SMIL were to expose a tick callback
> then we should definitely be explicit.  Typically, though, you don't
> need one with a declarative animation system.

Right.  I don't believe SMIL exposes a tick callback, just begin/end/repeat.

> That's useful information to have.  Can you link to some of these bugs
> so we can look in more detail at what the page was doing?

https://bugzilla.mozilla.org/show_bug.cgi?id=671600 is one.  I'm having 
trouble locating the others right this second; this one conveniently had 
the jQuery link in the bug, making it findable.

> We haven't seen a similar incidence in Chrome so far

Were you looking?  ;)

Here you go (mistitled, and the answer is wrong, but it's about this 
issue and explicitly about Chrome):
http://stackoverflow.com/questions/6737067/jquery-setinterval-too-fast-when-coming-from-another-tab

The code in that question is _exactly_ what people are doing, by the way.

> but some of that might be due  to the fact that we also aggressively throttle setTimeout() and
> setInterval() based timers in background tabs (to a floor of 1000ms).

So does Gecko.  And no, that's not the problem in this case.

>   There's also something to be said for author education such as the
> link you posted.

Sure; good luck convincing every single person using jQuery animations 
on the web to suddenly change their code because jQuery started using 
requestAnimationFrame for their animations and thus completely changed 
the semantics of their animate() function....

-Boris

Received on Wednesday, 27 July 2011 15:23:37 UTC