Before Win32k Lockdown, Canvas would ensure that it would get the fastest possible implementation by initializing
devices in content process before allocating persistent buffers for its backing.
However, with Win32k Lockdown it's no longer possible, as initializing Direct3D and Direct2D make Win32k calls that
crash the locked-down content process.
This issue is generally solved by Remote Canvas; however, Remote Canvas is disabled if the GPU process is disabled.
If that happens, the current behavior is to attempt to initialize hardware acceleration again, causing a crash when
Win32k Lockdown is in effect.
This patch changes the behavior so that the devices will not initialize if they are in a locked-down content process,
even if Remote Canvas is disabled. The effect is that Canvas will fall back to using Skia for everything.
Differential Revision: https://phabricator.services.mozilla.com/D126761
gfx/2d/SourceSurfaceD2D1.cpp(201,20): error: variable 'options' set but not used [-Werror,-Wunused-but-set-variable]
D2D1_MAP_OPTIONS options;
^
gfx/thebes/gfxDWriteFontList.h(269,13): error: variable 'hr' set but not used [-Werror,-Wunused-but-set-variable]
HRESULT hr = S_OK;
^
gfx/thebes/gfxGDIFontList.cpp(1020,12): error: variable 'cmapLoaded' set but not used [-Werror,-Wunused-but-set-variable]
bool cmapLoaded = false;
^
gfx/thebes/gfxMacPlatformFontList.mm:1771:10: error: variable 'isStandardFace' set but not used [-Werror,-Wunused-but-set-variable]
bool isStandardFace = false;
^
gfx/thebes/gfxPlatformFontList.cpp(1064,18): error: variable 'rejectedFallbackVisibility' set but not used [-Werror,-Wunused-but-set-variable]
FontVisibility rejectedFallbackVisibility = FontVisibility::Unknown;
^
gfx/vr/service/OculusSession.cpp(1329,12): error: variable 'bNewController' set but not used [-Werror,-Wunused-but-set-variable]
bool bNewController = false;
^
Differential Revision: https://phabricator.services.mozilla.com/D126454
Building with ac_add_options --disable-unified-build on macOS hits the following warnings-as-errors:
gfx/2d/FilterNodeSoftware.cpp:1022:10 [-Wunreachable-code-return] 'return' will never be executed
gfx/2d/DrawTargetCairo.cpp:1957:20 [-Wunused-function] unused function 'GfxMatrixToPixmanTransform'
gfx/thebes/gfxHarfBuzzShaper.cpp:1008:23: warning: unused variable 'sDageshForms' [-Wunused-const-variable]
gfx/thebes/gfxMacPlatformFontList.mm:818:31 [-Wunused-const-variable] unused variable 'kLangFontsDirs'
gfx/tests/gtest/TestSwizzle.cpp:221:21 [-Wunreachable-code] code will never be executed
gfx/tests/gtest/TestTreeTraversal.cpp:16:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_TREE_DEPTH'
gfx/tests/gtest/TestTreeTraversal.cpp:17:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_TREE_CHILD_COUNT'
gfx/tests/gtest/TestTreeTraversal.cpp:18:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_TREE_LEAF_COUNT'
gfx/tests/gtest/TestTreeTraversal.cpp:19:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_REGION_XWRAP'
gfx/vr/VRDisplayPresentation.cpp:151:3 [-Wunreachable-code-loop-increment] loop will run at most once (loop increment never executed)
gfx/ycbcr/scale_yuv_argb.cpp:61:21 [-Wunused-function] unused function 'Abs'
Differential Revision: https://phabricator.services.mozilla.com/D126592
Right now adding a dynamic pref for webrender involves plumbing in gfxPlatform, gfxVars, CompositBridgeParent, WebRenderBridgeParent, WebRenderAPI, the bindings, and then messaging the pref change to the right thread in WebRender.
That's quite a bit time consuming for something we tend to do for multiple things.
We already have a pretty good system for boolean debug prefs where the pref only needs to be listed in gfxPlatform and in the DebugPref enum of webrender_api/lib.rs, which has led us to use it for non-debug purposes.
This patch adds a system similar to the DebugFlags with values passed in a bitfield to be able to use gfxVars. In WebRender the parameters are key-value pairs which flow through the pipeline so that any component can react to them. A followup will add integer parameters.
The patch also moves a few prefs to this system and adds a pref to use PBO uploads.
Differential Revision: https://phabricator.services.mozilla.com/D126100
While not enabled by default, it is openly exposed in the driver
settings and thus apparently not uncommon. Currently it causes
significant glitches for Firefox HW-WR, but also other text focused
apps (GTK 4).
While this should get fixed in the driver eventually, use the
workaround recommended by Nvidia to force-disable it for now.
Differential Revision: https://phabricator.services.mozilla.com/D125981
Previously, content processes would try to contact the X server
directly during startup to read color calibration information; with
`dom.ipc.avoid-gtk` this doesn't work because the process is in headless
mode. This patch extends the color profile IPC facility added in bug
1540776 for Windows sandboxing (win32k lockdown) to GTK under X11.
(Currently there's no support for color management under Wayland, so
there's nothing for this patch to fix in that case.)
Differential Revision: https://phabricator.services.mozilla.com/D124507
The combination currently triggers crashes - not on Wayland though.
Put the code into non-shared code to not clutter `GLContextProviderEGL`.
Differential Revision: https://phabricator.services.mozilla.com/D125403
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