Switch between double and single buffering

Hi all,

I just got a new machine running Vista along with an Intel video adaptor. I noticed a change in behavior in an older piece of software and wondered if this is a bug.

Simply put, this program always specifies PFD_DOUBLEBUFFER in the pixel format. Depending on a user settable setting, the program either renders double buffered (setting glDrawBuffer to GL_BACK and calling SwapBuffers on render) or single buffered (setting glDrawBuffer to GL_FRONT and not calling SwapBuffers).

The behavior I am seeing on the new machine is that single buffering no longer works. If I take out PFD_DOUBLEBUFFER in the pixel format, then I’m ok. Obviously though, I can’t switch back on the fly since Windows won’t let me call SetPixelFormat more than once on a given window.

Has anyone else seen this behavior? Have I been lucky all this time or should I be able to switch on the fly?

Glenn

Create doublebuffered context and call glDrawBuffer(GL_BACK) or glDrawBuffer(GL_FRONT) and don’t call SwapBuffers.

that’s exactly what the program does, according to the poor man’s description :wink:

maybe you just have to insert a glFlush when the single buffered drawing is finished.

Nope. A call to glFlush doesn’t do it.

Regarding creating a double buffered context, I thought that’s what I was already doing by setting the pixel format to PFD_DOUBLEBUFFER.

Glenn

so the problem seems to be that you cannot draw to the front buffer when using a double-buffered pixel format. have you tried glGetError after calling glDrawBuffer(GL_FRONT) ?

That is correct. I haven’t tried seeing if an error occurred in the call to glDrawBuffer. I will try that (later when I have access to that machine again).

I placed some calls to glGetError after a handful of calls including glDrawBuffer and appear to be having an error free execution (or so they say).

This is beginning to stink of a driver bug.

It is possible that your program has problems with Vista’s composer (as it assumes your image is in the back buffer), but this is just a guess…

Not sure what you mean by that (Vista’s composer).

An added note … I made some enhancements so that I can force the software to run in software only and this seems to behave fine as well.

I think this hasn’t been asked: What HW are you using? Any chance to post the code to your program (or relevant parts of it)?

When in Aero mode, all windows draw to offscreen buffers which are then combined by a program called a composer. So the front buffer is not directly visible on the screen, it first has to pass through the composer. Now, it is possible, that the composer assumes that you’ll never draw to a front buffer of a double-buffered window, effectively ignoring it contents. Of course, if you don’t use Aero, just ignore me :slight_smile:

The hardware is a new Gateway PC with an Intel chipset. I have a simple and small Win32 program that exhibits the problem. You can snag it at http://www.poorman.ws/MinGL.zip . It just draws a simple box and allows you to rotate it with the mouse and also use the menu to switch between double and single buffer.

I am using Aero mode in Vista. When I get a chance (lunch time), I’ll try switching it off and see if that is the source of my grief.

I think you might be onto something with the Aero mode but I’m not sure. I turned that off and, for starters, neither single or double buffer rendered in the window. Instead they both rendered to the upper left corner of my desktop. It appeared that single buffer rendering worked but I didn’t see the flashes that I usually see which would suggest it was single buffering.

Intel was never known to make good GL drivers, so this may be your problem too…

You might also want to have a look at this fine article:
http://www.opengl.org/pipeline/article/vol003_7/

The code looks ok.

Except that rendering a cube with immediate mode, doubles, GL_POLYGON and colors outside but normals inside the glBegin-glEnd is far from optimal.
Dude, use one GL_QUADS primitive and floats. :wink:

You could try if the present operation from the offscreen front buffer to the desktop is invoked on Intel’s drivers when replacing glFlush with glFinish in your code.
Anyway that would still be a driver bug.

Yeah I saw that article and I tried using glFinish instead of and in addition to glFlush but to no avail. I saw some articles stating that some drivers require a CS_OWNDC style added to the window class (something my sample is lacking). I tried that too but it didn’t seem to make any difference.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.