AntiAliased text on X [was code bloat]

[Keith Packard]

Around 8 o'clock on Nov 2, "Kendall Bennett" wrote:

> So the only slow down is the blending of the small number of pixels around
> the edges.

That's true of software rendering as well -- it doesn't read the
destination pixels when the source is opaque, and doesn't read or write for
transparent pixels.  I did some measurements on my laptop.  x11perf shows
what frame buffer read/write performance looks like (x11perf -copywinpix500
-shmput500 using kaa does just what you want).  Then I grabbed a line from 
your email on my screen and measured the pixel coverage:

 1)  Frame buffer reads are 20 times slower than writes
 2)  Text is 74% transparent, 10% opaque and 16% translucent

Then, given infinite CPU speed (a reasonable approximation these days):

			read time	write time	total time
	transparent	0 * 74		0 * 74		0
	opaque		10 * 0		10 * 1		10 * 1
	translucent	16 * 20		16 * 1		16 * 21
			320 (92%)	26 (8%)		346 (100%)

We could measure this more precisely by temporarily modifying the software
drawing code to treat the other pixels as transparent and see what
performance looks like.  But, as a rough estimate, x11perf already has code
which measures client-side text performance for antialisaed and non-antialiased
text (in glyphs/sec):

			non-AA	  AA
	Charter 10	209000	 52300
	Charter 24	 97600	 15800
	Courier 12	207000	 45200

I think this measured 4-6x speedup supports the above hypothesis tying AA
text speed to frame buffer read performance for translucent pixels.  It
also suggests that the performance effect is not strongly affected by glyph
size (at least in this range).

We should clearly give Owen's suggestion a try and see what results that 
produces.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041102/e9ba66a2/attachment.pgp>