In future, spatial tree nodes will not be stored in a flat
vec array. Instead, they'll be retained based on their unique
key. To prepare for this, refactor the spatial tree so that
all access to nodes is done via an accessor, and the tree
update no longer relies on `split_mut`.
Differential Revision: https://phabricator.services.mozilla.com/D124593
In other words, don't batch items if we don't expect to be able to fit other items in the staging texture. The batched upload path has a cost on Windows (an extra copy) that is easily recovered when batching a lot of small items (typically works very well with glyphs), but we get diminishing returns and even slowdowns for larger items.
Differential Revision: https://phabricator.services.mozilla.com/D124791
The prefs name is gfx.webrender.blob-tile-size and can be changed at runtime.
It changes the behavior of a wrench reftest that was ensuring that we don't crash with unreasonable tile sizes. The new behavior (sanitizing the tile size) means we can render the image while we would previously skip it.
Differential Revision: https://phabricator.services.mozilla.com/D124789
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This does not change existing behavior, but will be required once font visibility
is no longer simply a global setting. The data cached in these members depends on
the font visibility level, so currently we just flush it if the visibility pref is
modified. But in future we may be using multiple levels at the same time (in
separate contexts), so we want to maintain separate per-level caches here.
Differential Revision: https://phabricator.services.mozilla.com/D124194
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This does not change existing behavior, but will be required once font visibility
is no longer simply a global setting. The data cached in these members depends on
the font visibility level, so currently we just flush it if the visibility pref is
modified. But in future we may be using multiple levels at the same time (in
separate contexts), so we want to maintain separate per-level caches here.
Differential Revision: https://phabricator.services.mozilla.com/D124194
Add a real root node that is not based on the root pipeline. Remove
the constant for the root spatial node, and retrieve it from the
spatial tree.
Although this doesn't achieve anything useful right now, it will be
needed when spatial nodes are retained between display list and are
referenced by handle.
Differential Revision: https://phabricator.services.mozilla.com/D124310
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. This
has occured several times in different shaders, so this patch finally
adds a test to ensure it does not occur again.
We have used the glsl crate to parse and validate the shaders rather
than angle, as exposing the required bindings to mozangle is messy. We
must therefore use the pre-optimized shaders as the glsl crate does
not handle preprocessor directives correctly.
This has been implemented as a wrench test rather than a unit test as
running unit tests on android is difficult. Additionally we want to
use the shaders specific to the platform the tests are ran on, the bug
only affects (some) android devices, and shaders on other platforms
may differ.
Differential Revision: https://phabricator.services.mozilla.com/D124205
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. The
original report was in bug 1630356, but it has been reported since on
several occasions for various shaders, which have been fixed one at a
time. This patch removes the remaining flat scalar varyings from all
of our shaders so that we do not encounter this issue again.
Additionally, it removes the usage of #ifdefs surrounding these
workarounds so that it applies to all platforms rather than just
android. This has been done to keep the code more readable - now that
we have a test to ensure this is not regressed it no longer needs to
be loud and ugly.
Differential Revision: https://phabricator.services.mozilla.com/D124204
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. This
has occured several times in different shaders, so this patch finally
adds a test to ensure it does not occur again.
We have used the glsl crate to parse and validate the shaders rather
than angle, as exposing the required bindings to mozangle is messy. We
must therefore use the pre-optimized shaders as the glsl crate does
not handle preprocessor directives correctly.
This has been implemented as a wrench test rather than a unit test as
running unit tests on android is difficult. Additionally we want to
use the shaders specific to the platform the tests are ran on, the bug
only affects (some) android devices, and shaders on other platforms
may differ.
Differential Revision: https://phabricator.services.mozilla.com/D124205
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. The
original report was in bug 1630356, but it has been reported since on
several occasions for various shaders, which have been fixed one at a
time. This patch removes the remaining flat scalar varyings from all
of our shaders so that we do not encounter this issue again.
Additionally, it removes the usage of #ifdefs surrounding these
workarounds so that it applies to all platforms rather than just
android. This has been done to keep the code more readable - now that
we have a test to ensure this is not regressed it no longer needs to
be loud and ugly.
Differential Revision: https://phabricator.services.mozilla.com/D124204
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153