GNOME Bugzilla – Bug 378153
loading of fonts is extremely slow on Vista
Last modified: 2008-10-02 17:41:49 UTC
Gimp will not go past the loading of the fonts on Windows Vista and will stop responding all the time.
That's just the well-known problem that's handled in the FAQ at http://gimp-win.sourceforge.net/faq.html, isn't it?
Hard to say. First of all, could the reporter tell us whether this is a stock Vista installation, or whether he or she has added any 3rd-party fonts? Anyway, somebody who can debug GIMP on Windows needs to run it on Vista. There are other reports too, unless I'm mistaken, about GIMP (and other GTK+ software?) misbehaving. I have Vista RC2 installed in a vmware virtual machine, will do it eventually... Lowering severity to "normal", GIMP misbehaving on an operating system that isn't even released yet is hardly critical, and besides, we don't know yet whether this happens on all Vista installations, or just the reporter's machine.
The bug reporter should definitely first try what the FAQ suggests, then report back.
*** Bug 390588 has been marked as a duplicate of this bug. ***
At least on a Vista RC2 installation with no 3rd-party software of fonts added, GIMP 2.2.13 and GTK+ 2.10.6 as installed by the installers from gimp-win.sourceforge.net works fine.
I just let it sit for about 4-5 minutes. It does work, just takes a while to load the fonts the first time. I didn't add any new fonts so that wasn't the problem. Now though the fonts load instantly so everything is fine. If it matters I am on vista ultimate build..
Hmm 4-5 minutes sounds awfully slow, it shouldn't take that long. It takes maybe some tens of seconds for me on Vista Ultimate (RC2), and that is even in a virtual machine with rather small memory. Something odd is happening on your machine. I guess it is possible something changed between RC2 and the shipping build that causes the slowness, but it doesn't sound likely.
well, that was just for the very first load, from there on it loads fast, but yes that does seem slow. I don't know if this is true or note but a friend was saying that the fonts in vista are in way more detail or something of that sort, so it took them a little longer to read. my machine isn't extremely fast, but it still shouldn't take that long to load...
It would probably worthwile then to grab a file monitor (e.g. Sysinternals' FileMon) and check if loading the fonts files is really that what does take so much time.
(In reply to comment #8) > well, that was just for the very first load, from there on it loads fast, [...] To be sure that the problem is indeed related to the initial creation of the font cache, could you exit GIMP, delete the cache file (as explained in the FAQ mentioned above) and confirm that it takes 4-5 minutes to re-start GIMP? If this can be confirmed, then it would be interesting to investigate further with a file monitor as suggested by Michael in comment #9.
I deleted the font cash and it's doing the same exact thing as it did during the first start up. I might try the file monitor...
I'm also experiencing this issue on Windows Vista RC2! My machine (running Windows Vista RC2 natively on my general use machine): ASUSTek P4B533-VM mobo Intel Pentium 4 (Northwood) 2533 MHz 1 GB PC3200 RAM (Kingston) 120GB HDD (System disc) 80 GB HDD (Data Disc) Thanks, Adrien
I suppose it's fine as long as it only does that for the initial font load up, I mean, once I get that done I really have no reason to delete the font cache. if you guys want though I can do a file monitor thing, though I am little busy trying to work out some other stuff.
It's not fine, not even for the initial startup. Simply because no user will wait several minutes. They will assume that the application has crashed.
*** Bug 420660 has been marked as a duplicate of this bug. ***
I installed Vista (the shipping version, from MSDN) (Ultimate, if it matters) in a virtual machine, and installed GTK+ 2.10.6 and GIMP 2.2.13 from gimp-win.sf.net in it. Again, sure, it takes a while to scan the fonts on the first GIMP start, but on subsequent starts, the splash screen's progress bar just zips along with no noticeable slowndown at the fonts stage.
Yeah, I filed bug 420660, which was recently duped to this one, and the workaround described in the FAQ does fix the problem: for some reason, the GTK font-cache got screwed up, and deleting it solved the problem. Now everything works fine.
Could the original bug reporter "Me" try that too, then? Changing status to NEEDINFO.
*** Bug 429805 has been marked as a duplicate of this bug. ***
We are still waiting for feedback from the original bug reporter...
WE have discovered that more recent versions of fontconfig try to create the font cache in %TEMP%, and fail to do this for some reason. I'd like to use this bug as the new "usual font cache problem" duplication bug, the old one (bug #154968) is obsolete.
*** Bug 154968 has been marked as a duplicate of this bug. ***
Just started GIMP up on Vista, still slowed at Font load but increased speed over previous loads. Not sure where the font cache is on Vista. Font cache clear might help.
*** Bug 473914 has been marked as a duplicate of this bug. ***
*** Bug 474619 has been marked as a duplicate of this bug. ***
Vista is released now, other applications using fonts (in general - not necessarily connected with fontconfig - trying to take casual user point of view) doesn't have such as problems. This bug prevents GIMP from starting properly and many users will probably kill GIMP and won't bother to wait minutes (on slower CPUs) until it loads. Severity should be raised to at least major.
The best thing to get this resolved would be a Vista user who did do some research on why the font cahce isn't created.
That was done in the last bug this problem was attached to. Nobody found any particular cause as I recall, only that it was a problem in fontconfig and not GIMP itself.
You are probably referring to bug #154968. I still think that it was wrong to resolve it as a duplicate to this one, as we are dealing with a different problem here.
I encountered this problem when upgrading an XP machine to Vista. I didn't nuke anything in my home directory, so the font cache would have been the one generated under XP, but the fonts would be different now, since I'm on Vista. I had horrible startup problems until I nuked the font cache and let GIMP/GTK/whatever rebuild it. If this is the actual source of the problem, perhaps there's a way to be detect "font cache is horribly out of date" and rebuild it automatically?
I have made a couple of posts in http://bugzilla.gnome.org/show_bug.cgi?id=154968 about this topic, and the problem with my computer is, that simply no font cache is created, neither in my %temp% - directories, nor in my user directory. Also I tried to convince you, that a font cache in a TEMP-directory does not make sense, because it will be occassionally deleted there automatically, therefore resulting in a very slow start of the GIMP each time. This would take place even if everything else would be okay, and that might be the reason for some people reporting this as a bug. What was stated above here, and in the old thread, is that the problem does not stem from the GIMP itself, nor from GTK+, but from the libfontconfig-1.dll. How can we get on with this? How do we manage to contact the developers of that .dll who seem to be responsible? For me, it seems senseless, to put the status here to "NEEDINFO" unless the guys responsible for that code read this threat and help us to find the actual reason for the problem.
Here's the bug on fontconfig's tracker: https://bugs.freedesktop.org/show_bug.cgi?id=11498 To understate, things don't look very good.
*** Bug 456772 has been marked as a duplicate of this bug. ***
I doubt the fontconfig developers even care that much about Windows. My latest fontconfig patch for Windows (the one at http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/fontconfig-2.4.2-tml-20070301.diff ) has not been accepted into the upstream sources yet (it's in fontconfig bugzilla at https://bugs.freedesktop.org/show_bug.cgi?id=8526 ). You don't seem to understand how Open Source works, especially in a case like GIMP on Windows. There is little chance that a developer who isn't personally affected by a problem is going to spend much time on debugging it. We don't have any need to achieve "market share". And most developers capable of building and debugging GIMP and/or fontconfig on Windows probably are running XP, not Vista. I, for instance, certainly have no intent of upgrading to Vista anytime soon. Installing a build and debug environment in a virtual machine running Vista would be a possibility, but requires some effort, and I am a lazy sod. (Anyway, as far as I can recall, when I last tried, GIMP ran fine in Vista (in a virtual machine), I didn't notice any slowdowns on subsequent starts after the first.) > Also I tried to convince you, that a font cache in a TEMP-directory does > not make sense, because it will be occassionally deleted there automatically By what mechanism? Does Vista (finally) come with some such mechanism? At least my personal experience (on XP) has been that the TEMP folder (the default one under Local Settings, at least) is not cleaned in any way automatically and cruft accumulates there during the whole lifetime of the Windows installation.
I have isolated the bug as being in mingw's /mingw/include/io.h (already reported in the relevant fontconfig bug report, and updated the mingw bug report). It is already reported in mingw bugzilla: http://sourceforge.net/tracker/index.php?func=detail&aid=1593268&group_id=2435&atid=202435 But as you can see, it has been closed for 11 months without an update from the developpers. Note that I recompiled fontconfig with X_OK defined to 0 in io.h, and it fixed the problem, maybe in an unsatisfactory or incorrect way.
> already reported in the relevant fontconfig bug report Thanks for actually debugging this. Which bug report is that? So rebuilding fontconfig with X_OK redefined as zero then solves the reported problems on Vista? Looking at fontconfig sources (2.4.2), is the mechanism that the access() calls with W_OK|X_OK in fccache.c always fail, and that then leads to no cache being set up, or an existing cache never being trusted?
The real fontconfig bug report I've reported to is: https://bugs.freedesktop.org/show_bug.cgi?id=12438 I'm using '#define X_OK 4' (thus equivalent to R_OK) because it made more sense to me. Of course, I'm aware X_OK different from 1 under linux is a no-go. To debug, I was running fc-cache and noticed it was failing to write the cache. Probably a call in FcDirCacheWrite, but I stopped at FcDirCacheProcess when I understood the probable cause. I can't assert that access (or _access) is the culprit here, but it's very likely: http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ksazx244(VS.80).aspx I was helped in that, I think, gcc is affected in the same way (not finding its internal binaries) and, in general, the change in behaviour of the Vista POSIX functions (more validation) has caused quite some trouble.
Wow, that's pretty lame. I don't have the POSIX standard in front of me, but IIRC supporting X_OK is *required*, though an implementation can return success always for it. Should probably do this in the two fontconfig files that use X_OK: #ifdef _WIN32 #undef X_OK #define X_OK R_OK #endif
Not a GIMP user, but working with latest fontconfig nonetheless has proven problematic :). This thread helped alot. For anyone wishing to cache to the USERPROFILE environment variable like fontconfig 2.3.x used to, you can use the following patch. Just a slight change from Tor Lillqvist's. http://www.cccp-project.net/nichorai/mplayer-patches/fontconfig-2.4.2-cachedir.diff
Nicholas, your patch has several problems IMHO. USERPROFILE is not defined under Windows 95 and 98. Those platforms are no longer supported by the newer Visual Studio releases (starting from 2005), but it really depends on what platforms the fontconfig developpers are targetting (notwhistanding some of their users such as pango/freetype/...). Therefore, you would better use the now deprecated SHGetSpecialFolderPath (Microsoft have recently removed the MSDN CRT pages about it). I guess looking at glib's g_get_user_config_dir code can shed even more light on this topic. Anyway, that's offtopic and better suited on fontconfig's bugtracker.
There are reports that tml's current fontconfig binaries fix this. They are available from http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies (i.e.: http://ftp.acc.umu.se/pub/gnome/binaries/win32/dependencies/fontconfig-2.4.2-tml-20071015.zip) They use #define X_OK 0 in fccache.c
With the TML library, the font cache is no longer created at all. That, or it's created outside the user directory and/or with a different filename. The font cache file at my user root has definitely disappeared.
See comment #21. Whether this is good or not should be discussed with the fontconfig developers, I guess.
Running "fc-cat --verbose" (in the fontconfig-dev package at http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/fontconfig-dev-2.4.2-tml-20071015.zip ) shows which folders are indexed by fontconfig and where the cache files are. (Redirect the output to a text file and look at the file with a text editor.)
It looks for ".fonts" in my root user dir (i.e. C:\Users\Tom\). The file doesn't exist.
That is normal. Does it not look anywhere else? What if you run fc-cache --verbose? What does it say?
C:\Users\Tom>C:\Users\Tom\Desktop\fc-cache --verbose C:/Windows/fonts: caching, 399 fonts, 0 dirs C:/Users/Tom/.fonts: skipping, no such directory C:/Users/Tom/AppData/Local/Temp/fontconfig/cache: cleaning cache directory C:/Users/Tom/.fontconfig: not cleaning unwritable cache directory C:\Users\Tom\Desktop\fc-cache: succeeded Temp/fontconfig/cache contains d031bbba323fd9e5b47e0ee5a0353f11-mipsel.cache-2, a 628KB file. I've tried to move it to my user dir and rename it .fonts to see if it behaves as a cache, but Windows doesn't like me renaming files to be, in Windows speak, just an extension.
fc-cat looks in C:\Windows\Fonts too, to answer your first question. It didn't seem worth mentioning at first.
Okay, I changed the name through the command prompt. Success! :-D Gimp loads more or less instantly now.
It didn't do this before?
Do what? The answer is probably "not sure" whatever you mean, as I've never run in verbose mode before.
Did GIMP load instantly before you created the .fonts directory?
No, it spent a good couple of minutes reading the fonts folder as per this bug. Before we get carried away, there may still be a problem with this cache. Doing anything related to drawing fonts floods the CPU and grinds Gimp to a halt for a good second or two. This happened when I didn't have a cache too, but I had assumed getting it in place would fix the issue. I am running 2.4.0-rc3 though.
This bug is about slow font loading. And thus the following question should be solved without any ambiguity: - if there is no .fonts, does launching GIMP take a long time, even after the initial launch during which the font cache is created? Issues with font rendering should go to a new bug report.
Yes, without .fonts launching Gimp takes a long time. With .fonts it is nearly instant. This bug is about the fact that the .fonts cache isn't created in the first place, so - dev builds of fontconfig and CMD hacking aside - initial launches and subsequent launches are the same.
> This bug is about the fact that the .fonts cache isn't created Hmm, the .fonts folder isn't a cache. It's a folder in the home directory of a user often used on POSIX (well, Linux at least) systems for per-user fonts. (Home directory is a POSIX concept that most closely corresponds to the %USERPROFILE% folder on Windows.) Are you sure you are interpreting what you see correctly, and not just guessing? Or have you set some environment variable that makes the fontconfig library store its cache in your .fonts folder?
.fonts isn't a folder on my system. It's a 629KB file. See Comment #47 for what happens regarding it.
> .fonts isn't a folder on my system. It's a 629KB file. That's extremely weird. > See Comment #47 which says: > C:/Users/Tom/.fonts: skipping, no such directory and > Temp/fontconfig/cache contains d031bbba323fd9e5b47e0ee5a0353f11-mipsel.cache-2, > a 628KB file. I've tried to move it to my user dir and rename it .fonts to see > if it behaves as a cache Oh no. What made you think .fonts should be a file? .fonts, if it exists at all, is supposed to be a folder containing fonts, for instance .ttf files. The fontconfig cache files have names like the string of hex digits etc above. The fontconfig cache files are not supposed to be in the .fonts folder. Fontconfig cache files are not font files. They contain information about the coverage of font files in some location. So what happens if .fonts is an (empty) folder for you?
> So what happens if .fonts is an (empty) folder for you? Nothing changes at all. Gimp still starts instantly, and drawing fonts (except for interface ones) still sets it chugging. Which is odd, because I expected things to revert to how they were before I renamed and moved the cache-2 file...
This bug has been marked as resolved by the fontconfig guys. http://bugs.freedesktop.org/show_bug.cgi?id=12438
I am closing it as NOTGNOME then. If there are still issues after upgrading to the newer version of fontconfig, then please open a new bug report.
*** Bug 521317 has been marked as a duplicate of this bug. ***
With 2.6.0 out it's about time for an update on this. - Is a cache still created? If so, where? I don't see one any more. - I only prompted a scan of installed fonts after I deleted the old .gimp-2.4 dir from my user folder. -- There haven't been any further scans since that. - Generating font previews and typing with the Text Tool still grind GIMP to a halt. I'm running Vista SP1.