GNOME Bugzilla – Bug 793918
Gimp keeps rebuilding the font cache at each startup
Last modified: 2018-03-01 22:01:48 UTC
My observations: On pristine system (no font cache): - start Gimp - Gimp shows "Loading fonts, this may take a while" - Gimp terminates init - when you exit ~/fontconfig/cache contains three files: * somelonghexname-le64.cache-7 (2MB on this VM (some additional fonts installed by MS Office)) * someotherlonghexname-le64.cache-7 (1K) * CACHEDIR.TAG (1K) - If Gimp is started again, it starts without delay. - install another system font - Gimp shows "Loading fonts, this may take a while" - Gimp terminates init - when you exit ~/fontconfig/cache may (about 2 times out of 3 for me) contain *four* files: * somelonghexname-le64.cache-7 (2MB) * somelonghexname-le64.cache-7.NEW (2MB+, slightly bigger) * someotherlonghexname-le64.cache-7 (1K) * CACHEDIR.TAG (1K) - If Gimp is started again, it shows "Loading fonts, this may take a while", and will do so for every startup from then on - If you erase `somelonghexname-le64.cache-7` and rename `somelonghexname-le64.cache-7.NEW` to `somelonghexname-le64.cache-7` Gimp starts without rebuilding the font cache. So it seems that sometimes/often something prevents the new cache to be taken in account, and Gimp keeps noticing the discrepancy between the current font cache and the system on every start.
Additional report: when in the ".NEW" situation, Gimp seems to take very look to close (main window goes off quickly, but the toolbox remains, in my case), and fixing the .NEW also fixes this. See https://www.gimp-forum.net/Thread-Gimp-loading-fonts-on-each-startup-possible-workaround?pid=6573#pid6573
s/very look/very long/
This problem has already been reported to us, and to this point, it is thought to be a bug in fontconfig (basically locked cache files which results in failed font cache update): bug 782676. This is why master and gimp-2-8 branch now requires fontconfig 2.12.4 or over, which contain a fix. Which version of fontconfig are you using? If below fontconfig 2.12.4, could you please update and retry. Then tell us if this fixes your problem (in which case, we'll just close as duplicate of bug 782676).
As it is on Windows, this Gimp instance is using whatever fontconfig that came with it AFAIK... where does Joe User get an independent fontconfig DLL at the proper level?
(In reply to Ofnuts from comment #4) > As it is on Windows, this Gimp instance is using whatever fontconfig that > came with it AFAIK... where does Joe User get an independent fontconfig DLL > at the proper level? Yeah sorry, somehow I assumed you were compiling (which is not very logical since that is a stable version you are reporting the bug on!). So yeah if you installed from the installer, you haven't got a recent enough fontconfig on Windows. This is a problem which should be fixed by next release (2.8.24) since we now have a higher minimum requirement. So I will just close as a duplicate of bug 782676. *** This bug has been marked as a duplicate of bug 782676 ***
Created attachment 369158 [details] Fontconfig cross-built lib for Windows 64-bit (untested) P.S.: if you wish to test to replace the fontconfig DLL, I can provide you with this DLL I crossbuilt for Windows 64-bit. Now just a fair warning: this is without any warranty of any sort, nor is it officially provided by GIMP and is without support, etc. This is just a quick build which I did for myself, and it is untested. And so on, just no warranty whatsoever. But if you want to test if it solves your issue as well, be my guest. Just replace the current fontconfig DLL (which you can just rename to restore it, just in case) provided by GIMP installer by this one and tell us if it is better. :-)
Close but no cigar. That new DLL requires a libexpat which is a new addition. And a size comparison with the previous one (1.6M vs 284K) makes me think that all the debug options have been left in.
(In reply to Ofnuts from comment #7) > Close but no cigar. That new DLL requires a libexpat which is a new Oups. Well, as I said, no warranty. Sorry that it didn't work. I can't really make the time to look for all the required dependent DLLs. :-/ > addition. And a size comparison with the previous one (1.6M vs 284K) makes > me think that all the debug options have been left in. Highly possible. I just made a quick build with all defaults. This mostly means debug is on.