We had to implement UpdateProperties(nsStyleContext*) explicitly
since there are some calls of UpdateProperties() with RefPtr<nsStyleContext>.
Without this compiler tries to use template function instead.
MozReview-Commit-ID: 72NgwmJ4kcx
We'd like to use template to manage functions that have almost the same functionality
both on stylo and gecko instead of branching in each functions because it will be
easier to maintain stylo and gecko for a while.
MozReview-Commit-ID: 25ukMpOeqLj
EnsureBaseStyle() requires an already resolved nsStyleContext
and resolves the base style by ResolveStyleByRemovingAnimation().
MozReview-Commit-ID: BHqJiBJspQY
EnsureBaseStyle() requires an already resolved nsStyleContext
and resolves the base style by ResolveStyleByRemovingAnimation().
MozReview-Commit-ID: BHqJiBJspQY
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
Test case, 1330190-2.html, is another variant of 1325193-1.html. It's for
animation on a pseudo element, causes timeout without part 3 patch.
MozReview-Commit-ID: KX6FE8mkZY2
Before this patch we skipped KeyframeEffectReadOnly::ComposeStyle() for
animations that are not in effect.
After this patch we call KeyframeEffectReadOnly::ComposeStyle() even if the
animation is not in-effect state in order to prepare the base style for
properties that can be run on the compositor because the in-effect animation
will be sent to the compositor and might be composed onto the base style on the
compositor after the animation gets out of its delay phase.
MozReview-Commit-ID: FuAZv4jqVMJ
KeyframeEffectReadOnly::ComposeStyle() might call nsStyleSet::ResolveStyleFor(),
and KeyframeEffectReadOnly::ComposeStyle() itself is called from
nsStyleSet::ResolveStyleFor(). So we have to carefully avoid nested calls of ComposeStyle.
MozReview-Commit-ID: IRM99bGUFLa
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
We don't need to rebuild the animation properties and recalculate the
computed offsets of Keyframes while copy-constructing a new
KeyframeEffect(ReadOnly) object, so avoid calling SetKeyframes()
directly. And we also need a customized copy constructor for AnimationProperty
to avoid copy mIsRunningOnCompositor.
MozReview-Commit-ID: CIF3Ibgc1tM
The copy constructors of KeyframeEffectReadOnly and KeyframeEffect are
similar, so we overload ConstructKeyframeEffect<...>(...) for copy
constructors.
MozReview-Commit-ID: 37hClpn9ZUG
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
MozReview-Commit-ID: AG1Y0IgoB3U
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
