[Xr] Help: Render error on XrFormatRGB32

[Owen Taylor]

On Sat, 2003-05-03 at 21:13, Keith Packard wrote:
> Around 16 o'clock on May 3, Owen Taylor wrote:
> 
> > So, the big culprit here is actually computing the alpha values for
> > the individual trapezoids. Since that computation is scheduled to
> > be completely rewritten, it's a little hard draw performance 
> > conclusions at this point.
> 
> It's more than rewriting the code.  We've made some fundemental 
> discoveries on the nature of incremental composition of tesselated figures 
> that go to the very heart of the low-level rasterization code.  
> Essentially, point sampling is as good as you can do, the only question is 
> where to place the points.  The current implementation places them 
> differently depending on the precise edges in use which generates some 
> significant "issues" in many tesselations, so our plan is to place them in 
> a regular grid using the observation that:
> 
> 	2**(2n) - 1 = (2**n - 1) * (2**n + 1)
> 
> e.g.
> 	   2**8 - 1 = (2**4 - 1) * (2**4 + 1)
> 
> 	        255 = 15 * 17
> 
> Right now, the best algorithm I've come up with is to just step
> the trapezoid edge 15 times per pixel row; that's actually pretty fast, 
> but it would be nice to have an analytical approach which computed the 
> covered samples directly from the edge values somehow.

After fooling around with the math for an hour or two, I don't believe
there is a simple closed form; the exact sample counts end up with sums
like:

    N-1         a*j + c
Sum     floor [ ------- ]
    j=0            m

Which is easy to compute for N=m (Knuth Ex. 1.2.4-37); and seems
otherwise intractable to me. Admitting that discrete math isn't
my strong point.

Certainly, I doubt the exact sample count is going to be easier to
compute from edge values than the exact coverage area. So, I'd
vote for just stepping fifteen times.

Regards,
                                           Owen