Fixing conflicts between WineD3D and WGL

[Ken Thomases]

(Resending with a download link instead of an attachment.  The previous attempt got dropped due to its size.  Apologies if anybody gets duplicates.)

Hi,

I now have a nearly complete implementation of the WGL_WINE_surface extension for both the X11 and Mac drivers.  A tarball of patches is available from <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface.tar.bz2>.  You'll have to enter an access key, "wgl_wine_surface" (without the quotes).

While implementing support for full-screen surfaces in the X11 driver, it became clear that I needed a reference to the wined3d device window or, more generally, the window for which the surface is a substitute.  This is necessary to manage focus since the full-screen window has to have X focus but the Win32 focus needs to remain with the device window.

Because of that, the function wglCreateSurfaceWINE() now takes a proxy window parameter.  This feels like an ugly kludge but I didn't find a cleaner alternative.  I'd be happy to discuss the X windowing issues that I feel lead to this requirement with anybody who may have better ideas.


There are some minor rough edges to the implementation.  In particular, in any desktop environment view of all windows (e.g. Exposé or Mission Control on OS X, the Alt-Tab switcher on Linux, etc.) both the device window and the window for the full-screen surface will appear.  The device window is likely to be blank because the rendering is happening in the full-screen surface window.  On the other hand, the full-screen surface window will not have a title or an icon, while the device window will.  There's a bit of split personality there, which may be confusing.

If the user attempts to switch to the device window, the full-screen window should take focus, instead.  So, the user should get the desired result and the problem should be merely cosmetic.  I have not had the opportunity to test this on Linux.  It's possible that some window managers will fight my attempt to redirect focus like that.

I believe I can hide the device window and also copy its title and icon to the full-screen window, which will resolve this.  (The device window will only be hidden on the X or Cocoa side.  From a Win32 perspective, it will still be visible.)


Other than those rough edges, the main thing holding me back from just submitting these patches is the lack of testing.  I would greatly appreciate if folks would give these patches a test and report any issues they introduce.

Things to test, specifically:

* Of course, that they don't break Direct3D games in general.  Things that used to work still work.

* They should fix regressions introduced by my commit 4c4552c5, such as bugs 35718, 35975, and 35950.

* They shouldn't have much performance impact other than those regressions.  There may be a slight performance improvement since they allow wined3d to skip some housekeeping.

* Full-screen games are actually full-screen, appearing in front of other apps, docks, panels, menus, taskbars, etc.

* But you can switch to another app as well/easily as you could without these patches.  Full-screen games don't take over your whole display such that you can't escape without drastic measures.

* After switching away, you can switch back successfully.

* Switching, especially repeated switching, among full-screen resolutions and between full-screen and windowed modes works.

* Mouse input works as expected.  In particular, clicks are not offset from where the cursor appears to be, especially after switching resolutions or between windowed and full-screen modes.

* Keyboard input works as expected.  The use of input methods such as for Chinese, Japanese, or Korean especially needs testing.

* With the X11 driver, games behave properly in virtual desktop mode, in both windowed and full-screen modes.

* In windowed mode, resizing the window works properly.

If you suspect the patches have introduced a bug, please be sure to double-check that the bug doesn't exist in unpatched Wine.  Once you're sure, please report it as a reply to this thread or a reply directly to me.

Thanks very much,
Ken