uninformed musings on ddraw + bugs 2082 and 1347 + dib engine
I apologize if what I'm about to say is wrong and useless. I feel the need to say it just in case it is not as wrong and useless as I fear. Background: We have two very difficult (possibly unfixable) ddraw bugs: http://bugs.winehq.org/show_bug.cgi?id=2082 - DirectDraw games only showing black screen http://bugs.winehq.org/show_bug.cgi?id=1347 - Screen is wiped/blanked on usage of DirectDraw Both of these bugs are the result of the fact that Windows (probably even Windows Vista when Aero is disabled, which I believe happens temporarily when an exclusive move ddraw app is active) ddraw can give apps direct access to the screen and X cannot. Instead of drawing to the screen, Wine draws to the application's window, which it determines based on an argument the application passed to SetCooperativeLevel. In the case of 2082, this window is obscured and no drawing happens even though it would on windows. There is a hack for ddraw that uses hwnd 0 instead (so drawing operations do go to the screen), but it can also break things in situations where an application uses both ddraw and gdi. 1347 is the result of non-fullscreen applications passing hwnd 0 to SetCooperativeLevel and (so I'm told) going through this series of steps: 1. Lock the primary surface, thus mapping the image on the screen to memory. 2. Write to your window. 3. Unlock the primary surface. On Windows, as long as Aero isn't running, this works out fine. But on Wine, mapping the image on the screen to memory is impossible. Instead, Wine simply gives the app an empty buffer, which the app writes to (but only its own window). It is impossible to determine afterwards which parts of the that buffer were written. When the primary surface is unlocked, Wine draws the image in the buffer to the application's SCL window, which is often (but not always) what the application happened to be drawing. Stefan mentions the idea of grabbing a screenshot when the surface is locked and writing it back when the surface is unlocked (which he says in one case would cause framerate to drop to less than 1 fps, which I believe). He thinks 1347 is unfixable. I think that if so, 2082 is also unfixable because even in fullscreen mode we can have problems caused by interactions with ddraw and gdi (using hwnd 0 is not always the right thing even for a fullscreen app). Now, here's where we get to the crazy uninformed ideas: What if, instead of picking one hwnd to draw to, ddraw drew to every window owned by an application? I'm making some assumptions here: it has to be possible to find the space occupied by "every window owned by an application" and draw to it at a reasonable speed. I'm also assuming that no app we want to support will want to draw to windows owned by other programs, especially X programs, even though there's nothing in ddraw that would prevent it. Well, we'd still theoretically have some problems. What if a program locked/unlocked the primary surface multiple times, once for each of various widgets that it wants to draw? The widgets would flicker. And what if a program has its own window that it wants to draw to with gdi? Its gdi parts would be painted black. Alright then, what if we had a single clientside buffer per app, the size and depth (as far as the app is concerned) of the screen, that was not synced with the actual contents of the screen but was preserved between locks/unlocks? Any operation in ddraw or gdi that resulted in a draw to the screen would have to first go through this buffer. The lock/unlock sequence would overdraw all the application's windows with the last thing the application drew there. Ignoring opengl (opengl and ddraw working simultaneously in one process should be extremely rare; maybe some swing apps do it), that should work pretty much perfectly. Sadly I can't even pretend to know enough to say how this affects opengl. It would require clientside buffers, and it would probably be difficult for current gdi to support. It seems like the sort of thing that would be more reasonable if we had a dib engine. (!) Also, giving every process a clientside buffer the size of the screen would be wasteful of memory (and optimizing for a rare case; most programs won't even have a primary surface, let along be locking/unlocking it). It may be more reasonable to have one per visible window or even one per X window, which would be manipulated as needed for lock/unlock (not sure about the X window thing because they'd have to be shared between processes.. but perhaps we need that capability anyway? it would also effectively mean we CAN give apps direct access to the screen for virtual desktops and CAN allow ddraw drawing to other Wine processes' windows). -- Vincent Povirk
There are a few more things to keep in mind: -> The DIB engine would not be used to draw to windows or the NULL hwnd. It will be used to draw to device independent bitmaps only. -> Some applications may *want* to draw to the screen outside their window. I think the dxdiag.exe app does so. -> Some apps may use ddraw without a window at all Can you confirm that the apps that show the black screen problem are broken in vista with aero on? This would be a strong indicator that the apps are doing something wrong(Keep in mind that QuickTime changes its behavior with winver=vista). All in all I think this is a hack that's not going to work well, although I did not think about it in detail yet. First of all, I think we need to do a bit more testing. E.g. test what happens if the app is in fullscreen-exclusive mode and tries to open a regular GDI window. Is it visible? There's also a dx7 sdk sample which illustrates how a GDI window with ddraw works. It works on wine, but I never looked into it in detail.
My information on Windows Vista comes from some things I happened to read on Wikipedia for an unrelated reason: http://en.wikipedia.org/wiki/Desktop_window_manager#Redirection That page cites this blog (creepily similar to what I described, using one clientside buffer per X window, except when gdi+ddraw or virtual desktops are involved): http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx If an application wants to draw to the screen where there is no Wine window (either the screen outside their window or with no window at all), I think we will have to accept that this is impossible as long as a compositing window manager is running. Such an application would have to be run in a virtual desktop. I do not have a copy of Windows Vista around to test any of this. I think I've seen the ddraw sample you refer to (with gdi and ddraw windows), but I seem to have misplaced it. Last I checked, the desktop hack breaks it, and I think it uses SetHWnd for a clipper on its primary surface. -- Vincent Povirk
Am Donnerstag, 29. Mai 2008 13:39:57 schrieb Vincent Povirk:
That page cites this blog (creepily similar to what I described, using one clientside buffer per X window, except when gdi+ddraw or virtual desktops are involved): http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx Yeah, but it mentiones that it does the double buffering for GDI windows, not directx / directdraw ones. It also mentiones that drawing to the screen is "Baaaad!". Also I do not see how shadowing the window would help here; If we don't want to overwrite any non-wine part of the screen, setting up the clipping when drawing ddraw to the screen is ok.
I've done some testing with the font.exe ddraw sample from the dx sdk. This is an illustration what it looks like: http://84.112.174.163/~stefan/font-wine.png There are no special surprises when the window is not overlapped by any other window. The app draws to a HWND, not NULL. Surprises occur when another Window overlaps it. This here is from Windows XP: http://stud4.tuwien.ac.at/~e0526822/ddrawtoscreen.bmp As you can see, the ddraw updates overwrite the Explorer window. I have no idea why the font color is different though; It seems unimportant. This is what happens on Vista with Aero off: http://84.112.174.163/~stefan/font-vista.png Now with aero on: http://84.112.174.163/~stefan/font-aero.png The aero-disabling screen flicker wasn't cought in the screenshot. However, you see the (german) aero-disable message. In the screenshot it has a nice fade effect, but on the screen it was flickering badly and not readable. A lot of other GUI elements were flickering too. This shows at least how vista handles aero + ddraw apps - not at all. However, with the aero disabling it can keep the draw-to-screen semantics, and with fullscreen apps disabling aero doesn't hurt anyway. I roughly remember some Vista-disables-aero-with-quicktime-antitrust!!!!! whining about 1.5 years ago too.
I think I've seen the ddraw sample you refer to (with gdi and ddraw windows), but I seem to have misplaced it. Last I checked, the desktop hack breaks it, and I think it uses SetHWnd for a clipper on its primary surface. What you have to keep in mind is that ddraw checks the position of the dest window and adjusts the drawing coordinates accordingly. So if you just replace the HWND with NULL you get a wrong placement. You'll have to adjust x11_copy_to_screen in dlls/wined3d/surface.c as well.
We can work around the black screen issue with a fast way to read back the screen on frontbuffer locks. This is called glReadPixels + GL_ARB_pixel_buffer_object. However, for this we need a way to get the NULL hwnd semantics with opengl, which seems impossible so far. My recommendation is this: -> Talk to the beryl devs to get a way to disable compiz. We'll need this for fullscreen mode anyway, but we should not rely on it for windowed mode, since we can't disable compositing on MacOS. So we have to work around this problem -> Continue to draw to the dest window with the gdi ddraw renderer. This keeps us Compiz and MacOS compatible, and I think we didn't have a problem that way so far -> Ignore the quicktime-black-screen bug. Make Dan happy by switching to winver=Vista by default after 1.0 -> make x11_copy_to_screen draw to the NULL window to fix Diablo 1, Worms and others. First we have to make sure this doesn't break with compiz or on MacOS though.
On Thu, May 29, 2008 at 10:21 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
-> Talk to the beryl devs to get a way to disable compiz. We'll need this for fullscreen mode anyway, but we should not rely on it for windowed mode, since we can't disable compositing on MacOS. So we have to work around this problem
We already allow this with the "Unredirect fullscreen windows" option. If the window is detected as fullscreen compiz basically disables itself and the window is drawn like it would be without compiz running. -- Travis Watkins http://www.realistanew.com
Am Donnerstag, 29. Mai 2008 17:36:26 schrieb Travis Watkins:
We already allow this with the "Unredirect fullscreen windows" option. If the window is detected as fullscreen compiz basically disables itself and the window is drawn like it would be without compiz running. That's perfect for our ddraw/d3d needs!
However, windows has a DLL which allows apps to disable Aero manually, I think that's wdm.dll. Do you expose any API which Wine could use to implement this?
On Thu, May 29, 2008 at 1:26 PM, H. Verbeet <hverbeet(a)gmail.com> wrote:
2008/5/29 Stefan Dösinger <stefan(a)codeweavers.com>:
However, windows has a DLL which allows apps to disable Aero manually, I think that's wdm.dll.
dwmapi.dll, iirc.
hModule := DllCall("LoadLibrary", "str", "dwmapi.dll") DllCall("dwmapi\DwmEnableComposition", "uint", 0) http://www.autohotkey.com/forum/topic23347.html
On Thu, May 29, 2008 at 5:21 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
My recommendation is this: -> Talk to the beryl devs to get a way to disable compiz. We'll need this for fullscreen mode anyway, but we should not rely on it for windowed mode, since we can't disable compositing on MacOS. So we have to work around this problem
Doesn't Compiz already offer the "Unredirect Fullscreen Windows" option? Remco
participants (6)
-
Austin English -
H. Verbeet -
Remco -
Stefan Dösinger -
Travis Watkins -
Vincent Povirk