When updating the cascade results between transitions and animations, if we
detect a change we force an update by taking the following steps:
a. Updating the animation generation on the restyle manager
b. Updating the animation generation on the collection
c. Iterating over all the properties animated by the collection and, for
each property that we can animate on the compositor, posting a restyle
event with the appropriate change hint (nsChangeHint_UpdateTransformLayer
or nsChangeHint_UpdateTransformOpacity)
d. Marking the collection as needing refreshes
e. Clearing the style rule refresh time so we generate a new style rule in
EnsureStyleRuleFor
As it turns out, the newly-added
AnimationCollection::RequestRestyle(RestyleType::Layer) already performs a, b,
d, and e. It also:
* Ensures we are observing the refresh driver if need be (should have no effect
in this case)
* Clears the last animation style update time on the pres context so that
subsequent calls to FlushPendingNotifications will update animation style
(it seems like we probably should have been doing this for changes to cascade
results anyway)
* Posts a restyle event with restyle hint eRestyle_CSSTransitions or
eRestyle_CSSAnimations
* Marks the document as needing a style flush (irrelevant since posting
a restyle event does this anyway)
The only missing piece that would prevent using RequestRestyle in place of this
code when updating cascade results is (c) from the list above. However, (c)
should not be necessary since ElementRestyler::AddLayerChangesForAnimation()
explicitly checks for out-of-date layer animation generation numbers and adds
the appropriate change hints (nsChangeHint_UpdateTransformLayer etc.) to the
change list.
We currently have a series of methods that clobber various bits of animation
state to force animations on layers to be updated. This aligns closely with
the restyle code introduced in this patch series.
By re-using RequestRestyle when updating animations on layers, not only should
we be able to simplify the code somewhat but, in future, we should also be able
to have Animation objects use the same mechanism to update layers during
a regular tick.
For example, currently we have a bug where when an animation starts after
a delay with the same value as the backwards fill then we don't send the
animation to the compositor right away (see
https://dxr.mozilla.org/mozilla-central/rev/d6ea652c579992daa9041cc9718bb7c6abefbc91/layout/style/test/test_animations_omta.html#287).
By adding this Restyle::Layer value we should be able to fix that in future.
EnsureStyleRuleFor contains logic for performing throttled updates to the style
rule but it is only used in one case: inside
nsTransitionManager::UpdateCascadeResults to determine what properties are
being animated by CSS animations.
We would like to remove throttling logic from EnsureStyleRuleFor altogether but
if that one case where it is currently used is run on every tick then removing
this logic could effectively mean we end up updating the style rule on every
tick. Fortunately nsTransitionManager::UpdateCascadeResults is only called
in the following cases:
1. From nsTransitionManager::StyleContextChanged (via
TransitionManager::UpdateCascadeResultsWithTransitions), when we are
processing style changes for transitions.
2. From AnimationCollection::EnsureStyleRuleFor (via
nsAnimationManager::MaybeUpdateCascadeResults and
nsTransitionManager::UpdateCascadeResultsWithAnimations), when we are
updating the animation style rule from CSS animations.
3. From nsAnimationManager::CheckAnimationRule (via
TransitionManager::UpdateCascadeResultsWithAnimationsToBeDestroyed), when
we are processing style changes for CSS animations.
None of these things should be happenning on a regular throttle-able tick so by
removing this logic we shouldn't be causing any additional work.
I have verified, using a test case that combines transitions and animations on
the same property, that we have the same behavior with regard to calling
EnsureStyleRuleFor both before and after this patch (specifically we avoid
calling it altogether while running only the transition but when the animation
starts and clobbers the transition we end up calling EnsureStyleRuleFor once on
each tick).
In preparation for ultimately being able to run animations without a manager,
this patch moves the request restyle code from FlushAnimations to
Animation::Tick. (Ultimately most of this functionality should move to the
KeyframeEffect but for now Animation is fine.)
This isn't actually needed for the only caller (which ensures that
frames with will-change: opacity create a stacking context), since
nsIFrame::BuildDisplayListForChild checks HasOpacity, which checks for
NS_STYLE_WILL_CHANGE_OPACITY. However, it's good to have the bit set
for consistency in case we use it elsewhere.
--HG--
extra : commitid : 2mKHVXRkjZL
We want to move the newly-introduced RequestRestyle call from FlushAnimations
to Animation::Tick. However, nsAnimationManager::CheckAnimationRule calls
Animation::Tick so this would cause us to start posting animation restyles
within a restyle.
Typically, Animations have an effect (currently there is only one type of
effect: KeyframeEffectReadOnly) and when there is any change in timing they
pass it down to their effect. However, the Animation is dependent on the
duration of the effect for determining if it is "finished" or not. As a result,
when an effect's timing changes, the owning Animation needs to know.
(The way this *should* work is that effects should tell their animation or
trigger some chain of events that causes animation's to update themselves.
However, the current implementation of effects is fairly primitive and does
not do this or even have a reference to the owning Animation. When we
implement the script API for updating the timing properties of effects we will
have to fix this but for now it is up to code in layout/style to update the
Animation when it touches the corresponding effect's timing.)
nsAnimationManager::CheckAnimationRule currently does this by calling
Animation::Tick() which ensures the Animation's finished state is updated
accordingly.
Ultimately we want to ensure that Animation::Tick is called exactly once per
frame (and at the appropriate point in that frame) so we'd like to remove this
call from CheckAnimationRule.
This patch achieves that by:
* Making Animation::SetEffect update the animation's timing - this is necessary
for animations that are created by CheckAnimationRule and will be
necessary when once we make Animation.effect writeable from script anyway.
* Calling Animation::SetEffect even for the case when we are updating the
existing effect.
Another side-effect of calling Animation::Tick within
nsAnimationManager::CheckAnimationRule is that CSSAnimation::Tick queues
events. There are some tests (e.g. layout/style/test/test_animations.html) that
assume that animationstart events are dispatched immediately when new
animations are created. That will change with bug 1134163 but for now we
should maintain this existing behavior since changing this might introduce
compatibility issues that are best dealt with as a separate bug rather than
blocking this refactoring. To that end, this patch also explicitly queues
animationstart events for newly-created animations.
nsTransitionManager::WillRefresh and nsAnimationManager::WillRefresh are now
identical and all methods they call exist on CommonAnimationManager so we
can unify them there.
The implementations of FlushAnimations and FlushTransitions should now be all
but equivalent so this patch combines them into a single implementation on
CommonAnimationManager.
Regarding some of the minor differences between the two methods:
* The combined implementation drops the check for an empty list of collections
found only in FlushTransitions. This seems like a very minor optimization
that could possibly cause us to fail to unregister from the refresh driver
if we forgot to do so when removing the last collection.
* The combined implementation uses the loop implementation from FlushAnimations
since it is more compact.
This patch also removes the extra nested scope since it doesn't seem necessary.
There are a couple of assertions that only exist in FlushTransitions (and not
FlushAnimations). This patch moves them to RequestRestyle since they appear to
apply to either transitions or animations equally. By eliminating this
difference between FlushTransitions and FlushAnimations we should then be
in a position to combine them into a common method on the base class.
This patch moves the additional checks (beyond those of Animation::CanThrottle)
from FlushAnimations/FlushTransitions to AnimationCollection::RequestRestyle.
These checks are on a per-collection basis hence it makes sense for the
collection to perform them. This also moves logic out of the managers which is
needed if we want to support script-based animations without introducing another
manager.
Ultimately we want to move throttling logic to AnimationCollection and
Animation::Tick (and later to KeyframeEffect::SetParentTime). This is so that
we can support script-generated animations without having to introduce yet
another manager.
To that end this patch introduces a method on AnimationCollection that can be
called from Animation::Tick to perform the necessary notifications needed to
update style.
Later in this patch series we will extend RequestRestyle to incorporate more of
the throttling logic and further extend it to cover some of the other
notifications such as updating layers.
This patch tracks whether or not we have already posted a restyle for animation
to avoid making redundant calls. Calls to nsIDocument::SetNeedStyleFlush are
cheap and more difficult to detect when they have completed so we don't filter
redundant calls in the Restyle::Throttled case.
If mHasPendingAnimationRestyle is set and AnimationCommon::EnsureStyleRuleFor
is *never* called then we could arrive at situation where we fail to make post
further restyles for animation.
I have verified that if we fail to reset mHasPendingAnimationRestyle at the
appropriate point (e.g. resetting it at the end of EnsureStyleRuleFor *after*
the early-returns) then a number of existing tests fail.
Furthermore, I have observed that it is reset by the beginning of each tick
in almost every case except for a few instances of browser mochitests such as
browser/components/customizableui/test/browser_1007336_lwthemes_in_customize_mode.js.
In this case, during the async cleanup of the test, we have an opacity
transition on a vbox element that becomes display:none and appears to be skipped
during restyling. However, even in this case, EnsureStyleRuleFor is called
within one or at most two ticks and mHasPendingAnimationRestyle flag is cleared
(i.e. it does not get stuck).
In FlushTransitions and FlushAnimations we use different mechanisms to see if a
transition/animation can be throttled on the current tick.
FlushTransitions calls Animation::CanThrottle whilst FlushAnimations calls
EnsureStyleRuleFor and checks if the rule has changed or not. These are not as
completely different as they might seem at first since, internally,
EnsureStyleRuleFor calls Animation::CanThrottle.
We would like to unify this behavior and simply use Animation::CanThrottle in
FlushAnimations as we do in FlushTransitions.
First, however, we have to account for the differences in these approaches:
1. Using the result of EnsureStyleRuleFor means we may *not* call
PostRestyleForAnimation if an animation collection's mNeedsRefreshes member
is false.
This member is false when all animations have finished (or there are no
animations in the collection). In this case EnsureStyleRuleFor will not
update the style rule and we will end up assuming the tick can be throttled.
*However*, in the case that all animations are finished
Animation::CanThrottle will *also* return true (technically it will return
false until we compose style for the first time after becoming finished but
beyond that one moment it will return true) so skipping this check by using
Animation::CanThrottle instead of EnsureStyleRuleFor should not
make a significant difference.
2. Using the result of EnsureStyleRuleFor will mean that if we have already
updated the style rule within a given tick we will avoid calling
PostRestyleForAnimation (and call SetNeedStyleFlush instead). This can
happen the first time we call FlushAnimations from
PresShell::FlushPendingNotifications. (When we call FlushAnimations from
nsAnimationManager::WillRefresh mStyleRuleRefreshTime will be stale and we
won't apply this optimization. Furthermore after the first call to
PresShell::FlushPendingNotifications we will typically skip calling
FlushAnimations since PresShell::StyleUpdateForAllAnimationsIsUpToDate will
typically return true).
This seems like a possibly useful optimization although it is surprising we
don't do the same for transitions. Note that this optimization applies
regardless of whether we are performing a throttleable flush or not. That is,
even if we pass CommonAnimationManager::Cannot_Throttle we will still end up
throttling the tick in this case. Furthermore, we will mark the document as
needing a style flush even though this does not appear to be necessary.
This patch copies this optimization (checking if mStyleRuleRefreshTime) to
FlushAnimations so we can maintain this behavior when calling
Animation::CanThrottle instead of EnsureStyleRuleFor. It also applies the
same behavior to FlushTransitions for consistency (and so we can later
combine FlushAnimations and FlushTransitions).
Note that we apply this optimization *before* calling Tick since it should
only apply once we have already Tick'ed the animations in the collection.
We will first hit FlushAnimations as a result of the refresh driver calling
nsAnimationManager/nsTransitionManager::WillRefresh at which point
mStyleRuleRefreshTime should be stale. Using this order not only saves
redundant work but also makes moving the restyle code to Animation later on
more straightforward.
(In future we will divorce WillRefresh and FlushAnimations and only call
Tick in WillRefresh and only perform this optimization FlushAnimations.)
3. Using the result of EnsureStyleRuleFor means that while checking if we can
throttle or not we also update the style rule in FlushAnimations. That seems
like an odd side-effect particularly since FlushTransitions doesn't do the
same thing.
There is no longer anything in FlushTransitions that modifies the set of
transitions. I believe this changed as of bug 960465, specifically changeset
https://hg.mozilla.org/mozilla-central/rev/b2ee72589c18, so that this code is
no longer needed.
By removing this we can further align FlushAnimations and FlushTransitions.
Brian Birtles
L. David Baron
Ms2ger
Robert O'Callahan
Wes Kocher
Ryan VanderMeulen
Ben Tian
William Chen
Ehsan Akhgari
Gijs Kruitbosch
Arthur Edelstein
Aryeh Gregor
Masayuki Nakano
Jonathan Kew
Kartikaya Gupta
Mike Hommey
Tom Tromey
Arnaud Bienner
Cameron McCormack
Mason Chang
Xidorn Quan
Francois Marier
Benoit Girard