Add an interface (and update Gecko to provide) a stable unique
identifier for each spatial node that is consistent across
display lists.
Although this patch doesn't _do_ anything useful with this yet,
we'll use this in future to allow interning, persisting and caching
a lot more information related to primitives and clips.
For now, it just asserts that the calling code never supplies a
duplicate unique identifier - which will be useful to have running
in nightly for a couple of weeks before starting to make use of
these identifiers.
Differential Revision: https://phabricator.services.mozilla.com/D123177
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
The motivation of introducing the structs is to use 64-bit integer
arithmetic to prevent 32-bit integer overflow. One application is to fix
the integer overflow when resolving flex item's main size in Bug 1469649.
The structs can be a start point to add more useful methods to explore
saturation arithmetic.
Differential Revision: https://phabricator.services.mozilla.com/D123266
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
We always expect integer values here, even with fractional scaling,
and if floating point errors cause `bufferClip.x` or `bufferClip.y` to
fall slightly below `0`, this will cause a protocol error.
We can savely avoid this by simply rounding the rect.
Differential Revision: https://phabricator.services.mozilla.com/D123289
Submitting invalid values to the Wayland compositor will trigger a
protocol error, which in turn will trigger an unhandled crash.
In order to create crash reports in such cases, assert on valid
values in such cases.
In the long run we can replace this with a general Wayland protocol
error handler.
Differential Revision: https://phabricator.services.mozilla.com/D123286
Intel BayTrail devices claim to support GL_EXT_texture_format_BGRA8888
as well as GL_EXT_texture_storage, which means we should be able to
use glTexStorage along with a BGRA internal format. However, doing so
does not work, resulting in black squares being rendered rather than
images.
Instead, use RGBA as the internal format and rely on texture swizzling
during sampling.
Differential Revision: https://phabricator.services.mozilla.com/D123246
What we want to assert is that, apart from a couple of edge cases,
aAncestorTransformId is represented in mScrollIds.
The previous approach assumed that mScrollIds was populated entirely
in the loop above, but in fact it can also be populated via
AppendScrollMetadata().
Differential Revision: https://phabricator.services.mozilla.com/D123036
The test function in helper_touch_action_regions.html needs to run as a
generator function, which means it doesn't work with async/await manners, so
once after we make some utility functions as async, it won't work as expected.
To avoid it, getting the scroller position in the screen coords part needs to
be split out from the generator since the part will be async in the next commit,
and nsIDOMWindowUtils.sendNativeTouchPoint needs to be used directly instead of
using synthesizeNativeTouch since synthesizeNativeTouch will also be async.
Differential Revision: https://phabricator.services.mozilla.com/D122558
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
Before this patch the embedded profiler would show the last avg/max values for a profile counter if it hasn't had samples for a long time. After this patch the counter shows 0 if there was no sample.
For example when no glyphs are rasterized there are no 'Rasterized glyphs' samples. If no glyphs are rasterized for multiple seconds then we are currently still showing the average and max number of rasterized glyphs from seconds ago which makes it look like we are constantly rasterizing glyphs. With this patch the counter goes back to zero after half a second of not rasterizing glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D122263
We need to track window compositor state in various cases, when compositor is paused after window creation,
when compositor is paused for hidden window (EGLSurface is missing) and paused compositor when layout is not updated yet
and drawing will lead to incorrect / obsoleted window content.
In this patch we track compositor state by WindowCompositorState atomic enum (because it can be accessed from Compositor thread)
and two private methods (PauseCompositorHiddenWindow and ResumeCompositorHiddenWindow) and two public ones (PauseCompositor() and ResumeCompositor).
Private interface is used by nsWindow when EGLSurface is missing so we can't render to window - it's initial compositor pause and
pause when window is hidden.
Public interface is used by nsWindow and WebRender compositor to disable/enable rendering when window content is updated.
When compositor is disabled by public interface it will be enabled automatically after a timeout (1s) or when content layout is updated.
Changes in the patch:
- Implement GtkCompositorWidget::RemoteLayoutSizeUpdated() to notify GtkCompositorWidget widget about layout size update in content process.
- Track nsWindow compositor state by WindowCompositorState
- Implement nsWindow::PauseCompositorHiddenWindow() and ResumeCompositorHiddenWindow() to handle internal nsWindow states.
- Implement nsWindow::PauseCompositor() and nsWindow::ResumeCompositor() to allow compositor pause/resume during content layout updates.
- Use timeout to resume compositor paused by public interface as a fallback when content is not updated or it takes too long.
Differential Revision: https://phabricator.services.mozilla.com/D121650
As it's usually not very useful. I don't know how easily we can add a
reliable test for this, let me know if you come up with an idea to do
that.
Differential Revision: https://phabricator.services.mozilla.com/D122222
On PowerVR devices we have seen reports of red lines and shapes
appearing randomly on the screen. What is happening is that clip masks
are being rendered in to the RGBA8 texture atlases that were the
previous pass' target, rather than the current R8 render target. Red
shapes therefore appear on top of the cached items in the RGBA texture
atlases, and parts of these subsequently get rendered to picture cache
tiles then the screen.
This appears to be due a bug with glInvalidateFramebuffer. We call
this function once we have finished using a render target for the
frame (ie we have rendered all items which need a clip mask). But
presumably, due to the asynchronicity of OpenGL, the draw calls to
render the clip masks to the render target are in fact still pending
at this point. Perhaps the driver incorrectly recycles the render
target's memory too early, and as a result the masks get written to
the wrong texture.
This patch therefore omits the calls to glInvalidateFramebuffer on
PowerVR devices. While this bug has been hard to reproduce reliably,
it appears to solve the issue.
Differential Revision: https://phabricator.services.mozilla.com/D122221
Move the extra_data to be a specific cache_data separate vec in
the display list payload.
This shouldn't change any functionality, but serves as a proof
of concept for future changes which will introduce several other
separated payload vectors.
Differential Revision: https://phabricator.services.mozilla.com/D121937
This attempts to emulate the behavior of GetRecommendedRenderingMode without
actually calling it. In addition, it allows some Gecko-specific behavior
like overriding the render mode explicitly that allows some simplification
of the decision-making.
Inside GetRecommendedRenderingMode, natural is only allowed if <= 20 size.
This allows us to thus decide mostly based on whether the size is > 20 or
if an explicit mode was specified. In the remaining case where we need
to check a GASP table if available, we defer to the symmetric flag. If
there is no GASP, we assume natural.
Differential Revision: https://phabricator.services.mozilla.com/D122025
Before this patch any item that is wider or taller than 512 pixels goes into its own standalone texture. However we often generate linear gradient tasks with a height of 1 pixels and a width between 512 and 1024. Having them in standalone textures wastes a lot of memory and breaks batches. 1024 pixels fits exactly in the linear color cache texture.
Differential Revision: https://phabricator.services.mozilla.com/D121362
We implement a new nsIDOMWindowUtils function sendNativeTouchpadPan to do this. It is only implemented on Windows here.
Depends on D122048
Differential Revision: https://phabricator.services.mozilla.com/D122049
This patch aims to address a worst-case theoretical possibility where the job count might for
some reason get out of sync, causing either the SwComposite thread or the main thread to deadlock
waiting on jobs that may never become available.
To this end, we get rid of the job count tracking entirely, and instead just track whether,
first, the SwComposite thread has completed all the jobs that have been queued for it, and,
second, that the main thread, having completed all jobs that were available, is waiting for
jobs to be available or completed such that the SwComposite thread would need to wake it up.
The main thread does not need to wait if it knows the SwComposite thread completed all jobs,
and the SwComposite thread does not need to signal if it knows the main thread is not waiting.
Otherwise stated, so long as both the main and SwComposite threads know there are no more
available jobs, then there is no way compositing can advance any further, and so compositing
must be finished. This avoids relying on having a job count that is always accurate to track
termination.
Differential Revision: https://phabricator.services.mozilla.com/D121821
It's non WebRender specific, so it will not be a problem on Fission,
additionally it's not used on non WebRender with retained display stuff
either.
Differential Revision: https://phabricator.services.mozilla.com/D121929
This provides settings, which are populated from gfxVars retrieved in the
parent, so that they can be used in all processes.
IDWriteRenderingParams are created lazily, so that we don't try and create them
in processes that have win32k locked down where the API calls will fail.
Differential Revision: https://phabricator.services.mozilla.com/D120597
Note: Sorry in advance that this patch is so big. Unfortunately
splitting it up would create lots of redundant changes.
This should be the last big refactoring for the Wayland compositor
backend for now.
Up until now SurfacePoolWayland was a pool of actual `wl_surface`s,
as before bug 1718569 we had no direct access to `wl_buffer`s when
using EGL. However, the way `SurfacePoolCA` manages native surfaces
is closer to what in Wayland terminology would be a buffer pool:
buffers are heavy-weight and expansive to allocate, while
`wl_surface` objects are cheap to recreate.
So instead of having a pool of surfaces, each of them having its
own pool of buffers, make `wl_surface`s part of tiles and make
`SurfacePoolWayland` manage `wl_buffer`s (in the form of SHM- or
DMABuf buffers). This will allow us to share buffers (especially
depth buffers) more efficiently, reducing VRAM usage and allocation
times.
Apart from that it will also simplify our tile management logic.
Most importantly, we'll need to reorder `wl_surface`s less often and
less complex (no `place_below` the parent surface) and can also drop
reattaching subsurfaces to compositors. Especially the former will
likely decrease CPU time in compositors.
Overall this patch makes `NativeLayerWayland` behave more like
`NativeLayerCA` while taking in lessons learned from
`WindowSurfaceWaylandMB`.
Differential Revision: https://phabricator.services.mozilla.com/D119993
The pending primitives have already been snapped, so this only
has an effect if the shadow offset is fractional. If that's the
case, it's probably reasonable to either (a) not snap at all,
or (b) round the shadow offset earlier.
Differential Revision: https://phabricator.services.mozilla.com/D121500
Currently each VAO owns its own VBO for per-instance array data. Prior
to submitting each draw call that instance buffer is orphaned and a
new one allocated at exactly the right size to contain the batch's
data. This frequent reallocation appears to cause a rendering glitch
on some Adreno 4xx devices, likely due to a bug in the driver's
internal allocation/recycling code. It can also be expensive on some
devices, as the drivers struggle with the overheads of allocating many
small buffers much more than the cost of actually transferring the
data.
This patch makes it so that the VAOs no longer own an instance buffer
each. Instead, they share a pool of buffers. This pool always
allocates buffers large enough to hold the largest batch we
allow. update_vao_instances() now writes data to the pool's current
buffer until that buffer is full, and then either an old one will be
recycled or a new one allocated. After writing to the buffer it must
be bound to the VAO at the correct offset, and then the draw call is
submitted.
By manually managing the buffer lifecycles ourselves we avoid the
glitches on Adreno 4xx, and also improve performance on some devices.
Differential Revision: https://phabricator.services.mozilla.com/D121104
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
We know from testing that the device valid rect itself can sometimes
be empty which produces the symptom that the compositor valid rect
is empty after quantization to i32. So it is sufficient to just check
if that device rect is empty, rather than having to use get_surface_rect
to reproduce the math downstream that produces the compositor valid
rect.
Differential Revision: https://phabricator.services.mozilla.com/D121453
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
The mpsc channel used for reporting glyph rasterization results does not implement
Sync/Send, so the recommended usage pattern is to wrap the channel endpoints in a
Mutex to safeguard them. This, however, turns out to be slow in some cases. Instead,
just always use a crossbeam channel which is thread-safe to begin with and does not
require a Mutex.
Differential Revision: https://phabricator.services.mozilla.com/D121244
Some of the defines are outdated and never actually set, and the
remaining ones can be easily set through existing or easily added
ifdefs.
Differential Revision: https://phabricator.services.mozilla.com/D121064
It has been unsupported since bug 1323303, > 4 years ago.
This removes MOZ_ENABLE_SKIA but keeps USE_SKIA for moz2d for now
Differential Revision: https://phabricator.services.mozilla.com/D120933
If we encounter a device reset in
RenderCompositorD3D11SWGL::TileD3D11::Map, we should fail the call, and
rely upon the device reset checks at the end of a render pass to
recreate our compositor sessions.
Differential Revision: https://phabricator.services.mozilla.com/D121251
Some clang/rustc build setups seem to result in rounding scenarios where the
valid rect, once converted to i32, is somehow empty. This can cause downwind
problems if we actually try to render those tiles. Instead, just cull it before
it becomes a problem.
Differential Revision: https://phabricator.services.mozilla.com/D121144
Although this currently only contains the existing data u8 vec of
serialized bytes, it will allow us to expand this structure in
future to contain other byte arrays.
This will be used for storing other payload information, such as
interned primitive types or data updates.
Differential Revision: https://phabricator.services.mozilla.com/D121160
We have in the past encountered a driver bug on Adreno 3xx devices
where using a flat scalar varying causes the fragment shader output to
be incorrect. See bugs 1630356 and 1705433.
We have now encountered this in cs_border_solid too, due to
vMixColors. As before, packing the varying in to a vector works around
the bug.
Differential Revision: https://phabricator.services.mozilla.com/D121211
Currently each VAO owns its own VBO for per-instance array data. Prior
to submitting each draw call that instance buffer is orphaned and a
new one allocated at exactly the right size to contain the batch's
data. This frequent reallocation appears to cause a rendering glitch
on some Adreno 4xx devices, likely due to a bug in the driver's
internal allocation/recycling code. It can also be expensive on some
devices, as the drivers struggle with the overheads of allocating many
small buffers much more than the cost of actually transferring the
data.
This patch makes it so that the VAOs no longer own an instance buffer
each. Instead, they share a pool of buffers. This pool always
allocates buffers large enough to hold the largest batch we
allow. update_vao_instances() now writes data to the pool's current
buffer until that buffer is full, and then either an old one will be
recycled or a new one allocated. After writing to the buffer it must
be bound to the VAO at the correct offset, and then the draw call is
submitted.
By manually managing the buffer lifecycles ourselves we avoid the
glitches on Adreno 4xx, and also improve performance on some devices.
Differential Revision: https://phabricator.services.mozilla.com/D121104
While running SandboxTest on Windows/Debug setup we can encounter a GPU
process hanging at shutdown. This is due to a destruction race between
GPUParent and VideoBridgeParent, and we end up with one
CompositorThreadHolder reference that is not properly released, making
the GPU process waiting for it.
This change aims at doing the release earlier to prevent such a
destruction race.
Differential Revision: https://phabricator.services.mozilla.com/D121045
This may be another source of failing OOP iframe document print. I will try to
see whether it can be reproducible locally later.
Differential Revision: https://phabricator.services.mozilla.com/D121075
Before this patch the clear tiles were drawn last which meant they would always be drawn on top of all transparent content. It was finde under the assumption that nothing is ever rendered on top of clear tiles, however it turns out to be an issue with the proton window modal darkining which renders some semi-transparent black on top of the whole window (including window controls on windows 8 which use clear tiles). Since the occlusion culling treats clear tiles as opaque they will cut through anything under them regardless of the drawing order, so we can render them before transaprent tiles to get the correct result which is to overwrite what's under the clear tile while still being able to render semi-transparent content on top.
Differential Revision: https://phabricator.services.mozilla.com/D120844
Maybe<T*> is a redundant representation if there is no semantic
difference between Nothing() and Some(nullptr), and just makes
for cumbersome access syntax.
Differential Revision: https://phabricator.services.mozilla.com/D120568
Transforms stored in WebRenderLayerScrollData::mAncestorTransform would
always end up on the topmost hit-testing tree node generated by that
WebRenderLayerScrollData node. That topmost node may not correspond
to the ASR of the transform item(s) which are the source of the
mAncestorTransform. The transform being in the wrong place in the
hit-testing tree can in turn violate APZ's assumptions about different
nodes that scroll together having the same ancestor transform.
To resolve this, this patch stores the transform item's ASR in the
WebRenderLayerScrollData, and applies it to the matching hit-testing
tree node.
Differential Revision: https://phabricator.services.mozilla.com/D120567