Leif Delgass wrote: > On Tue, 2 Jul 2002, Graham Hay wrote: > [...] > >>I did find a problem running an OpenGL app I wrote for work. >>It seems that when I use the XOR logic op for rubber >>banded lines/rectangles that it doesn't erase the previously >>drawn pixels. They get set to something which looks like an >>XOR would, but it stays that way. Maybe the logic op is set >>wrong? > > > OK, I've identified the problem here. It seems that the Mesa software > rasterizer is reading from the BACK buffer instead of the current > DrawBuffer (the FRONT). Using glDrawBuffer(GL_FRONT_AND_BACK) produces > the correct result without swapping buffers. Normally, I think the > software rendering code should switch to read from the current draw buffer > and then restore the context's original ReadBuffer state. This turns out > to be the same problem with blending textures rendered in software with > the framebuffer in the Mesa texenv demo in front-buffer mode. I tested > this by making the driver always read from the draw buffer in the span > functions, and it fixed the problem. What I haven't figured out yet is > whether the problem is in the driver or the Mesa software rendering > functions. The mach64 driver has SetReadBuffer and SetDrawBuffer > functions that look like the other drivers. I did confirm that the Rage > 128 driver has the same problem with the texenv demo for the GL_BLEND > texture environment when there is an environment color (the transparent > texture areas are blended against the black of the back buffer instead of > the checkerboard in the front buffer -- this is with the background > toggled off in the demo). > > It seems that the Mesa software rendering functions for logic ops and > blending in these cases aren't calling the driver's SetReadBuffer function > to match the context's DrawBuffer (I put a debug message in the > SetReaderBuffer function and it wasn't called). So, when the driver's > templated ReadSpan/ReadPixels functions are called, they are reading from > the wrong buffer. However, calling glReadBuffer followed by glReadPixels > in a GL program _does_ show the SetReadBuffer function being called. > > Anyone have any ideas?
The notion of 'current read buffer' is more complicated than one would first expect. There are basically two situations in which you need to read from a color buffer: 1. glRead/CopyPixels() and glAccum() 2. blending/logicops/masking In the first case, the source buffer is whatever glReadBuffer() indicates. Furthermore, the source for the pixels may be a completely different window. The glXMakeContextCurrent() and glXMakeCurrentRead() functions let you specify different drawables (windows) for reading and writing pixels. That's why Mesa's swrast->Driver.SetReadBuffer() takes a GLframebuffer argument. In the second case, the source buffer is what glDrawBuffer() indicates. Mesa considers the second case to be the more common and usually keeps the "default read buffer" = "default draw buffer". So the basic idea is to read spans from whatever the ctx->Driver.SetDrawBuffer() call indicates, until overridden by swrast->Driver.SetReadBuffer(). This stuff is kind of complicated and I want to try to simplify the process for Mesa 4.1. -Brian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek We have stuff for geeks like you. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
