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 _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
