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
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
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--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 was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This rearranges how synthetic-bold use is determined in the font selection
& rendering code. Previously, we would decide during the font-selection
algorithm whether we need to apply synthetic-bold to the chosen face, and
then pass that decision through the fontgroup (storing it in the FamilyFace
entries of the mFonts array there) down to the actual rendering code that
instantiates fonts from the faces (font entries) we've selected.
That became a problem for variation fonts because in the case of a user
font, we may not have downloaded the resource yet, so we just have a "user
font container" entry, which carries the descriptors from the @font-face
rule and will fetch the actual resource when needed. But in the case of a
@font-face rule without a weight descriptor, we don't actually know at
font-selection time whether the face will support "true" bold (via a
variation axis) or not, so we can't reliably make the right decision about
applying synthetic bold.
So we now defer that decision until we actually instantiate a platform font
object to shape/measure/draw text. At that point, we have the requested
style and we also have the real font resource, so we can easily determine
whether fake-bold is required.
(This patch should not result in any visible behavior change; that will
come in a second patch now that the architecture supports it.)
Andrew Osmond
Simon Giesecke
Emilio Cobos Álvarez
shravanrn@gmail.com
Brindusan Cristian
Cosmin Sabou
Jonathan Kew
Sylvestre Ledru
arthur.iakab
Ehsan Akhgari
Tooru Fujisawa
Chris Peterson
Jonathan Watt