In `gfx/config/gfxFeature.{h,cpp}`, it can be observed that a `mozilla::gfx::FeatureState` is
a state machine that collects different "levels" of enabled-ness. To summarize[^1], these are:
1. Default
2. User
3. Environment
4. Runtime
The rules for initializing each of these layers are basically that:
1. At least (1) must be initialized, otherwise, the feature is "unused".
2. Other levels may only be initialized (or re-initialized) if (a) all previous levels were
initialized, and (b) no subsequent levels are initialized. Otherwise, throw an assertion
error.
In the bug we're fixing here, we were attempting to configure the environment level before the user
level, which violates rule 2. Oops! Make sure we init the user level before initting the
environment level.
[^1]: You can find a better description of the intent of each layer at <https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/gfx/config/gfxFeature.h#147-155>.
Differential Revision: https://phabricator.services.mozilla.com/D170764
This patch adds two new prefs, gfx.webrender.scissored-cache-clears
.enabled and .force-enabled to control its status beyond the blocklist.
The former is true by default and allows one to turn the feature off by
flipping it to false. The latter allows one to force the feature on even
if the blocklist disables it. It also adds the status to the decision
log in about:support.
Differential Revision: https://phabricator.services.mozilla.com/D170507
This replaces CTFontManagerRegisterFontsForURLs, which is deprecated since macOS 10.15.
(No user-visible behavior change.)
Depends on D170287
Differential Revision: https://phabricator.services.mozilla.com/D170288
No user-visible behavior change; just trying to move a bit more work onto a secondary thread,
in the hope of improving startup perf (althogh if there's too much contention for disk i/o,
or not enough CPU cores available, it may not help much).
Depends on D170286
Differential Revision: https://phabricator.services.mozilla.com/D170287
Local testing indicates that if we don't do this, there's a risk that Core Text will resolve font names
differently in the content vs parent processes when duplicate fonts are installed (e.g. old versions of
Arial, Helvetica, etc that some users have "inherited" from ancient systems). The mismatched fonts used
for layout (in the content process) vs painting (by the parent) lead to the "garbled text" issue.
Unfortunately, this will impact content-process startup on macOS, so expect a perf regression report.
In my local testing, this appears to prevent the "garbled text" problem when an old version of Arial is
installed, or other similar font mismatch situations. There should be no user-visible behavior change
for systems with a "clean" font installation.
Differential Revision: https://phabricator.services.mozilla.com/D170286
This reverts the per-glyph-run optimization landed in bug 1816299, and replaces it with a per-glyph version
that will work within a long run of glyphs in a single font, as well as across the glyph runs in a mixed-font textrun.
To minimize the cost of the check, rather than retrieving individual glyph bounds, we use the overall font extents.
(Note that this uses the bounding box min/max coordinates from the 'head' table, which may exceed the typographic
ascent/descent of the font, and the advances of the glyphs; we care about the ink extents, not typographic size.)
Differential Revision: https://phabricator.services.mozilla.com/D170058
This seems tricky to test in CI as it doesn't reproduce consistently
(originally reported on Windows, but I haven't been able to reproduce it
there at all; but successfully repro'd and tested locally on Linux).
Differential Revision: https://phabricator.services.mozilla.com/D169935
This is an unsavoury workaround to let the fuzzing team make progress while we are sorting through our blob layerization and sizing issues.
This adds a hidden pref "gfx.webrender.debug.restrict-blob-size", which, when set to true, clamps the size of blob images to 2048x2048.
This means that bigger blobs will render incorrectly but will be less likely to cause OOMs.
Differential Revision: https://phabricator.services.mozilla.com/D169944
This substantially improves performance when there are lots of
individual emoji glyphs scattered through a textrun, each resulting
in a separate glyphrun using the emoji font.
Differential Revision: https://phabricator.services.mozilla.com/D169926
Mingw's dcomp.h is not the official one, but rather a by-hand
reproduction. While this newly-updated version has e.g.
IDCompositionFilterEffect, it is still missing e.g.
IDCompositionColorMatrixEffect.
Differential Revision: https://phabricator.services.mozilla.com/D168839
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
about:support's feature table still shows blocklisting, just not whether
the pref is set.
If different from default, dom.webgpu.enabled still shows up in about:support under
"Important Modified Prefs" like normal.
Also renames "gfx.webgpu.force-enabled" to "gfx.webgpu.ignore-blocklist"
to reflect its functionality.
Differential Revision: https://phabricator.services.mozilla.com/D169007
This is actually a bug that pre-dates the regression here, but I haven't seen a report
of it or a specific test failure that results. However, the new WPT reftests I'm
intending to land for the slant issue do exhibit a failure until this is fixed,
so let's go ahead and do it here.
Differential Revision: https://phabricator.services.mozilla.com/D169334
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
This patch reverts our behaviour closer to how we worked prior to bug
1780193. Parts of bug 1780193 remain because they are necessary to
ensure there are no race conditions when interacting with the cache from
multiple threads.
Now we remove fonts from the expiration tracker when there are strong
references remaining to the object. When the last strong reference is
cleared, we readd the font to the expiration tracker. A lookup will
remove it from the tracker (and creates a strong reference). If it
expires from the tracker, it is then destroy. There are several race
conditions we need to manage because the refcount can be updated without
holding the gfxFontCache mutex.
Differential Revision: https://phabricator.services.mozilla.com/D156716
Modify AHardwareBuffer implementation as to support gl::SharedSurface of out-of-process WebGL. And remove unused AHardwareBuffer implementation.
By limiting AHardwareBuffer only in GPU process, AHardwareBuffer implementation becomes simpler. We do not need to handle cross process AHardwareBuffer delivery and cross process android Fence delivery.
Differential Revision: https://phabricator.services.mozilla.com/D167911
Some widely-used icon fonts use ligature rules to replace icon names such as "volume_up"
or "down_arrow" with icon glyphs. If the site is designed to use such a font, but the user
disables document fonts and we use our default Latin font instead, the underlying text will
be rendered instead of the intended icon.
To enable such fonts to continue to work, we provide a list of known ligature-icon fonts
and allow them to be used even when the document-fonts setting is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D167923
A long time ago we blocked this on Adreno 630 due to causing strange
shader linking errors. We have recently discovered that this can also
affect Adreno 620 devices too.
Differential Revision: https://phabricator.services.mozilla.com/D167941
On Android, GPU process exists by default. When GPU process does not exist, an error should disable GPU process.
On Android, WebGL handling process could easily crash. The crash could trigger disable GPU process. Current out-of-process WebGL implementation creates WebGLParent in parent process. Then a crash in parent process could be triggered by WebGL. Then it seems better to disable out-of-process WebGL when GPU process does not exist.
And it seems also better to disable accelerated canvas, since it uses WebGL for acceleration.
Differential Revision: https://phabricator.services.mozilla.com/D167512
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
We only use it to generate a dummy URI for SVG-in-Opentype documents. We
don't really need the URIs to be unique or anything in practice.
I noticed this code while looking at the load flags set up for
bug 1809006.
Differential Revision: https://phabricator.services.mozilla.com/D166291
sotaro
Jonathan Kew
Erich Gubler
Andrew Osmond
Iulian Moraru
Nicolas Silva
Stanca Serban
Otto Länd
Kelsey Gilbert
stransky
Norisz Fay
Tom Schuster
Jamie Nicol
Csoregi Natalia
Emilio Cobos Álvarez