Project: skia Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users
Status: Started
Owner: ----
Area: Font
Priority: Low
Type: Defect

Sign in to add a comment
Lazy Font Initialization
Project Member Reported by, Aug 22 2014 Back to list
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