Idear for OpenGL overdraw child windows Bug

[Florian Köberle]

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.
> 
> 
> ------------------------------------------------------------------------
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenGL03.cpp
Type: text/x-c++src
Size: 5434 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060729/7c842184/OpenGL03-0001.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenGL03.exe
Type: application/x-msdos-program
Size: 27315 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060729/7c842184/OpenGL03-0001.exe