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
This is in anticipation of having a looser condition for enabling
DComp. Until that code is ready we might as well get more testing.
Differential Revision: https://phabricator.services.mozilla.com/D71060
--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 code is used to determine the sizes of the top-level windows. However the
code doesn't cause quite desirable behavior (see the bug, and comment 15).
This patch does two things:
* Unifies the html / xul code-paths. This shouldn't change behavior (because
GetXULMinSize returns the fixed min-* property if present anyways), but
makes the patch a bit simpler.
* Makes the min-width of the XUL window be the pref size instead of the
min-size (for the cases where you have no explicit min-width). This looks a
bit counter intuitive, but it's the only way to guarantee that the content
will be shown. This matches the sizing algorithm that dialogs use by default
(via calling window.sizeToContent()), while allowing to undersize the window
via a fixed min-width property.
This in turn makes sizeToContent() work "by default" on XUL windows, avoiding
having to make JS listen to everything that possibly could change the layout of
the document (like resolution changes).
Differential Revision: https://phabricator.services.mozilla.com/D70209
--HG--
extra : moz-landing-system : lando
We need to access the contents of pipeline layouts on CPU
when we are recording commands. This PR adds refcounting to them
and improves the destruction code path to happen once all references are gone.
Differential Revision: https://phabricator.services.mozilla.com/D70868
--HG--
extra : moz-landing-system : lando
Previously we were using 256 bytes (which happens to be equal to 64
pixels for RGBA8 textures). A recent change to the GPU Cache uncovered
the fact that the requirement is actually 64 pixels, eg 1024 bytes for
RGBAF32 textures.
Differential Revision: https://phabricator.services.mozilla.com/D70915
--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
it was a bogus warning that erroneously fire when Gecko flushed mapped contents
Differential Revision: https://phabricator.services.mozilla.com/D70789
--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
These just wrap regular std Sender/Receiver without providing any value. Serialize/Deserialize was implement manually for MsgSender/MsgReceiver to assert. Serde being amazing, it provides with annotations to not require the traits to be implemented on some enum variants and assert at runtime which functionally equivalent but less error-prone than the fake trait implementations.
Removing the rest of channel.rs is coming in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D70021
--HG--
extra : moz-landing-system : lando
Only drop targets from the render target pool when the size of
the pool is larger than an arbitrary threshold (this is 32 MB
for now), _and_ the render target hasn't been used in the last
60 frames of rendering.
This reduces the number of allocation thrashing of textures in
the render target pool on most pages.
Differential Revision: https://phabricator.services.mozilla.com/D70782
--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
The WR code that computed the sticky_offset didn't properly combine the offsets
from the top- and bottom- sticky calculations if an item had both. This patch
fixes the calculation, which makes the remaining test failure (in the
configuration without any dynamic toolbar) pass.
Depends on D70679
Differential Revision: https://phabricator.services.mozilla.com/D70680
--HG--
extra : moz-landing-system : lando
These assertions don't hold in some perfectly legitimate cases, such as when
items have both top and bottom sticky behaviours. The actual behaviour still
seems ok, so let's just drop the assertions.
Differential Revision: https://phabricator.services.mozilla.com/D70459
--HG--
extra : moz-landing-system : lando
Previously, the prim origin needed to be stored in the prim
instance, to avoid picture cache invalidations. With support
for external scroll offset, this is no longer necessary.
This simplifies some of the code paths, and reduces the size
of primitive instances.
Differential Revision: https://phabricator.services.mozilla.com/D70740
--HG--
extra : moz-landing-system : lando
On some (primarily older, integrated) drivers, we see significant
time in CPU stalls during updates to the vertex data textures.
As a short term fix, this patch creates an array of vertex data
textures, and rotates which set of them are in use each frame.
There are better long-term options (such as porting the GPU cache
scatter method, or perhaps using UBO/SSBOs here), but this is a
simple workaround for now.
Differential Revision: https://phabricator.services.mozilla.com/D70775
--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
