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.
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
Currently, the GetCMSOutputProfile() and related methods pass their output
using the old C-style "ptr, len" parameters. This makes them more difficult
to deal with later in this change when they need to be safely passed over IPC.
This refactors them to return nsTArray<uint8_t> results instead. I also
removed some old cruft and refactored the existing code.
Differential Revision: https://phabricator.services.mozilla.com/D63583
--HG--
extra : moz-landing-system : lando
Now that GfxInfo supports allowlisting, we can port our existing
configuration in gfxPlatform to using allowlist rules. This will
greatly increase maintainability and certainty that the expected
devices are getting WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D62325
--HG--
extra : moz-landing-system : lando
Now that GfxInfo supports allowlisting, we can port our existing
configuration in gfxPlatform to using allowlist rules. This will
greatly increase maintainability and certainty that the expected
devices are getting WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D62325
--HG--
extra : moz-landing-system : lando
This patch only allows sacrificing subpixel anti-aliasing when the
screen size is larger than WUXGA, and when the force disable pref is not
set. In the future, we may also add disable this for high end GPUs.
This also consolidates the WebRender debug flags to use the same
signaling infrastructure to avoid needing to store the debug flag state
and check on each transaction. Instead it now applies the debug flag
updates when the gfxVar changes.
Differential Revision: https://phabricator.services.mozilla.com/D57469
--HG--
extra : moz-landing-system : lando
This patch only allows sacrificing subpixel anti-aliasing when the
screen size is larger than WUXGA, and when the force disable pref is not
set. In the future, we may also add disable this for high end GPUs.
This also consolidates the WebRender debug flags to use the same
signaling infrastructure to avoid needing to store the debug flag state
and check on each transaction. Instead it now applies the debug flag
updates when the gfxVar changes.
Differential Revision: https://phabricator.services.mozilla.com/D57469
--HG--
extra : moz-landing-system : lando
These helpers will be used by the image decoders in the next part of
this series.
Differential Revision: https://phabricator.services.mozilla.com/D52007
--HG--
extra : moz-landing-system : lando
These helpers will be used by the image decoders in the next part of
this series.
Differential Revision: https://phabricator.services.mozilla.com/D52007
--HG--
extra : moz-landing-system : lando
Before this patch, we only considered the primary screen when deciding
whether or not WebRender should be enabled. This is problematic for
Intel users where we don't want to turn on WebRender for large screens;
several small screens are just as bad as one large screen. Now we sum
the pixel count for all the screens when making this decision.
Differential Revision: https://phabricator.services.mozilla.com/D46066
--HG--
extra : moz-landing-system : lando
StaticPrefs.h will be removed two commits from now, so update these comments.
The patch removes the comment above SetUsesContainerScrolling() because it's
wrong -- it did use static prefs when introduced by bug 1181832 but then
stopped using static prefs in bug 1470504 -- and makes it inlinable.
Differential Revision: https://phabricator.services.mozilla.com/D39133
--HG--
extra : moz-landing-system : lando
This adds the base64 encoded color profile to the about:support page in
order to allow us to better diagnose and reproduce color management
issues. We can extract this, decode it and load it directly via the
gfx.color_management.display_profile pref.
Wayland does not support remote drawing for widgets from another process
at this time. As such, it is best to force disable the GPU process, so
that users will be able to get WebRender with Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D32640
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
It just doesn't work.
We add the preference media.wmf.force.allow-p010-format to force enable it.
Depends on D8136
Differential Revision: https://phabricator.services.mozilla.com/D8310
--HG--
extra : moz-landing-system : lando
This function uses a nsAutoString internally, and its caller stores its
returned value in a nsAutoString. So it's silly for us to have it return a
different type (nsString). With this change, the compiler should be able to
perform return value optimization and avoid the need for any
copying/reallocation of this function's return value.
Differential Revision: https://phabricator.services.mozilla.com/D3926
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This commit adds a paint worker thread pool to PaintThread, and dispatches
tiled paints to it. The thread pool is only created if tiling is enabled,
and its size is set by 'layers.omtp.paint-workers' and defaults to 1. If
-1 is specified, it will be sized to 'max((cpu_cores * 3) / 4, 1)'.
The one tricky part of dispatching tiled paints to a thread pool is the
AsyncEndLayerTransaction message that must execute once all paints are
finished. Previously, this runnable would be queued after all the paints
had been queued, ensuring it would be run after they had all completed.
With a thread pool, there is no guarantee. Instead this commit, uses
a flag on CompositorBridgeChild to signify whether all of the paints
have been queued ('mOutstandingAsyncEndLayerTransaction'), and after
every tiled paint it is examined to see if that paint was the last
paint, and if it is to run AsyncEndLayerTransaction. In addition,
if the async paints complete before we even mark the end of the
layer transaction, we queue it like normal.
The profiler markers are also complicated by using a thread pool.
I don't know of a great way to keep them working as they are per
thread, so for now I've removed them. I may have been the only
one using them anyway.
MozReview-Commit-ID: 5LIJ9GWSfCn
--HG--
extra : rebase_source : 0c26806f337a1b4b1511945f9c72e787b426c5ba
Factory::DoesBackendSupportDataDrawtarget already fulfills the same
purpose and we should use that instead, as imgFrame is the only user of
the former API. It has the added bonus of allowing us to use shared
surfaces on Linux with WebRender, and using volatile surfaces on Windows
when D2D is disabled.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This allows us to reuse the minimum bound guards on the pref values in other
places that want to use the prefs.
MozReview-Commit-ID: 7XKuM5u1GB8
--HG--
extra : rebase_source : 9cf85c7cbe2e8511ad2db59e7bf7ba6e8db79883
This option turns on a frame counter that is shown in the top left corner via a
QR code. It was designed to be used in video recordings of B2G phones.
It no longer seems useful, so this patch removes it.
* * *
Bug 1357298 - Remove all traces of frame numbers and power from the profiler output. r=mstange.
--HG--
extra : rebase_source : 0ce87963ce375df64bb8d80ef2b5d40ea507bc7c
Supports creating a windowless browser on Linux without an X server. Most of the
changes are just adding branches to avoid calls in to GTK which calls
into X. Some of the bigger additions were adding a separate headless widget
which implements just enough to render a page. A headless look and
feel were also added since there are many calls into GTK in the platform
specific one.
nsIFontEnumerator::GetDefaultFont() returns always nullptr. However, it's used in font setting UI at creating drop down list of available fonts. So, if we implement this as returning first available font of "font.name-list.*", it's what is the necessary UI for "default" font when "font.name.*" is empty string.
So, with this patch, the top item of font list becomes "Default (%s)" if there is available font.
MozReview-Commit-ID: cRU8gixgdF
--HG--
extra : rebase_source : beca7b7d2d423f08d35358fc84b731e817724835
Instead of just reporting the value of the pref, also make sure that about:support
incorporates the runtime check of whether or not a touch device was discovered
in the widget code. The code to do this already exists in TouchEvent::PrefEnabled,
so we can just reuse that.
MozReview-Commit-ID: DN7FSlsDwD1
--HG--
extra : rebase_source : efb3d66e1669f8f2b038888ef2b1c8bb83f1c710
This allows the GLContextProviderWGL to be created on the compositor
thread, which is something we need for webrender integration.
MozReview-Commit-ID: DtBe9nUTdK7
--HG--
extra : rebase_source : b31973542beca75255b64f350f47df16435a60e3