This will allow storing state in a display list builder struct
between different display list builds. In time, this will be used
to reduce the size of the serialized display list data, by only
sending delta changes to WR. The extra information made available
by sending deltas will then allow WR to more efficiently cache and
reuse information across different scene/frame builds.
Differential Revision: https://phabricator.services.mozilla.com/D123579
There are two big parts in the MSVC toolchain we use:
- the Windows 10 SDK
- Visual C++
For the former, both the 15.8.4 and 15.9.6 toolchains are using the same
version of the Win10 SDK.
For the latter, we're not using the compiler itself anymore, so the only
substantial difference is in the headers and libraries included with
Visual C++, as well as the redist libraries for the CRT. Both versions
are supposed to be compatible to the same set of OS versions, fitting
our system requirements.
This makes us use the same version of MSVC on all our Windows builds
(arm64 builds were already on 15.9.6).
Differential Revision: https://phabricator.services.mozilla.com/D123720
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
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
On some Adreno 3xx devices, the brush_mix_blend shader renders its
output as coloured triangles. This is another instance of the driver
bug from bug 1630356, where the presence of a flat varying
scalar ("v_op" in this case) causes the entire fragment shader output
to be flat, ie a single colour per primitive.
In the past we have worked around this by packing the varying in to a
vector. Unfortunately, however, in brush_mix_blend this causes us to
encounter yet another driver bug. Using the component of the new
vector as the switch condition (or if conditions in the optimized
output) does not work: none of the cases are exectuted and the output
is rendered as the default yellow.
Unpacking the vector's component in to a local variable prior to the
switch avoids this bug, however it gets optimized away by glslopt. To
prevent that, we perform a bitwise AND on the component. This should
have no logical effect and have negligable cost, but importantly
avoids the driver bug meaning the correct branch is taken and the
shader renders correctly.
Differential Revision: https://phabricator.services.mozilla.com/D123766
On some Adreno 3xx devices, the brush_mix_blend shader renders its
output as coloured triangles. This is another instance of the driver
bug from bug 1630356, where the presence of a flat varying
scalar ("v_op" in this case) causes the entire fragment shader output
to be flat, ie a single colour per primitive.
In the past we have worked around this by packing the varying in to a
vector. Unfortunately, however, in brush_mix_blend this causes us to
encounter yet another driver bug. Using the component of the new
vector as the switch condition (or if conditions in the optimized
output) does not work: none of the cases are exectuted and the output
is rendered as the default yellow.
Unpacking the vector's component in to a local variable prior to the
switch avoids this bug, however it gets optimized away by glslopt. To
prevent that, we perform a bitwise AND on the component. This should
have no logical effect and have negligable cost, but importantly
avoids the driver bug meaning the correct branch is taken and the
shader renders correctly.
Differential Revision: https://phabricator.services.mozilla.com/D123766
In bug 1548056 we stopped using FLB/ComputeDifferences for invalidation of
filters and transform and switched to ConstructGroupInsideInactive.
Differential Revision: https://phabricator.services.mozilla.com/D123760
We previously identified a bug on Intel BayTrail devices when using
BGRA internal format with immutable textures. As a workaround, we used
RGBA as the internal format for textures and relied on swizzling
during sampling. However, the bug has been reported to affect more
devices than originally thought. This patch applies the workaround to
those devices too.
Differential Revision: https://phabricator.services.mozilla.com/D123735
There's no handy way to use functions in paint_listener.js inside extension's
popup document's context, if paint_listener.js gets loaded with a script tag
inside the document, it doesn't allow us using nsIDOMWindowUtils since it is in
extension's privilege. Running a similar chunk of the function code in
SpecialPowers.spawn is the simplest way to use the function.
Differential Revision: https://phabricator.services.mozilla.com/D123588
Since WebRenderLayerScrollData nodes are emitted on the way out
of the recursion over the display list, we need to be careful
that a deferred transform doesn't end up on a deeper node than
it should be.
Differential Revision: https://phabricator.services.mozilla.com/D123397
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