Re: [AnimationRequestFrame] Initial editor's draft of AnimationRequestFrame spec available

On Mon, May 2, 2011 at 7:15 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/2/11 10:06 PM, Jonas Sicking wrote:
>>
>> On the other hand, if you do want to implement the feature James is
>> talking about here, you'd end up with:
>>
>> 1)  Resample declarative animations.
>> 2)  Run animation frame callbacks if any.
>> 3)  Process pending restyles, if any.
>> 4)  Do relayout, if needed.
>> 5)  If something with an animationcallback has been moved into the
>> screen, goto 2.
>
> Not quite, because if we require that things that are not in the viewport
> NOT have their animation frame callbacks called and that animation frame
> callbacks are called in order they were set up, then we need to do relayout
> before running animation frame callbacks for anything with an element
> attached in step 2.  In other words, the algorithm would then need to look
> like this:
>
> 1)  Resample declarative animations.
> 2)  While (have animation frame callbacks that might need to run)
>   I) If next callback has element, flush style and layout
>  II) Run next callback
> 3)  Process restyles.
> 4)  Do relayout.

Only if we value "stable order of execution" higher than "best performance".

I think it could work to only guarantee order of callbacks on
callbacks that aren't registered for a specific element. For ones that
are only called on specific elements you aren't guaranteed to be
called in a specific order anyway since not all callbacks are going to
be called every time.

Of course, it'd still be a good idea for implementations to try to
follow a stable order as to make browser behavior as consistent as
possible cross browsers.

/ Jonas

Received on Tuesday, 3 May 2011 23:53:21 UTC