[cairo] Re: [Mesa3d-dev] another point in the Glitz paper
spitzak at d2.com
Thu Apr 22 12:50:02 PDT 2004
On Thursday 22 April 2004 10:43 am, Jon Smirl wrote:
> Isn't this an example of a fundamental performance problem in the Cairo
> API. Cairo allows non-simple polygons. I agree that this is definitely
> simpler for the programmer but it doesn't efficiently accelerate.
> To accelerate this the API needs to be split. You need a polygon tesselate
> function and a draw simple polygons function. If you don't split the
> function the list of polygons has to be sent through the tesselator every
> time the polygons are drawn. With the split model you tesselate the list
> once, if at all, and then feed the polygons repeatedly to the draw simple
> polygon function.
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.
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.
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. This would allow the path and clip to be
intersected into a single object. Adding an "invert path" command to make
fill use the area outside the path rather than inside should allow all the
SVG graphics to be replicated with only a little extra effort.
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.
I do not agree with people saying Cairo should be modified to better match 3D
hardware. I definatley want an interface where if I have a bitmapped image in
memory, I can get it on the screen with exactly one call, without creating
any objects. This is VITAL to making Cairo a programmer-friendly interface.
,~,~,~,~ ~ ~ ~ ~
/\_ _|_========___ Bill Spitzak
~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com
More information about the cairo