Transitions on the compositor sometimes go further ahead while the
main-thread is busy. When the transition on the compositor is replaced by a
new one, until now we calculate the current position of the old one with the
most recent refresh time. But if the replace is done on a busy frame, the
calculated position will be far from the real position on the compositor.
As a result, we can see jumping transitions after busy frames.
To mitigate this issue, we should calculate a plausible current position of
the old one with the current time just before sending the new transition to
the compositor, i.e., after all JS callback works have done.
The plausible value is stored into KeyframeEffectReadOnly::mProperties, not
into mKeyframes. If we store the value into keyframes,
KeyframeEffectReadOnly::GetKeyframes() will return a different values after
busy frames.
Note that with this patch getComputedStyle() does not return the plausible
value because this patch does not affect styling process. getComputedStyle
issue will be fixed in bug 1273834.
MozReview-Commit-ID: B85kIx6qeyy
Now we can throttle some sort of animations which run on the main thread
as well as animations on the compositor. So, AreAsyncAnimationsEnabled checks
should be removed.
The check in PresShell::HandleEvent might be replaced with checking
nsIDocument::mNeedStyleFlush, but I am not sure.
Currently if we have transition-property: 'all' and trigger a transition
on the 'color' property we will end up generating a transition on
-webkit-text-fill-color even if that property is disabled.
However, when we later call StyleAnimationValue::ToValue() in
nsTransitionManager::UpdateTransitions() to see if there are any transitions we
need to cancel, the comparison for currentValue != anim->ToValue() will pass
(since, as of the first patch in this patch series, ToValue() returns a null
value) so we end up cancelling the transition as soon as we create it).
Nevertheless, we will still trigger the warning introduced in the first patch
in this series when we call ToValue().
This patch stops us from creating transitions in the first place (and hence
triggering the warning). It also removes the code that suppresses transition
events for transitions on disabled properties since we should no longer be
generating such transitions in the first place (unless the pref is switched
while the transition is in motion which is probably not worth worrying about).
Note that we only test if the property is enabled for all content. This is
consistent with what we do throughout animation code including the existing
code in nsTransitionManager which iterates through shorthand sub-properties
using CSSPROPS_FOR_SHORTHAND_SUBPROPERTIES with the flag
nsCSSProps::eEnabledForAllContent.
The test case in this patch doesn't actually fail without this change, all it
does it trigger the warning in StyleAnimationValue::ToValue() introduced
in the first patch in this series. It's still a useful regression test however,
particularly if we later upgrade the warning in StyleAnimationValue::ToValue()
to a fatal assertion.
MozReview-Commit-ID: H9swDKLyiOf
Add a new API in nsTransitionManager, so we can cancel transitions for a
specific element easily. The purpose of this API is for cancelling transitions
without dispatching the event.
Although we know that the animation properties will always be filled in for
a transition in the cases where we need to query them (going forward we will
have a situation where an animation may only have frames, not properties, but
that will only happen when the animation isn't attached to an element or the
element is not attached to a document, but we don't run animations in that case
and cancel existing ones when we enter that state so although they *can* enter
that state, we'll never run these methods on them when they do), we still want
to move towards making frames the primary unit for interacting with animation
values since frames always exist and represent the public interface.
Ultimately it would be good to make the properties array on
a KeyframeEffect(ReadOnly) an encapsulated detail so that we can freely change
their structure (e.g. segments might not be the best setup, it might be better
to just have arrays of free-standing values to avoid the duplication of
values when segments are continuous).
This patch removes or encapsulates a few references to properties and
simplifies the code at the same time.
MozReview-Commit-ID: 3II36SYVoRE
Rather than passing around a bool flag to indicate if we should be creating
an AnimationCollection when none is found, it would be a lot easier to read
if we simply introduce a separate method for this.
MozReview-Commit-ID: 6bg8jGoH5pL
By moving GetAnimationCollection to AnimationCollection itself, we can remove
a bunch of virtual methods on the animation managers, simplify call sites,
and provide better type safety by ensuring a correspondence between element
property names and concrete animation types.
One change in behavior, however, is that in doing this we can no longer
add any newly-created AnimationCollection to the corresponding manager's linked
list of collections inside GetAnimationCollection. Instead we take a bool
outparam to indicate if a new collection was created and leave managing the
linked list to the manager. This is just a temporary measure, however, since
by the end of this patch series will will eliminate this linked list altogether
along with this flag.
MozReview-Commit-ID: 1jsc4QcmVDg
This patch templatizes the type of Animation stored in an AnimationCollection.
This allows us to remove a number AsCSSAnimation() calls in nsAnimationManager.
This patch also removes the AnimationPtrArray typedef. In its place we
introduce OwningCSSAnimationPtrArray and OwningCSSTransitionPtrArray but we
don't use these as widely. There was some comment previously that the typedefs
in animation code make it hard to read, particularly when these typedefs don't
make it clear if the data type is an owning reference or not.
In doing this we need to templatize CommonAnimationManager as well and move the
implementation of its (few) methods to the header file. We may be able to
remove the need for templatizing CommonAnimationManager later in this patch
series depending on how we ultimately decide to handle the lifetime of
AnimationCollection objects.
CommonAnimationManager::GetAnimationCollection is a bit messy but this will be
significantly tidied up in subsequent patches in this series.
MozReview-Commit-ID: 3ywatY53pRR
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().
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.
RestyleManager currently has a piece of state for tracking if throttled
animations are up-to-date or not. Actually, it's not so much about throttled
animations but really about outstanding changes to animation styles (which
is typically expected to be due to throttling animations but there are
other cases that invalidate the animation style rule that we should be
considering here).
We now have that same information stored in the EffectCompositor so we can
remove the redundant state from RestyleManager. Furthermore, the state stored
in EffectCompositor is more accurate since it captures the case when animation
style needs to be updated twice within a tick, or when nothing needs to be
updated within a tick.
This patch, therefore, introduces EffectCompositor::HasPendingStyleUpdates in
place of setting RestyleManager::mLastUpdateForThrottledAnimations.
nsTransitionManager also uses mLastUpdateForThrottledAnimations to warn if we
have not processed throttled animations. We can't use HasPendingStyleUpdates
here however, since it will return true in the case where we have triggered new
transitions in the process of restyling. However, any new transitions will
trigger "standard" (i.e. not throttled) restyles so we introduce another
method, HasThrottledStyleUpdates, that returns true only if we have outstanding
throttled updates and use this for the warning inside nsTransitionManager.
This flag is no longer needed because in bug 1232563 we introduced a more
thorough optimization that detects when the animation is not changing by
comparing the progress value between samples and avoids requesting restyles
when it does not change.
Now that we track whether or not animations are up to date using the hashset in
EffectCompositor, we can remove the mStyleRuleRefreshTime flag that is, as of
part 5 of this patch series, now only used for detecting whether or not
animations are up to date.
In order to preserve the existing behavior of FlushAnimations, however, this
patch temporarily introduces a method to indicate if there are throttled
animations or not.
It might not be obvious that FlushAnimations is only concerned with throttled
animations due to its name. FlushAnimations is simply intended to post
animation restyles for out-of-date animations. Any animations that are *not*
throttled will either be up to date, or we will have already posted an
animation restyle so we only need to consider throttled animations in this case.
This patch continues to migrate functionality from
AnimationCollection::RequestRestyle to EffectCompositor::RequestRestyle.
In order to post the animation restyle from the EffectCompositor, this patch
also moves the PostRestyleForAnimation method to EffectCompositor.
The GetElementToRestyle method is temporarily duplicated in both
EffectCompositor and AnimationCollection however we will remove the version in
AnimationCollection later in this patch series.
This is to align with the existing GetAnimationCollection method that takes
a frame. Also, by making this name more specific hopefully it will be used less
since we are trying to move as much code as possible over to using EffectSet
instead of AnimationCollection.
