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

[Bill Spitzak]

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