[cairo] After 1.3.2, what's going to make cairo faster next?

[Bill Spitzak]

I never used it, but I looked up what the calls he describes does.

The method is basically to draw the filled path into a seperate buffer 
(the Stencil buffer) that OpenGL has, as a black & white image, and then 
use that to mask a rectangle that is drawn into the final output.

The stencil image is done by drawing a lot of (very long and thin) 
triangles, all sharing one fixed vertex (such as 0,0) and the opposite 
edge being one segment of the path. Each triangle inverts the pixels it 
touches in the stencil buffer. It does not matter if the path is many 
seperate loops. The result is the even/odd filled path. I'm reasonably 
certain that this was what the stencil buffer was designed for so it is 
not suprising that this works well. The hardware is so fast at filling 
triangles that this is much faster than any method of reducing the set 
of triangles to a non-overlapping set.

It does look like non-zero path could be done, as the stencil buffer can 
be set to increment/decrement it's value for each triangle, you have to 
increment for a clockwise triangle and decrement for a counter-clockwise 
one. I think the way to do this is to turn on "backface culling" so that 
only the correct triangles draw anything, and draw everything twice. 
Also the documentation says that negative numbers are not supported, so 
the stencil buffer must be initialized to a half-way value. Any value 
not equal to the half-way value is inside the shape, and it looks like 
it can be set to use this as the masking test. Another problem is (on my 
machine) the stencil buffer only has 8 bits, meaning that more than 128 
overlapping triangles may fail (which can happen if the line from the 
fixed point to any of the path crosses more than 128 edges).

The first reason antialiasing is not supported is that OpenGL's stencil 
buffer's use for masking can only do true/false. However if you write 
this algorithim in software (or perhaps in hardware shading language) 
this is avoidable. The more serious problem is that the triangles must 
be aliased, they have to exactly touch, or all the lines from the fixed 
point to the path become visible. I supposed maybe triangles that are 
antialised on one edge would work (in fact I proposed this before for 
Cairo) but there are problems with making corners between antialiased 
and aliased edges. Also this would not correctly handle a path with 
coincident edges.

Daniel Amelang wrote:

>> http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html 
>>
>> >
>> >
>> > Obviously still not very clear, but like you said, we have work cut
>> > out in other areas first.
>>
>> Looks like that does even/odd filling, not the non-zero winding rule
>> that Cairo wants. Also does not do antialiasing.
> 
> Does this mean that the method is too incompatible with Cairo's
> behavior that it couldn't ever be used? And could you explain what
> about it prevents antialiasing?
> 
> Thank goodness we have at least one person (Bill) who understands how
> this method works :) .
> 
> Dan
>