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
The way CommitStyles called into servo caused it to call the closure
multiple times, and we were not dealing with that properly.
Handle the "was called" state internally.
Differential Revision: https://phabricator.services.mozilla.com/D131411
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
We only support writable Animation.timeline attribute on nightly
build, so use nightly build flag in WebIDL and Animation.h/cpp.
For the test expectations, we also use this build flag to skip them or
mark them as expected fail if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D63432
Replace ElementOrCSSPseudoElement with Element and add PseudoElement (which is
a DOMString) into KeyframeAnimationOptions and KeyframeEffect.
Differential Revision: https://phabricator.services.mozilla.com/D62667
In this particular case where we're paused, we don't need to repaint or
synchronize animations on layers, but we do need to update the effect set so
that getAnimations() returns the correct result.
Differential Revision: https://phabricator.services.mozilla.com/D61258
We move the check of important rule and animation level into
KeyframeEffect::ShouldBlockAsyncTransformAnimations(), and add a new warning
for it.
Note:
1. ShouldBlockAsyncTransformAnimations() only cares about transforms. And
for other compositor animation properties, we count on
HasEffectiveAnimationOfPropertySet() (in IsMatchForCompositor()).
2. If we check the important rules in both
EffectCompositor::HasAnimationsForCompositor() and
ActiveLayerTracker::IsTransformMaybeAnimated(), we may get the incorrect
animation warnings (i.e. TransformFrameInactive). In most cases, we
check these two functions together, so perhaps move the check of important
rules outside HasEffectiveAnimationOfPropertySet() is fine.
Besides, ActiveLayerTracker just tracks if there is a style change on this
property (or display item) on the active layers, so should be OK to not
check important rules in it.
So IsMatchForCompositor() should check all transform-like properties,
instead of each one, to get the correct result. (That's why we have to
refactor KeyframeEffect::GetPropertiesForCompositor() as well.)
Differential Revision: https://phabricator.services.mozilla.com/D34432
This method is used when updating the SMIL override style and from Web
Animations' Animation.commitStyles method. By using update we accurately return
false when no change is made to a declaration block.
For SMIL this simply acts as an optimization, meaning we can avoid updating the
SMIL override style ub some cases.
For Animation.commitStyles, however, this allows us to avoid generating
a mutation record. Normally making a redundant change to an attribute *does*
generate a mutation record but the style attribute is different. All browsers
avoid generating a mutation record for a redundant change to inline style.
This is specified in the behavior for setProperty[1] which does not update the
style attribute if updated is false.
[1] https://drafts.csswg.org/cssom/#dom-cssstyledeclaration-setproperty
Differential Revision: https://phabricator.services.mozilla.com/D30871
Animation::UpdateTiming takes a SyncNotifyFlag parameter. This is passed to
UpdateFinishedState where it determines how we handle finish actions.
If it is async we queue a microtask where we re-evaluate if the animation is
finished or not before queuing events / resolving promises.
That allows code like the following to _not_ trigger finish events:
```
const animation = elem.animate({...}, 1000);
animation.currentTime += 1000;
animation.effect.updateTiming({ duration: 2000 });
```
(Since the check that the animation is finished will run in a microtask _after_
the call to updateTiming.)
When the flag is "sync" we still don't _actually_ run the finish actions
entirely synchronously: the finished promise is resolved synchronously, but
resolving a promise actually queues a microtask for each callback. Likewise, the
finish event is queued synchronously, but not dispatched.
Since there should be no opportunity for script to run between when we call
Animation::Tick and when we run the next microtask checkpoint (currently at the
end of DocumentTimeline::WillRefresh but that will change slightly in the next
patch in this series) there is no need to introduce the extra "async" microtask
for re-evaluating an animation's finished state. Instead it should be possible
to use the "sync" finishing behavior. Such a change should be unobservable to
Web content but will reduce indirection somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D30318
