WineGL, take two

[Tomas Carnecky]

After submitting the patches last night, I got some feedback on IRC. It
seems that adding new exports to gdi32.dll is bad (it apparently tends
to break applications, those using safedisc2 seem to be good
candidates), so I had to look for another solution.

Everything that follows here is under the assumption that we want to
move all access to the native opengl library to x11drv. But that's the
impression I got from Alexandre in the other mail regarding new escape
codes (http://www.winehq.org/pipermail/wine-devel/2006-May/047539.html).

If the above assumption is true then opengl32.dll needs access to the
low-level driver (eg. x11drv) where all the WGL functions are
implemented. And if adding new gdi32.dll exports is not an option then
ExtEscape() or some other Escape function is the only way to go. Someone
told me that even in Windows Vista opengl uses an escape function to
talk to the low-level driver.

So my new approach is this:
- one new gdi driver function: WineGL_getDispatchTable
  => returns the dispatch table for the basic WGL functions.
- two new ExtEscape() codes:
  => WINEGL_GET_DISPATCH: returns dispatch table as returned by the new
driver function
  => WINEGL_GET_PRIVATE: returns physDev for the given HDC.
- opengl32.dll gets the dispatch table using the new escape code when it
is loaded.
- in x11drv, opengl.c is replaced by various winegl_??? files.

Why is WINEGL_GET_PRIVATE needed? The question really is: where do we
want to have the WGL extension entry points? I'd recommend to have them
in x11drv, why? If they were in opengl32.dll, we'd have to update the
dispatch table whenever we would add a new extension. And because the
application calls the functions which are entirely implemented in x11drv
and not called through wrappers (which don't really exist in my patchset
anyway) and the functions still need access to the physDev structure...
well, hence the second escape code.

I've removed all opengl related #ifdefs, I'd like to have configure set
WINEGLFILES to either 'winegl_noop.c', which implements noop functions
when opengl isn't supported, or a list with all the required winegl
files when all required headers are present.
And there is no need to check for linGL.so, too, (at least not for
opengl32 and x11drv) because all functions are loaded using wine_dlsym()
or glXGetProcAddress(). What is needed at compilation time are the three
opengl header files gl.h, glx.h and glu.h. I'm not a configure expert
and this big script scares me. That's why the configure patch is king of
a hack, but should work when someone uses --without-opengl.

The WGL related code is mostly copied over from opengl32/wgl.c and
opengl32/wgl_ext.c, I've formatted it a bit to look nicer and changed
what was needed to embed it into x11drv. For example 'get_dispay()' is
gone as we now have direct access to the display through 'gdi_display'.
The only thing that I've disabled is the WGL_ARB_render_texture
extension (nvidia drivers don't support it and there is a good chance
that no application relies explicitly on this extension, however, the
extension can be enabled by uncommenting one line in
x11drv/winegl_extensions.c).


I've put all the patches, eleven to be precise, on my server:
http://dbservice.com/ftpdir/tom/wine/

up until patch number 10, it should not introduce any regression as it
only makes the necessary changes to gdi to support the new GDI driver
function (but doesn't use it yet) and adds the winegl files to x11drv.
Patch number 10 is a bit large, it changes configure to compile the
winegl files, removes x11drv/opengl.c and updates
gdi32.DescribePixelFormat and friends to use the functions from the
dispatch table.
Patch number 11 seems big but it basically only replaces functions with
wrapper functions that call the function pointer from the dispatch
table. It also removes the now unnecessary wgl_ext.[c|h] functions and
updates the Makefile.

tom