This is needed in order to use std::stable_sort with this type since some
implementations of std::stable_sort require this (as opposed to simply a move
constructor).
MozReview-Commit-ID: 5QmcIxkC4aB
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
I have confirmed that by adding this, we end up calling SwapElements() on the
mPropertyValues member when we build up the nsTArray<Keyframe> result in
GetKeyframeListFromPropertyIndexedKeyframe. Without this explicit move
constructor (i.e. with only the default move constructor) the copy-constructor
for mPropertyValues is called.
MozReview-Commit-ID: 6IWkP97RFUr
Before we begin re-arranging KeyframeEffect.h we move ComputedTiming aside
since putting it in a separate file should make navigating the source
easier.
MozReview-Commit-ID: L5GTFAo00sh
We are now extending this API to include more than just metadata about each
animated property but also the property values themselves.
Note that we can't use the name AnimationProperty for the dictionary since
we already use that name internally and [BinaryName] doesn't seem to apply to
dictionaries.
MozReview-Commit-ID: AcXeN4fsgTz
This better matches the order in the WebIDL and, once we rename
GetPropertyState to GetProperties it will make sense for GetFrames and
GetProperties to be side-by-side.
MozReview-Commit-ID: 67s9WGksPFv
As well as generally simplifying the different KeyframeEffect(ReadOnly)
constructor methods, this patch also means we will use the realm document for
parsing timing functions in all cases. Although this currently doesn't have
any impact (the current set of timing functions are expected to be parsed
identically regardless of the document used) it may become significant if, in
future, it becomes possible to register hooks with certain documents for
parsing CSS properties as part of the houdini efforts.
MozReview-Commit-ID: 4gAZi1G1uAD
Once we update TimingParams to take a document, we will need to get an
appropriate document within the various constructor methods. This complicates
these methods and suggests they should be pushed into the .cpp file where
we can hide the complexity more easily and templatize the type of the options
argument so that we can share the document-fetching code.
By moving all uses of the declared template methods to the .cpp file we
can drop the explicit instantiations.
(We still need to declare the templated methods in the header file since
these methods need to be protected methods of KeyframeEffectReadOnly in
order to construct a KeyframeEffectReadOnly since its constructor is
protected.)
MozReview-Commit-ID: 8KrCWrWIb7X
Currently endTime is calculated when getComputedTiming() is called. As a
result, the value returned there doesn't necessarily reflect what we are using
in the model. It would be more simple, consistent and useful if we simply
calculate this as part of GetComputedTimingAt and use it both internally and in
the result to getComputedTiming().
Nothing() represents linear function, i.e. skip calculation.
ParseEasing is changed to return a Maybe<ComputedTimingFunction>,
if timing function is linear function, ParseEasing returns Nothing().
This will allow us to re-use the constructor from Animatable.animate() since the
existing type, UnrestrictedDoubleOrKeyframeEffectOptions, is not compatible with
UnrestrictedDoubleOrKeyframeAnimationOptions (introduced in the next patch in
this series), as used by Animatable.animate()
We store the original value of duration in AnimationTiming, and add
computed duration in ComputedTiming, so both the Timing model and
AnimationEffectTimingReadOnly can get what they want.
By the way, replace mIterationDuration with mDuration.
FillMode could be 'auto', and we should treat it as 'none' in the timing model.
However, AnimationEffectTimingReadOnly should get its original value.
By the way, replace mFillMode with mFill.
We want to store the original value from KeyframeEffectOptions whose
iterations is unrestricted double. Therefore, we can get the original value
of iterations by AnimationEffectTimingReadOnly.
By the way, replace mIterationCount with mIterations.
When updating animations, we shouldn't unnecessarily clobber the "wins in
cascade" state of their properties since this can lead to unnecessary restyles
when we then decide we need to update the cascade.
As of bug 1228229, the mWinsInCascade member of animation properties is set
consistently for both animations and transitions such that we only set this
to true if an animation is "in effect".
When an effect is initially created it is not "in effect" until it is attached
to a non-idle animation. We should, therefore, initialize this to false and,
when we become in effect, mark the cascade as needing an update.
Now that restyle requests are handled by the effect, we can more easily detect
cases where we don't need to trigger a style update by looking for when the
output of the effect could actually differ.
Currently, any changes that require updates where the progress does *not* change
(e.g. pausing) are triggered by the Animation. The exception is when we
update timing properties (e.g. animation-iteration-count) from CSS but
current nsAnimationManager takes care to adjust the animation generation in
this case.
KeyframeEffectReadOnly::NotifyAnimationTimingUpdated currently just acts as an
alias for UpdateTargetRegistration. However, bug 1226118 added logic to
UpdateTargetRegistration which is not strictly related to updating the target
element registration. This patch tidies this up so that UpdateTargetRegistration
only does what its name suggests. This is in preparation for adding more
logic to NotifyAnimationTimingUpdated.
KeyframeEffectReadOnly::CanAnimatePropertyOnCompositor has a comment that says
it, "Returns true |aProperty| can be run on compositor for |aFrame|" but it
does nothing of the sort.
What it *does* do is check answer the question, "If there happened to be an
animation of |aProperty| on |aFrame|, should we still run animations on the
compositor for this element?".
This patch renames the method accordingly and moves the step where we iterate
over a given effect's animated properties from
AnimationCollection::CanPerformOnCompositor to inside this method, making this
method a class method rather than a static method at the same time.
As noted in the expanded comment, the approach of blocking opacity animations
in these situations seems unnecessary but for now this patch just preserves the
existing behavior.
