We already avoid scene rebuilding for animated image frame updates, but
we can easily apply this to still images. If the decoding is happening
slowly and in chunks for some reason (really large image, slow network),
then we may save some work.
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
--HG--
extra : moz-landing-system : lando
So that it's easily available during painting.
The flag is set based on nsIPresShell::mIsFirstPaint, but the pres shell
flag is cleared at the beginning of the paint, so we can't query it from
the pres shell during the paint.
Differential Revision: https://phabricator.services.mozilla.com/D16237
--HG--
extra : moz-landing-system : lando
References to shared surfaces are already kept alive for the blob in the
content process, and it also ensures an image key is created to ensure
any release of the surface is delayed until the next epoch. Wrapped
shared surfaces (when used in an animation which is recycling its
surfaces) did not get an image key created which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D16191
If an item in a blob image gets a new parent container which clips it to
a smaller area than it was previously, we need to ensure the dirty rect
does not take into account the new clip when determining the old
intersection area. Instead now all old rects for an image are clipped to
the image bounds, rather than the image bounds clipped to the aggregate
of the ancestor containers.
Differential Revision: https://phabricator.services.mozilla.com/D16855
We are using the unrounded dest rect to calculate the image decode size
in ComputeImageContainerDrawingParameters, while passing the rounded
dest rect to WebRender. This mismatch causes images to be decoded to one
size and display at another, cause some visual distortions. Using the
correct rect seems to allow us to remove the extra snapping logic added
to work around this.
At this time, how we snap is different between WebRender and
non-WebRender in general. This patch will likely morph again once we
bring the two models closer together.
Differential Revision: https://phabricator.services.mozilla.com/D15739
If an item in a blob image gets a new parent container which clips it to
a smaller area than it was previously, we need to ensure the dirty rect
does not take into account the new clip when determining the old
intersection area. Instead now all old rects for an image are clipped to
the image bounds, rather than the image bounds clipped to the aggregate
of the ancestor containers.
Differential Revision: https://phabricator.services.mozilla.com/D16855
WebRender can handle small image without much overhead. Allowing
small images will give us more predictable behaviour because
we don't end up merging things unneccessarily.
Differential Revision: https://phabricator.services.mozilla.com/D16337
--HG--
extra : moz-landing-system : lando
So that it's easily available during painting.
The flag is set based on nsIPresShell::mIsFirstPaint, but the pres shell
flag is cleared at the beginning of the paint, so we can't query it from
the pres shell during the paint.
Differential Revision: https://phabricator.services.mozilla.com/D16237
--HG--
extra : moz-landing-system : lando
References to shared surfaces are already kept alive for the blob in the
content process, and it also ensures an image key is created to ensure
any release of the surface is delayed until the next epoch. Wrapped
shared surfaces (when used in an animation which is recycling its
surfaces) did not get an image key created which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D16191
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Discard animations after calling WrBridge()->EndTransaction(). It updates mWrEpoch in WebRenderBridgeParent. The updated mWrEpoch is necessary for deleting animations at the correct time.
Differential Revision: https://phabricator.services.mozilla.com/D15799
This shouldn't change any behaviour, just puts the code into a separate function so that it's easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D15794
--HG--
extra : moz-landing-system : lando
CONTENT_FRAME_TIME_VSYNC is more meaningful metric because it actually
starts at the beginning of the vsync making it easier to reason about
missing frames. It makes more sense for CONTENT_FRAME_TIME_REASON wants
to use this same starting point.
Differential Revision: https://phabricator.services.mozilla.com/D15790
--HG--
extra : moz-landing-system : lando
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time.
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time.
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time..
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
It perhaps makes more sense to use the start of refresh but I'd like to switch
to the start of the paint so that we get more consistent results between the
two probes.
Differential Revision: https://phabricator.services.mozilla.com/D15236
--HG--
extra : moz-landing-system : lando
Currently we use the regular fallback path for the mask images used by blobs.
This isn't really the best fit and is causing test failures with the current
blob re-coordination patches.
This changes the code to be more FrameLayerBuilder and handles
invalidation of the mask without using FrameLayerBuilder.
Differential Revision: https://phabricator.services.mozilla.com/D14779
--HG--
extra : moz-landing-system : lando
Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
This commit contains the Gecko-side changes from WebRender PR#3277:
- Dedicated DirtyRect type.
- Separate the blob image APIs from regular image ones.
Differential Revision: https://phabricator.services.mozilla.com/D12463
--HG--
extra : moz-landing-system : lando
This lets us avoid having to put usize in the exported signatures from bindings.rs
It also avoids a heap allocation when defining a clip chain.
Differential Revision: https://phabricator.services.mozilla.com/D12785
--HG--
extra : moz-landing-system : lando
Here we make use of the parts added in parts 1 and 2 to hold onto
recycled surfaces for as long as necessary to prevent the animated image
decoder from reusing them until WebRender is done with them.
Differential Revision: https://phabricator.services.mozilla.com/D10902
When we replace the external image ID an image key points to, the
previous external image ID may still be used by WebRender. We currently
wait until the frame has been rendered to release our hold on said
surface. With this patch, we will communicate the image key and previous
external image ID pairing to the owning process when releasing to let it
know that it can reuse it (e.g. for an animated image). Additionally we
now use the new textures updated checkpoint which should happen sooner
than the frame rendered checkpoint, but guarantee that WebRender is no
longer using the old external image ID.
Differential Revision: https://phabricator.services.mozilla.com/D10897
Previously, WebRender ignored clip_node_id on the clip/scroll stack
when pushing clips or reference frames. This got fixed to be more consistent in:
https://github.com/servo/webrender/pull/3315
Now Gecko can use the clip chains generated for display items naturally,
instead of smuggling the last clip through the scroll_node_id, which is what
was happening in this hacky code branch being removed.
Differential Revision: https://phabricator.services.mozilla.com/D12216
--HG--
extra : moz-landing-system : lando
Previously, the ASR overrides contained Maybe<ClipId>, where Nothing() corresponded to taking the top of the clip/scroll stack instead of overriding. This change removes the associated complexity by ensuring that we always provide the ClipId.
Differential Revision: https://phabricator.services.mozilla.com/D11813
--HG--
extra : moz-landing-system : lando
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
--HG--
extra : moz-landing-system : lando
If the parent item is removed our assertions will be wrong because
the parent item's bounds will not be added to the invalid rect until
after we've traversed all of the items. Further, the new unbounded rect
for the child item won't be added to the invalid rect unless we do it
ourselves. This makes sure we add the old and new rects to the invalid
rect.
Differential Revision: https://phabricator.services.mozilla.com/D11724
--HG--
extra : moz-landing-system : lando
This makes sure we don't end up with stale entries with geometry clipped
to the previous mImageBounds on the receiving side.
The update code is duplicated for now but will hopefully be cleaned up
after the blob re-coordination work is done.
Differential Revision: https://phabricator.services.mozilla.com/D11566
--HG--
extra : moz-landing-system : lando
This sets a placeholder transform on the root stacking context for the
content display list, and allows us to modify that transform directly in
the compositor. This is similar to what
nsDisplayOwnLayer::CreateWebRenderCommands does for scroll thumb layers,
which are similarly manipulated by APZ for async scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D11180
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
In ClipManager::DefineScrollLayers, we don't always create a scroll ID
for each ASR. We may fail to get the scroll metadata, or it may not be
scrollable, in which case we should use the scroll ID of its ancestor
(or the root scroll ID if there is no ancestor). This should fix a crash
where we simply assumed the leaf of an ASR tree will always have a valid
scroll ID.
Differential Revision: https://phabricator.services.mozilla.com/D10708
This patch allows us to intercept invalidation requests for display
items, and avoid regenerating the display list for animated images which
are using SharedSurfacesAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D7504
Animated images will work by changing the external image ID that an
ImageKey points to. We cannot allow the old external image to be
released and potentially unmapped until we have produced a new frame
with the new external image ID. We currently wait until the epoch has
advanced, but in the future when we don't rebuild the scene to animate
an image, the epoch will remain the same. This could cause us to hold
onto no longer used surfaces for much longer than expected. As such, in
this patch we switch to waiting for a FrameRendered notification from
WebRender, which works even if the scene rebuild was avoided.
Differential Revision: https://phabricator.services.mozilla.com/D7500
Animated images will require scheduling a composite of the frame in
addition to updating the ImageKey/external image ID bindings. It would
be good if this could be done as part of the same IPDL message.
Additionally a page may have many animated images that we update the
frame for at the same time, so these updates should be batched together.
In the event that we needed to regenerate the display list, or produce
an empty transaction, ideally we would just throw these resource updates
in with the rest of the changes. This patch allows us to do all of that
without unnecessarily burdening the caller with tracking extra state.
Differential Revision: https://phabricator.services.mozilla.com/D7499
Async animated images need a single ImageKey which can point to any
frame represented by its own external image ID. Additionally a frame
could be referenced again directly (e.g. something shows/uses the first
frame of the animated image).
Before this patch, the ownership between an ImageKey and an external
image ID for a shared surface was not clearly expressed. This resulted
in a special command to release the reference to the external image
separately from deleting the image key.
This patch makes the strong reference to an external image ID and an
ImageKey directly related. Not only does this facilitate multiple
ImageKeys owning the same surface, it also simplifies the ownership
semantics.
Differential Revision: https://phabricator.services.mozilla.com/D7520
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items in a row with different
ASRs. In this case, when we encounter the nested transform item that we
want to defer, we need to flush the previously-deferred transform item
into a WebRenderLayerScrollData item. This patch accomplishes that, and
includes a mochitest that exercises the relevant behaviour.
Depends on D8110
Differential Revision: https://phabricator.services.mozilla.com/D8111
--HG--
extra : moz-landing-system : lando
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items before encountering the
APZ-relevant display item. In this case we need to somehow accumulate
all the deferred transforms. This patch accomplishes that, and includes
a mochitest that exercises the relevant behaviour.
Depends on D8109
Differential Revision: https://phabricator.services.mozilla.com/D8110
--HG--
extra : moz-landing-system : lando
This code will be expanded a bit in the next few patches, so hopefully
the comments here provide a reasonable explanation of what this code is
about.
Differential Revision: https://phabricator.services.mozilla.com/D8108
--HG--
extra : moz-landing-system : lando
On android with webrender enabled, minimising the app results in an
assertion failure: CompositorBridgeParent::DidComposite asserts that
it should not be called with a webrender compositor.
This makes it so that that in CompositorBridgeParent::PauseComposition
we call NotifyPipelineRendered instead of DidComposite for webrender
compositors.
Differential Revision: https://phabricator.services.mozilla.com/D10563
--HG--
extra : moz-landing-system : lando
Similar to bug 1471671, we are seeing missing scroll metadata in cases
we do not expect that, and have been observing low volume crashes in the
wild as a result. It appears that in the non-WR path, it skips such items,
so we should probably do the same thing with WebRender. If it is a real
problem, we will hopefully get a reproducible test case from a user if
scrolling fails for them.
Differential Revision: https://phabricator.services.mozilla.com/D9815
We are seeing crash reports in the wild where there is no scroll
metadata available for an ASR for a display item and its clip. It
appears that in the non-WR path, it skips such items, so we should
probably do the same thing with WebRender. If the scrolling ends up
being wrong, hopefully a reproducible use case will make its way to use
to further debug, as the crash reports have not yielded anything to date.
Differential Revision: https://phabricator.services.mozilla.com/D9699
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
Using layer scaling confuses the filter code (see bug 1497239).
Right now we're sort-of double-scaling. Looks like what the filter code expects
is just getting the scaling passed down, see bug 1224207.
Differential Revision: https://phabricator.services.mozilla.com/D8910
--HG--
extra : moz-landing-system : lando
When a CompositorBridgeParent receives a force first paint message, it
sets the flag on the AsyncCompositionManager, which notifies the
widget code at the next composite via
UiCompositorControllerParent::NotifyFirstPaint().
With webrender, this is crashing as there is no
AsyncCompositionManager. And even if it weren't crashing, the widget
will never receive the first paint message, so it never uncovers its
content.
This change ensures the widget receives the first message when
webrender is enabled. CompositorBridgeParent will set the flag on its
WebRenderBridgeParent, which will set the flag on the next received
display list. When the WebRenderBridgeParent flushes the corresponding
transaction, it calls UiCompositorcontrollerParent::NotifyFirstPaint,
to ensure the widget code gets the message.
Differential Revision: https://phabricator.services.mozilla.com/D9250
--HG--
extra : moz-landing-system : lando
We need to correctly populate the cumulative resolution field in the
ScrollMetadata in order to support zooming. Without this, the cumulative
resolution doesn't include the presShell resolution, and that results in
APZ getting into an inconsistent state.
Currently, the cumulative resolution is populated from the
ContainerLayerParameters object's scale, but in the case of WebRender,
we call ComputeScrollMetadata with an empty ContainerLayerParameters
since don't actually do layer building or rasterization in Gecko.
This patch makes this more explicit by changing the argument to a
Maybe<ContainerLayerParameters> and passing Nothing() from the WebRender
call sites.
In this scenario, we just use the cumulative presShell resolution as
the cumulative resolution, which should be correct for WebRender as
we won't have an "extra" CSS-derived resolution applied on the Gecko
side.
Depends on D9120
Differential Revision: https://phabricator.services.mozilla.com/D9121
--HG--
extra : moz-landing-system : lando
I'll file a followup bug to deal with the fallback transition going wrong.
I don't know why it'd be fine to not apply the scale to SVG wrappers, but on my
quick testing I didn't manage to break it, so I'll spend a bit more time trying
to do that...
Differential Revision: https://phabricator.services.mozilla.com/D8013
--HG--
extra : moz-landing-system : lando
Andrew Osmond
Greg Tatum
Emilio Cobos Álvarez
Brindusan Cristian
Sylvestre Ledru
Daniel Varga
Jeff Muizelaar
Botond Ballo
Margareta Eliza Balazs
Ehsan Akhgari
Gurzau Raul
Narcis Beleuzu
Andreea Pavel
Dorel Luca
Cosmin Sabou
Csoregi Natalia
WR Updater Bot
Dzmitry Malyshau
Matt Woodrow
Oana Pop Rus
Doug Thayer
sotaro
Bas Schouten
Lee Salzman
Razvan Maries
Coroiu Cristina
Timothy Nikkel
Kartikaya Gupta
Ciure Andrei
Nicolas Silva
Bogdan Tara
Jonathan Watt
Jeff Muizelaar
Hiroyuki Ikezoe
Ryan Hunt
Jamie Nicol
Ryan VanderMeulen