Trying to get my 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's redraw is mangled---OpenGL is affecting the entire X11 Window.
In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, even if it is only a small child window, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed.
In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try. It is possible that glScissor might be used. A more accurate wglMakeCurrent emulation is necessary for a usable port. Suggestions welcome.
Thanks, Russ
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote:
Trying to get my 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's redraw is mangled---OpenGL is affecting the entire X11 Window.
In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, even if it is only a small child window, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed.
In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try. It is possible that glScissor might be used. A more accurate wglMakeCurrent emulation is necessary for a usable port. Suggestions welcome.
No need to repeat it ... I have seen the same, but no ideas. ;)
Ciao, Marcus
On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote:
Trying to get my 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's redraw is mangled---OpenGL is affecting the entire X11 Window.
This is basically the problem which is tracked through Bugzilla bug 2398 (URL: http://bugs.winehq.org/show_bug.cgi?id=2398).
In summary, the problem is as follows: due to some 'features' of Win32 handling of windows and DCs, having a Win32 window <=> X11 window one to one mapping is not feasible (it was done once but Alexandre removed it as part of the window management rewrite as it lead to some problems in applications). In the current Wine code, there is only one X11 window for each top-level Win32 window, everything else inside these windows (clipping, ...) is done internally by Wine.
The easiest way to fix the issue would be to 'override' the 'glViewport' call and pass to GLX no the viewport as decided by the Win32 application but the one relative to the X11 window taking into account the Win32 DC position relative to this X11 window (one could do the same with glScissor). This should work ... except that it won't handle the case where the DC is partially obscured by something (i.e. where Wine should do its own clipping) and one would need also to override all the 'buffer' functions (like glReadBuffer / glWriteBuffer). In that case, one could still imagine hacks (like using clip planes or stencil tests) but the big problem with that is that we use GL ressources to do this => if the application itself uses stencilling or clip planes, we are facing a ressource conflict.
So we have two possible solutions:
= write our own GLX extension that exports to the user the clip-list handling (the drivers must export something like that to the X11 server to be able to do propper window-level clipping, the goal of this extension would just be to enable the actual application to insert in this list its own clip rectangles).
= use pbuffers for all GL renderings and use Wine's standard GDI functions to 'blit' this on screen. This has the advantage that the application would be completely 'fooled' without having to hack any GL calls. The problem would now only be when to flush this pbuffer on screen (which would lead to changes to the thunks for front-buffer operations or single-buffered operations).
The first solution would clearly be the best but we need some volunteers to:
= draft the GL extension = check with people to see if they think something like that would be acceptable (maybe by coding it in the X.org tree for some cards where the GL driver is open source) = push for the extension to be included in the 'commercial' GL drivers (NVIDIA / ATI)
Lionel
В сообщении от 26 Август 2005 15:32 Lionel Ulmer написал(a):
On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote:
Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's
...
So we have two possible solutions:
= write our own GLX extension that exports to the user the clip-list
...
= use pbuffers for all GL renderings and use Wine's standard GDI functions
...
Lionel
Thank you for detailed description f the problem. I copied it into wiki, please check it at http://wiki.winehq.org/OpenGL
-
Lionel Ulmer -
Marcus Meissner -
Russ -
Vitaly Lipatov