I tried to implement it first in a demo application. One big problem is that there is no "paint to back buffer" function and drawing to front buffer cause often jittering.
Please view the attached sourcecode. I added a lots of comments at the position of the SwapBuffers Command.
If there is really no way to draw to background directly, we still could use OpenGL to do this. So we draw every child window to a single buffer, like I explaind before. Then we load these buffer with OpenGL as Image and draw it when SwapBuffers is called. This is the only time point when we draw the Buffer to the backbuffer with OpenGL. There will be no jittering (because we draw to the back buffer and not to the front buffer) and it will be fast!
The only needed OpenGL Ressouce will be some graphic card space for the texture. When the owning Window is 1024*768 huge we 3-4 MB space of 128 MB which a common graphic cards have.
How to solve the Placement problem is explained here: http://wiki.winehq.org/OpenGL
Before a swapbuffers call, every thread have to (see Win API help) call glFlush so OpenGL has finished all his drawing at the call time of swapbuffers.
Stefan Dösinger schrieb:
Am Montag 24 Juli 2006 22:01 schrieb Florian Köberle:
When OpenGL draws, child windows get overdrawn.
The suggestions to solve these problem where all based on the idear of clipping that what OpenGL render so that OpenGL doesn't overdraw them.
What do you think of the idear of letting OpenGL overdrawing the child windows, but then after this we redraw all the child windows?
There are two things who have to be done: 1.) find out when OpenGL finished his drawing 2.) find a way to draw the child windows.
possible solutions for 2.) The easiest (but slowest) way of doing this could be a broadcast of the window message WM_PAINT to all child windows.
It could work, but the performance hit would be quite hard(window redrawing is slow), and it still wouldn't sove the placement problem. Furthermore there is the problem that opengl is asynchronous, so it might happen that opengl drawing is started, you detect that the window needs redrawing, redaw and then opengl is finished drawing and draws over the just redrawn window. You would have to wait for gl after every gl call which would make it even slower. It is highly unlikely to ever occur, but it can happen.
Another issue is that the constant redrawing would cause a lot of flickering in the redrawn area which won't look nice.