- From: Shane Stephens <shans@google.com>
- Date: Thu, 6 Oct 2011 20:19:46 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, Rik Cabanier <cabanier@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, divya manian <divya.manian@gmail.com>, Brian Manthos <brianman@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAGTfzwT9e-447PJM5BrCuMd9cD8YOP4jc4J0YXzqNNfaEN10MQ@mail.gmail.com>
On Thu, Oct 6, 2011 at 7:23 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/6/11 8:26 PM, Shane Stephens wrote: > >> Whatever optimizations are made in the presence of a "display: none" >> subtree can >> continue to be made, with the results applying to animation state >> > > The problem is that the optimizations include "don't determine > 'animation-name'". > > Determining animation-name values isn't a big cost (see below). > > then directly animated properties on B should >> report with their current interpolated values when I call >> getComputedStyle. >> > > Interpolated between what and what? When should the animation be > considered as starting? Interpolated between the specified start and end values, starting when the style containing the 'animation-name' property applies. Yes, you'll need to calculate these too, but that's only in the presence of animations and only when the programmer asks for the current value. Animation resolution should be considered as having two phases - interpolation (which can run in the absence of a display as it depends only upon the specified start and end states and the current time value), and resolution (converting an interpolated value to a display value). For elements which are "display: none", interpolation need not apply except at certain well-defined occurrences (getComputedStyle calls, modifications of style rules that contain animation-name or transition-property, etc.) and resolution need never apply. i.e. by default all you're doing almost all of the time is tracking the timer. > > Basically I would propose that under the influence of "display: none" >> animations should continue to run and be allowed to start and stop. >> > > The starting and stopping is the problem. Why? Is there a reason why it's hard to detect a style change which might result in an animation starting and stopping? > (2) there are no unexpected performance overheads when running display: >> none animations >> > > But there are. If you want to determine the value of 'animation-name', you > have to perform selector matching on the descendants of the display:none > node. > Yes, but I think that's considering the problem incorrectly. Let's break it down: (1) on page load, every element is either display: none or not. - for those elements which are not display: none, do what we currently do - for those elements which are display: none, resolve just enough information to determine animation-name and transition-property values. Note that this is relatively simple as these properties don't inherit - in fact calling getComputedStyle on "display: none" subtrees yields this information. (2) The only events which are relevant to animations are: - getComputedStyle is called. This is a programmer-initiated cost. - The element stops being display: none. This is programmer-initiated, and probably similarly expensive whether animations are restarted or continued. - A style change occurs that modifies animation-name or transition-property. - A DOM change occurs, in which case redo the steps in (1). Nothing here is particularly expensive. If you want to be more specific, there will be a small overhead for animations on elements that start in display: none, a small overhead when the programmer initiates or cancels animations on elements that are display: none, and a small overhead when the programmer queries the state of animations that are in display: none. There will be no overhead for elements without animations, and no overhead for allowing animations to continue in display: none without querying them. Cheers, -Shane > > -Boris >
Received on Friday, 7 October 2011 03:20:21 UTC