This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
--HG--
extra : moz-landing-system : lando
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
--HG--
extra : moz-landing-system : lando
This prevents OS-produced momentum panning events from having an effect after
the user sees the momentum panning "end" due to scrolling as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D69624
--HG--
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
This patch is pretty uninteresting, just building the pipe to move data
from the main-thread to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D69555
--HG--
extra : moz-landing-system : lando
The GetIsStickyPosition function isn't really needed since we can distinguish
whether or not a layer is sticky via NULL_SCROLL_ID as the container id. Also
ensure we have proper AtBottomLayer checks where needed for fixed and sticky
data.
Differential Revision: https://phabricator.services.mozilla.com/D69554
--HG--
extra : moz-landing-system : lando
Instead of storing pointers to the nodes in the TreeBuildingState, and then
extracting information from them later, we can just extract the information
right away, put that in the TreeBuildingState, and move the final structure
into place.
This isn't possible with some of the other similar-looking structures that this
was presumably cargo-culted from (such as the one that holds the thumb
information) since those need to be able to look up references to other APZCs
which can only be done after the tree walk is complete.
Differential Revision: https://phabricator.services.mozilla.com/D69553
--HG--
extra : moz-landing-system : lando
It seems that first rendering to SwapChain was not handled by IDCompositionVisual2. Then, as shot term fix, force to do WR rendering twice during disabling WR native compositor. It could mitigate black flashing problem.
Differential Revision: https://phabricator.services.mozilla.com/D69677
--HG--
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
This patch is pretty uninteresting, just building the pipe to move data
from the main-thread to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D69555
--HG--
extra : moz-landing-system : lando
The GetIsStickyPosition function isn't really needed since we can distinguish
whether or not a layer is sticky via NULL_SCROLL_ID as the container id. Also
ensure we have proper AtBottomLayer checks where needed for fixed and sticky
data.
Differential Revision: https://phabricator.services.mozilla.com/D69554
--HG--
extra : moz-landing-system : lando
Instead of storing pointers to the nodes in the TreeBuildingState, and then
extracting information from them later, we can just extract the information
right away, put that in the TreeBuildingState, and move the final structure
into place.
This isn't possible with some of the other similar-looking structures that this
was presumably cargo-culted from (such as the one that holds the thumb
information) since those need to be able to look up references to other APZCs
which can only be done after the tree walk is complete.
Differential Revision: https://phabricator.services.mozilla.com/D69553
--HG--
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Depends on D69557
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
This patch is pretty uninteresting, just building the pipe to move data
from the main-thread to APZ.
Depends on D69554
Differential Revision: https://phabricator.services.mozilla.com/D69555
--HG--
extra : moz-landing-system : lando
The GetIsStickyPosition function isn't really needed since we can distinguish
whether or not a layer is sticky via NULL_SCROLL_ID as the container id. Also
ensure we have proper AtBottomLayer checks where needed for fixed and sticky
data.
Depends on D69553
Differential Revision: https://phabricator.services.mozilla.com/D69554
--HG--
extra : moz-landing-system : lando
Instead of storing pointers to the nodes in the TreeBuildingState, and then
extracting information from them later, we can just extract the information
right away, put that in the TreeBuildingState, and move the final structure
into place.
This isn't possible with some of the other similar-looking structures that this
was presumably cargo-culted from (such as the one that holds the thumb
information) since those need to be able to look up references to other APZCs
which can only be done after the tree walk is complete.
Differential Revision: https://phabricator.services.mozilla.com/D69553
--HG--
extra : moz-landing-system : lando
Back when webrender did not call FrameLayerBuilder::ChooseScale (it was called ChooseScaleAndSetTransform back then until it was factored out in bug 1415987) bug 1449640 landed which made the webrender scale choosing more closely align with FrameLayerBuilder::ChooseScale by not computing a scale of there was preserve3d or perspective involved. That patch had a bug, it looked at the parent stacking context helper to see if it had preserve 3d, but FrameLayerBuilder::ChooseScale looks at the current "stacking context".
This didn't cause a problem in the testcase from this bug until bug 1569215 landed. In the testcase in this bug we have a stacking context with a 2d transform whose parent stacking context is preserve3d. So we pass down the scale from the parent stacking context and completely ignore the scale induced by the 2d transform. Passing 1.f to ChooseScale instead of the parent scale factor "undid" this mistake, so when that was fixed we regressed this testcase.
Differential Revision: https://phabricator.services.mozilla.com/D69167
--HG--
extra : moz-landing-system : lando
This removes the WebRender side of the previous slow frame indicator and replace it with a simple implementation that only looks at the CPU time on the render backend and renderer thread involved for building a frame.
A followup patch will add a separate indicator for when the displaylist/ipc/scene bits take too long.
Differential Revision: https://phabricator.services.mozilla.com/D69247
--HG--
extra : moz-landing-system : lando
Nothing creates the content render root anymore, so we can delete
references to it and wipe it off the face of the codebase. This makes
the non-default render root array a zero-length Array which is a template
specialization that lacks things like begin() end end(). So we need
to also rip out any code that tries to iterate these things, in order
to get compilation to succeed. The code would be a no-op anyway now
that there are no non-default render roots left.
Depends on D68864
Differential Revision: https://phabricator.services.mozilla.com/D68865
--HG--
extra : moz-landing-system : lando
This also downgrades a bunch of WRRootId parameters back down to LayersId
in APZUpdater since APZUpdater doesn't need the render root information any
more.
Changes to comments generally restore the text that was there prior to the
document-splitting patch landing.
Differential Revision: https://phabricator.services.mozilla.com/D68396
--HG--
extra : moz-landing-system : lando
This is needed because display lists and DisplayItemCache have different lifetimes. For example, display lists can outlive WebRenderLayerManager when device reset occurs.
A slightly nicer way of fixing this would be to couple DisplayItemCache with nsDisplayList or nsDisplayListBuilder. This is would currently require a lot of refactoring to look nice, because the painting code still supports non-retained display lists and non-WR code paths.
Differential Revision: https://phabricator.services.mozilla.com/D68193
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68152
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
IsCurrentlyCheckerboarding can be removed now, as it does the same underlying
computation as "GetCheckerboardMagnitude(...) > 0". The only difference is that
the caller now needs to compute the clipped composition bounds, which is
easy enough to do at the one call site.
Differential Revision: https://phabricator.services.mozilla.com/D67377
--HG--
extra : moz-landing-system : lando
The goal of this patch is to enhance GetCheckerboardMagnitude so that it
correctly accounts for clipping by ancestor APZC instances, the same way
IsCurrentlyCheckerboarding does. However, IsCurrentlyCheckerboarding uses
the mParent parent pointer when computing the clipped composition bounds,
which requires the tree lock. GetCheckerboardMagnitude is not allowed to
acquire the tree lock as it runs on the sampler thread.
This patch therefore takes another approach: the APZCTreeManager code
precomputes the clipped composition bounds for each APZC (which it can do
relatively efficiently and holding just the map lock), and then provides
that rect to the individual APZCs when they invoke GetCheckerboardMagnitude.
The additional changes to GetCheckerboardMagnitude are copied from the
IsCurrentlyCheckerboarding codepath, and the next patch will remove the latter
function entirely since GetCheckerboardMagnitude will do everything that is
needed for IsCurrentlyCheckerboarding.
Differential Revision: https://phabricator.services.mozilla.com/D67376
--HG--
extra : moz-landing-system : lando
The operations of recording checkerboard events and advancing the animations
across all APZs are conceptually linked. This patch extracts a helper that
does these operations in a single function, that is then called from both
the WR and non-WR codepaths. This will allow us to expand this code a bit
without having to duplicate it in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D67374
--HG--
extra : moz-landing-system : lando
When you're zoomed inside a large text-area in GeckoView, we are zooming out
right now which is very disruptive and clearly not what the code intended.
Differential Revision: https://phabricator.services.mozilla.com/D67221
--HG--
extra : moz-landing-system : lando
This patch changes the underlying storage for WR display items in DisplayItemCache
from Vec<Option<CachedDisplayItem> to Vec<Vec<CachedDisplayItem>>.
This allows storing multiple WebRender display items for one Gecko display item.
The storage is populated by traversing BuiltDisplayList extra data portion
in display list format, which is roughly as follows:
RetainedItems(key k1)
Item1(..)
RetainedItems(key k2)
ItemN(..)
ItemN+1(..)
This would store Item1 under key k1, and ItemN and ItemN+1 under the key k2,
where k1 and k2 are arbitrary unique identifiers (currently of type uint16_t).
The entries in the storage are accessed by DisplayItemCache::get_iterator(key),
which is called by BuiltDisplayListIter, whenever it encounters a display item
DisplayItem::ReuseItems(key).
Differential Revision: https://phabricator.services.mozilla.com/D66443
--HG--
extra : moz-landing-system : lando
This patch changes the underlying storage for WR display items in DisplayItemCache
from Vec<Option<CachedDisplayItem> to Vec<Vec<CachedDisplayItem>>.
This allows storing multiple WebRender display items for one Gecko display item.
The storage is populated by traversing BuiltDisplayList extra data portion
in display list format, which is roughly as follows:
RetainedItems(key k1)
Item1(..)
RetainedItems(key k2)
ItemN(..)
ItemN+1(..)
This would store Item1 under key k1, and ItemN and ItemN+1 under the key k2,
where k1 and k2 are arbitrary unique identifiers (currently of type uint16_t).
The entries in the storage are accessed by DisplayItemCache::get_iterator(key),
which is called by BuiltDisplayListIter, whenever it encounters a display item
DisplayItem::ReuseItems(key).
Differential Revision: https://phabricator.services.mozilla.com/D66443
--HG--
extra : moz-landing-system : lando
The code in GetVisibleRect() uses the test scroll offset, but not the test zoom.
Using AutoApplyAsyncTestAttributes automatically uses both.
Differential Revision: https://phabricator.services.mozilla.com/D66956
--HG--
extra : moz-landing-system : lando
In addition:
- Move the fast hit tester to the rust side of the bindings.
- Avoid blocking by requesting a hit tester early and only blocking if the request isn't delivered by the time of the first hit test query.
Differential Revision: https://phabricator.services.mozilla.com/D66994
--HG--
extra : moz-landing-system : lando
GPUVideoTextureHost needs call wrapped TextureHost's PrepareTextureSource() and UpdatedInternal() for layer compositor.
Differential Revision: https://phabricator.services.mozilla.com/D66923
--HG--
extra : moz-landing-system : lando
This removes most dependencies on BlocksRingBuffer, to ease the transition to
the upcoming Fission-friendly profile buffer, including:
- Length type,
- SumBytes(),
- Gecko extensions of serialization.
Differential Revision: https://phabricator.services.mozilla.com/D66722
--HG--
rename : tools/profiler/public/BlocksRingBufferGeckoExtensions.h => tools/profiler/public/ProfileBufferEntrySerializationGeckoExtensions.h
extra : moz-landing-system : lando
If we don't wait for the click event before checking for the layerization,
then the layerization may not actually have happened at the time of the check.
Differential Revision: https://phabricator.services.mozilla.com/D67031
--HG--
extra : moz-landing-system : lando
The code in GetVisibleRect() uses the test scroll offset, but not the test zoom.
Using AutoApplyAsyncTestAttributes automatically uses both.
Differential Revision: https://phabricator.services.mozilla.com/D66956
--HG--
extra : moz-landing-system : lando
When NumSubTextures() returns 0, SurfaceTextureHost is not rendered to WebRebder by a check of AsyncImagePipelineManager::UpdateImageKeys().
Differential Revision: https://phabricator.services.mozilla.com/D66514
--HG--
extra : moz-landing-system : lando
This improves the implementation of IsCurrentlyCheckerboarding (which is not
invoked from anywhere prior to this patch) so that it takes into account the
recursive clipping applied by ancestor layers' composition bounds. In other
words, the visible rect for a layer may be additionally clipped because
ancestor scrollframes have scrolled, and this patch accounts for that.
It also records the currently-checkerboarding state into the APZTestData
at the time that the compositor APZTestData instance is fetched.
Differential Revision: https://phabricator.services.mozilla.com/D66427
--HG--
extra : moz-landing-system : lando
Slight functional changes:
- the checkerboard event call site will now include mTestAsyncScrollOffset
when calculating the visible rect, which should impact overall behaviour if
there's a test that cares about checkerboard events (there currently isn't).
- the IsCurrentlyCheckerboarding call site will use the compositing effective
scroll offset instead of the raw metrics scroll offset. This function is
not called from anywhere so it doesn't matter, but it makes sense to align
it with the other uses and I'll be using it in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D66426
--HG--
extra : moz-landing-system : lando
It turns out intersecting a rect with an empty rect doesn't
guarantee that the result is empty if overflow happens.
We work around this by checking dtRect for empty as well.
See 1622126 for more details.
Differential Revision: https://phabricator.services.mozilla.com/D66694
--HG--
extra : moz-landing-system : lando
DisplayItemBuilder now has methods:
```
void StartGroup(nsPaintedDisplayItem* aItem);
void CancelGroup();
void FinishGroup();
bool ReuseItem(nsPaintedDisplayItem* aItem);
```
WebRender display items previously created between calls to StartGroup() and FinishGroup() will be reused by a call to ReuseItem(),
which will push DisplayItem::ReuseItem(key) to WR display list, if the Gecko display item has been retained and reused.
Calling CancelGroup() will discard the display items that have been pushed after calling StartGroup().
For example, inside nsDisplayBackgroundColor::CreateWebRenderCommands():
```
aBuilder.StartGroup(this);
aBuilder.PushRect(r, r, !BackfaceIsHidden(),
wr::ToColorF(ToDeviceColor(mColor)));
aBuilder.FinishGroup();
```
Differential Revision: https://phabricator.services.mozilla.com/D65356
--HG--
extra : moz-landing-system : lando
The new ProfileBufferEntryReader/Writer are now used everywhere, including in
the profilers and tests.
The old EntryReader/Writer have been removed.
Differential Revision: https://phabricator.services.mozilla.com/D65697
--HG--
extra : moz-landing-system : lando
DisplayItemBuilder now has methods:
```
void StartGroup(nsPaintedDisplayItem* aItem);
void CancelGroup();
void FinishGroup();
bool ReuseItem(nsPaintedDisplayItem* aItem);
```
WebRender display items previously created between calls to StartGroup() and FinishGroup() will be reused by a call to ReuseItem(),
which will push DisplayItem::ReuseItem(key) to WR display list, if the Gecko display item has been retained and reused.
Calling CancelGroup() will discard the display items that have been pushed after calling StartGroup().
For example, inside nsDisplayBackgroundColor::CreateWebRenderCommands():
```
aBuilder.StartGroup(this);
aBuilder.PushRect(r, r, !BackfaceIsHidden(),
wr::ToColorF(ToDeviceColor(mColor)));
aBuilder.FinishGroup();
```
Differential Revision: https://phabricator.services.mozilla.com/D65356
--HG--
extra : moz-landing-system : lando
Having MotionPathData in layers::Animation is a bit inefficient for animations
other than transform like properties.
Differential Revision: https://phabricator.services.mozilla.com/D65921
--HG--
extra : moz-landing-system : lando
