why window leaves trace?

I am using MFC, Visual C++, double buffering. For new small additions to my scene I draw with glFlush(), but for refreshing the whole scene I am using SwapBuffers(). I do not want to redraw the whole scene for small addition.
If a popup window (a menu for example) is opened after glFlush() it leaves its trace when it is closed, but if popup is opened after SwapBuffers() nothing remains when it is closed. What is the reason for this? How can I prevent? Does anyone know?

Think carefully and practically about where you’re drawing and understand that a flush is not a swap. Flush will flush to the back buffer, you still have to swap to display in the frontbuffer, unless you are drawing directly to the frontbuffer.

I am drawing to GL_FRONT and then using glFlush() and then setting back to GL_BACK. Any other suggestions?

Originally posted by dorbie:
Think carefully and practically about where you’re drawing and understand that a flush is not a swap. Flush will flush to the back buffer, you still have to swap to display in the frontbuffer, unless you are drawing directly to the frontbuffer.

That should work. The flush should produce fragments in the frontbuffer, if it doesn’t you’re seeing a bug. You may want to try a glFinish which may help as a workaround.

Sorry if I sounded patronizing in my first response.

my problem is not with glFlush() . It is working. My problem is with the remnant of the popup windows. i want to know its reason and its relation to difference between swapbuffer and glflush. If you say that there can not be any difference between using glflush and swapbuffer then there must be a problem with some other part of my code. Also, if I draw my small scene parts to GL_BACK and then SwapBuffer, will OpenGL try to draw everything(all the scene) or only the new addition. Thanks.

Originally posted by dorbie:
[b]That should work. The flush should produce fragments in the frontbuffer, if it doesn’t you’re seeing a bug. You may want to try a glFinish which may help as a workaround.

Sorry if I sounded patronizing in my first response.[/b]

You understand the 3D scene is rendered to the screen as a bit map image, I not sure that windows stores the resulting image like that of one in a normal windows application. I am not 100% up on windows, but you may have to re-render the whole scene if you have another window above it, or when you render store the resulting image in a buffer that you call back when the window area has been drawn over.

You can only get by with not redrawing the whole scene when you add an object is if the object you are drawing is above all the other objects. Else openGL must reprocess the scene with the new object.

what is happening when I SwapBuffer(). I know like GL_BACK is copied to GL_FRONT, but what is happening to GL_BACK(erased or same). What happens if I SwapBuffer() again without drawing anything new? Also there is a function like glCopyPixels(), can it help my problem efficiently? Thanks.

Originally posted by nexusone:
[b]You understand the 3D scene is rendered to the screen as a bit map image, I not sure that windows stores the resulting image like that of one in a normal windows application. I am not 100% up on windows, but you may have to re-render the whole scene if you have another window above it, or when you render store the resulting image in a buffer that you call back when the window area has been drawn over.

You can only get by with not redrawing the whole scene when you add an object is if the object you are drawing is above all the other objects. Else openGL must reprocess the scene with the new object.

[/b]

It has to do with the way you are handling the paint event. If you are not swaping buffers then the whole window doesn’t get redrawn hence the problem.

If you don’t use clear then the scene is still in the back buffer. Actually the way it would work is the pointer to the “front buffer” would get set to the back buffer while the “back buffer” pointer would get set as the front buffer there is no memory copy or erase in the operation.

[This message has been edited by stonemetal (edited 02-03-2004).]