http://bugs.winehq.org/show_bug.cgi?id=2082
--- Comment #84 from Stefan Dösinger stefandoesinger@gmx.at 2011-07-07 17:38:23 CDT --- Created an attachment (id=35470) --> (http://bugs.winehq.org/attachment.cgi?id=35470) A slightly nicer hack
This hack makes the software emulated ddraw implementation render to the device window or clipper window. The device window is NULL in most cases, so the ddraw app will essentially render to the screen, overwriting the content of all Windows(including possible child Windows).
This is broken in a rather bad way, but that's what native ddraw does. It is also broken in native ddraw, and Windows Vista and newer will disable Aero when an app attempts to use ddraw without a clipper in Windowed mode. In Fullscreen mode it most likely disables Aero anyway, so the apps still get away with this behavior. The draw-to-screen behavior can be observed in the d3d7 SDK's "Font" sample, like on this screenshot: http://web.student.tuwien.ac.at/~e0526822/ddrawtoscreen.bmp
Drawing to the screen basically works in X11, but only as long as no compositing Window manager is active(Compiz for example). If Compiz is enabled the rendering will most likely go nowhere. Using a virtual desktop may also help, this way Wine still renders to a proper X11 window from the window managers point of view. In anyway rendering to a NULL window does not work with opengl-accelerated ddraw or direct3d. OpenGL needs a Window to render to. The only alternative is rendering to an offscreen buffer, but then the rendering results don't show up either.
The hack needs improvements in a few ways: *) Don't do this in Windowed mode, only fullscreen. If we're in Windowed mode cling to any window the app passes to ddraw, otherwise we make bug 1347 worse(Bug 1347 is essentially the opposite of this bug, where the app doesn't provide any Window and runs amok when locking the front buffer)
*) Test if using the device window in this way is correct. You can do this by extending the test app and call SetCooperativeLevel with DDSCL_SETDEVICEWINDOW and your partially obscured window, and probably pass NULL or a different window to the DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE SetCooperativeLevel call. DDSCL_SETDEVICEWINDOW needs IDirectDraw7 I think.
*) Test what the behavior is when DDSCL_FULLSCREEN is used without DDSCL_EXCLUSIVE.
*) Test clippers in fullscreen mode. E.g. try to set your obscured window as a clipping window and see how Windows reacts(CreateClipper, Surface::SetClipper & friends)