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?
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 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.  https://searchfox.org/mozilla-central/rev/fc229ed2c78648e402a9bbd50d99b69d0e227844/gfx/thebes/gfxAndroidPlatform.cpp#144
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Pushed by firstname.lastname@example.org: 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
You need to log in before you can comment on or make changes to this bug.