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