So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
In a subsequent patch in this patch series, we want to make nsPresContext
have an AnimationEventDispatcher as RefPtr<>.
Instead, if we were trying to make nsPresContext have the
AnimationEventDispatcher as data object (not RefPtr<>) just like we did in
CommonAnimationManager, we will fall into header inclusion hell since Element.h
includes nsPresContext.h and AnimationEventDispatcher.h ends up including
Element.h. Even if we could solve the inclusion hell, we will suffer from Rust
bindgen issues for some reasons.
MozReview-Commit-ID: B0nX2JzIRJD
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
In a subsequent patch in this patch series, we want to make nsPresContext
have an AnimationEventDispatcher as RefPtr<>.
Instead, if we were trying to make nsPresContext have the
AnimationEventDispatcher as data object (not RefPtr<>) just like we did in
CommonAnimationManager, we will fall into header inclusion hell since Element.h
includes nsPresContext.h and AnimationEventDispatcher.h ends up including
Element.h. Even if we could solve the inclusion hell, we will suffer from Rust
bindgen issues for some reasons.
MozReview-Commit-ID: B0nX2JzIRJD
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
