On Thu, Oct 11, 2012 at 12:51 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/11/12 3:39 PM, Jatinder Mann wrote:
>
>> I'm glad the spec is very precise on this point and that it defines the
>> more efficient option.
>>
>
> The problem is that this option requires different behavior for
> requestAnimationFrame and declarative animation events, as far as I can
> tell.
>
That's correct. It's a bit of an issue for us as well - I believe we use a
backup timer to tick declarative animation events when RAF isn't going
which is a bit ugly but far from the end of the world.
>
> Keeping those in sync with each other is why Firefox has the behavior it
> does.
>
> Note that the difference in efficiency between "never fire" and "fire many
> seconds apart" is very very low in practice, so I don't think the
> efficiency argument is particularly strong.
>
I'm not so certain about this - firing every now and again means
potentially paging in all the resources needed for a frame. For instance,
if a canvas animation with lots of image resources is driven from RAF
firing it in the backgorund even rarely means making all of those image
resources available which means potentially re-decoding and re-uploading
them to the GPU and evicting resources that the visible tabs want to use.
Same goes for font data or any other cached resources. If you assume a
user has lots of tabs, this adds up quickly.
> Now maybe declarative animation events should _also_ not fire in
> background tabs. I would be a lot happier with that than in having
> requestAnimationFrame get out of sync with declarative animations.
That would be best! We should bring this up with with the WGs that are
responsible for animation events, CSS mainly, and see what they think.
We've had compat issues when we've accidentally stopped firing such events
in background tabs but haven't made a serious effort to work through them
with the standards bodies and see if we could find a solid solution.
- James
>
> -Boris
>
>