[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