1617037 - 190ms in gfxFontEntry::SetupVariationRanges() during startup on macOS

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P2)

Description

[Markus Stange [:mstange]]

Profile: https://perfht.ml/32nX721

Is this only looking for variations of .SF NS or also of other fonts? If it's just for one font, it seems surprising that we call CTFontCreateWithGraphicsFont so many times.

Comment 1

[Jonathan Kew [:jfkthame]]

It appears that when we ask NSFontManager for the availableMembersOfFontFamily for the .SF NS family, we get an array of 56 individual face names, representing predefined instances of the variable font from Ultrathin to BlackItalic.

Unfortunately, we don't know that they're all instances of the same font resource; as far as we're concerned, they appear to be 56 separate faces, and so we need to inspect them individually to determine their available variations.

Clearly this is redundant, but I'm not sure how we can tell the difference between a family that returns a list of "real" faces, each representing a different font resource with (potentially) its own unique variations, and a family like this that returns a list of faces that are in fact just instances of the same resource.

(It's particularly unfortunate that we're doing this for faces of a family that is "hidden" so that it shouldn't be exposed by name anyway - though I notice we currently have a bug here, in that while font-family: ".SF NS" does not work -- which IMO is correct behavior -- a @font-face rule with src:local(".SFNS-Black") does use the "hidden" system font, which I don't think should be allowed. That's a trivial fix; I'll file a separate issue for it.)

Comment 2

[Cameron McCormack (:heycam)]

(In reply to Jonathan Kew (:jfkthame) from comment #1)

Clearly this is redundant, but I'm not sure how we can tell the difference between a family that returns a list of "real" faces, each representing a different font resource with (potentially) its own unique variations, and a family like this that returns a list of faces that are in fact just instances of the same resource.

Can we special casie ".SF NS" to avoid querying each face for its variations?

Comment 3

[Jonathan Kew [:jfkthame]]

We could, although that's a bit fragile (Apple changes the name of the system font family with some regularity -- which shouldn't matter as it's not supposed to be exposed by name) and the issue is likely to come back with some future system update.

Perhaps better, I think we can significantly improve the performance here by avoiding the use of Core Text. The main cost is instantiating the CTFont for each face we're looking at, which we do in order to call CTFontCopyVariationAxes. I guess Core Text probably does a bunch of additional work preparing the face for actual rendering - which in many cases we're never going to need. So we can do better if we just read the OpenType font variations table directly from the CGFont resource, within involving a Core Text face.

We already have code in gfxFontUtils that interprets the 'fvar' table, because we need that on both macOS and Windows to expose font-instance data for devtools; we can pretty easily use that same code to read the variation axes here as well. In my testing, this reduces the time spent in SetupVariationRanges (for a process that initializes the ".SF NS" font family) from 100ms-plus to under 30ms.

(Note that many content processes never need to use ".SF NS", so are less impacted by this; it mostly applies to the parent process, and to pages - like Apple's - that explicitly use the -apple-system font family.)

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1617037 - Don't instantiate a CTFont to implement SetupVariationRanges on macOS, just read the font tables directly. r=lsalzman

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b883fb0de16e
Don't instantiate a CTFont to implement SetupVariationRanges on macOS, just read the font tables directly. r=lsalzman

Comment 6

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/b883fb0de16e