[macOS] Reduce the cost of handling RegisteredFontsChanged notification during startup
Categories
(Core :: Graphics: Text, enhancement)
Tracking
()
People
(Reporter: jfkthame, Assigned: jfkthame)
Details
Attachments
(1 file)
See profile: https://share.firefox.dev/3xXmtEm
This is a profile of launching a local (opt) mozilla-central build to about:blank.
Note that starting around 0.76s, the main thread spends about 130ms in gfxMacPlatformFontList::RegisteredFontsChangedNotificationCallback.
This is unfortunate, because it is redundant work. Early in startup, we "register" the OS collection of supplemental fonts, so as to get more complete language support. This is done by the RegisterFonts thread, which runs as early as possible in startup.
After this completes, we initialize the platform font list with the available font families. This is done on the InitFontList thread. As part of this, we register for notifications of any updates to the installed font list.
Unfortunately, the Core Text font manager seems to be running a bit behind us, and even though we completed font registration before registering for the notification, we receive one a bit later -- at which point we throw away the work we'd done, and re-create the font list.
So the intent of this bug is to try and avoid this duplicated work (particularly as it's on the startup path).
| Assignee | ||
Comment 1•3 years ago
|
||
During font-list initialization, we call Core Text to "activate" the supplemental language fonts,
and potentially any bundled fonts shipped with the app. But this generates an OS notification,
which if we process it will cause a redundant rebuild of our list. So to avoid this, set a flag
when we activate the fonts, telling us that the upcoming notification can be ignored.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Backed out for causing bc failures in security/sandbox/test/browser_bug1393259.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/426070ba2e70397aed87cf3e32a76c50cd37987e
Failure log: TEST-UNEXPECTED-FAIL | security/sandbox/test/browser_bug1393259.js | Test timed out
Comment 4•3 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:jfkthame, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
| Assignee | ||
Comment 5•3 years ago
|
||
I'd like to try re-landing this, but have not yet been able to reliably resolve the test issues that showed up.
Updated•1 year ago
|
Description
•