In wglMakeCurrent(), when the HDC type is OBJ_MEMDC you activate the frontbuffer for drawing. PBuffers' type is also OBJ_MEMDC, but changing the drawbuffer in that case is wrong.
Is there a way to find out if the HDC is a PBuffer? I have some patches in my local tree but I took the freedom to put the X11DRV escape codes to one common header which alexandre doesn't quite like.. In my local tree I have a 'flags' field in X11DRV_PDEVICE which I use to store whether the PBuffer is damaged or not, I don't know if its the right place, but I could add a flag IS_PBUFFER and set it in wglGetPbufferDCARB() and check for it in wglMakeCurrent().
comments?
tom
Tomas Carnecky wrote:
comments?
Why do I have the impression that when it comes to x11drv/opengl nobody wants to take the responsibility. I won't submit a patch until someone says 'tom, your approach looks good, improve this and then submit a patch to wine-patches' or 'tom, no, this won't work because ... try to change this ... move the code there ... don't do that, it will break this' etc. I don't want to know whether the implementation details are ok, I just want to know whether the general idea (the flags field) is acceptable.
I did the changes I've described and it does work, but I won't work on it any further (eg. make it independent of my previous patches) unless I get a green light.
In the attachment is the latest patch I've applied to my local tree, you see that it requires the X11DRV_[S|G]ET_FLAGS escape code which I've added in one of my previous patches. Maybe that gives you an better idea of what I'm trying to do.
tom
Tomas Carnecky tom@dbservice.com writes:
Why do I have the impression that when it comes to x11drv/opengl nobody wants to take the responsibility. I won't submit a patch until someone says 'tom, your approach looks good, improve this and then submit a patch to wine-patches' or 'tom, no, this won't work because ... try to change this ... move the code there ... don't do that, it will break this' etc. I don't want to know whether the implementation details are ok, I just want to know whether the general idea (the flags field) is acceptable.
What we probably want is to move a lot more of the glX code into x11drv, and export the various wgl functions from there. That escape mechanism is beginning to be seriously abused.
Alexandre Julliard wrote:
What we probably want is to move a lot more of the glX code into x11drv, and export the various wgl functions from there. That escape mechanism is beginning to be seriously abused.
Even is the functions were implemented in x11drv.. wglMakeCurrent() still takes a HDC as an argument so the issue how to change the X11DRV_DEVICE given a HDC would remain. The escape mechanism seems to be the only way to communicate with the low-level x11drv implementation, or did I miss something? 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?
tom
Tomas Carnecky tom@dbservice.com writes:
Even is the functions were implemented in x11drv.. wglMakeCurrent() still takes a HDC as an argument so the issue how to change the X11DRV_DEVICE given a HDC would remain. The escape mechanism seems to be the only way to communicate with the low-level x11drv implementation, or did I miss something? 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.
Alexandre Julliard wrote:
Tomas Carnecky tom@dbservice.com 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
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
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).
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.
The attached patch is what came up by my hacking, just so you have an idea what I've done ;)
tom
On Thursday 11 May 2006 14:24, Tomas Carnecky wrote:
Alexandre Julliard wrote:
Tomas Carnecky tom@dbservice.com 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
-
Alexandre Julliard -
Raphael -
Tomas Carnecky