Around 22 o'clock on May 17, Carl Worth wrote:
> We've been getting hung up a bit on negative alpha values. They seem > odd since they are obviously wrong, (alpha like area is non-negative > by definition). But actually, the error that causes negative alpha is > no greater than the error in many other alpha calculations that we > accept just fine. These negative values are intrinsically different -- all of the other errors we make cancel out as the pixel is incrementally rasterized, these negative alpha values can't do that as we have no way to store them during incremental rasterization. > 2) When the remaining regions of the same pixel are computed, they are > "unaware" of whether there might be a negative alpha value > somewhere within the pixel. And independent of that, they will have > some amount of error. The problem is that an area tesselated into subareas containing negative alpha will have a different value than when computed in one piece. Without negative alpha values, arbitrary tesselation of an area yields the same total alpha as the alpha for the area as a single piece. We now compute different alpha coverage depending on how the pixel is split into pieces. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
