Add a gecko pref "gfx.webrender.use-optimized-shaders". If enabled,
then when attempting to compile a webrender shader first look for the
optimized source. If the optimized source is not present, emit a
warning and fall back to the unoptimized source.
Use the optimized source by default in wrench, and add the flag
"--use-unoptimized-shaders" to override this.
Differential Revision: https://phabricator.services.mozilla.com/D70033
Move more shader parsing code to webrender_build, so it can be used
both at runtime and build time.
At build time optimize a set of shaders and feature flag combinations,
using glslopt. Some features are skipped because they are not
supported by the gl version, because the optimizer does not support
them, or because webrender does not need them currently.
Use build-parallel to ensure the optimization is performed in parallel
using the make jobserver. Write the optimized shader source to a
hashmap to be used at runtime, in addition to the unoptimized source.
Differential Revision: https://phabricator.services.mozilla.com/D70032
In the past EGL only supported GLES, not OGL. This has not been true
for a very long time, so lets support OGL context creation in the EGL
backend.
This allows e.g. the Wayland backend to use OGL contexts, which brings
it on par with the X11/GLX backend.
Differential Revision: https://phabricator.services.mozilla.com/D48096
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
This change enables light tracking of the commands and submissions
that affect a CanvasContext. Upon reaching the GPUQueue, they send
a signal for the parent HTML Element to be invalidated.
We are also invalidating the HTML Element and requesting a new
frame to be built on the creation of the swapchain.
Differential Revision: https://phabricator.services.mozilla.com/D71194
Add `UNUSED` marker to `gl.cc` function arguments.
Add GCC pragmas to ignore `-Wunused-parameter` and `-Wunused-but-set-variable`
warnings in the generated shaders. Since these are generated from GLSL, it is
hard to avoid the warnings by changing the code itself.
Avoid uninitialized values in `vec4::operator[]`.
Differential Revision: https://phabricator.services.mozilla.com/D71445
Provide an explicit copy constructor for the GCC `VectorType` polyfill. Since
`VectorType` has an assignment operator, GCC is uncomfortable faking a copy
constructor, so we have to provide one.
Make `VectorType` default constructor actually initialize the elements. When we
have a GLSL `if` whose condition varies from fragment to fragment, and whose
alternatives either assign to a variable or discard the fragment, we compile the
assignment to an `if_then_else` call that preserves the old elements for
fragments not taking the assignment's path. But if this is the initializing
assignment, the 'old value' operand to that `if_then_else` is uninitialized. We
could make the translator smarter about this, and have it not use predicated
assignment in such cases, but this fix is fine for now.
Make `VectorType::wrap` take its argument by const reference, to avoid weird ABI
'notes'.
Differential Revision: https://phabricator.services.mozilla.com/D71444
When the `software` feature is enabled, a clause gets added to two `match`
statements, causing Rust to complain that another `match` clause is unreachable.
This patch makes the other match clause conditional on the absence of the
`software` feature.
Differential Revision: https://phabricator.services.mozilla.com/D71443
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
Bug 1630629 moved the check UseWebRenderDCompWin before it had been
initialized. This moves it below so that DirectComposition isn't
disabled everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D71498
This provides an implementation of linear filtering via the linear_blit
routine. That required factoring out textureLinear helper functions and
reusing them to do the actual filtering of the source texture.
Some collateral cleanups involved changing IntRect to use a start/end
format instead of origin/size, cleaner ways of getting offset texture
sampler pointers, and fixing clamping of linear filter coordinates.
Differential Revision: https://phabricator.services.mozilla.com/D70968
The FrameTexturesUpdated event is intended to be issued when any
necessary texture cache updates have been completed for the current
frame. Originally we would simply check if the pending_texture_updates
vector in Renderer is empty. However the updates themselves could be
nops, and not trigger a timely frame render to occur, causing the
notifications to be delayed indefinitely. Now we track if there are
actually any pending specifically texture cache updates and only defer
the notification if true.
A consequence of deferring the notification indefinitely was revealed
when animating images just outside the current view. We would not
release the buffers for recycling even though we had no reason to hold
onto them. This could cause the image decoder to allocate new buffers
while the old buffers would not get released. It was not a true memory
leak because as soon as a frame is rendered, it would release all of the
old buffers, but it could easily cause a out of memory crash to occur if
the user was not interacting with the browser while in this state.
Differential Revision: https://phabricator.services.mozilla.com/D70770
This moves the DirectComposition configuration code before
the WebRender configuration code so that we can depend
on the results to decide whether to user WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D71213
TaskQueues hold onto their nsIEventTarget (in this case mCanvasWorkers) until
after they resolve their shutdown promise, which is what causes
CanvasThreadHolder::StaticRelease to be submitted to the compositor thread.
So this assertion can't be guaranteed.
Differential Revision: https://phabricator.services.mozilla.com/D71176
The recording by CanvasDrawEventRecorder into the ring buffer is not thread-safe
and so must all occur on the same (main) thread.
In addition to that it sometimes needs to send IPC messages via the PCanvas
protocol, which also can only be done on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D71174
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
As described in bug 1630274, this has some unfixed cases, but it should
give good results in most real-world cases, where the magnitude of transient
async scrolling is relatively low.
Depends on D71083
Differential Revision: https://phabricator.services.mozilla.com/D71084
--HG--
extra : moz-landing-system : lando
This is just plumbing, no functional change. The current usage of eBottom is
parameterized and the eBottom hard-coded value is pushed out to the callers.
Depends on D70912
Differential Revision: https://phabricator.services.mozilla.com/D71083
--HG--
extra : moz-landing-system : lando
This patch just ensures the changes in the previous patches get applied
to the WR codepath, and is sufficient to make all the remaining sticky
tests pass on Android+WR.
Differential Revision: https://phabricator.services.mozilla.com/D70911
--HG--
extra : moz-landing-system : lando
The semantics of sticky items are somewhat different from the semantics of
fixed items. For fixed items, if an item is fixed to eTop or eBottom or
eTopBottom, it is *always* fixed to those sides. For sticky items, however,
the sides actively stuck to are dependent on the scroll position. So we need
a mechanism to dynamically figure out which sides are stuck, and use those
sides when computing the fixed margins to apply. This patch implements that
by modifying the IsStuckToRootContentAtBottom method into a
SidesStuckToRootContent method.
Differential Revision: https://phabricator.services.mozilla.com/D70910
--HG--
extra : moz-landing-system : lando
I couldn't understand what it was doing before, but conceptually it should
be pretty simple.
Differential Revision: https://phabricator.services.mozilla.com/D70909
--HG--
extra : moz-landing-system : lando
This sets us up to be able to use these helper methods on WR sampling codepath.
Depends on D70907
Differential Revision: https://phabricator.services.mozilla.com/D70908
--HG--
extra : moz-landing-system : lando
This will make future patches simpler, as we can now create these info objects
more easily for the non-WR codepath as well.
Depends on D70906
Differential Revision: https://phabricator.services.mozilla.com/D70907
--HG--
extra : moz-landing-system : lando
We can use the map lock to do a lookup in mApzcMap, instead of requiring the
tree lock to call GetTargetAPZC.
Differential Revision: https://phabricator.services.mozilla.com/D70906
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
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
Bogdan Tara
Glenn Watson
Jonathan Kew
Lee Salzman
Daosheng Mu
Jamie Nicol
Martin Stransky
Andrew Osmond
Dzmitry Malyshau
Simon Sapin
sotaro
Jim Blandy
Nicolas Silva
Stefan Hindli
Arash Fotouhi
Jeff Muizelaar
Bert Peers
Coroiu Cristina
Gijs Kruitbosch
Bob Owen
Andreea Pavel
Imanol Fernandez
Miko Mynttinen
Brindusan Cristian
Kartikaya Gupta
Arthur Iakab
Anny Gakhokidze
Emilio Cobos Álvarez
Glenn Watson
Timothy Nikkel
Joshua Gahan
Chris Martin
Roger Zanoni
Mihai Alexandru Michis
James Willcox
Eric Rahm
Kris Taeleman
Gabriele Svelto
Ting-Yu Lin
Edouard Oger
Andreas Farre
Kearwood "Kip" Gilbert
Cosmin Sabou
Aaron Klotz
Mirko Brodesser
Sylvestre Ledru
Botond Ballo
Ciure Andrei
Dorel Luca