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? > I wrote a smaller test program for this in C which you can > find here: > > http://www.tardis.ed.ac.uk/~gnh/mach64/xor_test.c > > It should show you what I'm talking about. Also, when the > window first pops up the glClear isn't coincident with the > top left of the window as if the viewport wasn't right, > although the rectangle is in the right place. Another > clear via expose does affect the whole window, but if I > put the window half off screen and drag it back into the > middle, only parts of it are cleared. This clear problem should be fixed in the current cvs. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
