Optimising xserver (Xft text rendering improvements)

[Keith Packard]

Around 19 o'clock on Mar 26, Soeren Sandmann wrote:

> In my opinion we should just leave it alone, because with actual
> applications we hit the fast paths almost exclusively. As applications
> show up that don't, we can add more fast paths.

There are two things I would like to get done here:

 1)	Automatically construct an optimized fast-path dispatch table for
	all of the present and future accelerated software drawing 
	functions.  With the huge number of variables in the rendering
	equation, it's really hard to tweak the existing dispatch code
	to fix a performance problem in a specific application.  Automating
	this construction would permit easy integration of new accelerated
	functions, which seems key to usable software performance.

 2)	Fix fbcompose to work on larger units than a single pixel.  By 
	moving up to 8x8 'patches', we can actually get reasonable 
	acceleration while still avoiding polynomial explosion of
	functions.

 3)	Write glyph-level text compositing code instead of travelling 
	through the general case code.

These seem orthogonal to me...

-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/20050326/60240fe7/attachment.pgp>