- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 03 May 2011 17:19:55 -0400
- To: James Robinson <jamesr@google.com>
- CC: robert@ocallahan.org, public-web-perf@w3.org
On 5/3/11 5:05 PM, James Robinson wrote: > On Mon, May 2, 2011 at 11:05 PM, Robert O'Callahan <robert@ocallahan.org > 1) Resample declarative animations > 2) Run all animation callbacks with no associated element (we know > these need to run, best to run them first) > 3) While there are callbacks that have not run yet: > a) Flush restyles and layout > b) Compute the set of callbacks that have not run yet whose > elements are currently visible in the viewport > c) If that set is empty, go to step 4 > d) Otherwise, run all those callbacks > 4) Flush restyles and layout > 5) Paint > > This can help in some cases, but does not improve the worst case (for > example http://webstuff.nfshost.com/raf-make-visible.html where each > callback changes the visibility of another element by toggling the > style.display property between "blank" and ""). Sure. The worst case will be worst-case no matter what. > Any algorithm that promises not to miss any visible elements will have to recalculate > visibility once per callback No, I don't think Robert's algorithm needs that.... > or end up invoking the callback for elements that are definitely not visible. Yes. > I also think it's not obvious that invoking the callbacks will typically be cheaper than reevaluating > the visibility criteria. It's a hard call, yes. Note that my main desideratum here is that step (2) in Robert's steps happen before any of the step (3a)s. The exact substeps of step 3 are much more negotiable in my opinion. Can we agree that doing all callbacks that don't need visibility checking before any of the callbacks that do need visibility checking makes sense? > I think we can accommodate both your proposed algorithm and the current > WebKit implementation by defining the visibility requirement > sufficiently loosely so that the user agent can use potentially stale > style+information to decide that an element might be visible, so long as > it ensures that no callbacks are left pending with definitely visible > elements at the end of the algorithm. Sounds good to me. > The drawback of leaving this loose is that the order of callback > invocation will change depending on the details of the algorithm. Yes. We really do want to pin these details down at some point.... -Boris
Received on Tuesday, 3 May 2011 22:06:06 UTC