#141 Fontconfig cache generation locks application during startup

Launching (18)
William Kendrick

This is typically seen on Windows (but if you delete your ~/.fontconfig cache folder on Linux, you can duplicate the issue). When using SDL_Pango for rendering, and fontconfig needs to (re)generate its cache of info about installed fonts, Tux Paint appears to crash or lockup on startup -- it's simply blocking for a very long time while the cache is generated, and eventually responds again.

Running "ltrace tuxpaint" on Linux (with an empty cache), the lockup seems to happen the moment we call SDLPango_CreateSurfaceDraw(). (I was hoping it was happening when we called SDLPango_Init(), but it seems fontconfig (via Pango, via SDL_Pango) does not bother making its cache until we acutally go to render something.)

It might be useful to create a kluge that does the following (and this could be used on all platforms that use SDL_Pango, not just Windows, where the issue takes place the most often):
(1) Right after SDLPango_Init(), spawn a new thread
(2) Have that thread call SDLPango_CreateSurfaceDraw() to create some text that we'll discard
(3) Have the main thread wait for the thread that's doing Step 2's work, all the while responding to SDL events, and occasionally drawing the "please wait" animated bar at the bottom of Tux Paint's window

That is, assuming this idea is thread-safe, or whatever. I should create a test app. :^(


  • Implemented and tested the thread-based work-around on Linux, and it works. (For sanity, also forced FORKED_FONTS option to be disabled, re-built, and things still ran as expected, on Linux.)

    The fix needs confirming on Windows, Mac OS X & BeOS.