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

Re: [RequestAnimationFrame] suspending callbacks in background pages

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 06 Jul 2011 18:04:57 -0400
Message-ID: <4E14DC09.1020805@mit.edu>
To: public-web-perf@w3.org, roc@ocallahan.org
On 7/6/11 5:56 PM, Cameron McCormack wrote:
> James was saying on the call today that he hasn’t encountered content so
> far that would be tripped up by not invoking the callback in the
> background tab.
>
> Boris or Rob, do you have any further thoughts on whether it would be
> safe to mandate not invoking the callbacks in the background?

On a general note, we have tried to make requestAnimationFrame behave 
like other animations, including CSS animations, CSS transitions, and 
SMIL animations.

In particular, its behavior should probably be similar to 
animation/transition end events and SMIL events.

Is there agreement on that much?

If so, then the real question is whether all those events can be delayed 
indefinitely in background tabs.

> One thing that just occurred to me is that the Page Visibility spec is
> conservative in that implementations must not indicate that a page is
> invisible if it is in fact visible, but that it is allowed to indicate
> that a page is visible if it is not (since it may be difficult to know
> for sure).  It seems like, to be consistent with that, implementations
> would need to be allowed to continue firing requestAnimationFrame
> callbacks for background pages if they wanted.

Indeed.  The visibility state and the throttling are tied together in 
Gecko's case, for what it's worth.

-Boris
Received on Wednesday, 6 July 2011 22:05:35 UTC

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