What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

[Huw D M Davies]

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
huw at codeweavers.com