Visuals and GL contexts
Hello, I've finally pinned down a problem (with help from Lucho) to do with blending and its back to the same old problem that by the time D3D8 gets initialized, the windows has already been created, but the properties of the visual are insufficient to handle the requirements of D3D. In my case for example by default, the visual used for my windows has double buffering, but no alpha channel. X11DRV process attach has some code which allows control over the visual created, but this is before we know what is going to be required, and this only gets called if DesktopDoubleBuffer is set to Y. In my case, I need an alpha channel on the back buffer. By default, I havent got one. I can add code into the X11DRV_setup_opengl_visual to ask for an 8 bit alpha and everything works perfectly. So.... 1. Should I add a new config option (something like RequireAlphaChannel) - FWIW I hate this idea 2. Is it ever going to be possible to replace a wine Xwindows visual? What is involved in doing this? This is the 'perfect' solution. 3. Can I default double buffering and alpha on regardless and remove the doublebuffering property. How does this affect non game apps? We need to resolve this to ever support games properly without lots of config options Jason
1. Should I add a new config option (something like RequireAlphaChannel) - FWIW I hate this idea 2. Is it ever going to be possible to replace a wine Xwindows visual? What is involved in doing this? This is the 'perfect' solution. 3. Can I default double buffering and alpha on regardless and remove the doublebuffering property. How does this affect non game apps?
This issue was already raised a long time ago on wine-devel about GL contexts (for OpenGL emulation and not for D3D). The problem is that I cannot really find this thread again in my archives (I just remember Alexandre's answer 'It won't be easy' :-) ). As you mentionned, the perfect solution would be 2) but, for that, one would need hooks in the X11DRV which would : - delete the window we want a new visual - create a new one with the correct visuam - and replace the current window by the new one (and, of course, reparent all child windows and attach the new X window to the parent of the deleted one) This done, of course, thread-safely, and more importantly, while being sure that nobody ever stores in its context the real X window id (which is what the D3D and GL code does :-) ). Let's hope that a game won't do D3D, D3D8 and GL on the same window :-) Another solution would be to propose an GLX / X11 extension to be able to change dynamically a visual once the window is created. Then, finally, the ultimate solution is to always use 'indirect rendering' (ie always to PBuffers and blit the framebuffer on screen instead of using glXSwapBuffers). This to some slight performance hit. For point 1), this could be automated a bit by printing a warning on screen 'Please add ..... in your Wine configuration for this game to run properly' (as you have access to the .exe name, you could generate an app-default entry that would fix this issue). As for point 3), I have absolutely no idea if using double-buffered visuals would slow 'non-game' apps down... I could imagine though, that if an apps uses thousands of X11 windows, to each time allocate a back buffer + an alpha buffer would maybe exhaust faster the ressources of the X11 server than a 'normal' visual. Lionel PS: this mail may smell of 'déjà-vu' for people in the wine-d3d list :-) -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
1. Should I add a new config option (something like RequireAlphaChannel) - FWIW I hate this idea 2. Is it ever going to be possible to replace a wine Xwindows visual? What is involved in doing this? This is the 'perfect' solution. 3. Can I default double buffering and alpha on regardless and remove the doublebuffering property. How does this affect non game apps?
This issue was already raised a long time ago on wine-devel about GL contexts (for OpenGL emulation and not for D3D). The problem is that I cannot really find this thread again in my archives (I just remember Alexandre's answer 'It won't be easy' :-) ).
Hello Lionel, May I ask, When you cut out the reply not to cut the original author ? This way we can see both authors at the same time with out doing a search or reply-all! We should try to make life more simple not the other way around....... Tom P.S. others as well :-)
participants (3)
-
Jason Edmeades -
Lionel Ulmer -
Tom