What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

[Vitaly Budovski]

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