This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
This is a preliminary step that is needed in order for the following patch to be safe. (It's
mostly just plumbing, although the patch looks big because we need to pass the index through
so many functions.)
The issue is that loading a font resource involves a couple of tasks that happen asynchronously -
fetching the data from the network, and decoding/sanitizing the font data. We have an implicit
assumption that once a font load has been initiated, the state of the associated gfxUserFontEntry
will not change; in particular, we depend on mSrcIndex remaining constant, because we may use it
to index into the mSrcList array and access the gfxFontFaceSrc record again in the various
completion tasks that are executed after the async steps finish.
But the following patch breaks this assumption, because it may reset mSrcIndex at arbitrary times
when we discover that we need to re-resolve the @font-face to potentially recognize a src:local()
resource that was earlier in the list, but was previously unavailable. If this happens while
a font-load is doing its off-main-thread work, then when it completes, it will end up accessing
the wrong gfxFontFaceSrc record, which would result at least in incorrect behavior, but can also
result in a crash (e.g. if the record is of the wrong type altogether, such as trying to use the
principal or URI fields from a record of type src:local).
To avoid this problem, we should pass the source index at the time the font load is initiated
through to the OMT tasks and back to their main-thread completion routines, so that we do not
depend on the field in the gfxUserFontEntry remaining frozen. This makes the loading process
safe even if the source index in the entry gets reset while loading tasks are in progress.
Differential Revision: https://phabricator.services.mozilla.com/D110911
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).
Differential Revision: https://phabricator.services.mozilla.com/D96978
We also rearrange bits in the CompressedGlyph so that the advance field doesn't need to be shifted,
and remove unnecessary glyphCount parameters from various setter methods.
Differential Revision: https://phabricator.services.mozilla.com/D90678
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--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
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
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
Bas Schouten
Jonathan Kew
Cristian Tuns
Mats Palmgren
Emilio Cobos Álvarez
Csoregi Natalia
Simon Giesecke
smolnar
Cosmin Sabou
Mihai Alexandru Michis
Andreas Farre
Andrew Osmond
Chris Peterson
shravanrn@gmail.com
Brindusan Cristian
Daniel Varga