Re: Sub-pixel area computations

Around 16 o'clock on May 2, Carl Worth wrote:

> And, each pixel would need two error rectangles, so we have a maximum
> error of one sub-pixel.

The error is irrelevant -- the entire computation is just an approximation 
of anti-aliasing.  I really don't care what the answer is, I just want it 
to be a reasonable approximation to pixel coverage and follow the rules for
imprecise polygons (sum of areas from arbitrary tesslation is exactly 
unity).  

For pixels intersected by the trapezoid face along parallel sides, I'd also
like to be able to use the obvious exact value, but even that is less
important than making the whole computation cheap enough that it will run
fast enough to avoid needing a software imprecise implementation for
performance.

So, we have the following constraints:

	1)	Sum of areas from arbitrary tesselation is unity
	2)	Invarient under translation
	3)	Should look "reasonable"
	4)	64 bit arithmetic
	5)	Within a factor of 2 of the fastest software algorithm that
		meets requirement 1) and 2)

Aside from these, we should really consider almost any possible algorithm. 

-keith