- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 3 May 2011 16:52:06 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org, "Robert O'Callahan" <robert@ocallahan.org>
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