On Microsoft Windows platforms, the first start of an application using fontconfig can be the first time the fontconfig cache is actually created. For GIMP, we get the occasionally bug report that this takes a very long time on startup, on every DST change (due to how MS Windows reports file modification dates), and sometimes "every time". We take that last one with several grains of salt, because "every time" may just be "I noticed it the last time I started GIMP, and oops it doesn't happen just now...". Anyway, in bug https://bugzilla.gnome.org/show_bug.cgi?id=782676 there is a description of what is happening to some users upgrading to GIMP 2.8.22 right now - including a copy of the fontconfig cache folder which allows to reproduce the issue. Maybe someone working on fontconfig can shed some light on the issue, and tells us whether this is an issue in fontconfig, or in the way it is packaged in the GIMP installers, or the way it is used by GIMP?
what version of fontconfig did gimp 2.8.22 use?
Likely some 2.11, judging by the 2014 creation date of the libfontconfig dll file (which is most likely taken from opensuse's mingw repository.
We have exactly the same problem in Inkscape for Windows. We could resolve one issue we faced [1]: By default fontconfig stored the cache to a temporary location. If this temporary location was cleared (i.e. by some system cleanup tool) the cache had to be re-created the next time Inkscape was run. (Maybe something like this is causing some of the "every time" comments for you?) We fixed the issue by configuring fontcache to write the cache to LOCAL_APPDATA_FONTCONFIG_CACHE We still have the underlying issue [2]: Creation of the fontconfig cache needs time, especially on slower systems or systems with a lot of fonts installed. This delays the startup of Inkscape considerably, which is especially bad since it obviously affects every first time user (and even worse because Inkscape - in contrast to GIMP - does not have a startup screen informing the user about what it's doing. Subsequent startups with this configuration are usually fast though, with the exception of bug 99360 which lately prevented fontconfig to update an outdated cache file. The behavior matches what you experience: a .new file with the updated cache was created but never used to actually replace the old cache (this was due to file locks as described in the linked bug; the patch there fixed the issue for us, though). [1] https://bugs.launchpad.net/inkscape/+bug/1196373 [2] https://bugs.launchpad.net/inkscape/+bug/1528629
Aha. then what I can propose is to try the latest one. it might be already fixed in there.
The slowness at the first time is intentional and not a bug in fontconfig at all. usually it is avoidable on most distributions by generating caches on installation time. but it often happens on Windows because that necessary process isn't usually taken. I'm not familiar with Windows though, if there are any trigger on installing fonts, you could do run fc-cache on it or run fc-cache by timer periodically if the cache location is on the common place.
For first-time slowness, let's follow up here: https://bugs.freedesktop.org/show_bug.cgi?id=64766#c47
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/58.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.