On Sat, 2009-01-31 at 15:58 +0100, Michel Dänzer wrote: > > I think a big part of the motivation for client side fonts was indeed > anti-aliasing, so if you don't want AA and core fonts are faster for > you, just use core fonts? >
Actually, the data showed that start up time was terribly affected when getting font metrics, and the logistics of deploying new server side font technology was horrific (you got to upgrade both sides of the wire at the same time, which is very tough). The more fonts, the worse it got. The observed fact was that the font metadata had shifted five times over X's history, and we were still stuck on the original broken model. The other issue is subtle: if programmers had to support two code paths in their applications, and AA support is server side only, you get a chicken and egg problem. We were asking app programmers to do additonal work *and* have a long term maintenance headache, while the installed base of those who could take advantage of AA fonts were small. This strategy demonstrably hadn't worked. So keithp wrote Xft so that it would work whether there was server support for glyph caching available or not (screen scraping if necessary). Then app/toolkit writers get to make one set of code modifications, there is a single code path for long term maintenance (*and *from the app/toolkit developers point of view, their testing problems are not multiplied by two). So that strategy was a much easier sell, (not to mention keithp wandering through many of the important projects and proving patches), and the rest, they say, was history. And we are future proofed against the next innovation in font meta data, and got rid of the application start up round trip disaster. See: http://keithp.com/~keithp/talks/usenix2003/ for a fuller explanation and data. - Jim -- Jim Gettys <j...@freedesktop.org> _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
