Closed Bug 1515240 Opened 2 years ago Closed 2 years ago

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

Categories

(Core :: Layout: Text and Fonts, enhancement, P3)

All
Android
enhancement

Tracking

()

RESOLVED FIXED
mozilla66
Tracking Status
firefox66 --- fixed

People

(Reporter: mstange, Assigned: mstange)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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)

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

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: nobody → mstange
Status: NEW → ASSIGNED

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

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

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

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