PaintMaskSurface shouldn't be applying ImgDrawResult::NOT_READY when we don't have a frame and the mask image hasn't been resolved. ImgDrawResult is only about drawing images, not about waiting for external resources to resolve or frames to get constructed. The only purpose of tracking ImgDrawResult's in painting code is to know which frames we need to invalidate because their rendering might change if we sync decode images during a Draw call. Applying NOT_READY here means we invalidate for every paint with the sync decode images flag (ie reftest paints), and it never changes from NOT_READY. This bites the reftest for this bug 1624532.
To fix it, instead of "overloading" the ImgDrawResult we return a bool to indicate the mask is missing or incomplete.
Differential Revision: https://phabricator.services.mozilla.com/D70595
--HG--
extra : moz-landing-system : lando
This allows us to determine if the event was handled in the
toplevel frame or not.
Differential Revision: https://phabricator.services.mozilla.com/D69871
--HG--
extra : moz-landing-system : lando
The displayport clip that is applied to sticky items from the enclosing
scrollframe can cause sticky items to checkerboard even when they might
reasonably be left visible. This is because the displayport clip moves as
the enclosing scrollframe is scrolled, but sticky items may remain fixed
during such scrolling. The displayport clip can therefore clip out sticky
items even if they are "stuck" and should be user-visible.
This patch sets a flag to identify when a sticky item is being clipped by
the displayport clip, and ensures that it doesn't actually get clipped. In
the case where other clips are being applied to the sticky item, we leave the
clips unaffected. This allows for other enclosing elements to clip the sticky
item as before.
Differential Revision: https://phabricator.services.mozilla.com/D68582
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
This basically allowed managing a bunch of scroll data things in parallel
for all the render roots which we don't need anymore.
Differential Revision: https://phabricator.services.mozilla.com/D69845
--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 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
Timothy Nikkel
Roger Zanoni
James Willcox
Kartikaya Gupta
Edouard Oger
Andreas Farre
Dzmitry Malyshau
Cosmin Sabou
Bogdan Tara
Kris Taeleman
Sylvestre Ledru
Botond Ballo
Ciure Andrei
sotaro
Brindusan Cristian
Nicolas Silva
André Bargull