Re: More trouble in trapezoid land

On May 22, Keith Packard wrote:
 > > I've been experimenting with 'sharp' polygons, those with aliased edges. 
 > > This is effected by generating a 1-bit mask instead of an 8-bit mask.
 > 
 > I think a reasonable solution is to define a different coverage equation 
 > for sharp polygons.  I suggest that we use all of the coverage stuff for 
 > smooth polygons except for the "primitive" area computations -- those 
 > involving areas to the left of a trapezoid diagonal edge and above a 
 > horizontal bounding line.  For that primitive computation, I suggest 
 > making the alpha '1' when the area includes the pixel origin and '0' 
 > otherwise.  

Keith,

This is certainly a nice improvement.

Would any small alpha depth other than 1 also deserve special
treatment? I suppose not.

As I've played with the new coverage equation for sharp polygons,
dropout problems become obvious very quickly. For example, using core
zero-width lines, xclock shows distinguishable ticks down to sizes
such as 60x60. Meanwhile, at sizes that small, "xclock -render -sharp"
can drop almost all ticks. And, even at sizes as large as 220, the
sharp rendered version can drop the large horizontal and vertical
ticks.

Would it make sense to do some (perhaps optional) extra work to
protect against dropouts, (quick bresenham walk around trapezoid
edges)? As long as we only turn more pixels on and don't turn any off,
then we don't' violate the "sum to 1" invariant, no?

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 [email protected]
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725