This is the IDL added to the Web Animations specification:
5af5e276ba
Note that some of the changes in the above commit were reverted in the following
commit:
673f6fc126
A folded version of the changes:
https://gist.github.com/birtles/d147eb2e0e2d4d37fadf217abd709411
MozReview-Commit-ID: CJV7bzizXg4
--HG--
extra : rebase_source : 6dc6819e158bcdd094962769096a17da6cd2026a
In the case where we throttle transform animations in visibility:hidden
element, we just need to unthrottle only if the element is scrolled out since
unlike the scrolled out element, visibility:hidden element keeps invisible
even after the element moved into view.
MozReview-Commit-ID: 7X2SsOLz4Y5
--HG--
extra : rebase_source : ca7210f7ed637f858127c4008fe98fbeec874a10
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : e56505706bb2799b59bbfb3bbcce4a9ce86892f4
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : a462845ac2d8280986bb8db5e6482bf401f65322
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : f3d8c1f9561fbb19d1ca8594ba2b69cffd25445b
The original value were too small for Android.
MozReview-Commit-ID: 4V6qC8orYNJ
--HG--
extra : rebase_source : 55ea0525bfaafa60d8e5d711cc70dd29d21acc78
In this test we need to know precise time for checking that we unthrottle
throttled transform animations periodically.
MozReview-Commit-ID: ICLf448KFLr
--HG--
extra : rebase_source : 26128735231679031bd1e727cf9d9016054e7664
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : 5c1a3a1bb7cb10cd5c4a608f30bf097bd7e119b9
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : ceb95bdce1042cbfc16751d6d023fc6feee5845e
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : 1cd03a78a522b1a6965ba73ebf002ddacb0ab4f2
Since we do not support async-transform for individual-transform yet.
MozReview-Commit-ID: gfOzHpjOnQ
(grafted from dd508458f70d5473256a4bfe5a2f6bc665bbac9d)
--HG--
extra : source : dd508458f70d5473256a4bfe5a2f6bc665bbac9d
And disallow using copy constructor and copy assignment for the structs.
MozReview-Commit-ID: 7jSktlu1SqN
--HG--
extra : rebase_source : cc8bcb1f95843a2a46a044e226c299a6196ef2a2
tweakExpectedRestyleCount() is supposed to work with observeStyle() which is
called right after tweakExpectedRestyleCount(). That's because
tweakExpectedRestyleCount() adjusts the expected restyle count which will
happen in continuous frames that begins from the startsRightNow() call,
especially a redundant restyle might be observed in the last frame if the
animation did not begin at the current timeline time and if the Promise inside
the last requestAnimationFrame is fulfilled after restyling happened.
Instead of using tweakExpectedRestyleCount(), we need to check whether the
animation begun at the current timeline time when the animation started, and if
the animation begun at the current timeline time, we don't observe the
superfluous restyle in a frame after the animation element was re-attached.
MozReview-Commit-ID: 6TLQERSSbjU
--HG--
extra : rebase_source : 1a1dcb56b889bebedb44346bbc315ec01870cf79
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
--HG--
extra : rebase_source : 286b3d5d29208496bfe8405819b44b5f52f6671c
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
--HG--
extra : rebase_source : 28c8e2a50d29c5344e2c5ca3c43af41f4692fa0f
Now we sort pending events only when dispatching the events, i.e.
only inside DispatchEvent().
MozReview-Commit-ID: BZbuF8gD39b
--HG--
extra : rebase_source : 2a90697356d980b1fd1329d34936eaef1179d12f
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
--HG--
extra : rebase_source : 405c8232e93c54a073c722a4332873af02daa870
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
--HG--
extra : rebase_source : 4eb998876b2fc39de8d09cac09c19e1a51cd382e
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
--HG--
extra : rebase_source : 50da76f51cf65cdd1245d93d8b48aaf0ae0ec94b
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
--HG--
extra : rebase_source : d111c63baac0ad3005723c1c76bad08e975555ec
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
--HG--
extra : rebase_source : e1963d9eef996cdf5d64c64f80eb1b93ac6fd18a
Now we sort pending events only when dispatching the events, i.e.
only inside DispatchEvent().
MozReview-Commit-ID: IRqH56BEnKb
--HG--
extra : rebase_source : dd2b8528fdc36d1371815feaf07ead0b258fe453
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
--HG--
extra : rebase_source : 52226c33a511451c31d4c3fef94ff02de8462256
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
--HG--
extra : rebase_source : cd010ca5fe5b1f9fa8f519fdab0dc47d6e519bef
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
--HG--
extra : rebase_source : 06ef844f41cfe81b9a629340b5a328c1bed80e8e
The implementation of the template function is defined in KeyframeUtils.cpp,
whereas the caller is inside KeyframeEffectReadOnly.cpp. I guess it's been
compiled accidentally because of unified builds.
MozReview-Commit-ID: 9GeIT7nDpLG
--HG--
extra : rebase_source : ce58ac6a013ff45d402c51994eb4f0bc28a2c671
Since the function assumes that both of actual and expected values
have the same precision requirements.
MozReview-Commit-ID: 4C3TAH6mUVg
--HG--
extra : rebase_source : 1e40e489745b0d9047d34e851a5f043db616323e
This assertion is supposed to be used where the first argument has a tolerance
but the second argument doesn't have such tolerance. Whereas
assert_times_equal() is supposed to be used for the case both arguments have
the same tolerance, actually it hasn't, it will be fixed in a subsequent patch
in this patch series.
MozReview-Commit-ID: FEDHilbX2rm
--HG--
extra : rebase_source : e773902b474bd9a411e7bb3f234702a93547ebba
