Is the same/similar to the snow leopard fontconfig bug? We still don't run on snow leopard.
If you take a peek at this bug:
there's an issue that affects a lot of Windows users
(but I'm able to reproduce it on Linux, and presumably it can
also affect Mac OS X).
The symptom of the problem is Tux Paint appearing to hang during startup.
(So much so, that it seems -- at least for some people -- that Windows will
pop up a notification/warning window, telling them that the app has stopped
responding, and giving the user the option of killing it.)
So here's what's going on:
Our full-featured builds (Win XP, 2000, Vista, 7, and recent Linuxes)
utilize SDL_Pango for rendering UI text. This allows it to properly
render text in all locales, including the tricky ones that plain SDL_ttf
totally fails at, like Arabic.
SDL_Pango is just a thin wrapper around the Pango library.
In turn, under the hood, that uses fontconfig, described in Ubuntu
as: "is a font configuration and customization library, which does not
depend on the X Window System. It is designed to locate fonts within
the system and select themaccording to requirements specified by
fontconfig maintains a cache (on Linux, I find a global copy,
no doubt handled by 'dpkg' on my Ubuntu laptop, in /var/cache/fontconfig,
as well as a local copy in my home directory at ~/.fontconfig )
It seems to scan the system for fonts, and record some useful info
about them, which helps it decide what fonts to hand off to Pango,
when we go to render text in a certain locale. That's nifty...
HOWEVER, while it's scanning, Tux Paint stops responding.
As mentioned in the bug I posted at SourceForge, my proposed solution
(one that doesn't involve hacking our own copies of the entire
set of libraries all the way to the fontconfig layer:
SDL_Pango => Pango => fontconfig) is to simply spawn a temporary
thread at start-up, right before we go to render any kind of UI text.
The first time Tux Paint -- and hence fontconfig's caching routine -- is
launched, that thread will take a long while. In the meantime, though,
we can do a little animation, handle any events coming from SDL, and
even let the user abort the launch if they decide they didn't really
want to run Tux Paint. During future launches, that thread will
spawn and disappear almost instantaneously, since fontconfig won't
need to do its scan-and-cache stuff.
Of course, if the user -- or perhaps their anti-virus software (it
happens! see "Known Issues" on the website!) -- deletes the cache,
fontconfig will need to do its work again, so the thread will be
useful. Or, a more likely case, someone installs a bunch of new
fonts on their system that fontconfig hadn't scanned yet...
Anyway, so I was set. I figured out (thanks to ltrace and some
trial and error) where we needed to spawn this thread, and
wrote a pair of little routines. One renders a dummy string
into an SDL surface (via SDL_Pango), and hence will cause fontconfig
to come to life and scan the system for fonts. The other animates
the progress bar at the bottom. This also keeps the title screen from
disappearing or getting corrupt -- an issue you can see in the current
code, at least under Linux -- since we're 'listening' for SDL events.
Guess what, though? It doesn't work! :^( I admit I'm new to using
SDL's threading routines, but it turns out the issue seems to be due
to the _forking_ (as in, "fork()" call) that we do to bring our
OWN font loading tool to life!
What's that? It's the thing that lets Tux Paint launch relatively
quickly, even if you have a ton of fonts (TTF & otherwise) installed.
(In other words, we're kind of duplicating what fontconfig does for
Pango.) Tux Paint responds to the user, and continues loading
fonts in the background. You can draw/etc. The moment you try to
use the "Text" tool (or, now, the new "Label" tool), if the fonts
haven't finished loading, you'll get stuck in a "please wait..." state.
So at this point, I've thrown my hands up and yelled "drat!"
I can't get the SDL_thread stuff to work because of our own font stuff.
I can't drop our own font stuff, and just use SDL_Pango for the Text
and Label tools, because (the current version I have of) SDL_Pango
doesn't really let us query for fonts, so that we can provide various
fonts and styles to the user in the Text & Label tools.
Anyway, that's where I am. I'm thinking _maybe_ I can change
_when_ we do the fork() for our own font-loader routine.
If that works, I'll commit, send a note, and I'd like everyone to
go out and test and see if things seem to work right and/or blow up. :^)
Windows users -- if you want to try purging your own fontconfig cache,
it might be something like:
C:\Documents and Settings\Owner\Local Settings\Temp\fontconfig\cache\
(seen on Known Issues: http://www.tuxpaint.org/docs/known_issues/ )
Sadly, another fontconfig-related issue we've noticed has to do with
conflicting versions of fontconfig on Windows. (i.e., once that comes
with Tux Paint, another that comes with Inkscape.) Why on Earth
Windows is so incapable of having sane libraries and library versioning,
I cannot fathom. (i.e., why the heck are _we_ supplying all of our
own DLLs for libraries that other apps use?) Nergh!
In the meantime, any suggestions / comments?
Sent from my computer
Tuxpaint-devel mailing list