OpenGL windowing and wglMakeCurrent

[Lionel Ulmer]

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

-- 
		 Lionel Ulmer - http://www.bbrox.org/