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
CLOSED TREE
Backed out changeset 622591504941 (bug 1616901)
Backed out changeset 034d885d32cb (bug 1623777)
Backed out changeset 610fe9c88f2e (bug 1623647)
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
So that accesses that use mSkipRect.XMost() - 4 or - 16 are aligned to a 4-byte
boundary. Not doing so would crash on some architectures due to a SIGBUS.
Differential Revision: https://phabricator.services.mozilla.com/D66748
--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
It was previously set on mac only due to driver mischiefs, however the cost of growing texture arrays becomes high with large layer counts, which capping the layer count to 32 everywhere helps mitigate at the expense of batch breaks.
Depends on D67368
Differential Revision: https://phabricator.services.mozilla.com/D67369
--HG--
extra : moz-landing-system : lando
Doesn't make for a stellar API but texture_cache.rs has a lot of code and I had a hard time wrapping my head around the scattered parts of picture-cache specific code.
In addition (and more importantly) texture arrays for each tile sizes can be allocated on demand and do not need to be created when initializing the texture cache. This avoids allocating and deallocating the mispredicted picture texture size when the initial window size is garbage.
Depends on D67367
Differential Revision: https://phabricator.services.mozilla.com/D67368
--HG--
extra : moz-landing-system : lando
Also make sure that the pressure factor never gets to zero.
These new constants aren't deinitive in any way though I think that they are a bit more reasonable.
Depends on D67366
Differential Revision: https://phabricator.services.mozilla.com/D67367
--HG--
extra : moz-landing-system : lando
As an initial step to reduce the reallocation churn a bit. This texture array grows up to 12 layers for any trivial page and goes up to 40+ on many sites (like the youtube front page) so it's far from enough but it's a start. Simple popups like Help > About Nightly don't need more than 4 layers, though.
Differential Revision: https://phabricator.services.mozilla.com/D67366
--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
As a strating point for the vertex shader, this patch isolates the parts that are common to both shaders: the code that fetches various piece of data, adding a branching point between the text shader and other brushes just after having fetched most of the data. Hopefully we can devise ways to further unify the vertex shaders in followups.
Differential Revision: https://phabricator.services.mozilla.com/D63094
--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
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
This patch removes the old thread_profiler bindings, and adds
support for profiling WR with the tracy profiler, which is a
much more advanced frame profiler.
Since it's very lightweight, and only instruments annotated CPU
and GPU zones, it can retain very large profiles, allowing
fine grained analysis of thread interactions, CPU spikes etc.
Differential Revision: https://phabricator.services.mozilla.com/D66926
--HG--
extra : moz-landing-system : lando
Updates `wgpu` code as well as our WebIDL bindings.
The `wgpu-types` is a new component crate that has public types available to
Rust applications that target the Web directly.
Differential Revision: https://phabricator.services.mozilla.com/D67013
--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
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.
Differential Revision: https://phabricator.services.mozilla.com/D66126
--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
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--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
Add annotations to vertex shaders so that SWGL can detect when a vertex attribute
is generated by per-instance data rather than per-vertex data.
Differential Revision: https://phabricator.services.mozilla.com/D65614
--HG--
extra : moz-landing-system : lando