[Bug 2398] OpenGL is only used only on top level windows so child windows get overdrawn

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2398





------- Additional Comments From philip at digitalinfinity.biz  2006-29-04 20:58 -------
Right now with the way the current code works. Just making a GL view port to
display will be very problematic to implement. From the discussion that I've
read on this bug and others. I can see conditions where that implementation and
all the other implementations will be a problem. This is a really ugly situation
we have here to make it work. But here is how I see it. I'm writing this post to
help identify the problem and define the problem better so as to get a better
solution:  

First GL view ports probably won't interact properly with the wine windows
properly. I can give you guys some examples. What happens to the view port when
you drag it partially off the screen or over an area where the rendering engine
is supposed to render but clip the window. Because the viewport is a separate X
window your going to run in to problems here. It will be another bug because the
view port will clip the rendered area using the regular engine rather then the
other way around. So this is the draw back of using GL view ports for this. 

With pbuffers although these will be the best solution for view ports in
programs that have MDI windows it is not ideal for games and other programs that
don't use those. You will see a performance hit in high performance gaming and
applications. So pbuffers will not be the ideal solution in that situation due
to the fact that you are not rendering directly to the screen. There is a
question of weather there is hardware support for pbuffers and GL Pixmaps. From
what I understand there is none or its very limited. So rendering to the screen
with these will be a problem as well. Pbuffers cannot be used in all
applications or wine will be unusable for games. 

These unfortunately is where it stands now with the current engine. When we look
at it windows and X are not that different in their design. All controls in
windows are a window. The same as in X. I remember reading a book on the old
Motif library and how they created a set of controls called gadgets. They were
basically windowless controls.  What they indicated in that book is that these
objects were created in earlier version of X and as time went on implementing
objects as an XWindow actually became less expensive then using gadgets. This
was due to improvements in efficiency in the X server. Thats why the practice
doesn't exist today in X and every X control has its own window.  This may be
something to consider here. 

Any rendering issues of which window to render can be taken care of by using an
Octree to determin which windows to paint. A paint message is then sent to the
individual control or window. The code I've given you above can be used for this
although the C implementation may be a little more involved. It would require
support in the x11drv code and the API to make this happen. 



-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.