Visuals and GL contexts

Lionel Ulmer lionel.ulmer at
Fri Nov 21 13:05:43 CST 2003

> 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

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.


PS: this mail may smell of 'déjà-vu' for people in the wine-d3d list :-)

		 Lionel Ulmer -

More information about the wine-devel mailing list