GNOME Bugzilla – Bug 89946
incorrect error logic in pangoxft -> really slow startup time
Last modified: 2009-08-15 18:40:50 UTC
with GDK_USE_XFT=1, apps would take a really long time to startup. i think the attached patch is the right fix. jacob@localhost:jacob$ time GDK_USE_XFT=1 ./test-pango real 0m4.553s user 0m4.000s sys 0m0.170s jacob@localhost:jacob$ time GDK_USE_XFT=1 ./test-pango real 0m1.628s user 0m1.330s sys 0m0.110s
Created attachment 10273 [details] [review] exit the loop when we've found a match
Created attachment 10276 [details] test-pango.c
No, the current code is right... the list *is* supposed to have all the fonts so that we can do fallback matching. Don't know why it is so slow for you.
ok. how many fonts does fc-list give you?
when running test-pango with this patch i get: Took 4.660614 seconds to check 2641 patterns (avg: 0.001765).
Created attachment 10279 [details] [review] print some time output
You have 2600 hundred ttf's installed? While I can't claim that people don't install 1000-crappy-fonts CD's, it isn't actually useful... Or, hmm, do you have fontconfig pointed into your .pcf directories? (Normally on Linux, nothing bad happens because the X server's pcf files are gzip'ed, and freetype can't load gzip'ed pcf files.) I have a patch from Keith to redo this code, but I'm not sure it would fix your problem.
i have ~65 .ttf fonts installed, and just .pcf.gz (no .pcf).
Can you figure out what all the patterns are then?
i added an FcPrintPattern() on the pattern_copy: jacob@localhost:jacob$ ./test-pango | xargs -n 1 echo | grep -c Verdana 658 it's a huge string - tons of duplicated family names etc (ie, 658 "Verdana" entries) still looking at why that is happening...
so it turns out this was because my ~/.fonts.conf was an edited copy of /etc/fonts/fonts.conf, and i guess it was recursively including itself or something else strange.
How would you like me to fix this? Generate an error if include files are nested too deeply? I could also make the font directories unique so that multiple instances of the same names don't generate multiple fonts in the database. Making fonts unique would be *much* more expensive, essentially turning an O(n) operation into O(n**2).
Yeah, I think making sure a directory is not added more than once is enough.
I submitted a patch to fontconfig list that makes sure config files are not processed more than once. Seems like directories are already handled correctly.