The check of negative elapsedDuration is basically no longer valid since
animation delay is not factored into start time any more. But still we have
somtimes met negative elapsedDuration sice we use a previous vsync time stamp
for async animations to make the animations more sync. This is not a problem
in most cases but makes two reftests intermitent failure because both of them
used steps(1, start), the steps(1, start) composed different results in the
before phase and in the active phase. To avoid this difference this patch
replace the steps(1, start) with steps(1, end).
Once we incorpolate playbackRate into GetCurrentOrPendingStartTime, we don't
need to call AnimationTimeToTimeStamp for deviding delay by playbackRate since
the time passed to AnimationTimeToTimeStamp does not contain delay any more.
MozReview-Commit-ID: IVE2IFfNgm0
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
Use SetEffectNoUpdate() for the procedure of setting effect, and let SetEffect()
also calls PostUpdate(), so we can use SetEffectNoUpdate() if we don't want to
call RequestRestyle(RestyleType::layer).
MozReview-Commit-ID: CaWA34UebpH
Both Cancel() and SetEffect() need the procedure of "Reset an animation's
pending tasks", so factor it out and then we can reuse it.
MozReview-Commit-ID: C7Q5kF9aPrV
This is a pre-patch for part 5, which is trying to make our code closer to the
spec. Some methods in KeyframeEffectReadOnly belong to AnimationEffectReadOnly,
so first, use AsKeyframeEffect() to access those keyframe-related methods, and
then add virtual methods for timing-related methods to AnimationEffectReadOnly.
MozReview-Commit-ID: 1srA1f8JYeN
The previous patch in this series renamed nsCSSProperty to nsCSSPropertyID.
This patch renames nsCSSPropertySet to nsCSSPropertyIDSet accordingly.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSPropertySet\b/nsCSSPropertyIDSet/g' -i''
Then:
hg mv layout/style/nsCSSPropertySet.h layout/style/nsCSSPropertyIDSet.h
... and finally, manually renaming nsCSSPropertySet in the include guard in
nsCSSPropertyIDSet.h.
MozReview-Commit-ID: ASUNs7FWbKP
If we run following code, content process will crash.
------
anim1.timeline = timeline;
anim2.timeline = document.timeline;
anim2.timeline = timeline;
------
The AnimationTimeline has LinkedList variant. (called mAnimationOrder) And Animation is sub-class of LinkedListElement.
We will create the relationship of AnimationTimeline and Animation when calling the AnimationTimeline::NotifyAnimationUpdated. However we didn't remove these relation ship when setting new timeline.
So we should remove these relationship when setting new timeline object.
MozReview-Commit-ID: RDyranduTA
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().
In some circumstances when composing style, we tweak the time of the animation
before telling the effect to compose style. This is to avoid visual flicker in
certain situations where the main thread progress is being synchronized with an
animation running on the compositor.
In the past, effects would store their latest sample time locally so when
tweaking the animation time, we would need to call UpdateEffect() after tweaking
the time, and then again after restoring it as otherwise the style composed by
the effect would not reflect the adjusted time.
Now, however, effect's always query their animation for the time so this is no
longer necessary. Furthermore, the actions triggered by UpdateEffect are not
desirable in this case because they can, amongst other things, cause the
associated EffectSet to be destroyed and recreated.
Specifically, Animation::UpdateEffect() calls
KeyframeEffectReadOnly::NotifyAnimationTimingUpdated() which:
* Calls UpdateTargetRegistration which can trigger EffectSet
destruction/creation which is undesirable in this case because we intend to
restore whatever changes we make to the Animation's state and deleting and
recreating the EffectSet will cause any pointers to it to dangle.
* Cause us to possibly reset the "is running on compositor" status.
This too is undesirable since we intend to restore the state of the
Animation immediately after tweaking the hold time so we don't want to
act as if any state has changed.
* Similarly for marking the cascade as possibly needing an update or
requesting a restyle.
In summary, all the actions performed by NotifyAnimationTimingUpdated are
unnecessary and undesirable in this situation where we are temporarily tweaking
an Animation's current time only to restore it immediately afterwards since the
actions are all involved with recognizing actual changes in state.
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.
This is in preparation for moving RequestRestyle to EffectCompositor (and
because we'll run into compile issues if we don't since AnimationCommon.h
includes too many interdependent definitions).
When requesting restyles we take special care to detect when an animation has
newly finished so we perform the necessary restyle to represent the fill state.
However, we should really explicitly pull the animation off the layer at this
point by requesting a layer update. (That is, when an animation is
newly-finished we should use RestyleType::Layer instead of
RestyleType::Standard. Currently we just use RestyleType::Standard.)
In this bug we plan to move restyle requests down to the effect (since it is
the *effect* that is restyled). However, only the Animation has the notion of
"finished" or not so we detect this particular case in the Animation and
request the layer update there. We already request layer updates in the
Animation for other situations such as pausing so doing *layer* updates in the
Animation and regular restyles in the effect is not inconsistent.
This patch also tweaks test_animations_omta.html since it was previously
erroneously testing that a finished animation was still running on the
compositor.
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.
