We keep a set of properties which are running on the
`CascadeLevel::Animations`, to make sure we compose the correct properties
for the rule on Animations/Transitions cascade level.
In other words, without this patch, we may accidentally compose an
animation rule for `CascadeLevel::Animations` (from the KeyframeEffect of
the existing transition), even if we don't have any running animations,
if this transition property is a custom property.
The resolution is to use `AnimatedPropertyIDSet`, for
`mPropertiesForAnimationsLevel`, so we can skip the custom properties which
shouldn't belong to Animations cascade level when composing them.
Note that we don't change the logic, and we are still using
`nsCSSPropertyIDSet` for `EffectSet::mPropertiesWithImportantRules`
because compositor animations don't allow custom properties now.
(This could be a future work I guess, if we are using custom property
values for opacity, translate, rotate, scale, etc.)
Also, I noticed the subtest, "No transition when removing @property rule",
is similar to the testcase in this bug, and so it got passed as well.
Differential Revision: https://phabricator.services.mozilla.com/D210589
The regressing bug made a crucial mistake which is setting the
compositor animation ready time to the _current_ refresh driver time,
even though the main thread will use the _next_ refresh driver time to
do that.
That means that the compositor and main thread can be desynchronized by
one frame, which depending on the main thread workload can be a lot.
Differential Revision: https://phabricator.services.mozilla.com/D199614
The regressing bug made a crucial mistake which is setting the
compositor animation ready time to the _current_ refresh driver time,
even though the main thread will use the _next_ refresh driver time to
do that.
That means that the compositor and main thread can be desynchronized by
one frame, which depending on the main thread workload can be a lot.
Depends on D199613
Differential Revision: https://phabricator.services.mozilla.com/D199614
The regressing bug made a crucial mistake which is setting the
compositor animation ready time to the _current_ refresh driver time,
even though the main thread will use the _next_ refresh driver time to
do that.
That means that the compositor and main thread can be desynchronized by
one frame, which depending on the main thread workload can be a lot.
Depends on D199613
Differential Revision: https://phabricator.services.mozilla.com/D199614
This will make possible to animate custom properties on Gecko side. For now, the
animation code keeps only dealing with nsCSSPropertyID, so behavior is unchanged.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D190816
Differential Revision: https://phabricator.services.mozilla.com/D191059
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
This rejiggers a bit the transition event setup to not carry around an
InternalTransitionEvent. We create one once we're ready to dispatch it.
We can implement similar optimizations for animation and playback
events.
Also moves the markers out of line because those constructors were
getting rather unwieldy.
Differential Revision: https://phabricator.services.mozilla.com/D185425
HasBoxFFI and HasArcFFI aren't great, see bug 1831242 as for examples of
why.
HasArcFFI requires a bit more care, but HasBoxFFI doesn't give us much
benefit. Instead use the same type in the FFI boundary.
Differential Revision: https://phabricator.services.mozilla.com/D177252
We always use the document timeline of the cloned document, and clone the
paused animation with the preserved progress, even if the original
timeline is null.
Differential Revision: https://phabricator.services.mozilla.com/D164712
Basically, in SetTimelineNoUpdate(), we shouldn't call PostUpdate(). So we
shouldn't call SetCurrentTime() directly.
There is no behavior change. Just make sure we don't PostUpdate twice
while updating an existing CSS animation via changing animation-timeline.
Differential Revision: https://phabricator.services.mozilla.com/D161245
It's possible to change the timeline if the animation is in pending. So
we still need an animation tracker to track the scroll-linked
animations. Besides, per the spec, we should keep this animation in
pending if its timeline is inactive. So in this patch, we always put the
scroll-linked animations into ScrollTimelineAnimationTracker, and if we
change the timeline but the animation is still in pending, we move the
animation into the correct animation tracker if needed.
Using two different animation trackers because we would like to trigger
scroll-linked animations after frame construction and reflow,
and don't want to ensure the paint is scheduled.
Note:
1. All tests in scroll-timeline-dynamic.tentative.html are failed. We
will fix them in Bug 1774275.
2. Drop `animation-duration: infinite` from
progress-based-animation-animation-longhand-properties.tentative.html,
because infinite is not defined in animation-duration in [css-animations-1].
Differential Revision: https://phabricator.services.mozilla.com/D159650
It's possible to change the timeline if the animation is in pending. So
we still need an animation tracker to track the scroll-linked
animations. Besides, per the spec, we should keep this animation in
pending if its timeline is inactive. So in this patch, we always put the
scroll-linked animations into ScrollTimelineAnimationTracker, and if we
change the timeline but the animation is still in pending, we move the
animation into the correct animation tracker if needed.
Using two different animation trackers because we would like to trigger
scroll-linked animations after frame construction and reflow,
and don't want to ensure the paint is scheduled.
Note:
1. All tests in scroll-timeline-dynamic.tentative.html are failed. We
will fix them in Bug 1774275.
2. Drop `animation-duration: infinite` from
progress-based-animation-animation-longhand-properties.tentative.html,
because infinite is not defined in animation-duration in [css-animations-1].
Differential Revision: https://phabricator.services.mozilla.com/D159650
If both end time and start delay are Infinity, the result of interval
end time is undefined, so now we return zero duration to avoid the
assertion in StickyTimeDuration.
Differential Revision: https://phabricator.services.mozilla.com/D153818
Keep a separate list of animations in the timeline that are hidden by
content visibility. This allows the DocumentTimeline to disconnect from
the refresh driver when all animations are hidden and prevents ticking
hidden animations in general.
Differential Revision: https://phabricator.services.mozilla.com/D150764
We have to make sure the scroll animations is still responsive at
boundaries even if it's playstate is finished.
This patch includes the update of UpdateFinishedState() to match the
spec, and make sure we still tick scroll animations at finished play state.
Getting a finished state might be strange for scroll animations, and this
might be a spec issue. However, for consistency with JS-generated animations,
we'd like to align the behaviors with other browsers, and make sure we are
still match the definition of finished state in the spec.
Besides, we have to use EndTime() on the compositor so
animation-iteration-count works properly.
Tests are in the last patch.
Differential Revision: https://phabricator.services.mozilla.com/D149940
`sTiming` is a hack and I believe animation-delay,
animation-iteration-count, animation-direction, and animation-fill-mode
should be meaningful for scroll-linked animations. (I will add the
tentative wpt in Bug 1775327.)
So we need to introduce a normalized timing when resolving the specified
timing.
Also, this patch makes the bug of printing scroll animations detectable.
No behavior is changed and I'd like to remove the magic values and do
normalization in Bug 1775327.
Note: Based on https://github.com/w3c/csswg-drafts/issues/4862 and
web-animations-2, we will introudce CSSNumberish for duration, current
time, and delay. That is, we will accept percentage for
animation-duration, animation-delay. However, Gecko doesn't support
CSSNumberish for those values, so we'd like to normalize these time values
in Bug 1775327. This patch is the 1st step: split the normalized
timing from the specified timing, and use it when resolving the
timing, for progress-based timeline.
Differential Revision: https://phabricator.services.mozilla.com/D149683
Basically, we use the current target scroll position as the ready time for
scroll animations, so we don't need to wait until it gets painted.
In fact, it's unclear whether do we need play/pause pending status for
scroll animations, so we choose the natural way for now, and this should
match other browsers' behaviors.
Note:
We avoid puting the scroll animation into PendingAnimationTracker
in PlayNoUpdate() and Pause(). However, we may still "try" to remove
scroll animations from PendingAnimationTracker in some APIs just in
case if those APIs change the animations from using DocumentTimeline to
using ScrollTimeline. They should be revisited once we expose
ScrollTimeline to JS.
Differential Revision: https://phabricator.services.mozilla.com/D132750
For simplicity purposes, we don't consider OMTA for now. OMTA support
for scoll-timeline will be done in Bug 1737180.
However, in this patch, we would like to address:
if the geometic animations use scroll-timeline, we don't have to let it
affect the transform animations on the same animation target:
1. If we don't do scrolling, its geometric properties don't change, so no
effect on transform-like properties.
2. If we do scrolling, we may un-throttle the transform animations by
other ways, e.g. Keyframe::CanThrottle(). So we don't need to worry
about this.
Note: tests are in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D129103
Based on https://github.com/w3c/csswg-drafts/pull/4842, we define
"has finite timeline", which is a timeline that's not monotonically increasing.
We need this to update start time and hold time for scroll-timeline, so
we play scroll-linked animations as we expected, e.g. GetLocalTime() returns
the correct time value from GetCurrentTimeAsDuration().
Known issue: we still have bugs when setting "animation-play-state:paused".
Will do that in Bug 1741255.
Differential Revision: https://phabricator.services.mozilla.com/D131168
