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
I'm hesitant to use RenderBlocking in the sense that... well, we know we
are not going to get to fetch it between rendering. Maybe this?
Differential Revision: https://phabricator.services.mozilla.com/D190107
This only makes a difference in the (obscure) case where the block ancestor's
"first available font" (as defined by CSS Fonts) does not support the <space>
character; an example is PowerlineSymbols.
I confirmed that this fixes the GitHub "ghosting" issue on my Ubuntu system
when I have the fonts-powerline package installed.
Test in following patch.
Differential Revision: https://phabricator.services.mozilla.com/D189650
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).
Differential Revision: https://phabricator.services.mozilla.com/D170287
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
Somewhat arbitrarily, require at least 3 standard "Base" fonts; otherwise assume
the user has done something weird such as delete all the distro fonts and install
an alternative collection, so we can't usefully classify them.
Differential Revision: https://phabricator.services.mozilla.com/D189394
This method does not rely on any instance data, it just depends on system font APIs.
So it can be declared as static and used regardless of whether the platform font list
is fully initialized.
This avoids blocking on platform font list initialization when the widget code
calls LookupSystemFont during startup.
Differential Revision: https://phabricator.services.mozilla.com/D171207
We register the gfxUserFontSet instance with the platform font list so that it can
be updated when necessary, if the font list changes such that src:local rules might
resolve differently. But if src:local is not used, the font set does not need to
be aware of the platform list, so we can make the connection only when a local
lookup is actually present.
This avoids blocking the main thread during startup, e.g. when we create a font set
for the -moz-bullet dataURI font that is part of the UA stylesheet.
Differential Revision: https://phabricator.services.mozilla.com/D171206
Prior to this patch, CanvasRenderThread represents the concrete thread
we would spawn if gfxVars::UseCanvasRenderThread() returned true.
CanvasManagerParent was responsible for checking our state and deciding
between using the Compositor, Renderer and CanvasRender threads.
This patch makes the CanvasRenderThread class represent a virtual
thread. It will spawn a CanvasRender thread if necessary. Other classes
may use the abstraction to run on the correct thread without having to
duplicate the selection logic.
Differential Revision: https://phabricator.services.mozilla.com/D187719
This patch makes the remote canvas enabled state global. If we failed to
create a context, then it cannot recover, so we should never try again.
In the event of stream errors, it is likely due to virtual memory
shortages.
Differential Revision: https://phabricator.services.mozilla.com/D187718
Now that the minimum supported version of the mac SDK is 13.3, all the
macro-based checks for SDK versions older than that are always false.
Remove them.
Differential Revision: https://phabricator.services.mozilla.com/D187639