uninformed musings on ddraw + bugs 2082 and 1347 + dib engine

[Stefan Dösinger]

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.