W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

Re: [RequestAnimationFrame] Processing model defined

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 27 Jul 2011 02:04:42 -0400
Message-ID: <4E2FAA7A.2070801@mit.edu>
To: public-web-perf@w3.org
On 7/27/11 1:23 AM, James Robinson wrote:
> The one point of potential interest or controversy is the expected
> callback behavior for background tabs.  The processing model I've
> specified says that callbacks do not fire at all when a document is
> hidden

I'd like to reiterate that I don't think this is acceptable unless _all_ 
web platform animation-related callbacks (SMIL, CSS transitions, CSS 
animations, etc) have that as an acceptable behavior.

>   We've discussed this a few times on the list before and absent any new
> data I think that not firing callbacks is a better default behavior for
> users since it uses the least CPU for background content.

Of course.  But that's not the only consideration here; API and platform 
consistency as well as existing author expectations need to be factored 
in too.

> We can revisit this if we get any new data, for example if we find evidence of
> compatibility issues with suppressing the callbacks completely.

We have compatibility issues right now, even with just the backoff 
behavior Firefox has.  For example, sites that use jQuery animations to 
move things off an interval timer go completely haywire if you stick 
them in a background tab for a bit in current Firefox or Chrome, and the 
effect is somewhat worse in Chrome due to the fact that it completely 
pauses the callbacks.  See http://api.jquery.com/animate/#notes-0 second 
bullet point -- sites violate the advice of that note all the time; 
we've had at least 3 separate bug reports on Firefox about it so far 
that I've seen.  It's enough of a problem that I've been seriously 
considering switching back from the exponential backoff we do now to 
some fixed but slow heartbeat rate.

-Boris
Received on Wednesday, 27 July 2011 06:05:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC