Re: [RequestAnimationFrame] Processing model defined

On Wed, Jul 27, 2011 at 11:13 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/28/11 1:54 AM, James Robinson wrote:
>
>> 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
>>
>
> Ah, ok.  That was the missing piece, thanks.
>
>
>     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
>>
>
> As long as you actually get a callback at some point.  If you never do
> because your're in a background tab, until the user switches to your tab,
> then suddenly you do get a callback and your animation runs, which is pretty
> unexpected.
>
>
>  It's only when the author does want to do something at the animation's
>> termination that this becomes an issue.
>>
>
> I believe jQuery does in fact do things from the animation's termination,
> but I haven't sorted through their code in detail.  It may be simpler to
> just ask them....
>
>
>  Some people writing buggy code and posting on stackoverflow is not the
>> same thing as seeing compat issues causing user unhappiness.
>>
>
> Again, this is the most common way I expect people to use this API, since
> it's the way jQuery exposes.  And jQuery-animated transitions handling at
> some interval are a pretty common effect on the web.
>
> The user-facing effect of the jQuery behavior is that when you switch to
> the background tab suddenly however many animations were buffered up (figure
> one per every few seconds that the user was not looking at the tab) all run
> at once, leading to weird bouncing behavior and a pegged CPU for a while.
>
> Now maybe we can get jQuery fixed here somehow.  It's not clear to me how,
> since I'm not quite sure what behavior they're _trying_ to implement.
>
>
>  No new API will every be used correctly by every single author on the web
>>
>
> Yes, but in this case there's a really _easy_ way to use this API
> "incorrectly".
>
>
>  There are some real concrete benefits to not firing requestAnimationFrame
>> callbacks at all in
>> background tabs
>>
>
> What are those benefits compared to, say, firing them once a minute? And
> yes, I realize that 0 cpu usage is better than "a very small amount", but at
> once a minute we're talking a _very_ small amount.


>
>  and I'd like to try to realize those, even if there are
>> a few bumps along the road.
>>
>
> I wouldn't characterize "jQuery's use of the API is broken by design if we
> do this behavior" as a "bump along the road"....  Either the behavior of the
> API needs to change or jQuery's behavior needs to change.  In my opinion.
>
>
>  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.
>>
>
> Well, sure.  But all the code I've seen using this pattern uses an interval
> > 1s anyway, since the idea is to every so often animate something on the
> page and most people don't consider < 1s to be "every so often".
>
>
>  It's a misuse of .animate()
>>
>
> It wasn't until animate() suddenly got changed to use
> requestAnimationFrame.  There was deployed code that was just fine, and now
> it's broken.  That's not OK.
>
>
>  I don't think we can
>> do all that much if a third party library provides an API
>>
>
> Well, we can try to get the third-party library to fix the way it uses the
> APIs we provide, and talk to its authors about how our APIs would be easier
> for them to avoid misusing.
>
> Or put another way, we _do_ want jQuery to build animate() on top of
> requestAnimationFrame and we do _not_ want to break the huge amount of
> deployed content that's using animate() and was perfectly fine with the
> behavior it used to have.  The question is how animate() can implement the
> behavior it used to have on top of requestAnimationFrame.
>

That's a good way to put it.  One counterargument is that jQuery (or other
authors) could implement the behavior you describe with a combination of
requestAnimationFrame, page visibility, and timers.

I'm sorry I let this thread die for so long.  You've raised a lot of good
points and we plan to experiment some more in Chrome and relay our results
back to the group.  I would still personally prefer not to invoke callbacks
in the background, but that might be a pipe dream.

- James

>
> -Boris
>