gfxFontGroup::WhichSystemFontSupportsChar reads too many cmaps on Android when loading dailymail.co.uk

RESOLVED FIXED in Firefox 66

Status

()

enhancement
P3
normal
RESOLVED FIXED
6 months ago
5 months ago

People

(Reporter: mstange, Assigned: mstange)

Tracking

(Blocks 1 bug)

Trunk
mozilla66
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed)

Details

Attachments

(2 attachments)

Assignee

Description

6 months ago
During page loading of dailymail.co.uk on a Moto G5 Android phone, we spent 1.2 seconds in gfxFontGroup::WhichSystemFontSupportsChar: https://perfht.ml/2R6VvpZ
Any thoughts, Jonathan?
Flags: needinfo?(jfkthame)
Priority: -- → P3
This implies we're encountering a character that (a) isn't supported by whatever font(s) have been explicitly chosen in CSS; and (b) also isn't supported by a font provided via GetCommonFallbackFonts[1] on that device; and so we end up in the "last-ditch" fallback codepath which scans all the installed fonts looking for one that supports the character in question. This can be expensive the first time we do it, because we have to inspect each font to determine its character coverage.

So several questions arise: what character or characters on the page are triggering the fallback search? Is this specific to a certain page that happens to have an unusual character, or does it apply to all pages on dailymail.co.uk? What fonts does the device actually have, and should something be added to GetCommonFallbackFonts to increase the chances of finding a usable font there?

Markus, can you reproduce this under a debugger (or with some tracing code added) to determine what is the first character code we encounter that goes into gfxPlatformFontList::GlobalFontFallback? Knowing that may help us figure out if we can adjust something to avoid ending up on the slow path here.


[1] https://searchfox.org/mozilla-central/rev/fc229ed2c78648e402a9bbd50d99b69d0e227844/gfx/thebes/gfxAndroidPlatform.cpp#144
Flags: needinfo?(jfkthame)
Flags: needinfo?(mstange)
Assignee

Comment 3

5 months ago

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

Markus, can you reproduce this under a debugger (or with some tracing code
added) to determine what is the first character code we encounter that goes
into gfxPlatformFontList::GlobalFontFallback? Knowing that may help us
figure out if we can adjust something to avoid ending up on the slow path
here.

Here's a profile with some tracing code added: https://perfht.ml/2QZkBmF
Specifically, there's a "Fonts" row in the marker chart.

On my device, we're doing the search because of character 10095, and we end up finding it in the font "noto sans symbols". The search takes around 300ms - 600ms with the profiler running. Adding this font to gfxAndroidPlatform::GetCommonFallbackFonts eliminates that time completely: https://perfht.ml/2R2kTZV
It's now spending 1.4ms instead of ~500ms for the search.

Flags: needinfo?(mstange)
Assignee

Comment 5

5 months ago

I don't know if "Droid Sans Symbols" is a font that exists, I've only observed
"Noto Sans Symbols" on my device.

The block number 0x27 is the block number of char 10095. There might be other
relevant blocks for this font.

Assignee

Updated

5 months ago
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Assignee

Comment 6

5 months ago

String.fromCharCode(10095) is "\u276f" is "❯"

Comment 7

5 months ago
Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/08939adf2790
Add "Noto Sans Symbols" and "Droid Sans Symbols" to the list of common fallback fonts on Android. r=jfkthame
Assignee

Comment 8

5 months ago

Uh, I forgot to correct the commit message. Oh well.

Comment 9

5 months ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.