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
WebRender could be used when WebRender does not use ANGLE. And there is a case that we want to use WebRender with ANGLE for testing.
Differential Revision: https://phabricator.services.mozilla.com/D69771
--HG--
extra : moz-landing-system : lando
On some (mostly older, integrated) GPUs, the normal GPU texture cache
update path doesn't work well when running on ANGLE, causing CPU stalls
inside D3D and/or the GPU driver. To reduce the number of code paths we
have active that require testing, we will enable the GPU cache scatter
update path on all devices running with ANGLE. We want a better solution
long-term, but for now this is a significant performance improvement on
HD4600 era GPUs, and shouldn't hurt performance in a noticeable way on
other systems running under ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D70764
--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
Previously, it was possible for a tile that had a valid scroll root
to have an empty valid (and dirty) rect due to the picture cache
clip rect, in some situations.
This could result in the tile not being tagged as off-screen, which
means it is added to the queue of tiles to be updated. On most
platforms this is benign, but the BeginDraw method of DirectComposition
fails if the dirty rect is empty.
This patch fixes the logic so that tiles that meet these conditions
are correctly tagged as not visible, and skipped from update queue.
Differential Revision: https://phabricator.services.mozilla.com/D70616
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we can't use gfxWindowsSurface in content for offscreen
surfaces, since it invokes Windows GDI calls.
It appears from testing that a gfxImageSurface works just fine, so this change
just disables the native surface usage for content processes.
Differential Revision: https://phabricator.services.mozilla.com/D70022
--HG--
extra : moz-landing-system : lando
In wr/swgl/src/gl.cc, force_clear constrains skip_end to be no less than y0, but
skip_end is a horizontal position, not a vertical position, so skip_start is the
correct lower bound.
Differential Revision: https://phabricator.services.mozilla.com/D70462
--HG--
extra : moz-landing-system : lando
Picture primitives are special, so it doesn't make sense to have
the normal common primitive data for them. For example, the
bounding rect of a picture is determined during frame building.
Removing the common data for picture primitives simplifies the
code and makes it impossible to accidentally access an invalid
bounding rect for picture primitives.
Differential Revision: https://phabricator.services.mozilla.com/D70295
--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 parameters to the middle two arguments of SetBox were flipped, causing
RectAbsolute to get improperly swizzled over IPC.
Differential Revision: https://phabricator.services.mozilla.com/D70252
--HG--
extra : moz-landing-system : lando
Most `Internable` implementations give `PrimitiveSceneData` as their
`InternData` associated type, the type of data associated with the handle in the
scene builder thread. However, nothing in the scene builder code, or anywhere in
WebRender, actually uses the contents of `PrimitiveSceneData`, so it can be
replaced with `()` with no effect on the code other than memory savings.
Differential Revision: https://phabricator.services.mozilla.com/D70121
--HG--
extra : moz-landing-system : lando
UnpremultiplyRow will be used in the image encoders to reverse
premultiplication. SwizzleRow needs to support copying (no swizzling)
and swapping RGB/BGR.
Differential Revision: https://phabricator.services.mozilla.com/D66743
--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
This fixes a case where the backing surface of a picture cache tile
changes, but was still being considered a no-op frame, which skips
the composite as an optimization if nothing has changed.
In this case, the tile surface changes from a rasterized texture
to a solid color that doesn't require a picture cache texture.
The patch ensures that the composite surface descriptors that are
used to detect no-op frame compositions include the backing
surface for each of the tiles that make up this virtual surface.
Differential Revision: https://phabricator.services.mozilla.com/D70138
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
Audit all the types related to app units [1] printed in
nsIFrame::List (and all the methods that override it), and use
ConvertToString to convert their printing format to CSS pixels if
needed.
In addition, add operator<< to BaseCoord so that it can cooperate with
mozilla::ToString, which is needed by ConvertToString.
[1] The types include nsRect, nsSize, nscoord, LogicalRect, and
LogicalSize.
Differential Revision: https://phabricator.services.mozilla.com/D69915
--HG--
extra : moz-landing-system : lando
Previously, primitive dependency checking would invalidate a tile if
the spatial node index for a given primitive changed.
However, if a new display list is sent that changes the shape of
the spatial node tree this may cause unnecessary invalidations.
For example, a new display list that inserts a new spatial node at
the start of the tree could result in spatial node indices being
different, even though the values of the transforms was the same.
This patch changes the invalidation logic for spatial nodes to
compare the transforms by value, rather than index, meaning that
invalidations are avoided if the shape of the spatial tree has
changed, but the values are consistent.
Differential Revision: https://phabricator.services.mozilla.com/D69913
--HG--
extra : moz-landing-system : lando
This implements Z plane clipping, gl_FragCoord.zw interpolation, and vertex attribute perspective-correction with support from the glsl-to-cxx compiler by using PERSPECTIVE feature in a WR shader.
Differential Revision: https://phabricator.services.mozilla.com/D69429
--HG--
extra : moz-landing-system : lando
The `sampleInUvRect` function in `gfx/wr/webrender/res/cs_svg_filter.glsl` calls
`texture`, passing the optional third argument that specifies a bias to the
sampler's level-of-detail calculation, used for mipmap interpolation. However,
the `texture` override in `gfx/wr/swgl/src/glsl.h` that accepts this parameter
is stubbed out, with an `assert(0)`. This causes twelve tests in
`gfx/wr/wrench/reftests/filters` to crash.
Nothing in Firefox uses mipmaps, and Servo doesn't use Software WebRender, so it
should be fine for that call to `texture` to simply not pass the level-of-detail
bias.
This patch makes that change.
Differential Revision: https://phabricator.services.mozilla.com/D69867
--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
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--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
In mozilla::ipc::SharedMemory, the memory() method was virtual, so we cached the address here
(although the compiler would likely have inlined the accessor as the `final` concrete subclass
was known). Anyhow, in base::SharedMemory it's a trivial (non-virtual) accessor, so there's
no sense in shadowing it here.
Differential Revision: https://phabricator.services.mozilla.com/D68789
--HG--
extra : moz-landing-system : lando
The base::SharedMemory class provides APIs to create a "read-only" copy of a shared memory block,
which means it can be shared to a child process without the risk that the child might map it as
writable and corrupt the contents. We want to use this facility for the font list, hence switching
the shared-memory APIs used.
Differential Revision: https://phabricator.services.mozilla.com/D68778
--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
CLOSED TREE
Backed out changeset 34ebd6260867 (bug 1550037)
Backed out changeset 7571e5bc19e7 (bug 1550037)
Backed out changeset 71fdead8eecb (bug 1550037)
In mozilla::ipc::SharedMemory, the memory() method was virtual, so we cached the address here
(although the compiler would likely have inlined the accessor as the `final` concrete subclass
was known). Anyhow, in base::SharedMemory it's a trivial (non-virtual) accessor, so there's
no sense in shadowing it here.
Differential Revision: https://phabricator.services.mozilla.com/D68789
--HG--
extra : moz-landing-system : lando
The base::SharedMemory class provides APIs to create a "read-only" copy of a shared memory block,
which means it can be shared to a child process without the risk that the child might map it as
writable and corrupt the contents. We want to use this facility for the font list, hence switching
the shared-memory APIs used.
Differential Revision: https://phabricator.services.mozilla.com/D68778
--HG--
extra : moz-landing-system : lando
We were only missing some validation as part of the XRFrame initialization.
Rest is already happening in XRSession::StartFrame
Differential Revision: https://phabricator.services.mozilla.com/D64691
--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
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--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
The picture cache code retains a set of tiles that are currently
off-screen but might be needed again soon, depending on how the
page is scrolled.
However, off-screen tiles were being skipped during draw processing,
which meant that the texture cache request method was not being
called on these tiles. This would often result in the texture
cache eagerly evicting these seemingly unused surface tiles.
This patch re-arranges the occlusion and visibility processing
code for tiles, so that if a tile has been retained in the
picture cache grid, the texture surface is always requested,
even if that tile is currently off-screen. This prevents the
texture cache from evicting tiles that we want to retain for now.
Differential Revision: https://phabricator.services.mozilla.com/D69760
--HG--
extra : moz-landing-system : lando
Implement DOM interfaces for the WebXR Core Module. Additional work to implement the WebXR Core Module are marked with TODO (Bug #) comments within the patch and must be landed before enabling the dom.vr.webxr.enabled flag.
Differential Revision: https://phabricator.services.mozilla.com/D62369
--HG--
extra : moz-landing-system : lando
this is an attempt to handle tasks outside of the device bounds,
that belong to surfaces not establishing raster roots.
I suspect that the scaling we are now setting up in adjust_scale_for_max_surface_size
doesn't work properly, since the function was assumed to only affect the raster-rooted
surfaces. But it does fix the crash we have.
Differential Revision: https://phabricator.services.mozilla.com/D69654
--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
This adds a helper for applying gfxinfo state to a gfxFeature. The
helper includes the blacking list reason which should give us some more
information for about:support and telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D69427
--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
we expect that the children spatial node goes after the parent.
If it's not the case, we can still fall back to a full world transform,
but it's not going to be correct with regards to flattening.
As we don't know the circumstances and are unable to reproduce the issue,
making this fallback could be a reasonable thing to do for now.
Differential Revision: https://phabricator.services.mozilla.com/D69289
--HG--
extra : moz-landing-system : lando
Few of the counters actually have anything to do with IPC although they all relate to events of layout transactions.
Depends on D69414
Differential Revision: https://phabricator.services.mozilla.com/D69415
--HG--
extra : moz-landing-system : lando
Instead of collecting so-called ipc counters when receving the SetDisplayList on the render backend, pass the information through the scene builder thread and update the profile on the render backend after the scene is swapped. This prevents ipc counters to be displayed while the transaction is still being processed by the scene builder thread.
Differential Revision: https://phabricator.services.mozilla.com/D69414
--HG--
extra : moz-landing-system : lando
It moves when DL building + IPC + scene building takes more than 100ms.
Depends on D69247
Differential Revision: https://phabricator.services.mozilla.com/D69254
--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
Before this patch:
- Consume time merely is the time it takes to push something into a vector (always displays zero).
- Total IPC time and the DisplayList IPC graph measure the time between api.set_display_list and the render backend picking the message up, plus the time it took to build the display list (but doesn't take into account the time it took for actual IPC in between).
- Send time is only the time between api.set_display_list and the render backend picking the message up but doesn't take into account the time it took between the content thread sending the DL and the compositor thread forwarding it.
After this patch:
- Content send time measures the time between the content thread sending the display list and the compositor forwarding it (actual IPC).
- Api send time measures the time between the compostor thread forwarding the DL and the render backend picking it up.
- Consume time is removed.
- Total send time is the sum of content and api times.
- Display list build times and display list IPC (total send time) are on separate graphs.
Depends on D69227
Differential Revision: https://phabricator.services.mozilla.com/D69228
--HG--
extra : moz-landing-system : lando
These two platforms are the easiest to get started with - as well as accounting for the great majority
of desktop Firefox users.
This patch is based on the OS vendors' lists of fonts shipped with the current version of each OS.
Differential Revision: https://phabricator.services.mozilla.com/D66125
--HG--
extra : moz-landing-system : lando
This replaces and extends the "hidden" flag we currently use on macOS to mark internal system fonts
like .LastResort and .Keyboard that should not be exposed; rather than just a boolean "hidden" flag
we'll have several levels of visibility, some of which the user may opt in to exposing (at the cost
of potentially becoming more fingerprintable).
The current patch assumes three levels besides always-hidden:
Base - fonts that are part of the base OS install and always available
LangPack - fonts that are provided by the OS subject to user's chosen language options
User - user-installed fonts that were not provided by the OS
(This categorization may be subject to revision as we learn more about real-world needs and
configurations.)
Differential Revision: https://phabricator.services.mozilla.com/D66124
--HG--
extra : moz-landing-system : lando
The test added in this changeset is already fixed by the no-normalization change, but there are probably cases that require the explicit check that this patch adds.
When we were still normalizing the plane normals, the TransformAndClipBounds call in the added test was returning (1023.999878, 1023.999878, 0.000061, 0.000122).
Depends on D68703
Differential Revision: https://phabricator.services.mozilla.com/D68704
--HG--
extra : moz-landing-system : lando
For example, if the clipping rectangle has aClip.X() == 1024, then the normal for the clipping plane induced by the left edge of the clip will now be (1, 0, 0, -1024) rather than (0.0009765620343390458, 0, 0, -0.9999995231631829).
This change is mathematically valid:
- The dot products computed from these vectors become multiplied by planeNormal.Length() (compared to before this patch).
- The sign of the dot products is not affected, so the "intersection with plane" check is not affected:
`if ((nextDot >= 0.0) != (prevDot >= 0.0)) {`
- The value of the dot products is only used to compute `t`, as follows:
`F t = -prevDot / (nextDot - prevDot);`
Here, the length now appears both in the numerator and in the denominator, canceling itself out.
As a result from this change, the existing tests no longer require integer nudging in order to pass.
Depends on D68702
Differential Revision: https://phabricator.services.mozilla.com/D68703
--HG--
extra : moz-landing-system : lando
These two platforms are the easiest to get started with - as well as accounting for the great majority
of desktop Firefox users.
This patch is based on the OS vendors' lists of fonts shipped with the current version of each OS.
Differential Revision: https://phabricator.services.mozilla.com/D66125
--HG--
extra : moz-landing-system : lando
This replaces and extends the "hidden" flag we currently use on macOS to mark internal system fonts
like .LastResort and .Keyboard that should not be exposed; rather than just a boolean "hidden" flag
we'll have several levels of visibility, some of which the user may opt in to exposing (at the cost
of potentially becoming more fingerprintable).
The current patch assumes three levels besides always-hidden:
Base - fonts that are part of the base OS install and always available
LangPack - fonts that are provided by the OS subject to user's chosen language options
User - user-installed fonts that were not provided by the OS
(This categorization may be subject to revision as we learn more about real-world needs and
configurations.)
Differential Revision: https://phabricator.services.mozilla.com/D66124
--HG--
extra : moz-landing-system : lando
There's only one instance of this left (mSubBuilders) and that can be
easily removed as well.
Depends on D68865
Differential Revision: https://phabricator.services.mozilla.com/D68866
--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
Nothing uses the popover render root any more, so we can assume
render_root_variable == Popover is always false.
Depends on D68862
Differential Revision: https://phabricator.services.mozilla.com/D68863
--HG--
extra : moz-landing-system : lando
num-traits depends on 1.0.0 while rand depends on version 0.1.2.
Depends on D68470
Differential Revision: https://phabricator.services.mozilla.com/D68856
--HG--
extra : moz-landing-system : lando
This was added in a previous patch but it seems that we don't need it if invalid glyphs can be treated as blank glyph cache items.
Depends on D68857
Differential Revision: https://phabricator.services.mozilla.com/D68858
--HG--
extra : moz-landing-system : lando
num-traits depends on 1.0.0 while rand depends on version 0.1.2.
Depends on D68470
Differential Revision: https://phabricator.services.mozilla.com/D68856
--HG--
extra : moz-landing-system : lando
By using the destination DT we will use the correct offset
during playback instead of the offset of the reference target.
Differential Revision: https://phabricator.services.mozilla.com/D68495
--HG--
extra : rebase_source : cff20f1a467138e0d9fe3e22772bb3edbb409318
extra : source : 0e08a1d7fb078cc36882b737f00da2f48f9349a6
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--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
By using the destination DT we will use the correct offset
during playback instead of the offset of the reference target.
Differential Revision: https://phabricator.services.mozilla.com/D68495
--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
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
The texture array is currently grown layer by layer and we typically get to 3 or 4 layers over several frames by the time we are done loading a simple wikipedia page.
Differential Revision: https://phabricator.services.mozilla.com/D68056
--HG--
extra : moz-landing-system : lando
The current heuristic in TextureCache::maybe_reclaim_shared_memory pretty much clears the cache every 5 seconds. Clearing the cache is prtty drastic though, because it causes us to re-upload data and reallocate several textures on the next frame. We really only want to do it when the savings are big, which happens less often now that texture array layer count is capped at 16 and that textures are released as soon as they are empty.
This makes us clear the cache less often by augmenting the threshold to 16 megabytes and only considering texture regions that would not be reallocated right away (since we grow some texture arrays more than one region at a time).
Differential Revision: https://phabricator.services.mozilla.com/D68051
--HG--
extra : moz-landing-system : lando
We already have a cooldown from texture cache items being deallocated a certain amount of time and frames after their last use so we can deallocate texture arrays as soon as they are completely empty. We do this at the end of the frame to avoid deallocating and reallocating within the frame. It's better to reclaim texture memory this way than run into maybe_reclaim_shared_memory which will throw away everything and cause new allocations on the next frame.
Differential Revision: https://phabricator.services.mozilla.com/D68050
--HG--
extra : moz-landing-system : lando
Support hiding slices to better understand what's on which layer,
and to hide UI when not relevant.
Requires using a HTTP server due to cross-scripting.
Differential Revision: https://phabricator.services.mozilla.com/D67963
--HG--
extra : moz-landing-system : lando
When we calculate the repeating tile size, errors can be introduced,
such that there are cases it should be the same as the bounds, but is
slightly different. This can cause a new repetition where we did not
expect one. This patch makes the comparison when may force the tile size
to be the same as the snapped bounds more fuzzy.
Differential Revision: https://phabricator.services.mozilla.com/D67620
--HG--
extra : moz-landing-system : lando
This is no longer as important, with picture caching. Removing it
will simplify the planned changes to switch to a simpler segment
model based on nine-patch rectangles during scene building.
Differential Revision: https://phabricator.services.mozilla.com/D67792
--HG--
extra : moz-landing-system : lando
Previously, we kept the object IDs managed on content side only.
The GPU side would work with given indices.
When an object is destroyed, we'd free the ID on the content side and signal the GPU to delete the object.
Problem is that on the GPU process the object may still be kept alive for as long as any dependants are alive.
What this change is doing - hooking up the callbacks to the *actual* freeing of IDs on the GPU side.
These callbacks end up in messages from WebGPUParent to WebGPUChild, and only then the IDs are freed
on the content side and able to be reused.
Differential Revision: https://phabricator.services.mozilla.com/D67211
--HG--
extra : moz-landing-system : lando
Bob Owen
Glenn Watson
Arthur Iakab
Imanol Fernandez
Bert Peers
Daosheng Mu
Kartikaya Gupta
Anny Gakhokidze
Lee Salzman
Jeff Muizelaar
Jonathan Kew
Stefan Hindli
sotaro
Emilio Cobos Álvarez
Dzmitry Malyshau
Jamie Nicol
Nicolas Silva
Glenn Watson
Timothy Nikkel
Brindusan Cristian
Joshua Gahan
Andrew Osmond
Chris Martin
Roger Zanoni
Jim Blandy
Mihai Alexandru Michis
James Willcox
Eric Rahm
Kris Taeleman
Gabriele Svelto
Ting-Yu Lin
Edouard Oger
Andreas Farre
Kearwood "Kip" Gilbert
Cosmin Sabou
Bogdan Tara
Aaron Klotz
Mirko Brodesser
Sylvestre Ledru
Botond Ballo
Ciure Andrei
Dorel Luca
Markus Stange
Miko Mynttinen
Simon Giesecke
Sebastian Hengst
André Bargull
Chris Peterson
Razvan Maries
cbrewster