[cairo] Pixman glyph performance, and beyond!

[Aaron Plattner]

On Fri, Oct 23, 2009 at 05:28:44AM -0700, Soeren Sandmann wrote:
> > > For spans, I still think that a polygon image type in pixman is the
> > > way to go, since again this would benefit both X and cairo. There
> > > could certainly be a call to convert it into spans if that is useful
> > > to other cairo backends, so that we wouldn't need to have two
> > > rasterizers.
> > 
> > I'm actually not so convinced that this the direction that pixman should
> > be going in. From my perspective cairo requires specific path -> backend
> > geometry converters, and a polygon rasteriser with a span line interface
> > has quickly become the default method for pushing masks around. Whereas
> > traps have been relegated to mostly handling boxes, aside from when the
> > most efficient wire request we have available is CompositeTraps. (Has
> > anyone else noticed that the RLE mask for curved geometry is often an
> > order of magnitude smaller than the equivalent set of trapezoids,
> > almost as small as the original path?) 
> 
> One of the major reasons for adding a polygon image to pixman is that
> it would make a PictPolygon render picture possible, thereby finally
> eliminating the use of trapezoids, while allowing the X server to do
> one-pass compositing of geometry, at least in software.

This is maybe only sort of related, but can we push even more of that work
to the server?  Modern GPUs can evaluate Bezier curves very efficiently,
and can rasterize them quickly without having to tesselate at all.  An
approach that stores the control points in video memory and evaluates them
using something akin to a display list call should be WAY faster than any
amount of RLE or fancy span encoding or even sending polygons.  The server
could always decompose it into spans if the implementation can't do the
paths itself.

-- Aaron