[cairo] new trapezoid code in glitz

[Bill Spitzak]

David Reveman wrote:

>>I'm pretty certain that "intersecting" includes trapazoids that are 
>>close enough together that their antialiased pixels overlap, even though 
>>they in reality do not overlap if drawn at infinite resolution. Is this 
>>correct?
> 
> The alpha values in the implicit mask produced by the algorithm I have
> in glitz will always be 0 for pixels that are not in "reality"
> intersected by the trapezoid. Hence, for glitz, all we need to care
> about is if they intersect the same pixel in reality or not.

I *think* we are saying the same thing. The actual paths of the 
trapazoids do not intersect, but the pixels that intersect the paths 
intersect.

  ------+       ________
        |      /
      +-|----+/
      | |    |
  a   | | p /|      b
      |_|__/_|
        | /___________
  ______|

Ie in this diagram the trapazoids a and b do not intersect, but both 
overlap the pixel p and thus the pixels intersect.

>>PS: Ignoring this case and drawing the trapazoids one after the other is 
>>VERY common, in fact so common that lots of programs rely on the 
>>incorrect result being produced. For this reason it may be necessary to 
>>ignore it as well.
> 
> 
> I'm confused, do you mean that we should never rasterize trapezoids to
> an intermediate mask? That will produce very incorrect results,
> especially with the trapezoids generated by cairo's current tessellator.

If Cairo is generating intersecting actual path trapazoids from shapes 
that the user does not think are intersecting, it must use an 
intermediate mask. However I assummed that Cairo was tesselating the 
path area into a set of non-intersecting trapazoids, with the horizontal 
edges exactly on the lines between pixels, if this is not true I think 
we are losing any advantage of having Cairo do this.

I was only concerned about the case shown above, where the path is 
actually shaped like the outlines of the trapazoids. If the coverage of 
pixel p by the shapes is a and b, the correct opacity of that pixel is 
a+b, but virtually all software I have seen will act like the opacity is 
a+b-ab. This may also be necessary so the results of drawing a and b one 
after the other are identical to combining them into a single path.