[Dri-devel] a subtle scissor problem

[Brian P. <br...@va...>]

I spent the past few hours tracking down a bug involving glReadPixels
which actually turns out to be a scissor problem.  I'd like to explain
it so the other DRI developers are aware of it.  This was in the
tdfx-3-0-0 branch.

The symptom was that glReadPixels was returning garbage data instead
of what was really in the framebuffer.  glReadPixels isn't supposed to
be scissored but that's exactly what the tdfx driver was doing.

When scissoring is enabled we intersect the GL scissor box with the list
of X cliprects and keep the new cliprect list.  In the span-read template
code we were clipping pixel reads to the scissored cliprect list.

The fix is to use the un-scissored cliprect list when reading pixels but
use the scissored cliprect list when writing pixels.  Luckily, in the
tdfx driver we have easy access to both types of cliprect lists.

To do this I had to modify common/spantmp.h to use separate HW_READ_CLIPLOOP
and HW_WRITE_CLIPLOOP macros instead of just HW_CLIPLOOP.  This is pretty
similar to the introduction of separate HW_WRITE_LOCK and HW_READ_LOCK
macros instead of just HW_LOCK.

I see that in the mga driver (for example) that cliprect/scissor intersection
isn't done until we're about to render a batch of vertices.  It might
be better to do the intersection work earlier, like in the tdfx driver.

Also, I'm not 100% sure that all Mesa calls to Driver.WriteRGBASpan/Pixels()
are first scissored inside Mesa.  With the tdfx driver this isn't a
worry.

-Brian

Footnote: the only real reason that we have to scissor pixel reads is to
deal with windows that are partially off the edge of the screen.  It's OK
to read garbage pixels from obscured pixel regions otherwise.  Maybe this
could be optimized in the future.