What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

Vitaly Budovski vbudovsk at cs.rmit.edu.au
Mon Mar 27 20:31:43 CST 2006

Tomas Carnecky wrote:
> Huw D M Davies wrote:
>> On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote:
>>> Ah right, glDrawBuffer alters the rendering state, that's bad.  We
>>> should presumably be calling glXSwapBuffers here (but only in the
>>> GLXPixmap case).
>> Which of course won't work either.
>> We need to find out what happens to the render state under Windows
>> when we make call wglMakeCurrent on a bitmap (I know that even with
>> the rendering state set for GL_BACK then the bitmap gets drawn on) and
>> whether we restore the rendering context when we switch back to using
>> some other dc afterwards.  We probably shouldn't do anything in the
>> pbuffer case (which is what's causing your problem I guess).
>> The big issue is that pbuffers and bitmap rendering are getting
>> confused all over the place.
> Feel free to take http://dbservice.com/tom/LinuxTest.cpp, change it and
> test it.. it's a win32 application, despite its name :)
> tom

You need to call wglMakeCurrent right before you test for the presence 
of ARB/EXT wgl functions.

On windows I get the following result:
initial drawBuffer: 0x405
after setting back buffer: 0x405
after activating pbuffer: 0x405

On wine I get (NVidia Geforce 6800):
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  143 (GLX)
   Minor opcode of failed request:  13 (X_GLXCreateGLXPixmap)
   Serial number of failed request:  135
   Current serial number in output stream:  136

and the log is partially filled to:
initial drawBuffer: 0x405
after setting back buffer: 0x405

More information about the wine-devel mailing list