There's no need to lazily create a renderer here. We already avoided
this in content processes, but there's no need to do so in the parent
process either.
This shouldn't change behavior, but might help with bug 1772691, and
generally seems cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D148337
We don't send the animation to the compositor if it's scroll-timeline is
inactive (e.g. no layout frame or no scrollable frame).
Besdies, we also add a new struct, ScrollTimelineOptions, to represent
scroll timeline information in the IPC messages.
This patch handles the main thread side, and extract the information
from the transaction and store into AnimationStorageData.
We will sample ths scroll animations later in the patch series.
Differential Revision: https://phabricator.services.mozilla.com/D140548
It's non WebRender specific, so it will not be a problem on Fission,
additionally it's not used on non WebRender with retained display stuff
either.
Differential Revision: https://phabricator.services.mozilla.com/D121929
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
In SVG frame tree SVG{Inner,Outer}Frame is normally not scrollable but clips
descendants, thus nsLayoutUtils::GetNearestScrollableFrame is not able to find
the clip/scroll frame. So in this change, we introduce
GetNearestOverflowClipFrame which is a similar function to
GetNearestScrollableFrame but it also checks whether the frame is SVGInnerFrame
or SVGOuterFrame which is clipping the given nsIFrame during walking up the
frame tree.
In this change we also change the logic to get the clip/scroll frame and the scroll
id as follows;
1) Get the nearest overflow clip frame in the same document
2) Use the root frame if there is no clip frame
3) Then try to find the scroll id if the clip frame is asynchronously scrollable
so that it becomes clearer before. It's still messy though.
Differential Revision: https://phabricator.services.mozilla.com/D90647
On WebRender there is no layer tree structures so that we can't accumulate
transform values up to the nearest APZ's scroll layer by walking up the layer
tree, or we can't tell a given transform animation is inside a perspective layer
to decide whether we need to apply the offset from the reference frame or not
[1]. So we get the accumulated transform by using
nsLayoutUtils::GetTransformToAncestor on the main-thread and inform it to the
compositor thread, and also inform the offset which is set conditionally [2]
so that we don't need to tell whether the transform animation is inside a
perspective layer or not on the compositor thread.
I am not yet 100% sure that these values are same both on WebRender and non
WebRender in all cases, once after partial pre-rendering transforms have
been used in the wild well enough and any problem has not appeared, even if
there are problems we should fix them then the non WebRender version should
eventually use this same setup instead of walking up the layer tree.
[1] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/gfx/layers/CompositorAnimationStorage.cpp#273-275
[2] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/layout/painting/nsDisplayList.cpp#7879-7891
Differential Revision: https://phabricator.services.mozilla.com/D83201
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
The benefits are:
1. For the rest `layers::Animation`s, their `TransformData` are `Nothing()`,
so we can avoid any posisible copy.
2. In the compositor, we move `TransformData` out of the array, and use
`UniquePtr` to avoid including AnimationHelper.h into AnimationInfo.h,
which causes some compilation errors because LayersMessages.h is not
visible in AnimationInfo.h.
Differential Revision: https://phabricator.services.mozilla.com/D57751
This function was added for B2G actually, to check if the layer has OMTA for
painting high-res layer. However, It's worth to let it also check other
OMTA transform-like properties.
Depends on D22565
Differential Revision: https://phabricator.services.mozilla.com/D19636
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
