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
--HG--
extra : moz-landing-system : lando
(The pref is about to be removed, but even before its removal, it defaults to
'true' so these tests don't need to bother setting/checking it.)
Differential Revision: https://phabricator.services.mozilla.com/D33805
--HG--
extra : moz-landing-system : lando
In particular:
- The tests test_disabled_properties.html and
test_animations_with_disabled_properties.html just want to be able to toggle
some pref to turn off some property. So, this patch changes them to use a more
recently-added pref-controlled property (-webkit-line-clamp). (We'll probably
have to update these tests again when we eventually remove the pref for that
property. Oh well.)
- The tests 1265611-1.html and test_transitions_with_disabled_properties.html
are more picky -- they require a pref-controlled property **whose initial value
is 'currentcolor'**. We don't have any such property anymore, once the
layout.css.prefixes.webkit pref is removed. For the crashtest, we might as
well keep the test, with a disclaimer that its tested codepath has changed.
And for the mochitest, we can't really "fix" the test, so let's just remove
it. (We can take some comfort in knowing that the still-present test
'test_animations_with_disabled_properties' is very similar and covers some of
the same codepaths.)
Differential Revision: https://phabricator.services.mozilla.com/D33804
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
We want to set the performance warning by a property set, so update it.
Besides, add more tests for individual transforms (translate, rotate,
scale).
Differential Revision: https://phabricator.services.mozilla.com/D19633
--HG--
extra : moz-landing-system : lando
We should also throttle other transform-like animations which can run on
the compositor thread, on visibility hidden element without 0% or 100%
keyframe.
Depends on D22568
Differential Revision: https://phabricator.services.mozilla.com/D19634
--HG--
extra : moz-landing-system : lando
This also adds the missing preference in test_transition_per_property.html.
Depends on D22567
Differential Revision: https://phabricator.services.mozilla.com/D22568
--HG--
extra : moz-landing-system : lando
Disabled all instances of test_event_listener_leaks.html scattered across the `dom/` test suite.
There exists a bug, 1530894 to track the failures, which has seen no movement for the 3 weeks it has been on file for.
Differential Revision: https://phabricator.services.mozilla.com/D23755
--HG--
extra : moz-landing-system : lando
There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*)
because the intention of the caller is not clear. If it is called for the
primary frame of display:table content do we expect it to get the EffectSet
associated with the style frame or not? Generally it depends on if we are
looking for transform animations or not.
Rather than inspecting each call site and making it choose the appropriate frame
to use, this patch introduces a new method to EffectSet to get the appropriate
EffectSet based on the properties the caller is interested in.
This patch also uses this function in FindAnimationsForCompositor which in turns
fixes the glitching observed on Tumblr that arose since a number of places in
our display list code were passing the style frame to
EffectCompositor::HasAnimationsForCompositor.
Over the remainder of this patch series we will convert more callers of
EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming
EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the
method is intended to work.
Differential Revision: https://phabricator.services.mozilla.com/D23282
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
A forthcoming spec change will require that Animatable.animate() and other
methods that mutate animations do not flush style:
https://github.com/w3c/csswg-drafts/issues/3613
Bug 1525809 will add web-platform-tests for this change once it is made (and
tweak the behavior introduced in this patch if necessary).
Currently Firefox and WebKit will flush styles when calling
Animatable.animate(). This is undesirable since this method will _also_
invalidate style. As a result, if content triggers multiple animations in
a single animation frame, it will restyle every time it creates an animation.
This patch removes the style flush from a number of these methods.
In general the style flush is not necessary. For example, we don't need to flush
style before getting the computed style to pass to UpdateProperties. That's
because if there are pending style changes, then UpdateProperties will be called
with the updated style once they are applied anyway. Flushing style first means
that we may end up resolving style twice, when once would be sufficient.
For GetKeyframes() however, when used on a CSS animation, it should return
the most up-to-date style so for that call site we *do* want to flush style.
The test case added in this patch will fail without the code changes in the
patch. Specifically, we will observe 10 non-animation restyles (from the
5 animations) if we flush styles from SetKeyframes.
Differential Revision: https://phabricator.services.mozilla.com/D18916
--HG--
extra : moz-landing-system : lando
test_missing-keyframe-on-compositor.html assumes that calling Element.animate()
will flush style and trigger transitions. However, in this patch series we will
make Element.animate() stop flushing style (and the spec will also mandate
this). Once we do that, the expected transitions will no longer fire and this
test will fail. This patch updates the test to explicitly trigger transitions
before calling Element.animate().
Differential Revision: https://phabricator.services.mozilla.com/D18915
--HG--
extra : moz-landing-system : lando
Typically we set the NS_FRAME_MAY_BE_TRANSFORMED bit on a frame when one of the
following situations arises:
a. We update the keyframes of a KeyframeEffect to include transforms or we
create a new KeyframeEffect that animates transforms (in
KeyframeEffect::SetKeyframes), or
b. We retarget a KeyframeEffect with transforms at a new element (in
KeyframeEffect::SetTarget), or
c. We create an nsFrame with transform animations applied to it (in
nsFrame::Init), or
d. We get a nsChangeHint_AddOrRemoveTransform hint in
RestyleManager::ProcessRestyledFrames and decide to update the frame bit on
the frame and its continuations accordingly.
However, there are some situations where we can have a transform animation on
a frame where none of the above are triggered.
For example, if the style frame is not unavailable (e.g. a display:none
element) when the KeyframeEffect is initialized we will fail to the frame bit in
(a) and if we never retarget the effect we will never set reach (b).
Furthermore, if we have an animation that is "not relevant" (e.g. idle) and
hence not registered with the EffectSet when the frame is initialized we will
fail to set the frame bit in (c).
Finally, if the the animation does not produce a style change that causes the
nsChangeHint_AddOrRemoveTransform bit to be set (e.g. the transform animation
begins at 'none') we will not set the frame bit in (d).
As a result, we can end up failing to set the NS_FRAME_MAY_BE_TRANSFORMED bit
for some content.
The crashtest included in this patch produces such a case and, without the code
changes in this patch, will fail the assertion in ApplyRenderingChangeToTree[1]:
NS_ASSERTION(!(aChange & nsChangeHint_UpdateTransformLayer) ||
aFrame->IsTransformed() ||
aFrame->StyleDisplay()->HasTransformStyle(),
"Unexpected UpdateTransformLayer hint");
That is because although the nsChangeHint_UpdateTransformLayer bit will be set,
aFrame->IsTransformed() will return false because the frame bit has not been
set, and aFrame->StyleDisplay()->HasTransformStyle() will return false because
the animation sets the transform to 'none'.
Not only will this assertion fail, but once we cease flushing style as part of
triggering an animation later in this patch, the reftest
layout/reftests/web-animations/stacking-context-transform-changing-effect.html
will begin to fail. That reftest produces a similar situation to the crashtest
but it currently does not fail because the style flush that happens as part of
creating an animation ensures the style frame is available at the point when the
animation is triggered and hence case (a) from above is hit.
This patch addresses this by detecting the case where we have this change hint
set but not the corresponding frame bit, and setting the frame bit.
[1] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/layout/base/RestyleManager.cpp#1191-1199
Differential Revision: https://phabricator.services.mozilla.com/D18911
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
Bug 1508522 relaxed async animation size restriction with WebRender. Then test_animation_performance_warning.html also needs to be updated to accept it.
Differential Revision: https://phabricator.services.mozilla.com/D17470
--HG--
extra : moz-landing-system : lando
Performance of sync animation with large images is worse with WebRender than non-WebRender case. We want to use async animation as much as possible and relax aysnc animation size restriction. With WebRender, memory usage increase for async animation is limited compared to non-WebRender case. Image does not needs additional TextureClient allocation for async animation and majority of frames are comverted to WebRenderCommands. Then we could relax aysnc animation size restriction with WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D16791
--HG--
extra : moz-landing-system : lando
This is a first step to share LengthOrPercentage representation between Rust and
Gecko.
We need to preserve whether the value came from a calc() expression, for now at
least, since we do different things depending on whether we're calc or not right
now. See https://github.com/w3c/csswg-drafts/issues/3482 and dependent bugs for
example.
That means that the gecko conversion code needs to handle calc() in a bit of an
awkward way until I change it to not be needed (patches for that incoming in the
next few weeks I hope).
I need to add a hack to exclude other things from the PartialEq implementation
because the new conversion code is less lossy than the old one, and we relied on
the lousiness in AnimationValue comparison (in order to start transitions and
such, in [1] for example).
I expect to remove that manual PartialEq implementation as soon as I'm done with
the conversion.
The less lossy conversion does fix a few serialization bugs for animation values
though, like not loosing 0% values in calc() when interpolating lengths and
percentages, see the two modified tests:
* property-types.js
* test_animation_properties.html
Differential Revision: https://phabricator.services.mozilla.com/D15793
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
We manually implement ComputeSquaredDistance for Translate, Rotate, and
Scale because we have to handle mismatch cases, and actually we don't
need to implement it for specified types.
Depends on D11934
Differential Revision: https://phabricator.services.mozilla.com/D11935
--HG--
extra : moz-landing-system : lando
It's worth to serialize the timing function from web animation api with
servo, too. However, we need an FFI to do that, so this patch also add a
new FFI.
Depends on D10443
Differential Revision: https://phabricator.services.mozilla.com/D10444
--HG--
extra : moz-landing-system : lando
For now, we keep supporting the prefixed version, since there are examples/instructions
on the Web that don't include an unprefixed value.
Differential Revision: https://phabricator.services.mozilla.com/D10451
--HG--
extra : moz-landing-system : lando
For some content both transitions and animations are triggered simultaneously.
As a result of bug 1301305, if the set of animations includes animations that
affect geometry, then we ensure that any transform animations are run on the
main thread, rather than on the compositor.
However, we have observed some content where this synchronizing is not necessary
and produces unnecessary jank. In the particular cases we have observed,
the transitions and animations do not need to be synchronized so this patch
refines the approach from bug 1301305 to only synchronize within the set of CSS
transitions or the set of non-transition animations.
Differential Revision: https://phabricator.services.mozilla.com/D10328
--HG--
extra : moz-landing-system : lando
This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
--HG--
extra : moz-landing-system : lando
When a compositor animation finishes that doesn't apply a fill, rather than
jumping back to the underlying value immediately we should apply a fill mode
until the main thread has a chance to remove the animation from the compositor.
This ensures that any main thread effects that are intended to synchronize with
the end of the animation have a chance to run before we show the underlying
style and helps to avoid flicker in such cases.
Currently we apply this synthesized fill mode to animations when they run
forwards (i.e. positive playback rate), but not backwards. This patch makes us
apply the same handling when running in reverse.
Differential Revision: https://phabricator.services.mozilla.com/D7259
--HG--
extra : moz-landing-system : lando
According to the new svg 2 spec update (#543), we flip the flag half way for
path interpolation.
Differential Revision: https://phabricator.services.mozilla.com/D6192
--HG--
extra : moz-landing-system : lando
