Accelerate font fallback by avoiding freetype face creation where possible
Categories
(Core :: Graphics: Text, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox85 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
Details
Attachments
(2 files)
This is similar to bug 1614600, where using harfbuzz APIs in preference to freetype improved the performance of initializing the font list.
A similar issue applies when we're doing font fallback searches; if there are fonts for which we don't have an FT_Face already on hand, it's expensive to instantiate this just to check if the font has the character coverage we need. We can do better (as confirmed by Andrew's profiling in bug 1676966 comment 21) by avoiding freetype and reading the fonts using harfbuzz APIs instead.
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
In Bug 1676966, comment 14 I compared this change, fenix_harfbuzz_only
to the baseline fenix and it showed significant improvements to visual metrics on certain sites (Pixel 3).
I've captured a few profiles, and as expected, I don't see any jank in the parent process, since we've improved the font face creation.
e.g.
https://share.firefox.dev/2Vu34Yg
I'll also compare this on a lower-end phone.
Comment 4•5 years ago
|
||
This patch also shows a measurable improvement on the lower-end Moto G5.
These are live sites so there is a fair deal of noise, but this looks like:
~7-8% speedIndex improvement on accounts.google
~12-13% speedIndex improvement on wikipedia.
More metrics here:
https://docs.google.com/spreadsheets/d/1FjhbYxNH37FZCeJiBcz2_pH7KmXvkiclV2ppQGz3jes/edit#gid=1430810009
It will be interesting to see if this picks up anything in the geckoview browsertime tests.
Comment 5•5 years ago
|
||
To compare against what browsertime in CI picks up:
On Pixel 3 I'm seeing
~10% speedindex improvement on accounts.google.com
~29% speedindex improvement on wikipedia.org
Comment 6•5 years ago
|
||
bugherder |
Description
•