I’m thinking of using directdraw to lock the framebuffer right after the SwapBuffers. Does that sound like a good idea ? The reason is that I want to be absolutely sure that the 3D pipeline has been cleared, which is what glFlush/glFinish should be doing, but apparently, don’t. I’m using GDI after the swap to add some GUI data, and on NVidia this does not render correctly. It does improve if I add a sleep () between the swap and the actual GDI drawing, so it sounds like a synchronization issue (-> don’t think wgl_swap_control would help). I tried forcing a stall by issuing a glReadPixels but that didn’t help.
This is related to another issue – is it valid to combine GDI and doublebuffering at all ? MSDN says you can’t, but they’re talking about the generic (software) renderer…
I’m sure that the GPU pipeline is empty after SwapBuffers() (unless there is some sort of a driver bug, but that would show up in normal rendering as well). Also a glReadPixels is certainly completely flushing the pipeline and stalling the CPU until the GL command stream is completed (otherwise glReadPixels wouldn’t work).
But: there is the possibility (I’m not certain but it would explain the behaviour that you encounter), that the SwapBuffers() finishes the GPU pipeline and returns, but that the actual buffer swap is not necessarily completed by the time SwapBuffers returns. In other words, I could imagine the actual buffer swap being performed somewhere in the middle of your GDI drawing commands (especially in windowed mode, where a block copy has to be used instead of a simple address swap).
Cass? Matt?
One way to work around the problem could be to render the GDI commands to an offscreen bitmap, retrieve the bitmap and use it as a texture to render onto a Quad with OpenGL, if you have to run windowed mode.
Also, try to set the buffer flipping mode to ‘auto select’ in display properties/advanced/additional properties/OpenGL settings and run the app in fullscreen mode afterwards. See if you’re still having the same problem then.
As long as your GDI drawing is rectangular, you should be able to create subwindows of your OpenGL window, and perform the GDI drawing in them. Make the subwindows standard windows, NOT OpenGL windows. I’m not sure what effect this has on performance in full-screen mode, though.
I’m also thinking the problem may be a delayed swap. (Sidenote, I’m not sure if it is related but I’m also often seeing dangling windows graphics, for example selecting an item from a dropdown menu can leave traces of a half-faded menuitem) This is why I could imagine that a glReadPixels works ok, because it just gets pipelined until after the actual swap, whereas a ddraw lock may force the stall… I don’t know.
Settings are autoselect, drawing is windowed. Rendering GDI to a bitmap sounds like a headache… and full screen may be difficult, but I’ll keep it in mind.
tcobbs-- do you mean creating some sort of transparent child window so that it acts as a kind of overlay ? The GDI drawing is covering the rendered stuff (axis, selection rects, stuff like that), it certainly sounds interesting…
Edit : example update bug (the side note I mention) : http://users.chello.be/sf15772/updatebug.jpg This was after selecting an item from a menu which caused the scene to be redrawn with funky colors. Where the item is shows the previous frame which was greyscale
(white bars = censoring to not get fired for posting pics )
[This message has been edited by bpeers (edited 06-06-2002).]
