What's with fon files being slow? Please report *that* and let's fix it.
We've made scanning, like, 100x faster already. 2007 stats are irrelevant. Checksuming files is slower than scanning them now.On Sun, Feb 25, 2018 at 8:08 AM, Kurt Kartaltepe <kkartaltepe@xxxxxxxxx> wrote:
While trying to move a project to the pango stack I noticed the native
font selection backends were bad/useless on some platforms (like
windows see [1]). So I opted to try and use fontconfig on all
platforms as it performs outstandingly and has wonderful defaults for
all platforms.
However during this transition I noticed that there are some major
issues with cache build speed and during investigation I see that
there has recently been effort to improve the situation[2]. From what
I can tell the fontconfig team has maintained that these cache issues
were irrelevent for the primary fontconfig platform (linux) [3]. On
linux of course the cache is global and maintained usually by font
packages ensuring its up-to-date. However it was precisely this the
slow cache build times that lead to package managers being required to
build in additional tooling to support not rebuilding cache for every
font installed [4].
Anyway I hope that is enough reason to persuade you that there are
substantial improvements to make to the caching strategy and they are
beneficial not only for the odd platforms (osx, windows) but also for
Linux.
My question is if fontconfig would be receptive to building/accepting
a patch modifying the caching strategy to include checkums per file
instead of/in addition to per directory. Currently any change to
directory (such as adding a new font) invalidates all fonts within
that directory. This means for directories like the system directory
it results in re scans of hundreds or more fonts. Thankfully this is
faster on platforms like linux where all fonts on freetype. However
this improvement in scanning did not carry over to windows with its
many FNT (150 on the average install) and even on my very robust
development machine building a cache for a mere 650 files takes half a
minute. This might be acceptable on install of the application where
we can take our time building the cache, but what happens when a user
installs 1 more font? A change to cache individual file checksums
would provide fontconfig a way to only require the expensive coverage
check of a single font instead of the entirety of a users. I dare say
with this exact change the need to use a faster less robust coverage
check that made scanning freetype fonts faster may be unneeded as the
number of scans required to rebuild a cache would reduced 100x on the
average system or more.
I'm certain such a change would be highly appreciated by all
fontconfig consumers who are hoping to use its powerful feature set in
a multiplatform context.
--Kurt Kartaltepe
[1] https://bugzilla.gnome.org/show_bug.cgi?id=162681
[2] https://lists.freedesktop.org/archives/fontconfig/2017- August/005986.html
[3] https://bugs.freedesktop.org/show_bug.cgi?id=64766
[4] https://lists.freedesktop.org/archives/fontconfig/2007- October/002728.html
_______________________________________________
Fontconfig mailing list
Fontconfig@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fontconfig
--
behdad
http://behdad.org/
http://behdad.org/
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
