System font rasterization on macOS 11+ slows down page load, tab opening and tab switching, take 2
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: mstange, Assigned: lsalzman)
References
Details
(Keywords: perf, perf:responsiveness)
This is a follow-up to bug 1683975, which only fixed part of the problem.
The default new tab page displays some text, for example in the Pocket suggestions. This text uses the system font.
With WebRender, we seem to be re-rasterizing system font glyphs on every new tab. Creating system fonts seems to be particularly slow on Big Sur. This delays the paint of the new tab by 100ms.
Loading pages that use system fonts, for example github or stackoverflow, also incurs this issue.
Tab switching can also hit this, for tabs that haven't been painted in a while.
Steps to reproduce:
- Open a new Firefox window, and navigate to mozilla.org.
- Press Cmd+T to open a new tab.
- Press Cmd+T again to open another new tab.
Expected results:
Opening a new tab, or switching between github tabs, or loading a gith, should be really fast.
Actual results:
There is a 100ms paint delay. Profile: https://share.firefox.dev/31V7r5m
You can see "BlockOnResources" markers on the RenderBackend thread that take over 100ms.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
The severity field is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
![]() |
||
Updated•3 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
This is currently one of the top Firefox performance problems on macOS. It's a very frequent source of jank during tab switching and page load.
Setting qf priority to 1, and I think this deserves a higher severity than S4.
Comment 3•3 years ago
|
||
I did some local instrumentation and profiling of this: https://share.firefox.dev/3t3ddM4
It seems like running the profiler slows things down by more 2x. The time for a single call to new_ct_font_with_variations goes from around 3-4ms to 9-12ms (With mozilla::profiler::AllocCallback being mostly to blame).
Updated•3 years ago
|
Reporter | ||
Comment 4•3 years ago
|
||
This was mostly fixed by bug 1758555: We now only rasterize the fonts once per window. This means that opening a new tab is fast, and switching tabs in the same window is also usually fast.
There's still work to do to share fonts across windows, or to reduce the time it takes to initialize these fonts. But the main performance problem in this bug is fixed.
Thanks, Lee!
Updated•3 years ago
|
Comment 5•2 years ago
|
||
I was able to reproduce the delay on Firefox 97.0a1 (2021-12-11) on macOS 13 by following the info provided in Comment 0.
Verified that the issue is fixed on Firefox 100.0.2 and a newer Firefox 106.0b9 and the performance was greatly improved. Tests were performed on the same system as above.
Description
•