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 Bd!. 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.
