On May 17, Keith Packard wrote: > This is not an effect of truncation, and in fact our current algorithm > avoids this problem most of the time.
Of course. <blush> For having implemented this algorithm and having thought I understood it several times, I wish I would stop making mistaken claims about how it acts. </blush> Then again, I'm probably about to do the same with the following rantings... > 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. Yes. And I think I now have a compelling argument that this will not cause visual problems. A pixel can only be filled "too quickly" if its tessellation includes microscopic trapezoids. Once the tessellation is complete, if the microscopic trapezoids have all been covered, then the surplus alpha is simply truncated to 1 and there is no problem. If the microscopic trapezoids are not all covered, then the tessellation has attempted to render some microscopic sub-pixel feature, which the algorithm has never claimed to be able to render faithfully. Remember, accurate area calculation has never been a requirement of the algorithm, simply that the alpha values of trapezoids subdividing a pixel must sum to one. The sum of the alpha value for trapezoids subdividing a subset of a pixel really does not matter. > 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. Ah, that makes sense. Repeating myself in other words: I'm convinced that truncating negative values to 0 will not cause noticeable visual problems. This whole negative alpha problem never occurs until more than one trapezoid line intersects within a single pixel. At that point, there is sub-pixel geometry that is not visually discernible, (since it is all merely approximated by a single alpha value), so small amounts of error, (such as 2 alpha units), would be indistinguishable from other equally plausible sub-pixel geometries, (think rounded vs. sharp corners on the sub-pixel intersections). Accurately reproducing small features of sub-pixel geometry and precisely computing area is never important. The "sum to 1" invariant is only important when the whole pixel is covered and the algorithm maintains that even with truncating negative alphas to 0. -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
