Re: [RequestAnimationFrame] suspending callbacks in background pages

On 7/13/11 4:44 AM, James Robinson wrote:
> On Wed, Jul 6, 2011 at 3:04 PM, Boris Zbarsky <bzbarsky@mit.edu
> <mailto:bzbarsky@mit.edu>> wrote:
>     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.

That includes SMIL?

What about desktop Safari?

> When the user switches back to the tab the
> animation/transition resumes from the state it was in.

So you're actually freezing the monotonic clock, not just skipping frames?

> I think we should try to resolve what the expected
> behavior here is on public-fx.

That seems fine, but I think we need to do that before we can take 
requestAnimationFrame to CR, or make the requestAnimationFrame 
definition sufficiently flexible to allow coordination with public-fx 
after the fact.

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

I'm not sure where the verb was supposed to go in that sentence... is it 
"are" before "used"?

> It doesn't make sense to 'tick' an animation and update the interpolated values in a background tab.

There is no need to update the interpolated values to fire end events, note.

> 1.) Are authors depending on the 'tick' to trigger their state
> transition logic

No idea about the 'tick', but I believe authors do rely on end events of 
various sorts for various purposes...

> 2.) Does the lack of the state transition logic trigger in background
> tabs break pages?

This is an excellent question, yes.

Another question is whether the lack of end events violates the specs 
that define those events.  And if so, how we proceed.

-Boris

Received on Wednesday, 27 July 2011 05:57:26 UTC