[Fontconfig-bugs] [Bug 64766] Make fontconfig scanning faster

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri May 16 14:26:56 PDT 2014


https://bugs.freedesktop.org/show_bug.cgi?id=64766

--- Comment #24 from Behdad Esfahbod <freedesktop at behdad.org> ---
Ok, I looked into this a bit.  First, I made some cleanups to the FC_HASH code.
 It's as streamlined as it can be right now.  That said:

  * We spend more than half of the time in computing the hash,

  * Of the remaining time, we spend half verifying that each glyph has an
outline,

The rest I suppose we spend computing the languages covered by the font...

So.  I think we might want to:

  * Reconsider the FC_HASH.  I could see a use for FC_HASH for speeding up
cache rebuild, but given that querying the rest of the font is faster than
computing the hash, it makes no sense.  So we're left with a FC_HASH that some
clients might find useful, but so far we don't have anyone actually using it. 
So we might as well remove it.

  * Alternatively, keep FC_HASH, but not compute it if file=NULL is passed to
FcFreeTypeQueryFace.  Previously, file=NULL was NOT supported and one had to
pass file="" or something like that.  I just made file="NULL happily not add
FC_FILE.  I think we can use the same as a signal to skip FC_HASH calculation. 
That helps with the "make querying memory fonts faster" at least, but not quite
with the cache generation speed,

  * If font has loca/glyf tables, access those directly instead of loading
glyphs from FreeType,

  * See where the rest of the time is going and speed that up.

What do people think about FC_HASH?  Should we just remove it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20140516/4e3b2851/attachment.html>


More information about the Fontconfig-bugs mailing list