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 change existing behavior, but will be required once font visibility
is no longer simply a global setting. The data cached in these members depends on
the font visibility level, so currently we just flush it if the visibility pref is
modified. But in future we may be using multiple levels at the same time (in
separate contexts), so we want to maintain separate per-level caches here.
Differential Revision: https://phabricator.services.mozilla.com/D124194
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 change existing behavior, but will be required once font visibility
is no longer simply a global setting. The data cached in these members depends on
the font visibility level, so currently we just flush it if the visibility pref is
modified. But in future we may be using multiple levels at the same time (in
separate contexts), so we want to maintain separate per-level caches here.
Differential Revision: https://phabricator.services.mozilla.com/D124194
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 gives the RegisterFonts thread more time to complete its work, so that
the main thread doesn't have to wait for it in InitFontList.
In the worst case, where the registration thread still hasn't finished
by the time we call gfxPlatformFontList::PlatformFontList() the first time,
it's still no worse than previously, it just reorders some of the work
that has to be done before we can render any content.
Depends on D114863
Differential Revision: https://phabricator.services.mozilla.com/D114865
This gives the RegisterFonts thread more time to complete its work, so that
the main thread doesn't have to wait for it in InitFontList.
In the worst case, where the registration thread still hasn't finished
by the time we call gfxPlatformFontList::PlatformFontList() the first time,
it's still no worse than previously, it just reorders some of the work
that has to be done before we can render any content.
Differential Revision: https://phabricator.services.mozilla.com/D114865
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 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
This reduces IPC traffic, and avoids the (severe) impact of file access interception
and proxying by the sandbox on DirectWrite in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D83240