# [Xr] Help: Render error on XrFormatRGB32

Owen Taylor otaylor at redhat.com
Sun May 4 10:28:49 PDT 2003

```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

```