To avoid using StyleAnimationValue on stylo, we should skip
ApplySpacing, which means We always fall back to distribute spacing on stylo.
MozReview-Commit-ID: 9DNwhOI8saf
--HG--
extra : rebase_source : c535139a8171bcdc874fef6bc1a12045957de9e1
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
Move the implementation of uncomputing to string into AnimationValue,
and add one more FFI for RawServoAnimationValue.
MozReview-Commit-ID: JFnXnGO3mlp
--HG--
extra : rebase_source : 83c0e084ef4202a5c98c668d68bfe9066196d735
Replace the argument type with AnimationValue.
MozReview-Commit-ID: IeydVOLKTB9
--HG--
extra : rebase_source : 9537e40c9ffa16919a08765daa5d12e020e5d17c
1. Call Servo's interpolation from KeyframeEffectReadOnly::ComposeStyle().
2. Store the results into ServoAnimationRule.
MozReview-Commit-ID: LOp2mbXforg
--HG--
extra : rebase_source : eda5e275e81f2413b2a729e8d06663eae496c15c
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
Based on the other changesets in this series, we don't expect to be calling
UpdateProperties() and ComposeStyle() from within ComposeStyle() itself.
However, in case there is some scenario where that does still occur, we leave
the mIsComposing check in place and add an equivalent MOZ_DIAGNOSTIC_ASSERT so
that we are alerted if this does occur on debug / Nightly / DevEdition builds,
but handle it gracefully on beta or release builds.
MozReview-Commit-ID: 2cFpyMFR29Q
--HG--
extra : rebase_source : 8d6175b8785dd062bda85eda7f06c01bec42fbee
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
--HG--
extra : rebase_source : f5efbae0cc30036a511659eab9b29b5091df7539
This patch also fixes expected computed offset values in frame at 0.5 offset for
add composite.
MozReview-Commit-ID: 8PNp237NoV4
--HG--
extra : rebase_source : 7bdf83741198fb81c6721cad1764e6464033c240
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
--HG--
extra : rebase_source : 9ef2f078e5ee18735fb8cd3086f20774fe8b1fd0
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
--HG--
extra : rebase_source : 05dfab033b738bae92706588708bd7b7a29ec7de
This should be easier to read and provide us a convenient place to check for
other cases where we need to synchronize with the main thread (such as the
change introduced in this bug where we synchronize with other animations
started at the same time).
MozReview-Commit-ID: 8iuA7P4ycwM
--HG--
extra : rebase_source : 60a706d51897a0522794cd140734ad7158f4ccd6
extra : histedit_source : cbd0849fcb9077afaf3d2cd3f168201ddb2bf7a4
If margin or padding is being animated then we should synchronize with transform
animations.
Originally I included the border-*-width properties in this set. However
I removed them because:
1. Generally animations of border-width are more subtle and it won't be
noticeable if they are not synchronized with transform animations.
2. If authors animate the border shorthand (e.g. border: 1px blue -> 1px black)
we will end up interpolating each of the longhands (including the widths
despite there being no change) and yet such an animation does not really need
to be synchronized with transform animations. Until we add code to workaround
that it seems best to ignore border properties.
I have verified that the tests added in this patch fail without the code changes
in this patch.
MozReview-Commit-ID: AJiDAvTpFuN
--HG--
extra : rebase_source : 58462ab48acc0b1298915d0d3572915b6973ac82
extra : histedit_source : d293cfc68ff59483b4f9543a7a63b140d627a4fa
Test cases in file_composite.html are matching pair of tests in
web-platform-tests.
MozReview-Commit-ID: ApuvVCHKQ8Y
--HG--
extra : rebase_source : 58342389a3eb1ed2a3c1889b5ce974dbde19c32f
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
If all of animations on an element are paused, finished or zero playback rate,
we don't send those animations to the compositor.
Also in this change, we send zero active duration animations to the compositor
in the same way as normail animations.
MozReview-Commit-ID: CHjv6Buy5fa
In order to use single_value_to_css() in
Servo_DeclarationBlock_SerializeOneValue(), we need to pass the property name
and a flag for custom properties.
MozReview-Commit-ID: 5HfI2qOmPwP
--HG--
extra : rebase_source : 968468b3c9313c4ec3007ee9883075c8fc4ab769
Factor out BuildProperties to have a better readability of UpdateProperties.
MozReview-Commit-ID: A3cIS65STAx
--HG--
extra : rebase_source : a09d935d6ced8f4a6c7311e69e3840e195c575a1
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
--HG--
extra : rebase_source : 7bbc8c1666451435982651f11af9c00f37708807
The copy constructors of KeyframeEffectReadOnly and KeyframeEffect are
similar, so we overload ConstructKeyframeEffect<...>(...) for copy
constructors.
MozReview-Commit-ID: 37hClpn9ZUG
--HG--
extra : rebase_source : 48de18c190dd8cbc61e0363e999960f2e823f2ea
To send animations to compositor in the delay phase we need to
modify Animation::IsPlaying returning true in the delay phase.
Note about background-position-in-delay.html:
After this patch, background-position animation also creates an active layer
from its delay phase.
Also note about test cases in test_animations_omta.html:
After landing bug 1279071, getOMTAStyle() returns the style value only
specified by animations, also in this patch we don't apply any opacity or
transform values in the delay phase, as a result we can't tell animating
value during delay phase on the compositor.
MozReview-Commit-ID: ILYKig3c08d
--HG--
extra : rebase_source : 5715c1f9ec43da3c8374f08cdca82e2ca29fe474
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
Xidorn Quan
Boris Chiou
Hiroyuki Ikezoe
Sebastian Hengst
Hiroyuki Ikezoe
Boris Zbarsky
Brian Birtles