[cairo] Re: [Mesa3d-dev] another point in the Glitz paper

[Carl Worth]

On Thu, 22 Apr 2004 12:50:02 -0700, Bill Spitzak wrote:
> It seems that this can be achieved by allowing the implementation to remember
> the tessalation when it creates it for a given path. You can then fill it 
> repeatedly with different patterns. Changing the transformation other than 
> integer translations would throw it away. It could also remember the 
> tesselation for the most recent stroke command. gsave/grestore can be used to
> keep track of a few paths.

Yup. One of the best things about the current implementation is that
there is so much room for performance improvements.

> This would avoid any need to create a "path object", which would be too heavy
> to get the desired behavior. Any such object must be successfully transferred
> from one Cairo implementation to another, meaning it must contain the actual 
> path and not just a device and transform-specifc tesselation. These objects 
> also have annoying problems with rules about who can destroy them and when.

Those concerns are valid. That's the kind of reason I want to wait until
we have an application that needs the performance improvement before we
make an API change specifically for performance reasons.

> Some API changes I do think will help considerably for speeding it up:
> 
> It looks like eliminating any compositing operation that modifies pixels 
> outside the path would help a lot.

The sematnics of the compositin operation does need a reexamination.

> Add some calls to define paths by packed arrays. There should be rectangles 
> (4n values to define n rectangles), triangle-strip and triangle-fan (4+2n 
> values to define n triangles), and trapazoid-strip (3(n+1) values to define n
> trapazoids linked vertically, a y and two x values, and would probably only 
> be faster if there is no rotation in the ctm). Stroking paths defined this 
> way would produce unpredictable results except for the rectangles. This 
> allows the tesselation to be bypassed for very common shapes.

Everyone seems to agree we'll probably need something like this. I don't
love the multiplication of datatypes/APIs. And breaking the
orthogonality of the API, (eg. you can make paths that you can't
stroke), is not pleasant at all.

But I could probably look past both of those problems if this is shown
necessary for an important application. So, bring on the applications!

-Carl