http://bugs.winehq.org/show_bug.cgi?id=2398
------- Additional Comments From philip@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.
-
Wine Bugs