[Bug 17548] wine startup scans all fonts, takes ages

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Sep 16 15:09:44 CDT 2009


http://bugs.winehq.org/show_bug.cgi?id=17548


Sebastian Thürrschmidt <thuerrschmidt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thuerrschmidt at gmail.com




--- Comment #8 from Sebastian Thürrschmidt <thuerrschmidt at gmail.com>  2009-09-16 15:09:42 ---
This is still very much an issue with Wine 1.29 (as with all previous versions
I have used, going back to pre-1.0 times). The start-up time of any Windows
executable run under Wine will increase dramatically (and non-proportionally)
when the number of fonts installed under Linux grows into the thousands.

My computer is a fairly recent Core 2 notebook currently running Ubuntu 9.10
(Karmic) amd64 Alpha 5 with Wine 1.29 (Jaunty build). I have a few hundred
fonts installed in /usr/share/fonts, which constitute the font set that I
actually use. In addition, I have a collection of several thousand font files
in ~/share/fonts, few of which I actually ever use.

As long as only the system-wide fonts (i.e. those in /usr/share/fonts) are
active, launching most Windows programs with Wine doesn't take more than a few
seconds. If, however, I add a reference to my user font directory
(~/share/fonts) in ~./.fonts.conf and then try to run a Windows program, even a
very simple one like Wine's own notepad.exe, there will be frenetic activity
(in terms of processor load and hard disk access) for several minutes, without
any visual feedback from Wine and/or the operating system. Only after this long
delay will an application window appear.

When I launch another program with Wine (or the same program again) during the
same session, the delay will initially be much shorter. Later on, however, and
especially after I restart the computer, the delay will go into the minutes
again.

Here are some measurements that I took, the first one with only the system-wide
fonts being active:

time wine cmd.exe /c exit

real    0m1.206s
user    0m0.144s
sys    0m0.052s

Then I added ~/share/fonts to my .fonts.conf and ran the fc-cache command, and
I got these results:

time wine cmd.exe /c exit

real    2m20.847s
user    0m1.280s
sys    0m0.412s

Without any changes to my font configuration, I ran the same command once more:

time wine cmd.exe /c exit

real    0m5.495s
user    0m1.236s
sys    0m0.348s

So the time needed to start and immediately quit cmd.exe went from about 1
second with a few hundred fonts installed, to well over two minutes with
several thousands fonts installed, back to just five seconds with the same huge
font set. However, after restarting my computer and with system-wide plus user
fonts still all installed, the delay went up again:

time wine cmd.exe /c exit

real    2m43.974s
user    0m1.192s
sys    0m0.552s

Finally, after removing the reference to ~/usr/share/fonts in .fonts.conf and
running fc-cache once more, I got these results:

time wine cmd.exe /c exit

real    0m1.283s
user    0m0.128s
sys    0m0.068s

To summarize: There seem to be scaling problems in the way Wine manages font
information, which are most visible when an above-average number of fonts are
installed. While having thousands of fonts installed simultaneously is certaily
not a good idea and can be avoided by using tools like FontForge, applications
should a least give the user some kind of feedback during long delays,
font-related or otherwise, to avoid the impression of blockage. Apart from
that, even with thousands of fonts installed, most of the Linux applications I
know (Inkscape being one notable exception) show only minor delays during
launch and/or user interaction. The same should be true of Wine.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.


More information about the wine-bugs mailing list