client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?

[Jim Gettys]

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 <jg at freedesktop.org>