Closed Bug 1745591 Opened 3 years ago Closed 3 years ago

System font rasterization on macOS 11+ slows down page load, tab opening and tab switching, take 2

Categories

(Core :: Graphics: WebRender, defect)

All
macOS
defect

Tracking

()

VERIFIED FIXED
100 Branch
Performance Impact high
Tracking Status
thunderbird_esr91 --- wontfix
firefox-esr91 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- verified
firefox106 --- verified

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:

  1. Open a new Firefox window, and navigate to mozilla.org.
  2. Press Cmd+T to open a new tab.
  3. 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.

Depends on: 1683975
Blocks: 1681339
No longer blocks: wr-perf

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Severity: -- → S4
Flags: needinfo?(jmathies)

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.

Whiteboard: [qf:p2:responsiveness] → [qf:p1:responsiveness]

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).

Performance Impact: --- → P1
Whiteboard: [qf:p1:responsiveness]

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!

Assignee: nobody → lsalzman
Status: NEW → RESOLVED
Closed: 3 years ago
Depends on: 1758555
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.