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
I thought it was going to be trivial to add a test-case for this with a scale
transform and such, but I haven't been able to.
This restores the wallpaper that there was before my change.
Differential Revision: https://phabricator.services.mozilla.com/D8000
--HG--
extra : moz-landing-system : lando
To avoid trimming pixels at the top / left.
This makes it closer to non-WR[1], and fixes both the checkboxes getting
cut off and the master password field.
[1]: non-WR at least at 124 scaling on a hiDPI display is still perfect, though I saw nin symmetric borders at other resolutions, so we might be able to improve here further.
Differential Revision: https://phabricator.services.mozilla.com/D7251
--HG--
extra : moz-landing-system : lando
When scrolling on Twitter video frames can sometimes be drawn with a flicker
above or below them. This is because the bounds for video frames' images that
we pass to WebRender are not rounded to pixel boundaries, and so they can end
up being rounded off in WebRender unexpectedly when composited.
So round off the bounds of video frame images to device pixel boundaries before
passing to WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D6857
--HG--
extra : moz-landing-system : lando
Prevent future ambiguous conversion once a bit depth int is added.
Also more self-explanatory
Differential Revision: https://phabricator.services.mozilla.com/D6662
--HG--
extra : moz-landing-system : lando
This allows us to invalidate individual items inside of the mask instead of
treating the mask and it's children as a single item.
Differential Revision: https://phabricator.services.mozilla.com/D6224
It isn't possible to trigger this code currently because
the only way to have an inactive 3d transform is with a mask
or filter item and those get handled with a BasicLayerManager.
This becomes necessary once we handle mask items internally.
Differential Revision: https://phabricator.services.mozilla.com/D6222
Introduce an ImageRendering argument for CreateImageKey which is then used at the CreateAsyncImageWebRenderCommands call to provide the proper filtering instead of using always Auto filtering. Update all calls to CreateImageKey to use the new interface.
We can't rely on the FrameID continuity to determine if a frame has been dropped due to timing or not.
The reason being that the VideoSink will not send to the compositor frames it knows as being late already (causing a discontinuity in the frames IDs), and count them as being dropped.
If we were to look at discontinuity on the compositor we would account for those frames twice.
FramesID will also increase non-linearly if a frame isn't painted because it's not visible (either out of the visible tree or in a hidden tab).
What we can measure however, is when a frame should have been painted but didn't because it was too late by looking at the value returned by ImageComposite::ChooseImageIndex() or when a new set of images is being received by the ImageComposite.
Any images found in the earlier array but never returned must have been dropped due to timing.
Looking at the index continuity greatly simplify the logic as we no longer need to worry if a video is hidden or not, or be part of a layer that is itself hidden as neither SetImages will be called then, nor ChooseImage
For now, we only account for those frames dropped, and do not report them yet.
Differential Revision: https://phabricator.services.mozilla.com/D2176
We will use the characteristic of which TimedImage is returned to keep track on how many frames were dropped because they were too old. As such, we must make sure the retrieval of the current image is serialised.
This allows to reduce duplicated code between WebRenderImageHost and ImageHost classes.
Additionally, make RenderInfo::img member const as really, we never want to modify that one.
A future change will enforce that RenderInfo.img never survives longer than the ChooseImage()'s caller to clarify the lifetime of the TimedImage.
Differential Revision: https://phabricator.services.mozilla.com/D2175
When the namespace changes (e.g. due to a tab move between windows), we
may get stale transaction requests that we need to ignore. In
WebRenderBridgeParent::RecvSetDisplayList, we would automatically send
any unsent transaction data when exiting the method, but this did not
take into account the staleness. This patch ensures we only flush the
data if we actually want it.
The transaction in question that was observed and causing crashes was
UpdateImageBuffer.
On the compositor we store animation values in a hash table and the hash is
the compositor animation id which is a unique id for each property respectively.
So we can get the corresponding animation value for the given property.
In this patch there are lots of duplicated code, but they will be removed in the
next patch.
MozReview-Commit-ID: 7EboVcculcg
--HG--
extra : rebase_source : 304ea80849af8af72a07437736041aeabbe47eeb
On the compositor we store animation values in a hash table and the hash is
the compositor animation id which is a unique id for each property respectively.
So we can get the corresponding animation value for the given property.
In this patch there are lots of duplicated code, but they will be removed in the
next patch.
MozReview-Commit-ID: 7EboVcculcg
--HG--
extra : rebase_source : 304ea80849af8af72a07437736041aeabbe47eeb
This restricts the active-item-detection code to wrap lists and
perspective items because other wrapper items are not supported yet.
MozReview-Commit-ID: JuirkAId7Kk
--HG--
extra : rebase_source : 971de2c56d183090bb9a8701af62ada493e39b77
This restricts the active-item-detection code to wrap lists because
other wrapper items are not supported yet.
MozReview-Commit-ID: JuirkAId7Kk
--HG--
extra : rebase_source : 5dbb8af8504f301ca49273b4f6f434a91524860a
The prefs, when enabled, will dump the gecko DL items followed by the
WR DL items that were generated from that gecko item. This allows us to
easily go from a DOM element with known id/class attributes to e.g. an
ImageKey of an image that was generated for that element.
Also, this logging can be enabled in CI builds just like gecko display-list
dumping, instead of the ifdef that we previously had in WebRenderLayerManager.
MozReview-Commit-ID: Eeo4iO62YY1
--HG--
extra : rebase_source : b4a348b2e8bced976489257b966f70b29c56df25
In some cases we get a gecko display list that looks like this:
WrapList with asr(<A>, <B>)
Item with asr (<B>) and clipchain(<something> [A])
In this case, we would initialize the WebRenderLayerScrollData for the
nested item using a stop-at ancestor of A (because that was the leafmost
ASR from the containing WrapList) but the item itself has an ASR of B,
which is an ancestor of A. So when walking up from B we'd never hit the
stop-at ancestor, and so we'd end up duplicating metrics from the
containing WRLSD onto the nested WRLSD. This generated an assertion
failure in the APZ code.
This patch detects this scenario and skips adding metrics on the nested
WRLSD. This produces an APZ tree equivalent to what the non-WebRender
path would produce.
MozReview-Commit-ID: 8eo6pzXXKBd
--HG--
extra : rebase_source : 0581c54c4d9fa6ca08249e42b306c7155022bec7
In the case of an invalid clip-path, the browser is supposed to discard the
mask entirely. In the non-webrender codepath this would happen
implicitly because the computed MaskUsage would have no flags set, and
so no actions would be taken on the gfxContext which contained the
display items rasterized so far. In the WebRender codepath, though, we
invoke the code on a A8 drawtarget that's zero-filled, so if PaintMask
fails to rasterize anything into it, it gets treated as a "mask everything
out" mask. Instead, this patch makes it so that we detect the scenario
where the computed MaskUsage is a no-op, and ensure that we don't apply
the mask in that case.
An alternative approach considered was to initialize the A8 drawtarget to
white instead of black but in cases where there is an actual mask, the
rest of the code assumes it is zero-filled and so that doesn't work.
MozReview-Commit-ID: Hw7nCiUXVJl
--HG--
extra : rebase_source : 241d550fa0ed1b3bd088c73d9565b166acbcece8
The client side can't get the GL context in CompositorOGL. So, it can't know
the texture direct mapping capability directly. This patch adds the texture
direct mapping info in TextureFactoryIdentifier. Then, the client side could
get the info form the TextureFactoryIdentifier.
MozReview-Commit-ID: KEazDVg0p9Y
--HG--
extra : rebase_source : 09ce1065cd076a3a5dc276f93837d608443c60a1
This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : 973253589d6c27138bd49f4d81b3e74c3fcf5022
extra : histedit_source : 5b126b0285b674d59d8bd4b7bda09a01804dc043
This commit adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 97b0a86c4a2905d098ab199d6d1a1fd00c58a46d
This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : acbf83d0071e8932b5e96016e6e39e27a7b4da8c
extra : histedit_source : a0f93f80441e5f45c0113244d15400d0f53d9c92
This commit adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 8ecb1f9146376ac84b84680a5a3454200c940d6a
Kartikaya Gupta
Nicolas Silva
Bogdan Tara
Dzmitry Malyshau
Ehsan Akhgari
Jonathan Watt
Matt Woodrow
Csoregi Natalia
sotaro
Jeff Muizelaar
Coroiu Cristina
Jeff Muizelaar
Andrew Osmond
Andreea Pavel
Gurzau Raul
Narcis Beleuzu
Hiroyuki Ikezoe
Razvan Maries
Ryan Hunt
Ciure Andrei
Jamie Nicol
Emilio Cobos Álvarez
Ryan VanderMeulen
Daniel Varga
shindli
Markus Stange
Daniel Zielas
arthur.iakab
Chris Pearce
Jean-Yves Avenard
Bas Schouten
Bobby Holley
Henrik Winnemöller
Margareta Eliza Balazs
Lee Salzman
Andi-Bogdan Postelnicu
Alexis Beingessner
Doug Thayer