New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 2866 link

Starred by 5 users

Issue metadata

Status: Started
Owner: ----
Area: Font
NextAction: ----
Priority: Low
Type: Defect

Sign in to add a comment

Lazy Font Initialization

Project Member Reported by, Aug 22 2014

Issue description

The Android font manager had a TODO in the constructor for SkFontStyleSet_Android, suggesting that we might want to make parsing all the font streams lazy.

Applying suggests that, in a Release build on a Nexus 4 with the LMP fonts.xml, we spend ~32ms on startup reading the font from streams and scanning them in FreeType.

+benm@, miguelg@: Since this is a cost for Clank (for every process startup!) and WebView, we'd like your input as to whether or not this is worth pursuing.

Project Member

Comment 1 by, Nov 14 2014

Ben, Torne, can you opine whether 32 ms startup time (on N4) is worth the engineering work & possible hitches for font loading at runtime?
Project Member

Comment 2 by, Nov 14 2014

Note that this also times creating a FT_Library for each font as well, which cannot be trivial. With I made it so we only create one, outside this loop. Can we rebase the timing CL ( ) and see what the new numbers are?
Project Member

Comment 3 by, Nov 14 2014

Doing some testing myself, it looks like the change mentioned in Comment #2 cuts ~3ms (7%-10%). It does improve things a bit, but isn't the big difference we're looking for.

On the other hand, note that Skia already doesn't create the FontMgr at all until the first request for a typeface. Retrieving the font/style information lazily also brings up thread issues and overhead later. The way DirectWrite and FontConfig get around this is by placing all of this information in persistent storage in a format where they can just mmap the cache and use it directly. We would like something like this anyway so that we can store more information , like a bitmap of supported characters in a font.

Comment 4 by, Nov 18 2014

Any improvement is nice, of course :-) what is the engineering effort involved in making this change? WebView startup time on a HH is around 250ms, so a 32ms gain is greater than 10% of that (assuming the gain on N4 is similar to that on N5).
Project Member

Comment 5 by, Nov 18 2014

Getting an actual cache would be great and probably speed things up quite a bit (both for Chrome and Android itself), but that's a lot of work and would probably mean another API and the cache storage would need to be managed by the app. It would also be far more efficient with many fonts installed.

Just doing the TODO in the code is probably not going to affect perceived startup time, since it is likely that everything will need to be loaded anyway on the first request for a typeface (which is essentially what is already happening). It would be a good deal of work and complicate the code with threading issues. I think it would probably be around as much work as getting a cache working as well.

Mostly, this hasn't been worked on yet because at the moment we're still transitioning to the SkFontMgr interface itself.
Project Member

Comment 6 by, Nov 18 2014

One other thing which may or may not be more work. Android itself gets around this by having a zygote process in which this work has already been done. When it starts a process it gets forked from this zygote, so the runtime is already "warmed up". Chrome could do something similar on Android so that the font scanning is only done at app startup instead of once per renderer process. I think Chrome Linux does something like this in order to have a central font cache as well. On the other hand, this may or may not be a lot of work as well, and does not help initial app / first renderer startup time.
Project Member

Comment 7 by, Dec 7 2015

Labels: Hotlist-Fixit
Project Member

Comment 8 by, Oct 5 2016

Owner: ----

Sign in to add a comment