Re: PBuffer and wglMakeCurrent()

[Raphael]

On Thursday 11 May 2006 14:24, Tomas Carnecky wrote:
> Alexandre Julliard wrote:
> > Tomas Carnecky  writes:
> > > As far as I understand, the only way to access x11drv is through GDI
> > > (which implements ExtEscape), would your proposed change require new
> > > functions for opengl32 <-> x11drv communication through GDI? Or is it
> > > somehow possible to bypass GDI and access x11drv directly from opengl32?
> >
> > The DC access will have to be done through GDI, yes, but that can be a
> > simple wrapper that calls the corresponding driver entry point. For
> > functions that don't need to access the DC, opengl could call x11drv
> > directly, though of course if everything goes through GDI it will make
> > it easier to support opengl with a different driver.
>
> Based on your ideas, I did the following:
> - added a new gdi driver function: 'wglMakeCurrent'
> - move wglMakeCurernt to x11drv
> - new function wrapper_wglMakeCurrent in gdi/driver.c
> - wglMakeCurrent in opengl32 just calls wrapper_wglMakeCurrent
>
> and it works, though I had to add -lGL to the x11drv Makefile, I don't
> know how you see a libGL.so requirement for x11drv, maybe load libGL.so
>  and the required entry points at runtime like in opengl32/wgl.c

No x11drv should not depend to GL.so. see opengl.c 
you can see that GL.so is dynamically loaded (dlopen/dlsym) 
so not mandatory
> I had to simplify wglMakeCurrent, I didn't spend much time on this hack,
> and I had to copy the Wine_GLContext structure to x11drv/opengl.c, quite
> ugly.. I know

well ...
> I also had to comment out calls to 'NtCurrentTeb()' because it wouldn't
> compile otherwise, I don't know what that function does, but World of
> Warcraft works without it (and as a sidenote, I think it runs much faster).

Yakkk
NtCurrentTeb is used to access current thread descriptor as opengl contexts are thread-specific. And it sould permit to share opengl context between many wine ibraries (as windows do) without ugly hacks :)
> I didn't know how much logic to put into opengl32/gdi or x11drv, gdi
> extracts the PHYSDEV from the HDC and passes it as the first argument to
> the x11drv function implementation, along with the original arguments
> (Is is ok to pass HDC to the x11drv?).
>
> And I don't know if the function naming is ok, x11drv exports a function
> named wglMakeCurrent, maybe that should be changed to
> wine_wglMakeCurrent and I don't know if the gdi wrapper and exported
> function names (both wrapper_wglMakeCurrent) are ok.
>
> If we can sort out the naming I could start adding the driver entry
> points to both GDI and x11drv, without migrating the actual function
> implementation, and than start migrating function by function to x11drv.

For info in windows openGL32.dll prerequs:
 - user32.dll
 - gdi32.dll 
 - ddraw.dll

I'll look at patch when i'll have time (too little for now)
Thx

Regards,
Raphael