[cairo] Re: [Mesa3d-dev] another point in the Glitz paper
cworth at east.isi.edu
Thu Apr 29 03:58:11 PDT 2004
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!
More information about the cairo