On Mon, Mar 27, 2006 at 05:32:12PM +0200, Tomas Carnecky wrote: > Huw D M Davies wrote: > > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: > >> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. > >> And I don't think PBuffers or Pixmaps can be stereo, so is there any > >> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? > > > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > > buffer of the resulting rendering area, so we make sure that we're > > rendering into the X pixmap, not some dummy buffer created by > > glXCreateGLXPixmap. > > > > Ok, but see what happens if an application has one rendering context, > one window (doublebuffered) and one pbuffer (doublebuffered or not), > activates the window (per default the backbuffer is selected for > rendering), then activates the pbuffer (together with the same context), > now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the > frontbuffer is selected for rendering, and now the application again > activates the window and now it suddenly renders into the frontbuffer, > instead of the backbuffer like it thinks. > > wglMakeCurrent() isn't supposed to change the rendering context state > (someone prove me wrong, I couldn't find any good description of this > function, but neither does glXMakeCurrent) and application can make > assumptions according to that. > > I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't > run (and won't for a looong time, sadly). And one application to test it > with apparently isn't enough. > > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers.
Ah right, glDrawBuffer alters the rendering state, that's bad. We should presumably be calling glXSwapBuffers here (but only in the GLXPixmap case). Huw. -- Huw Davies [EMAIL PROTECTED]