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

Re: [RequestAnimationFrame] suspending callbacks in background pages

From: James Robinson <jamesr@google.com>
Date: Wed, 13 Jul 2011 01:44:11 -0700
Message-ID: <CAD73mdJ3VWOfeTV4N_yA08dFZvo9gZxSaye1nn0-=EQzShCmug@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-web-perf@w3.org, roc@ocallahan.org
On Wed, Jul 6, 2011 at 3:04 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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

This is a really interesting question.  Currently, in Safari on iOS
animations and transitions are suspended, including the related events, in
background tabs.  When the user switches back to the tab the
animation/transition resumes from the state it was in.  I'm not convinced
this behavior is the best in all cases, but it is an interesting idea.  I
think we should try to resolve what the expected behavior here is on

That said, my mental model for imperative animations is that the state
transitions (start/end/iteration) and the individual 'ticks' used to update
the animated values.  It doesn't make sense to 'tick' an animation and
update the interpolated values in a background tab.  I think the key
questions then are:
1.) Are authors depending on the 'tick' to trigger their state transition
logic, and if so
2.) Does the lack of the state transition logic trigger in background tabs
break pages?

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

Same for Chrome, at least for now.  In cases where it's ambiguous or
difficult to determine whether a tab is visible or not we'll always err on
the side of thinking tabs are visible.

- James

> -Boris
Received on Wednesday, 13 July 2011 08:44:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:08 UTC