Re: [css3-animations] display:none, visibility:hidden and animations

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
>