The recording by CanvasDrawEventRecorder into the ring buffer is not thread-safe
and so must all occur on the same (main) thread.
In addition to that it sometimes needs to send IPC messages via the PCanvas
protocol, which also can only be done on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D71174
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
As described in bug 1630274, this has some unfixed cases, but it should
give good results in most real-world cases, where the magnitude of transient
async scrolling is relatively low.
Depends on D71083
Differential Revision: https://phabricator.services.mozilla.com/D71084
--HG--
extra : moz-landing-system : lando
This is just plumbing, no functional change. The current usage of eBottom is
parameterized and the eBottom hard-coded value is pushed out to the callers.
Depends on D70912
Differential Revision: https://phabricator.services.mozilla.com/D71083
--HG--
extra : moz-landing-system : lando
This patch just ensures the changes in the previous patches get applied
to the WR codepath, and is sufficient to make all the remaining sticky
tests pass on Android+WR.
Differential Revision: https://phabricator.services.mozilla.com/D70911
--HG--
extra : moz-landing-system : lando
The semantics of sticky items are somewhat different from the semantics of
fixed items. For fixed items, if an item is fixed to eTop or eBottom or
eTopBottom, it is *always* fixed to those sides. For sticky items, however,
the sides actively stuck to are dependent on the scroll position. So we need
a mechanism to dynamically figure out which sides are stuck, and use those
sides when computing the fixed margins to apply. This patch implements that
by modifying the IsStuckToRootContentAtBottom method into a
SidesStuckToRootContent method.
Differential Revision: https://phabricator.services.mozilla.com/D70910
--HG--
extra : moz-landing-system : lando
I couldn't understand what it was doing before, but conceptually it should
be pretty simple.
Differential Revision: https://phabricator.services.mozilla.com/D70909
--HG--
extra : moz-landing-system : lando
This sets us up to be able to use these helper methods on WR sampling codepath.
Depends on D70907
Differential Revision: https://phabricator.services.mozilla.com/D70908
--HG--
extra : moz-landing-system : lando
This will make future patches simpler, as we can now create these info objects
more easily for the non-WR codepath as well.
Depends on D70906
Differential Revision: https://phabricator.services.mozilla.com/D70907
--HG--
extra : moz-landing-system : lando
We can use the map lock to do a lookup in mApzcMap, instead of requiring the
tree lock to call GetTargetAPZC.
Differential Revision: https://phabricator.services.mozilla.com/D70906
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
CanvasClientSharedSurface did not handle a case that CanvasClientSharedSurface was re-created, but GLScreenBuffer was not re-created. And RenderCompositorEGL::Pause() detaches all SurfaceTesxtures, but RenderAndroidSurfaceTextureHostOGL did not handle it.
Differential Revision: https://phabricator.services.mozilla.com/D70667
--HG--
extra : moz-landing-system : lando
This also adds checks for the other side closing during the ReturnRead and
ReturnWrite loops.
Depends on D70336
Differential Revision: https://phabricator.services.mozilla.com/D70337
--HG--
extra : moz-landing-system : lando
This fixes an issue with the AboutToWait check. It is possible that this could
be done without this, but while there might be a very slight performance hit, it
seems to be smaller than the general noise in the tests.
Depends on D70335
Differential Revision: https://phabricator.services.mozilla.com/D70336
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
The basic problem here for the page is that we should draw an svg element as if it has no mask specified if the specified mask is display: none. (For html elements in the same situation we should not draw the html element at all.)
The fix is to treat the return values of PaintMaskSurface (which come through nsSVGIntegrationUtils::PaintMask and nsDisplayMasksAndClipPaths::PaintMask) in WebRenderCommandBuilder::BuildWrMaskImage the same way as in CreateAndPaintMaskSurface.
Differential Revision: https://phabricator.services.mozilla.com/D70596
--HG--
extra : moz-landing-system : lando
This isn't used any more; the only getter function is not called from
anywhere.
Depends on D70602
Differential Revision: https://phabricator.services.mozilla.com/D70603
--HG--
extra : moz-landing-system : lando
For the case where we got a hit-result with a NULL_SCROLL_ID, we wouldn't
get a node, and would fall back to the root APZC for the layers id. But we
should actually still find the HTTN so that we can check the override flags.
Differential Revision: https://phabricator.services.mozilla.com/D70396
--HG--
extra : moz-landing-system : lando
We need to propagate the flags from the reflayer into the descendant subtree,
but remove the flag from the HTTN corresponding to the reflayer itself. See
comments in the patch for why.
Differential Revision: https://phabricator.services.mozilla.com/D70395
--HG--
extra : moz-landing-system : lando
This is a "naive" implementation that will be refined in the next couple of
patches.
Differential Revision: https://phabricator.services.mozilla.com/D69203
--HG--
extra : moz-landing-system : lando
No functional changes here, just plumbing to allow the caller to
access all the results instead of just the one picked out by
bindings.rs.
Differential Revision: https://phabricator.services.mozilla.com/D69202
--HG--
extra : moz-landing-system : lando
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
