The base::SharedMemory class provides APIs to create a "read-only" copy of a shared memory block,
which means it can be shared to a child process without the risk that the child might map it as
writable and corrupt the contents. We want to use this facility for the font list, hence switching
the shared-memory APIs used.
Differential Revision: https://phabricator.services.mozilla.com/D68778
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 34ebd6260867 (bug 1550037)
Backed out changeset 7571e5bc19e7 (bug 1550037)
Backed out changeset 71fdead8eecb (bug 1550037)
In mozilla::ipc::SharedMemory, the memory() method was virtual, so we cached the address here
(although the compiler would likely have inlined the accessor as the `final` concrete subclass
was known). Anyhow, in base::SharedMemory it's a trivial (non-virtual) accessor, so there's
no sense in shadowing it here.
Differential Revision: https://phabricator.services.mozilla.com/D68789
--HG--
extra : moz-landing-system : lando
The base::SharedMemory class provides APIs to create a "read-only" copy of a shared memory block,
which means it can be shared to a child process without the risk that the child might map it as
writable and corrupt the contents. We want to use this facility for the font list, hence switching
the shared-memory APIs used.
Differential Revision: https://phabricator.services.mozilla.com/D68778
--HG--
extra : moz-landing-system : lando
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.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
This adds a helper for applying gfxinfo state to a gfxFeature. The
helper includes the blacking list reason which should give us some more
information for about:support and telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D69427
--HG--
extra : moz-landing-system : lando
These two platforms are the easiest to get started with - as well as accounting for the great majority
of desktop Firefox users.
This patch is based on the OS vendors' lists of fonts shipped with the current version of each OS.
Differential Revision: https://phabricator.services.mozilla.com/D66125
--HG--
extra : moz-landing-system : lando
This replaces and extends the "hidden" flag we currently use on macOS to mark internal system fonts
like .LastResort and .Keyboard that should not be exposed; rather than just a boolean "hidden" flag
we'll have several levels of visibility, some of which the user may opt in to exposing (at the cost
of potentially becoming more fingerprintable).
The current patch assumes three levels besides always-hidden:
Base - fonts that are part of the base OS install and always available
LangPack - fonts that are provided by the OS subject to user's chosen language options
User - user-installed fonts that were not provided by the OS
(This categorization may be subject to revision as we learn more about real-world needs and
configurations.)
Differential Revision: https://phabricator.services.mozilla.com/D66124
--HG--
extra : moz-landing-system : lando
These two platforms are the easiest to get started with - as well as accounting for the great majority
of desktop Firefox users.
This patch is based on the OS vendors' lists of fonts shipped with the current version of each OS.
Differential Revision: https://phabricator.services.mozilla.com/D66125
--HG--
extra : moz-landing-system : lando
This replaces and extends the "hidden" flag we currently use on macOS to mark internal system fonts
like .LastResort and .Keyboard that should not be exposed; rather than just a boolean "hidden" flag
we'll have several levels of visibility, some of which the user may opt in to exposing (at the cost
of potentially becoming more fingerprintable).
The current patch assumes three levels besides always-hidden:
Base - fonts that are part of the base OS install and always available
LangPack - fonts that are provided by the OS subject to user's chosen language options
User - user-installed fonts that were not provided by the OS
(This categorization may be subject to revision as we learn more about real-world needs and
configurations.)
Differential Revision: https://phabricator.services.mozilla.com/D66124
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68152
--HG--
extra : moz-landing-system : lando
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.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
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
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--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
This corrects the direction of the skew for non-WebRender drawing.
For WR, I guess we'll need to adjust the matrix that's generated in
FontTransform::synthesize_italics (or something like that).
Differential Revision: https://phabricator.services.mozilla.com/D63893
--HG--
extra : moz-landing-system : lando
- Increment MAX_DISPLAY_CONNECTIONS to 5 (main, compositor, renderer, and two media threads).
- Stop posting events to message loop when it's deleted. Use message loop shutdown observer for it.
- Shutdown nsWaylandDisplay event queue on both chrome and content processes.
- Use static preference variables which means dmabuf prefs are renamed to: widget.wayland-dmabuf-textures.enabled widget.wayland-dmabuf-webgl.enabled widget.wayland-dmabuf-vaapi.enabled
Differential Revision: https://phabricator.services.mozilla.com/D64474
--HG--
extra : moz-landing-system : lando
We are intending to advance the toolkit.shutdown.lateWriteChecksStage
pref, to collect information (and crash on DEBUG) about writes which
happen during and after the xpcom-shutdown-threads notification. This
is producing failures in the PrintTargetPDF.cpp destructor because
we end up calling write_func and writing to (I presume) the target
PDF. This _feels_ like something we can just skip, so that's the
review request I am sending, but please let me know if it's critical
that we write to this file during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D63218
--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
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--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
We include it everywhere because it's included from gfxTypes.h.
This should avoid including all the generated bindings _everywhere_.
Differential Revision: https://phabricator.services.mozilla.com/D62174
--HG--
extra : moz-landing-system : lando
In bug 1578329 I introduced two scoping mistakes:
- A marker was made to have a shorter duration.
- A label was scoped too short and so would most likely be missed during
sampling.
This patch reverts to the original wider scope.
Differential Revision: https://phabricator.services.mozilla.com/D62274
--HG--
extra : moz-landing-system : lando
We will no longer allow OMTP on 32-bit systems with less than 2GB of RAM
and 2 or fewer cores. These systems are unlikely to realize a benefit
from OMTP and see a higher than normal incidence of OOM crashes in the
content process due to OMTP having a higher memory footprint.
Differential Revision: https://phabricator.services.mozilla.com/D60058
--HG--
extra : moz-landing-system : lando
We need a way to switch it on and off to compare the performance and power usage of various test cases.
The new pref is "webrender.enable-multithreading" and does not require a restart.
Differential Revision: https://phabricator.services.mozilla.com/D61589
--HG--
extra : moz-landing-system : lando
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_FULL_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalCorners())"
rename "NS_FOR_CSS_FULL_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61251
--HG--
extra : moz-landing-system : lando
We replace SetWidthIfLength and SetOffsetIfLength with ComputeDecorationLine{Thickness,Offset} functions,
and consolidate more of the computation of the offset within this function to simplify callers.
Differential Revision: https://phabricator.services.mozilla.com/D61454
--HG--
extra : moz-landing-system : lando
Now mfbt/Move.h is empty except for that excellent comment about move
semantics... Should we put it somewhere else and delete the header as a
follow-up? Or just delete the header and carry on?
Differential Revision: https://phabricator.services.mozilla.com/D60297
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Optionally serialize N frames into a circular memory buffer, and save
them as part of wr-capture into tilecache/.
The new tile_view utility reads the folder and converts the frames to
svg for easier visualization, with a few extra features:
- color code each primitive based on which slice it is on;
- highlight new or moving primitives in red (brute force diff);
- print all invalidated tiles at the top and the invalidation reason;
- overlay the tile quadtree to visualize splitting & merging;
- HTML and JS wrappers for animation playback, timeline scrubbing;
Positioning of the tiles on the screen is a bit broken still; especially
during scrolling and "special" pages (like about:config).
Interning info is not used yet.
Differential Revision: https://phabricator.services.mozilla.com/D59975
--HG--
extra : moz-landing-system : lando
Optionally serialize N frames into a circular memory buffer, and save
them as part of wr-capture into tilecache/.
The new tile_view utility reads the folder and converts the frames to
svg for easier visualization, with a few extra features:
- color code each primitive based on which slice it is on;
- highlight new or moving primitives in red (brute force diff);
- print all invalidated tiles at the top and the invalidation reason;
- overlay the tile quadtree to visualize splitting & merging;
- HTML and JS wrappers for animation playback, timeline scrubbing;
Positioning of the tiles on the screen is a bit broken still; especially
during scrolling and "special" pages (like about:config).
Interning info is not used yet.
Differential Revision: https://phabricator.services.mozilla.com/D59975
--HG--
extra : moz-landing-system : lando
Optionally serialize N frames into a circular memory buffer, and save
them as part of wr-capture into tilecache/.
The new tile_view utility reads the folder and converts the frames to
svg for easier visualization, with a few extra features:
- color code each primitive based on which slice it is on;
- highlight new or moving primitives in red (brute force diff);
- print all invalidated tiles at the top and the invalidation reason;
- overlay the tile quadtree to visualize splitting & merging;
- HTML and JS wrappers for animation playback, timeline scrubbing;
Positioning of the tiles on the screen is a bit broken still; especially
during scrolling and "special" pages (like about:config).
Interning info is not used yet.
Differential Revision: https://phabricator.services.mozilla.com/D59975
--HG--
extra : moz-landing-system : lando
We need to provide separated dmabuf configurations for WebGL and Texture backends
as we want to enable dmabuf for WebGL only right now.
Depends on D59487
Differential Revision: https://phabricator.services.mozilla.com/D59488
--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
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
I'm not quite familiar with the history of this code, but Gnome a11y settings
set the scale to 1.25 (which gives 120dpi). We were rounding it away, which
seems quite unfortunate.
Differential Revision: https://phabricator.services.mozilla.com/D58279
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
* Duplicate gfx.compositor and gfx.adapter.device_id with last_seen
versions that have a 'user' lifetime to temporarily work around
telemetry null string issues.
* Fix linting warnings
Differential Revision: https://phabricator.services.mozilla.com/D57143
--HG--
extra : moz-landing-system : lando
about:support could have an information that WR compositor is disabled by disabling picture caching.
Differential Revision: https://phabricator.services.mozilla.com/D57266
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
FeatureState does not add a log when it is enabled by default. But we want it for Feature::WEBRENDER_COMPOSITOR.
Differential Revision: https://phabricator.services.mozilla.com/D56848
--HG--
extra : moz-landing-system : lando
Now that we have C++17, and thus inline const, we can do this.
Depends on D56306
Differential Revision: https://phabricator.services.mozilla.com/D56307
--HG--
extra : moz-landing-system : lando
For a PMSession to be given a job name, the job name must be set on the
PMPrintSettings before it is passed to PMSessionBeginCGDocumentNoDialog.
However, since nsDeviceContext::BeginDocument calls PrintTarget::BeginPrinting
before calling nsDeviceContextSpec::BeginDocument, the setting of the job name
in nsDeviceContextSpecX::BeginDocument was happening after the
PMSessionBeginCGDocumentNoDialog call in PrintTargetCG::BeginPrinting, and was
doing us no good. This moves the job name setting into
PrintTargetCG::BeginPrinting so that the job name is set first.
Note: The job name is shown if your printer/OS has software to manage the list
of queued jobs waiting to print.
Differential Revision: https://phabricator.services.mozilla.com/D56241
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Lets Wayland sessions run vsync off wayland surface frame callbacks by creating
an interface for widgets to return a local VsyncSource, if applicable.
This interface is currently used for the compositor, and for refresh drivers
in the parent process. It is not yet used for vsync in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D28430
--HG--
extra : moz-landing-system : lando
These operations report whether certain async plugin drawing modes are supported on the host architecture. They use kernel graphics operations to decide this so they need to be removed from the content process for sandboxing. We just bounce the requests to the gpu process (or main process on systems without a GPU process).
Differential Revision: https://phabricator.services.mozilla.com/D46085
--HG--
extra : moz-landing-system : lando