We always call TElement::get_animation_rules() for both cascade levels while
there are animations or transitions, so we want to handle the following cases:
1. Have both CascadeLevel::Animations and CascadeLevel::Transitions:
* We use EffectSet::mPropertiesForAnimationsLevel to filter out
CascadeLevel::Transitions because transitions are suppressed when both
are presented.
2. Have CascadeLevel::Animations, but don't have CascadeLevel::Transitions:
* We also use EffectSet::mPropertiesForAnimationsLevel to filter out
the unwanted CascadeLevel::Transitions.
3. Don't Have CascadeLevel::Animations, but have CascadeLevel::Transitions:
* EffectSet::mPropertiesForAnimationsLevel doesn't work for this case.
In Gecko, mElementsToRestyle can help us to filter out the unwanted
CascadeLevel::Animations, However, mElementsToRestyle is cleared in
Pre-Traversal, so now we rely on the cascade ordering of transitions to
override animations. I think we still need to optimize this eventually.
4. No animations:
* EffectSet helps us to check if there is any animations/transitions.
Therefore, we need to call MaybeUpdateCascadeResults(), which updates
mPropertiesForAnimationsLevel, in Pre-Traversal.
MozReview-Commit-ID: IHYw56EX7Ta
--HG--
extra : rebase_source : 4d5eb1335cdce9bf54c9646db1fba72ca3f2c70b
We no longer need separate time for cascade levels respectively since we do
send all type of animations on the same element to the compositor regardless
of cascade level.
MozReview-Commit-ID: 7cGQGE3yHvm
--HG--
extra : rebase_source : 009e0cc510faea2b83760c141da545e87de8aeaf
It's just for transform animations on the compositor.
MozReview-Commit-ID: 288CcG4kko4
--HG--
extra : rebase_source : 943f67beeecd3c05b7ae2c6608b7a725c47f2b23
We need to call GetEffectSet() from Servo code, which passes an
immutable reference to GeckoElement, so it's better to make dom::Element
const.
MozReview-Commit-ID: GqQEB7BwkJA
--HG--
extra : rebase_source : 4b025f56949d8327781be26d1607e6d9f4668f2f
1. Introduce ServoAnimationRule, which is an equivalent of AnimValuesStyleRule.
2. Wrap ServoAnimationRule and AnimValuesStyleRule into a struct, and
use it as the parameter of Animation::ComposeStyle and
KeyframeEffectReadOnly::ComposeStyle.
3. Uncompute the RawServoAnimationValues in ServoAnimationRule when we
need it.
MozReview-Commit-ID: HahXDYBCAhH
--HG--
extra : rebase_source : cd8c6f3a8409abf97f04af888953ff0e77d98348
Currently this function is used when an nsIFrame is generated by reframing. In
reframing, we call EffectCompositor::UpdateEffectProperties, as a result, we
have to clear the base style that we resolved once. So, for such cases, we need
to re-resolve the base style with the style context that is associated with the
nsIFrame.
MozReview-Commit-ID: F90OuF44SPI
--HG--
extra : rebase_source : ef163681f49b11887d4ea546d28a9fd217251d97
This patch adds a hashtable to store the non-animated base style of each
property in EffectSet class if the following conditions are met.
1) the effect is the lowest priority of the effect
2) the effect is additive or accumulative
The styles are stored as StyleAnimationValue objects since it's handy class to
store a CSS value for different properties.
MozReview-Commit-ID: 1MZV7MnqzfI
This patch also makes composite order lowest to highest, as a result we also
need to replace mWinsInCascade checks with the the properties.
The mWinsInCascade membed itself will be removed in a subsequent patch.
Now we call RequestRestyle(Layer) respectively for transition and animation,
so a test case in test_restyles.html works as expected.
And now lower-priority animations are also sent to the compositor so this patch
fixed some tests in test_running_on_compositor.html and
test_animation_performance_warning.html
MozReview-Commit-ID: BchUsJbmatg
--HG--
extra : rebase_source : ff295aecb08bb672ac5f02e26e37a4ea4f3eb7c0
AnimationCollection keeps a TimeStamp that records the refresh driver time when
the animation style rule was last updated. This is used for two purposes:
1. To determine when the style rule is out of date.
2. For animations that are partially throttled on the main thread, e.g.
transform animations that affect the scrollable region which we update every
200ms on the main thread.
In this bug we are removing all the overlapping bits of state used to track if
animations are up-to-date or not and replacing them with the hashmap stored on
the EffectCompositor which tracks which animations are currently in need of an
update. As a result, we would like to remove this style rule refresh time.
However, we will need something for case (2) from above.
This patch adds an animation rule refresh time to the EffectSet purely for the
purposes of partially-throttled animations so that we can later remove the style
rule refresh time from AnimationCollection.
As we gradually move logic from layout/style/AnimationCommon.cpp to
dom/animation/EffectSet and EffectCompositor it makes sense to let this class
live in its own file inside dom/animation where it is used.
--HG--
extra : rebase_source : aed0632a19800e0ef9d8fe1d03d0364bf1ccc4dc
This is needed in order to support script-generated animations since they do not
belong to any AnimationCollection.
This patch adopts the naming "animation rule" over "style rule". Currently we
are inconsistent about this (e.g. GetAnimationRule vs EnsureStyleRuleFor).
We don't do a mass rename here but just a few places near where we're touching.
Many of the other references to "style rule" will be revised in this bug or
related bugs so we can fix those references when we come to them.
--HG--
extra : rebase_source : e1f824029b39960915e056328447de256b6c1c6d
There are three situations when the cascade results of effects needs to be
updated.
1. The sets of effects (animations) has changed.
2. One or more effects have changed their "in effect" status.
3. Other style properties affecting the element have changing meaning that
animations applied at the animations-level of the cascade may now be
overridden or become active again.
We want to detect these situations so we can avoid updating the cascade when
none of these possibilities exist.
Currently we handle case 1 by calling UpdateCascadeResults at the appropriate
point in nsAnimationManager and nsTransitionManager when we build
animations/transtiions.
Case 2 only affects animations (since whether transitions are in effect or not
makes no difference to the cascade--they have a lower "composite order" than
animations and never overlap with each other so they can't override anything).
As a result, we handle it by adding a flag to CSSAnimation to track when an
animation was in effect last time we checked or not.
For case 3, we take care to call UpdateCascadeResults when the style context
changed in nsAnimationManager::CheckAnimationRule (called from
nsStyleSet::GetContext).
We want to generalize this detection to handle script-generated animations too.
In order to do that this patch introduces a flag to EffectSet that we will use
to mark when the cascade needs to be updated in cases 1 and 2. This patch also
sets the flag when we detect case 1. A subsequent patch sets the flag for
case 2.
Case 3 is more difficult to detect and so we simply maintain the existing
behavior of making nsAnimationManager::CheckAnimationRule unconditionally
update the cascade without checking if the "needs update" flag is set.
--HG--
extra : rebase_source : fc56b1bb5a98ae78b93a179c7a3b8af4724a06a1
This is so that when we have code like:
elem.animate({ opacity: 0 }, 1000)
the resulting Animation object is kept alive by |elem| based on the following
ownership chain:
elem --(strong)--> KeyframeEffectReadOnly --(strong)--> Animation
Now, there is an ownership cycle introduced here because KeyframeEffectReadOnly
objects also store owning references to their target elements. This is broken
when the Animation finishes (if it does not fill forwards) or is cancelled
since either event will trigger a call to
KeyframeEffectReadOnly::UpdateTargetRegistration.
If the Animation fills forwards, the resource will not be released until
it is cancelled. For Animations corresponding to CSS Animations / CSS
Transitions this happens when the Element is unbound or when the corresponding
style property is updated causing the animation to be replaced or removed.
For the general case of script-generated animations, however, this cycle won't
be broken until the Element is unbound and all external references to the
Animation or KeyframeEffectReadOnly are dropped.
It's unfortunate that we can't more aggressively prune these objects but it's
what the spec currently says. I've posted to the mailing list[1] about this but
have yet to find a good solution.
[1] https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0029.html
Hiroyuki Ikezoe
Boris Chiou
Sebastian Hengst
Hiroyuki Ikezoe
Brian Birtles
Jonathan Watt
Nigel Babu