The commits to fontconfig (fc-2_4_branch) at 2006-04-13 introduce REALLY bad performance issues, eg. it takes 3 seconds to open a new tab in gnome-terminal, while it's almost instantly with fontconfig from the day before (2006-04-12). No problems: cvs -z3 -q -d :pserver:anoncvs@anoncvs.freedesktop.org:/cvs/fontconfig update -D2006-04-12 -dP -r fc-2_4_branch . Here it becomes REALLY slow: cvs -z3 -q -d :pserver:anoncvs@anoncvs.freedesktop.org:/cvs/fontconfig update -D2006-04-13 -dP -r fc-2_4_branch . The commit messages say: 2006-04-12 Frederic Crozat <fcrozat@mandriva.com> reviewed by: plam * src/fcpat.c: (FcPatternFreeze): Fix memory leak (Coverity defect #2089). * src/fcfreetype.c: (GetScriptTags): Ignore script if subtable is missing (Coverity defect #2088). 2006-04-12 Patrick Lam <plam@mit.edu> * src/fccfg.c (FcConfigSubstituteWithPat): Fix possible null pointer dereference (Coverity defect #784) and memory leak (Coverity defects #785, #786). 2006-04-12 Patrick Lam <plam@mit.edu> * src/fcmatch.c (FcSortWalk, FcFontSetSort): Don't copy FcCharSet if we're going to throw it away anyway. (Reported by Kenichi Handa). Any clue what might be causing this and how to revert it?
Ok, I'm pretty sure this commit caused it: http://webcvs.freedesktop.org/fontconfig/fontconfig/src/fcmatch.c?r1=1.28.2.16&r2=1.28.2.17&only_with_tag=fc-2_4_branch
gnome-terminal uses FcFontSort in a rather different way than the test program in 6508 (which may also be the way that gdmgreeter uses it, by the way). I'm looking into this problem.
Ok, that's fixed. I didn't really get the conditional right in bug 6508, despite sleeping on it. Oops.
Marking fixed.
Confirming current CVS has fixed the problem. Thanks for the quick patch!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.