I am working on an application which is using MFC with wGL. It can have multiple windows at a time, and hence multiple rendering contexts.
The problem I am facing is that if a window is being overlapped, e.g. a dialog box is covering a portion of a GL window, and if the GL window is currently in a draw loop, then I get trails (shadows) of that dialog box on the GL window if I try to drag it. Note that this doesnt happen if i drag a dialog box when the draw loop has completed for the GL window
I am using glCopyPixels in case of OnPaint() to dump whatever is in the back buffer onto the front buffer. Is it a problem with Pixel Ownership Test that the system performs? or can it be that my back buffer becomes invalid? any thoughts will be highly appreciated …
Exactly, it has to do with pixelownership.
CopyPixels from the back buffer is not the correct way to repaint the front buffer of an OpenGL window on window expose messages.
An OpenGL pixel is the whole number of bits in front, back, depth, stencil etc. buffers. A window expose message must be answered with a correct repaint of the the whole arrays of bits.
You can also not expect an implementation to render into areas overlapped by dialog boxes, means your “correct” behaviour you see when you move the dialog after rendering finished, will not work on other OpenGL implementations.
You can only render reliably into unclipped buffers with targets using p-buffers or frame buffer objects (FBO).
The problem I just posted has been solved. Please disregard the previous message. If anyone would like to know more about the solution though, please feel free to reply.
uhm … actually i think i have created some confusion here. According to Relic, the pixel ownership problem renders the method that i am using useless. So what I did to fix it becomes meaningless. (The fix was actually that CopyPixels was not being called while the draw loop was active).
Relic, I havent experienced the problem you mentioned on my PC and few others, but u r right. Other implementations of OGL might not show the “correct” behavior.
You suggested pbuffers or FBOs. Now, both of these are OGL extensions, and I beleive not a part of the core OGL yet. (correct?) Dont you think that it might be a good idea to implement Render To Texture myself?
I mean if i do something like rendering to back buffer, then copying n saving a texture from the back buffer in system memory, and using that texture whenever WM_PAINT occurs? does the pixel ownership problem affect rendering to back buffer even while the rendering context is active and there is a window overlapping the GL window?
Originally posted by salman.awan:
I mean if i do something like rendering to back buffer, then copying n saving a texture from the back buffer in system memory, and using that texture whenever WM_PAINT occurs? does the pixel ownership problem affect rendering to back buffer even while the rendering context is active and there is a window overlapping the GL window?
Yes. Nothing which sources the front or backbuffer will help to implement an unclipped backing store mechanism like you want when the pixelownership fails.
Especially on implementations which share the back depth and stencil buffer among all OpenGL windows, like workstation boards tend to do, you cannot render below an overlapped region. Imagine two OpenGL windows overlaping each other. There is only video RAM for the top one visible.
Same for all regions outside the desktop window. You cannot render into invisible areas of windows which are dragged partly offscreen.
The only way to solve this is to either do your repaint correctly (same like you would do for 2D windows GDI apps) by actually redrawing the part of the newly exposed update region, or by rendering into a p-buffer or FBO and copying from there.