What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
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? tom
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. Huw. -- Huw Davies huw(a)codeweavers.com
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. tom
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(a)codeweavers.com
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. Huw. -- Huw Davies huw(a)codeweavers.com
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
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
participants (4)
-
Huw D M Davies -
Tom Spear (Dustin Booker, Dustin Navea) -
Tomas Carnecky -
Vitaly Budovski