[Fontconfig] Application startup performance

[Nick Alcock]

On 15 Jan 2016, Keith Packard told this:
> It could, in theory, run a separate thread to monitor font directories
> for change and automatically rebuild the list on the fly. However,
> fontconfig isn't exactly the most thread-friendly library in the world,
> having been designed before application-level threading was common...

In addition to being excessively complex, you can't rely on such a
mechanism working anyway, because many network filesystems have no
reliable notification mechanism built in, and inotify/dnotify/etc are
local-only. This whole thread, after all, started because of people
living in the last century like me who keep either systemwide or
$HOME-based fonts, or both, on shared network filesystems -- i.e. the
sort of people who used to use the X font server before client-side
fonts were a thing.

In practice, any application that's going to *use* a bunch of fonts that
are likely to be installed in a recently-updated directory probably just
installed them itself, and can request a rescan itself. (That's not to
say it *does*, and of course there is still the edge case of someone who
tries to use some font in a long-running app, finds it's not there,
installs it using the distro tools and then gets annoyed because the
mapped font cache is out of date and the app almost certainly has no way
to explicitly refresh it so they have to restart to pick it up. Nobody's
even *tried* to fix that problem, though it seems like a fairly
plausible use case to me. Even Emacs, almost the canonical annoying-to-
shut-down long-running application that uses lots of fonts, or at least
the canonical one that programmers use, has no function exposed to Lisp
to rescan the Fontconfig cache.)

-- 
NULL && (void)