Avoid using FreeType to read font information during cold-start on Android
Categories
(Core :: Layout: Text and Fonts, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox75 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
Details
Attachments
(1 file)
Given the win we get in bug 1613996 by using harfbuzz to read font tables instead of instantiating a FreeType face, I wonder if we can also improve cold-start time by similarly avoiding FreeType during font-list initialization.
I'll put up a patch so that we can try to measure the impact.
|
Assignee | |
Comment 1•4 years ago
|
||
|
|
Assignee | |
Comment 2•4 years ago
•
|
||
Here's a patch that tries to avoid all those freetype face instantiations, in the hope that it'll be less expensive. I've pushed a try run at https://treeherder.mozilla.org/#/jobs?repo=try&revision=c4f7b7687bc8838e4cbab02eabc01b51dbdcd175, but not sure if it'll be possible to tell anything from the talos measurements there, as they seem pretty noisy.
Markus, would you be able to profile cold startup with this patch, and compare to a build without? (Or tell me how I can do it -- but I don't have a suitable device on hand!) My hope, if it works as intended, is that we'll end up spending less time under gfxFT2FontList::InitFontListForPlatform() by avoiding freetype there. (I believe this should only be relevant on first run, as subsequent startups should be using font data from the startupcache rather than reading all the fonts afresh.)
|
||
Comment 3•4 years ago
|
||
Fantastic results again!
Before: https://perfht.ml/2HrvHP7 https://perfht.ml/2HdDrUq
After: https://perfht.ml/2HgaV4E https://perfht.ml/2vnwPQP
It brought down the time spent in gfxAndroidPlatform::CreatePlatformFontList on my phone down from 200-250ms to 20ms.
(In reply to Jonathan Kew (:jfkthame) from comment #2)
(Or tell me how I can do it -- but I don't have a suitable device on hand!)
Well, you do need a device, I think. I wouldn't trust emulator timings for this.
I'll need to write up some better instructions on how to do this. I used the adb shell am start [...] command from the MDN section about startup profiling but with a custom tweak to about:debugging that let me capture existing profiling runs.
(I believe this should only be relevant on first run, as subsequent startups should be using font data from the startupcache rather than reading all the fonts afresh.)
I don't think the startupcache mechanism is working for me in GeckoView-example. Or maybe I just didn't give the app enough time to settle so that it would write the information to the cache. In any case, I'm seeing slow initialization even on subsequent starts.
|
|
Assignee | |
Comment 4•4 years ago
|
||
Awesome, thanks for testing! I'm just looking into the unexpected-pass that we seem to get with this patch, as I'd like to understand what's going on there, then will see if I can get this ready to review & land.
|
|
Assignee | |
Comment 5•4 years ago
|
||
OK, the unexpected-pass happened because the patch just used the original TrueType "family" name, but this results in things like Roboto Black ending up as a separate family from Roboto, rather than the single Roboto family having multiple weights. This then affected which font is used in that testcase, and made the current (trivial) failure go away.
So to maintain expected behavior, we need to look at the "typographic" family name in preference, if present in the font, so that we get the proper structure for extended families with >2 weights.
With that fixed, we should be fine here. New try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2595e1b29b5edeb9b00a887c3e035300580f8244
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4c71cdf4c81c Avoid instantiating an FT_Face for each font just to read properties during font-list initialization. r=lsalzman
|
|
||
Comment 7•4 years ago
|
||
I profiled the updated try build again, and I think this time I actually encountered a proper cold load in one of the profiles. It seems like we can still spend 200-300ms in gfxFT2FontList::AppendFacesFromBlob.
"Slow" profile: https://perfht.ml/2OMGHue
"Fast" profile: https://perfht.ml/2UKF8AL
|
||
Comment 8•4 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 9•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #7)
I profiled the updated try build again, and I think this time I actually encountered a proper cold load in one of the profiles. It seems like we can still spend 200-300ms in
gfxFT2FontList::AppendFacesFromBlob."Slow" profile: https://perfht.ml/2OMGHue
"Fast" profile: https://perfht.ml/2UKF8AL
Hmm, that's curious. So maybe it's unclear how much (or how consistent) the improvement here will be. I wonder if there's some reason that disk i/o is sometimes extremely slow - e.g. if the storage device is busy for some reason?
Description
•