After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 449848 - Startup: initialize fontconfig in the background to avoid long pause on start
Startup: initialize fontconfig in the background to avoid long pause on start
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal major
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
: 498443 533674 696998 737817 739456 741823 742738 744340 753746 754905 756092 758538 759800 761215 761696 762436 762574 764830 781507 (view as bug list)
Depends on: 141797
Blocks:
 
 
Reported: 2007-06-21 18:47 UTC by Sam Switzer
Modified: 2017-04-20 01:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First attempt at patch (3.42 KB, patch)
2007-06-25 11:07 UTC, Tor Lillqvist
none Details | Review
Updated patch, no longer conditional on ENABLE_MP (3.12 KB, patch)
2007-06-25 14:12 UTC, Tor Lillqvist
needs-work Details | Review
Updated patch (3.14 KB, patch)
2007-06-25 16:06 UTC, Tor Lillqvist
needs-work Details | Review
Updated patch (3.05 KB, patch)
2007-06-25 18:02 UTC, Tor Lillqvist
none Details | Review
Even simpler patch (1.73 KB, patch)
2007-06-26 11:25 UTC, Tor Lillqvist
needs-work Details | Review

Description Sam Switzer 2007-06-21 18:47:18 UTC
When opening gimp the first time in windows vista it gets to the fonts, and thanks to all the crazy fonts vista has by default (no, I don't need the Hungarian language font, who knew?) when it is loading them vista thinks it has stopped responding, and I did too at first, I suggest adding some visual activity (percentage done, what fonts its finding, ect.) to not confuse first time users

Other information:
It only occurs the first time it is run, because then gimp has an idea of what fonts are in the system, and it only occurs on systems with alot of fonts.
Comment 1 Tor Lillqvist 2007-06-21 20:30:04 UTC
Sorry, as far as I recall from when I last looked at this, there is no callback from fontconfig (the software, external to GIMP, that scans the fonts) while it is scanning fonts, so there is no way to get a true progress bar or percentage from this phase of the startup. GIMP probably can't even know whether the slow font scanning is going to happen or whether still valid font information cache files were found.

Maybe GIMP could do something like initialize fontconfig in a separate background thread so that the UI would come up faster, even if the fontconfig initialization is still going on? The fontconfig stuff is needed only by GIMP's text tool and the related font selector, so one can do lots of things even before fontconfig is available.

But at least for you GIMP's font scanning when starting is slow on Vista only the first time. Some people have experienced it being slow at every start on Vista... But it is good to know that that is not a universal problem.

I don't think it makes sense to keep this bug open as such, as what you see is more or less what is expected, sorry. Or, actually I think I will retitle this bug as an enhancement request for background initialization of fontconfig.

P.S: I don't think there are any fonts specific to Hungarian. Hungarian uses a pretty standard Latin alphabet with diacritics that are usually present in any decent font covering the Latin script.
Comment 2 Sam Switzer 2007-06-22 01:07:37 UTC
Hm...that's a possiblility but if the user was to go to fonts first thing (doubtful but possible) they would be greeted with another wait... we could just do a lazy fix and put "Fonts (this may take a while)" I didn't know it was separate software, so I'm stumped.

Wait...I'm not a programmer by any means so tell me if I'm wrong but is there a way to run fontconfig during setup and then send the information to The Gimp?

P.S.
Actually the Hungarian part was a joke, it was the first language I thought of, but they do have alot of alternate language fonts, I'm sure it's because I accidentally clicked something during setup.
Comment 3 Sven Neumann 2007-06-22 07:30:02 UTC
I've picked up this suggestion and actually changed the string displayed in the splash screen:

2007-06-22  Sven Neumann  <sven@gimp.org>

	* app/core/gimp.c (gimp_restore): note that loading fonts may take
	a while (on Win32 at least).
Comment 4 Tor Lillqvist 2007-06-22 08:47:32 UTC
> if the user was to go to fonts first thing (doubtful but 
> possible) they would be greeted with another wait

True, but there would be little we can do about this. Or actually, one little thing would be to move starting a font loading thread earlier (assuming this is possible) so that it would have more time to finish while GIMP does initialization other things.

> is there a way to run fontconfig during setup and then 
> send the information to The Gimp?

Yes, that is a good idea. Running fc-list for instance during installation should create the caches. But fonts need to be rescanned each time a font has been added. (I am not 100% sure whether this actually works currently, though...) So rescanning is stil needed now and then, especially for people who often add new fonts, and these people might also be heavy GIMP users...
Comment 5 Sven Neumann 2007-06-22 08:55:20 UTC
We could give the thread idea a try. It should be relatively easy to move this code to a thread. We just need to inform the user then that fonts are still being queried in case that the user tries to use a font. That could become the more difficult part.

But perhaps it would be better though to fix this upstream in fontconfig. Someone should profile the font cache creation on Windows. Perhaps it can be improved significantly. If that is not possible, then it would be a good idea to provide a way to get some sort of progress information from fontconfig.
Comment 6 Sam Switzer 2007-06-22 17:13:29 UTC
well if we ran the scan during setup it would still run the scan at startup but it would have a better idea of the fonts on the computer.
Comment 7 Tor Lillqvist 2007-06-24 17:11:39 UTC
> if we ran the scan during setup it would still run the scan at startup

No, it wouldn't, unless new fonts have been added or fonts deleted. That's why fontconfig caches this information in the first place, so that it can quickly read the information from the cache files unless fonts have been added or deleted. The way it determines if that has happened is to look at the timestamps of the font folders. (Also maybe timestamps of individual font files, to catch the case if a font file has been replaced by a new one with potentially different coverage, for instance. Without bothering now to look in the fontconfig sources I don't know for sure.) 

> but it would have a better idea of the fonts on the computer

That is the whole point of what fontconfig does when it is initialized (and then either scans or uses cached information), to find out what fonts are present on the computer.
Comment 8 Tor Lillqvist 2007-06-25 11:07:38 UTC
Created attachment 90608 [details] [review]
First attempt at patch

After just some hours of hacking, this relatively small patch seems to work. Can it be this trivial?

Apparently the container freezing and thawing stuff just works out fine without me having added any calls anywhere (except in the gimp_fonts_load function itself, for extra safety) to explicitly wait for a fonts loading thread to finish.

GIMP starts up nicely while fonts are being scanned in the background, and if one tries to select the text tool, nothing happens (presumably because the fonts container is frozen or something, haven't yet looked into it). If one has the dockable font list open when GIMP starts, and if one removes the fontconfig caches so that the font scanning threads takes a while, the font list dialog just stays empty until the scanning is done and then gets populated. (Here I at first got crashes until I moved the call to gimp_font_list_restore() to happen in the main loop in an idle handler.) One can open images, edit them, etc while the font loading continues.
Comment 9 Tor Lillqvist 2007-06-25 14:12:07 UTC
Created attachment 90615 [details] [review]
Updated patch, no longer conditional on ENABLE_MP

Slight cleanup according to discussion on IRC. No change in how it works.
Comment 10 Michael Natterer 2007-06-25 14:25:16 UTC
some comments:

+typedef struct
+{
+  Gimp     *gimp;
+  FcConfig *config;
+} gimp_fonts_load_func_data;

we don't name structs like that, PleaseRenameProperly


+  data = g_new (gimp_fonts_load_func_data, 1);

Use GSlice please.


Generally, what happens here if font loading takes long and the user
quits gimp before it's finished? Can we somehow make this case work too?
(probably a non-issue since we use exit() in stable versions to speed
up quitting)
Comment 11 Tor Lillqvist 2007-06-25 16:06:25 UTC
Created attachment 90621 [details] [review]
Updated patch

At least for me, quitting GIMP before the font loading has finished works fine.
Comment 12 Sven Neumann 2007-06-25 16:14:10 UTC
It probably works sometimes, but there are possible race conditions. Your thread has a pointer to the Gimp object but doesn't hold a reference to it. When GIMP is quit, the Gimp object is destroyed. If your thread finishes at the wrong moment, this will lead to a crash.

Also what's the point of returning NULL from gimp_fonts_load_func() ?
Comment 13 Michael Natterer 2007-06-25 16:32:18 UTC
Also, you can't call gimp_container_freeze/thaw() from the thread.
There are widgets connected to this container's signals and neither
the gimp core nor the widgets are thread safe.
Comment 14 Tor Lillqvist 2007-06-25 18:02:41 UTC
Created attachment 90627 [details] [review]
Updated patch

OK, and I guess there actually is no reason to call gimp_container_freeze/thaw() in the thread function anyway. Not in the idle function either, as gimp_font_list_restore() does it itself. Right?
Comment 15 Sven Neumann 2007-06-26 09:22:33 UTC
Can you move the thread, the mutex and the condition out of the Gimp object and put it into the GimpFontsLoadFuncData struct, please? Or is there a reason for keeping them in the object?
Comment 16 Tor Lillqvist 2007-06-26 11:06:50 UTC
Don't they need to be in the Gimp object so that gimp_fonts_load() can wait until a previous font loading thread has finished, if that unlikely case should happen?
Comment 17 Tor Lillqvist 2007-06-26 11:25:06 UTC
Created attachment 90657 [details] [review]
Even simpler patch

And on the other hand, if no such synchronization is actually needed, we don't need to use any mutex and condition at all, do we? Makes the patch even smaller... Except probably calling the fontconfig API should be protected by a global mutex?
Comment 18 Sven Neumann 2007-06-26 17:13:06 UTC
You can better keep the mutex as a static variable in the file where it is needed. It doesn't need to be in the Gimp object and actually it is even wrong to have it there because that object is not guaranteed to be a singleton.
Comment 19 Tor Lillqvist 2007-06-27 09:28:52 UTC
If a mutex is needed for fontconfig calls, it can't be local in gimp-fonts.c only, because there are some fontconfig calls in a few other files, too. What about calls to PangoFT2? Might they call fontconfig too?
Comment 20 Sven Neumann 2007-06-27 12:45:59 UTC
At least on the UNIX platform, basically everything may make calls into fontconfig. Pango uses it and Pango is used from GTK+. I am afraid we are taking a high risk here of breaking things badly.
Comment 21 Tor Lillqvist 2007-06-27 13:14:53 UTC
Yeah, I can understand that, I certainly agree that the patch might be quite risky. Which is too bad, the (apparent) speedup and improved user experience from the patch in the case where the fontconfig cache had to be recreated was quite significant, at least on Windows. Is recreating the fontconfig cache faster on UNIX? I have 630 fonts totalling 157 MB on my XP machine, including some quite large ones like Arial Unicode MS and a couple of CJK fonts. After removing the fontconfig cache files, running fc-list takes 27 seconds.
Comment 22 Michael Natterer 2007-06-27 16:35:26 UTC
Whatever, removing the mutexes can't work since the user can easily
hit the refresh button again while the old refresh is still running.
Also, it seems you removed the freeze/that from the patch, why?
Comment 23 Sven Neumann 2007-06-27 16:38:42 UTC
A mutex alone doesn't solve the problem of the user hitting the refresh button again. There needs to be some kind of feedback that fonts are being scanned. And the button should be insensitive while that happens. The application must not block while waiting for the thread to finish.
Comment 24 Sven Neumann 2007-11-21 12:54:18 UTC
*** Bug 498443 has been marked as a duplicate of this bug. ***
Comment 25 Sven Neumann 2008-01-15 13:50:05 UTC
Changing version to "Current SVN" as this request is not specific to any
particular version.
Comment 26 Sven Neumann 2008-05-18 13:28:50 UTC
*** Bug 533674 has been marked as a duplicate of this bug. ***
Comment 27 Sven Neumann 2008-05-18 13:46:25 UTC
The general idea of using a thread to load the fonts is a good idea. Before the thread is spawned, the fonts container should be emptied and the Reload action needs to be set insensitive. This should prevent the text tool from being used while the fonts are loaded. When the thread finishes, the resulting list of fonts can be added to the fonts container from an idle handler. Basically Tor's last patch does this. It just needs some minor changes to make sure that the user doesn't start another thread while the fonts are loaded.

Comment 28 Michael Schumacher 2013-04-26 07:04:59 UTC
*** Bug 696998 has been marked as a duplicate of this bug. ***
Comment 29 Michael Schumacher 2014-10-10 11:14:27 UTC
*** Bug 737817 has been marked as a duplicate of this bug. ***
Comment 30 Michael Schumacher 2014-12-20 23:20:41 UTC
*** Bug 741823 has been marked as a duplicate of this bug. ***
Comment 31 Michael Schumacher 2015-01-16 12:58:11 UTC
*** Bug 742738 has been marked as a duplicate of this bug. ***
Comment 32 Michael Schumacher 2015-02-06 15:01:44 UTC
*** Bug 739456 has been marked as a duplicate of this bug. ***
Comment 33 Michael Schumacher 2015-02-18 21:49:56 UTC
*** Bug 744340 has been marked as a duplicate of this bug. ***
Comment 34 J 2015-05-21 17:55:51 UTC
From what I gather most developers and users use some distribution of Unix or Mac, but maybe Windows users are not as vocal (or not willing to report a bug here).

Based on quite a few forum posts (on different sites), users have been experiencing slow startups on GIMP for Windows for quite a while. Some users have mentioned Windows 7 64-bit.

My experience: I've noticed GIMP slow on startup every first time since my Windows XP 32-bit days. My case is different as I package software for an educational institution. I'm working on Windows 8.1 and Windows 2012 R2 these days and am attempting to package GIMP 2.8.14 with Microsoft App-V.

I am running into the fontconfig cache issue and have been trying to bypass the 20 minute startup time on every user who launches the software for the first time. I've read rebuilding the fontconfig cache may work but my users do not have permission to rebuild the fontconfig cache nor should they have to. 

My initial fontconfig cache is only 1MB, so it shouldn't take such a long time to start up. I have not found a way to troubleshoot this reading the GIMP manual. 

Suggestions I found but did not help via:
Youtube: move unused brushes to the obsolete folder
Forum: recreate fontconfig cache
Forum: delete .gimp2.8 folder
Forum: move unused plugins or whatever to a folder named 'Unused'
Forum: modify fontconfig.dll and move fontcache to C:\Temp (http://gimpchat.com/viewtopic.php?f=7&t=4162)

I will try moving the fontconfig cache to C:\Temp.

From the link of the last suggestion, a good point was made. Why re-scan the fonts on startup everytime?

My suggestion: Would it be possible to allow the user to import their own fonts or direct it to the C:\Windows\Fonts folder? Give us a choice when we import and have it done in the background.

If I was a developer, I would jump right in and help you guys but unfortunately, I am not. I would really appreciate it if someone can suggest a workaround or inform me whether work would be done in the near future. Thanks!
Comment 35 Michael Schumacher 2015-05-21 18:13:19 UTC
You could try to distribute the font cache of one initial run to other users.

BTW, we are not really waiting for more report of that bug, we are waiting for a Windows users with the time and skills to fix the bug :)
Comment 36 J 2015-05-22 17:56:10 UTC
Thanks, Michael, for the suggestion. I'm currently looking into a way to do this.

I didn't think it would hurt to supply more information. In that case, I'm hoping someone will have the time to help out :)
Comment 37 Michael Natterer 2015-09-11 21:40:49 UTC
*** Bug 754905 has been marked as a duplicate of this bug. ***
Comment 38 Michael Natterer 2015-09-11 21:55:06 UTC
Since this issue comes up all the time, let's make it more prominent,
enhancement is just too hidden.

Thinking about the attached patch again, it actually keeps the font
list completely empty until the thread is done, and at least the text
tool does absolutely nothing if there are no fonts, so we are never
in danger of using fontconfig while the thread is running.

Checking and changing all the other few places that access text layer
rendering should be pretty easy.
Comment 39 Michael Schumacher 2015-10-06 14:18:36 UTC
*** Bug 756092 has been marked as a duplicate of this bug. ***
Comment 40 Michael Schumacher 2015-11-23 15:20:22 UTC
*** Bug 758538 has been marked as a duplicate of this bug. ***
Comment 41 Jehan 2016-02-13 19:49:38 UTC
This issue comes up all the time also because there is a fontconfig configuration issue. Hence the long wait happens not only at first startup, but also often after a reboot for many Windows users.

Fixed if we use fontconfig 2.11.1 (default config is patched) or later, OR if we edit ourselves fontconfig config files in our Windows build. See bug 703331.

I even added a warning in our configure file when you try to build for Windows with an older fontconfig. All what remains is for us to follow our own indications, but I am not sure we do, even in our official Windows builds.

Of course, the patch would still be very welcome. But I wanted to say that it should still be better if we at least used a well configured fontconfig.
Comment 42 Michael Schumacher 2016-02-15 13:38:30 UTC
*** Bug 761696 has been marked as a duplicate of this bug. ***
Comment 43 Michael Schumacher 2016-02-15 13:46:02 UTC
To spell it out, the issue repeats for some users because they, their environment or a utility they are using are clearing out %TEMP% on every reboot, and this is where the font cache is created by default.

More recent versions of fontconfig use LOCAL_APPDATA_FONTCONFIG_CACHE as the default, and this directory is less likely to be cleared on reboots.
Comment 44 Michael Natterer 2016-04-10 22:20:48 UTC
*** Bug 764830 has been marked as a duplicate of this bug. ***
Comment 45 Max Mustermann 2016-04-16 22:27:25 UTC
*** Bug 762574 has been marked as a duplicate of this bug. ***
Comment 46 Kristian Rietveld 2016-04-17 08:35:34 UTC
*** Bug 759800 has been marked as a duplicate of this bug. ***
Comment 47 Kristian Rietveld 2016-04-17 08:37:16 UTC
*** Bug 761215 has been marked as a duplicate of this bug. ***
Comment 48 Kristian Rietveld 2016-04-17 16:42:27 UTC
In both gimp-2-8 and master, the Fontconfig calls are now performed in a separate thread. The main thread will wait for the "Fontconfig thread" to be finished and pulse the GUI regularly. This fix depends on an earlier commit by Michael Natterer which enables a pulsing progress bar in the splash window.


commit 30b73125f87b19e3ae322b9fc5bacc9f0b8ef3c1
Author: Kristian Rietveld <kris@loopnest.org>
Date:   Sun Apr 17 17:27:06 2016 +0100

    Bug 449848 - Startup: initialize fontconfig in the background ...

    ... to avoid long pause on start

    On non-Linux operating systems the fontconfig cache is often not
    initialized by default. The first time GIMP was launched, this led
    to a non-responding application, confusing many users.

    The initialization of fontconfig has now been moved to a separate
    thread. The main thread will wait for this fontconfig thread to
    complete, regularly pulsing the UI.

    This patch was partly based on an earlier patch by Tor Lillqvist.
Comment 49 Michael Schumacher 2016-09-07 07:58:30 UTC
*** Bug 762436 has been marked as a duplicate of this bug. ***
Comment 50 Michael Schumacher 2016-09-24 21:20:54 UTC
*** Bug 753746 has been marked as a duplicate of this bug. ***
Comment 51 Michael Natterer 2017-04-20 01:48:32 UTC
*** Bug 781507 has been marked as a duplicate of this bug. ***