[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

    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.


More information about the cairo mailing list