Re: [RequestAnimationFrame] Processing model defined

On Wed, Jul 27, 2011 at 8:23 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.
>

In WebKit (that is in Chrome, desktop Safari) animations keep going
regardless of whether the tab is in the foreground or background.  I
previously mentioned that Mobile Safari on iOS has (or possibly had) a
different behavior where animations were completely suspended in background
tabs as another possible behavior, to the best of my knowledge that code has
never made it into the mainline WebKit branch, and I certainly can't speak
for Apple.


> 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.


I can believe that a lot of people do that.  That pattern is fine, however,
since in most cases you don't really care about the 'end' event.  In fact,
I'd wager that most people who use CSS animations/transitions don't register
for the 'end' event at all.  It's only when the author does want to do
something at the animation's termination that this becomes an issue.

>
>
>  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<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<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.


Some people writing buggy code and posting on stackoverflow is not the same
thing as seeing compat issues causing user unhappiness.  No new API will
every be used correctly by every single author on the web, it's a matter of
balancing potential misuse of the API against the potential benefits from
defining given semantics.  There are some real concrete benefits to not
firing requestAnimationFrame callbacks at all in background tabs and I'd
like to try to realize those, even if there are a few bumps along the road.


>
>
>  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.


It does partially mitigate that particular pattern, however, since the page
can't enqueue as many requestAnimationFrame callbacks if the setInterval()
is running at a lower rate.


>
>   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....
>

It's a misuse of .animate().  We can only really improve the web APIs we
expose and try to educate authors, within reason.  I don't think we can do
all that much if a third party library provides an API and then users of
that library misuse the library's API.

- James

>
> -Boris
>