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.