Updated prerelease for Xft and fontconfig
Keith Packard <[email protected]> Fri, 31 May 2002 00:23:02 -0700
| Newsgroups | gmane.comp.xfree86.render |
|---|---|
| Message-ID | <E17DgkY-00016J-00@localhost> |
I've updated the tarballs containing Xft and fontconfig bits and have included Xrender and Xft1 sources as well. Those haven't been 'autoconf'ized yet, so they only build with xmkmf. Several significant changes have happened in the sources due to input from Owen in his quest for Xft2 support in Pango: Xft: +) Unreferenced fonts are left around for a while in case they're reused +) Open fonts are placed in a hash table for quicker matches +) When using the core protocol for AA rendering, Xft was leaking the temporary image used to composite text. Fontconfig: +) CharSets have been reimplemented to save memory and improve performance. For a 4800 font test case, I reduce memory usage from 6MB to 100KB for the coverage information. +) Lots of profiling driven changes converting a bunch of linear searches into hash tables or binary searches. A quadratic loop over pattern pairs was also changed into a linear walk. +) FcFontSetSort performance was tuned; a list matching 'sans-serif' from my 383 font test set has improved from 10ms to 3.8ms. If further performance improvements seem warrented, it would be quite reasonable to cache the search results; they're quite compact, consisting of an array of pointers into the global font set. +) A FcFontSort API was added; it is to FcFontSetSort as FcFontMatch is to FcFontSetMatch. This should be the preferred API for font list generation. Other than that, I've done some pretty extensive cleanups in the build process, testing all of the libraries with xmkmf and Xft/fontconfig with autoconf on my Debian Woody box which is running XFree86 4.1. So, unless Owen thinks Fontconfig should be caching pattern->font list computations, I'm hoping Xft2 and fontconfig are nearing release. Thanks to everyone for sending in bug reports and suggestions; there's no way I could have made this much progress so quickly without them. Keith Packard XFree86 Core Team HP Cambridge Research Lab