On May 17, Keith Packard wrote:
> 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.
As usual, Keith points out the error in my thinking. I'll take one
more shot at trying to demonstrate the current algorithm is
workable. If I'm refuted as soundly, I might just have to give up. ;-)
> 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.
I see the light now and I see how errors from a region containing a
negative alpha can accumulate into a pixel.
But, fortunately, the error accumulation only occurs when the
following two conditions hold:
1.a) The alpha value for region 1 which contains a negative alpha is
computed.
1.b) The alpha value for an adjacent, (either to the right or below),
region 2 is computed. This computation involves directly solving
for the alpha of region 1 and subtracting it. Since region 1 had
some negative alpha which was truncated to 0, the sum of the
alpha of the two regions now has some positive error in it.
Given arbitrary tessellations, it is possible for this to occur many
times within one pixel resulting in large cumulative errors.
However, a negative alpha only occurs when a trapezoidal region is
smaller than a minimum area, (determined by the alpha
depth). Trapezoids can be this small in one of two cases:
2.a) The tessellating client provides a trapezoid smaller than the
threshold area.
2.b) A larger trapezoid is clipped by the lower or right edge of a pixel
boundary, resulting in a trapezoid smaller than the threshold.
Case 2.a is easily controlled by the tessellating client. If it truly
desires to render features that small, then it should increase the
alpha depth.
Case 2.b can not be easily avoided by the client, but here, condition
1.b will not hold since alpha errors will not propagate across pixel
boundaries.
Thus, as long as the client provides trapezoids above a minimum size,
the negative alphas generated by the algorithm will not cause any
problems.
Any holes in this logic?
-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
