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
Drop the hack which prevents individual transform running on the
compositor thread.
Depends on D22566
Differential Revision: https://phabricator.services.mozilla.com/D22567
--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
For most of the functions we call on this frame there will be no difference in
result since the transform styles are inherited from the style frame to the
primary frame. However, for Combines3DTransformWithAncestors() at least, which
calls IsCSSTransformed(), the result will differ.
Differential Revision: https://phabricator.services.mozilla.com/D23283
--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
It took me a long time to understand why
KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to
KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that
while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more
generally useful. This will allow us to tidy up the various animation checks in
nsLayoutUtils later in this patch series.
Ultimately, however, we should make this check part of the regular compositor
animation vetting machinery in bug 1534884. That should remove a number of
inconsistencies such that we don't need the extended comments added in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D23281
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
Since bug 1524480 we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit when needed
in RestyleManager::ProcessRestyledFrames so that it is now redundant to also set
it from KeyframeEffect.
Furthermore, setting frame bits from KeyframeEffect is a little fragile since it
depends on the life cycle of the KeyframeEffect which is independent of the
nsFrame. If we can avoid doing that, we probably should.
Differential Revision: https://phabricator.services.mozilla.com/D21885
--HG--
extra : moz-landing-system : lando
We restrict the argument (i.e. `nsCSSPropertyIDSet`) of some functions is
the subset of other property set (e.g. transform-like properties), so
add this function for better readability.
Depends on D19629
Differential Revision: https://phabricator.services.mozilla.com/D21598
--HG--
extra : moz-landing-system : lando
Transform display item may have multiple properties, so it's better to
use display item type as the input.
Also, factor some code out of AddAnimationsForProperty, so we can easier
to extend this for multiple properties.
We will pass a list of layers::Animation to the compositor thread. In
this list, the animations belonging to the same property are grouped together,
so we can easily separate the animations by property and sample the animations
for each property on the compositor thread. (Will do this in Bug 1425837.)
Depends on D19628
Differential Revision: https://phabricator.services.mozilla.com/D19629
--HG--
extra : moz-landing-system : lando
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
--HG--
extra : moz-landing-system : lando
FrameLayerBuilder needs to clear this flag by DisplayItemType, so we add
a new function for it.
Differential Revision: https://phabricator.services.mozilla.com/D19630
--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
So we can let KeyframeEffect::ContainsAnimatedScale check individual
transforms, which is used by ActiveLayerTracker.
Depends on D19631
Differential Revision: https://phabricator.services.mozilla.com/D19525
--HG--
extra : moz-landing-system : lando
Let ActiveLayerTracker track individual transforms. (Will add
motion-path in the future.)
Besides, using a property set for transform and opacity is more efficient,
so let's change it. For background position, we use a different code path,
so we can have more restrictions in IsStyleAnimated.
Differential Revision: https://phabricator.services.mozilla.com/D19631
--HG--
extra : moz-landing-system : lando
nsIFrame::BuildDisplayListForStackingContext() will check the existence
of transform animations, so we need to update
nsLayoutUtils::HasAnimationsOfPoperty(). However, checking only
eCSSProperty_transform is not enough. We have to check all the transform-like
properties. Therefore, we update these functions to accept a property
set as the argument, and pass a collection of transform-like properties
into them.
Differential Revision: https://phabricator.services.mozilla.com/D20412
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
This is unrelated to this bug (the assertion can already fail without the
patches in this patch queue) but I uncovered it while writing the tests in the
next patch which will trip the assertion that is removed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D19885
--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
Without this fix, various tests in
dom/animation/tests/mozilla/test_restyles.html will fail once we remove the
style flush from KeyframeEffect::SetKeyframes. That is because we will fail to
set mCumulativeChangeHint correctly when we initially set up the keyframe's
properties and then never update it since UpdateProperties will return early
when it determines the properties have not changed.
Differential Revision: https://phabricator.services.mozilla.com/D18914
--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
Regarding the missing dom:: specifications, presumably this currently works
because in the unified build this file gets combined with something with "using
namespace mozilla::dom" but this will fail if the chunking of the unified build
changes.
Differential Revision: https://phabricator.services.mozilla.com/D18910
--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
After this I can pass the document from the caller to ResolveSameStructsAs, and
get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to
ResolveSameStructsAs, and get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--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
I don't know why this check was ever added. A comment here suggests we expected
irrelevant animations to be removed from their timeline:
https://hg.mozilla.org/mozilla-central/rev/8406c5300ab7051ae6fe9bf41a1d30261cf70a4a#l2.16
Furthermore, a comment in the changeset description for that same changeset
suggests that to be the case:
"For example, if a CSS animation is finished (IsRelevant() == false so that
animation will have been removed from the timeline)"
Another comment removed in that patch has:
"Note that we only store relevant animations on the timeline since they are
the only ones that need ticks and are the only ones returned from
AnimationTimeline::GetAnimations"
which suggests it was added a point when we had a GetAnimations() method on
AnimationTimeline and hence it was needed for that.
The other possibility is that we were preempting a point when timelines would
switch between being active and inactive:
"FIXME: Once we expect animations to go back and forth betweeen being inactive
and active, we will need to store more than just relevant animations on the
timeline. This is because an animation might be deemed irrelevant because its
timeline is inactive. If it is removed from the timeline at that point the
timeline will have no way of getting the animation to add itself again once it
becomes active."
Indeed, we might need this for ScrollTimelines. For now, however, it seems
unnecessary (a try run with simply this check removed passes all test).
(Furthermore, in bug 1253476 or one of its dependencies, this check will prevent
us from combining filling animations since the original (filling) animations
will be kept alive by the timeline. Should this indeed prove necessary for bug
1253476, that bug will add an automated test that will fail if we re-introduce
this condition.)
Differential Revision: https://phabricator.services.mozilla.com/D17798
--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
As per the following spec change:
4ec1deb76a
Spec issue:
https://github.com/w3c/csswg-drafts/issues/3193
Of the added test cases, only the last one, "Returns reversed animations yet to
reach their active phase" fails without this code change. The others pass
because the animation is finished at that point but I added them for consistency
with the previous tests.
Differential Revision: https://phabricator.services.mozilla.com/D16001
--HG--
extra : moz-landing-system : lando
Boris Chiou
Edwin Gao
Brian Birtles
Emilio Cobos Álvarez
Ryan Hunt
James Willcox
Andreea Pavel
Razvan Maries
sotaro
Margareta Eliza Balazs
Ehsan Akhgari
Oana Pop Rus