Around 18 o'clock on May 17, Carl Worth wrote:
> On the other side, (truncating errors resulting in negative alphas to > zero), there is a potential practical problem. In the worst case, a > large portion of a pixel could be covered by many small trapezoids but > result in a combined alpha value of zero. This is not an effect of truncation, and in fact our current algorithm avoids this problem most of the time. Take any sub-area of the pixel with alpha 'A', the algorithm enforces that any tesselation of that sub-area always yield alpha of precisely 'A', some of the microscopic trapezoids will end up with alpha of 1 while most have alpha of zero. The effect of this rounding problem is to introduce some microscopic trapezoids with negative alpha; this are always offset by having some trapezoids with additional area. Truncating the unfortunate negative alpha trapezoids to zero provides an overall surplus of alpha values, making the pixel fill faster than it should. I've tesselated circles into 1000 triangles with no gaps. > Can anyone think of other reasonable tessellations that cause > problems? Keith, have you found noticeable errors in practice by > truncating negative alphas to zero? You did discover this problem > after all -- how did you find it? I found it by not truncating alpha values, instead just masking them to 8 bits. The -1 alpha values were translated into opaque instead of transparent. They stood out quite strikingly when I was drawing xclock against a black background, twinkling as I resized the window. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
