1895926 - gfxPlatformFontList::InitFontList takes 159ms on Android startup

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

See this profile here: https://share.firefox.dev/3ykrQkg
Chrome doesn't seem to have any calls to minikin::SystemFonts::getFontMap during startup + pageload of YouTube:
See https://share.firefox.dev/3yd0tJ4

Jonathan do you know why we need to enumerate all the fonts on startup and Chrome doesn't seem to need to?

Comment 1

[Jonathan Kew [:jfkthame]]

We've always implemented font selection "manually" in Gecko (determining what fonts to use for text shaping/measurement/rendering) rather than depending on platform APIs that may not entirely conform to the CSS font-matching algorithm and may differ between systems. But this requires collecting a list of the available fonts before we can do any text shaping, so that is indeed an up-front cost that could perhaps be avoided if we relied directly on OS font-lookup APIs.

From the profile, it looks like the bulk of the time is under ASystemFontIterator_open itself.... it's apparently not just preparing to iterate over the fonts, but actually scanning them itself, opening files and creating Skia faces etc. That's unfortunate, given that all we want from it is a list of the font files. If we could get that in a more lightweight way, it should help considerably here.

(We used to just iterate over files in the /system/fonts directory, but some manufacturers put fonts in other places, so we adopted ASystemFontIterator to more reliably find them. But that seems to be unexpectedly expensive.)

We could try moving this off the main thread, like we do on macOS (see gfx.font-list-omt.enabled), but we'd need to check whether the gfxFT2FontList implementation is actually safe to run on another thread.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Presumably, Chrome does depend on the platform APIs for CSS font-matching right? Do we have examples where Chrome chooses a different font and we prefer our behaviour?

How much work would it be for us to have the option of using the platform API for CSS font-matching on Android?

Comment 3

[Jonathan Kew [:jfkthame]]

I don't know enough about the Android APIs to answer this offhand; it'll take some investigation. It's possible Makoto-san might know more; he implemented the current ASystemFontIterator-based code, IIRC.

Comment 4

[Makoto Kato [:m_kato]]

Chrome won't use AFont matcher APIs. They use Skia, then it will read XML files directly.

I guess that we have to read XML files directly rather than using AFont matcher API, or I have to look for other ways even if using AFont matcher...

Comment 5

[Jonathan Kew [:jfkthame]]

I was going to suggest we look into reading the XML files directly, which would probably be much cheaper than instantiating the ASystemFontIterator, but comments like this are not encouraging....

WARNING: Parsing of this file by third-party apps is not supported. The
file, and the font files it refers to, will be renamed and/or moved out
from their respective location in the next Android release, and/or the
format or syntax of the file may change significantly. If you parse this
file for information about system fonts, do it at your own risk. Your
application will almost certainly break with the next major Android
release.

Comment 6

[Makoto Kato [:m_kato]]

https://cs.android.com/android/_/android/platform/frameworks/base/+/b950a1f746c9e130c78eafefc9bfd7ec87da730f causes this issue. Before landing this, font API reads XML file simply, but after that, Android will read each font data to create font list for support updated font by Android 12+.