This allows us to skip additional font registration in content processes,
as it ensures consistent resolution of the font descriptor even when there
are multiple font resources with the same psname present.
Differential Revision: https://phabricator.services.mozilla.com/D195418
See comments in the bug for reasoning. macOS hasn't used subpixel AA for
quite a while.
Emulating this macOS AA on vibrant backgrounds was the only point of
this feature.
This allows to simplify the WebRender code quite a bit, too.
Differential Revision: https://phabricator.services.mozilla.com/D192311
This aims to avoid conflicts with user-installed fonts that shadow system fonts,
where there is a risk that different processes end up using different, incompatible
versions of "the same" font (i.e. they resolve the same font descriptor to different
resources).
Differential Revision: https://phabricator.services.mozilla.com/D170286
The new approach works on Ventura and Sonoma, but appears to regress behavior on some
earlier releases, so put it behind a runtime version check.
Once we no longer support pre-macOS 13 versions, we can simplify this.
Depends on D190501
Differential Revision: https://phabricator.services.mozilla.com/D190502
This should not change behavior, it just merges the two versions of
CreateCTFontFromCGFontWithVariations to simplify maintenance.
Depends on D190500
Differential Revision: https://phabricator.services.mozilla.com/D190501
Not sure why the new implementation doesn't work on older OS versions,
but these APIs are inadequately documented and liable to change behavior
between releases. So just go with what works, as shown by testing.
Differential Revision: https://phabricator.services.mozilla.com/D190500
It appears that when a Core Text font is instantiated from a CGFont or from a font descriptor,
its optical-size setting now always gets assigned according to the font size being created,
overriding any 'opsz' variation that was already specified on the CGFont or the CTFontDescriptor.
(This seems to be a behavior change compared to older macOS versions.)
To get the desired 'opsz' setting on the Core Text font, it seems to be necessary to use
CTFontCreateCopyWithAttributes to get a modified copy of an already-existing CTFont.
Differential Revision: https://phabricator.services.mozilla.com/D190389
This aims to avoid conflicts with user-installed fonts that shadow system fonts,
where there is a risk that different processes end up using different, incompatible
versions of "the same" font (i.e. they resolve the same font descriptor to different
resources).
Differential Revision: https://phabricator.services.mozilla.com/D170286
This just tries to address fairly random changes in the Skia API and correct
our usage of it in Moz2D and some other places.
Differential Revision: https://phabricator.services.mozilla.com/D173324
This just tries to address fairly random changes in the Skia API and correct
our usage of it in Moz2D and some other places.
Differential Revision: https://phabricator.services.mozilla.com/D173324
This just tries to address fairly random changes in the Skia API and correct
our usage of it in Moz2D and some other places.
Differential Revision: https://phabricator.services.mozilla.com/D173324
WR tries to normalize Mac FontInstances so that regardless of the font color
we only need to generate one version of the glyph in the cache. This strategy
backfires for fonts with color glyphs that are nominally supposed to ignore
the font color, but may choose to opt-in to the font color per-glyph based
on table data.
This determination is problematic to do in WR itself, but Gecko knows whether
a font has color glyphs ahead of time. So we let Gecko pass this data into
ScaledFonts which can then transmit the knowledge of whether the font has
color glyphs to the WR Mac font backend, which will then take appropriate
action.
Differential Revision: https://phabricator.services.mozilla.com/D130819
WR tries to normalize Mac FontInstances so that regardless of the font color
we only need to generate one version of the glyph in the cache. This strategy
backfires for fonts with color glyphs that are nominally supposed to ignore
the font color, but may choose to opt-in to the font color per-glyph based
on table data.
This determination is problematic to do in WR itself, but Gecko knows whether
a font has color glyphs ahead of time. So we let Gecko pass this data into
ScaledFonts which can then transmit the knowledge of whether the font has
color glyphs to the WR Mac font backend, which will then take appropriate
action.
Differential Revision: https://phabricator.services.mozilla.com/D130819
This is an alternate approach to aadbc6deca05.
CTFontCreateWithGraphicsFont seems to give "LastResort" when used on a
system CGFont with variation applied on 10.12-10.14. We can avoid that
by using CTFontCreateWithGraphicsFont with a variation descriptor.
I'm only applying this approach to cairo for now to mimimize the risk
of this breaking something or causing the crashes that we were seeing
before.
See https://github.com/servo/core-foundation-rs/pull/439 for
a standalone test case.
Differential Revision: https://phabricator.services.mozilla.com/D104581
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
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
This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
--HG--
extra : moz-landing-system : lando
