Calculate the paced spacing for each Keyframes by the context element. Use the
algorithm in the spec.
MozReview-Commit-ID: HFWQwoKhKWt
--HG--
extra : rebase_source : 40112eb1f722179cfc0a4ccbd188e22bc7af9b9b
We want to reuse the StyleAnimationValues of properties of each keyframe when
applying spacing and building animation property segments, so refactor this
part.
MozReview-Commit-ID: 8G56C3BU3FR
--HG--
extra : rebase_source : 73b6d374ac8bd25645d1b1b2f15f4e778b3ec949
When we apply paced spacing, we have to check if there are still null computed
offsets after applying paced spacing to paceable Keyframes because the
calculation of distance may be failed or some Keyframes are not paceable in
the specific range. Therefore, using -1 would be easier to check it.
Also, add a const, kComputedOffsetNotSet, to represent this invalid value.
MozReview-Commit-ID: GPhj7cdiX2W
--HG--
extra : rebase_source : 8c4e7769c454fe50eb1cc08db63866dcc4ed62e5
Rename it to ApplySpacing, and let it handle both distribute and paced mode.
MozReview-Commit-ID: 2kGA6LMHUsz
--HG--
extra : rebase_source : ebd5566392b1ea6a4a445ff7c3ed81cdc94bdded
We only support spacing mode from Web Animations API, so add a simple parser and
use it only from the API. In this patch, parse spacing mode from the constructor
and throw TypeError if we have any parse error.
MozReview-Commit-ID: 9H7g80IcZfZ
--HG--
extra : rebase_source : e1bc781ff0f20a1a38c04e672832ec013edc549d
BuildSegmentsFromValueEntries now needs base nsStyleContext to calculate
the change hints.
If the change hint is not set correctly, we will check it in
CanIgnoreIfNotVisible() introduced in a subsequent patch (part 3).
This patch also includes a tweak to not-animatable.html to match the order in
which properties are enumerated on the object. This test was always in error but
we never noticed since the test failed before reaching the test in question.
Making the test dependent on the order in which object properties is enumerated
is not good but we will remove this test in the next patch. In this patch we
just make sure it passes.
MozReview-Commit-ID: AKXdHj4nUMv
--HG--
extra : rebase_source : 64270ae9d9cf68cdf534baaf198583fb1974025c
In order to support CSS variable references in animation properties we need to
handle token stream values. However, we already use token stream values for two
other purposes:
* To store shorthand property values
* To store invalid longhand property values
The shorthand property value case is already handled correctly, however for
longhand values we need to distinguish between valid token streams (e.g.
values that contain variable references) and invalid values stored as token
streams.
This patch makes us do that by looking at the mPropertyID member of the
nsCSSValueTokenStream object which will be eCSSProperty_UNKNOWN for an invalid
value but will be set to something sensible for a valid token stream.
MozReview-Commit-ID: AXUaO5dopBC
Earlier in this patch series we divided keyframe processing into two stages:
(1) Turning javascript objects into an array of Keyframe objects
(2) Calculating AnimationProperty arrays from the Keyframe objects
This patch creates a SetFrames method so that CSS animations and
CSS transitions can skip (1) and pass the frames constructed from CSS syntax
into (2).
It also adds the following additional processing:
a. Notifying animation mutation observers when the set of frames has changed.
This is currently performed by nsAnimationManager but ultimately we should
encapsulate this logic inside the effect itself. Furthermore, it will be
needed when we implement effect.setFrames() (i.e. the Javascript-facing
wrapper for this method).
b. Preserving the mWinsInCascade and mIsRunningOnCompositor state on properties
when updating them.
This is currently performed by:
bool KeyframeEffectReadOnly::UpdateProperties(
const InfallibleTArray<AnimationProperty>& aProperties)
which is what nsAnimationManager currently uses. We will ultimately remove
the above method and here we are just moving this code to the new version
of UpdateProperties.
c. Requesting a restyle when the set of AnimationProperty objects has changed.
Again, this is currently performed by the existing UpdateProperties method
so we are just moving it here. This behavior will also be required when
we implement effect.setFrames() and when we call UpdateProperties from
elsewhere in restyling code.
This is bug 1235002 but we fix it here and leave that bug to just do further
cleanup work (e.g. re-instating the check for an empty property set before
requesting a restyle in NotifyAnimationTimingUpdated).
d. Marking the cascade as needing an update when the set of AnimationProperty
objects has changed.
This is in preparation for calling UpdateProperties from elsewhere in
restyling (e.g. when the nsStyleContext is updated).
MozReview-Commit-ID: 2ll26lsWZTm
StyleAnimationValue::ComputeValue(s) will automatically look up the style
context of the supplied element. This is mostly fine, but when we start using
this method in scenarios where we are building the initial style context
(as happens later in this patch series) it can easily land us in a situation
where we iterate indefinitely.
It would be better, instead, to just explicitly pass in the style context we
want to use, as we already do for StyleAnimationValue::ExtractComputedValue.
MozReview-Commit-ID: ZoVBlBRRBI
--HG--
extra : rebase_source : 9012cc2e405fc887f070fbfaa2f9853289882862
Boris Chiou
Brian Birtles
Hiroyuki Ikezoe
Xidorn Quan
Ryan VanderMeulen
Mantaroh Yoshinaga