http://bugs.winehq.org/show_bug.cgi?id=9506
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine-bugs@winehq.org, | |stefandoesinger@gmx.at AssignedTo|wine-bugs@winehq.org |stefandoesinger@gmx.at
--- Comment #3 from Stefan Dösinger stefandoesinger@gmx.at 2007-09-13 19:10:29 --- Yeah, this bug sounds very much like 4902. This problem occurs if applications create a windowed DirectDraw object with a the target window = NULL(which means the whole screen), then locks it and unlocks it. When the surface is created, it is initialized to black. The application does not modify it after locking, and on unlock, the black is written to the screen.
I am not sure how to really fix this. The most obvious thing is to read the screen content into the surface when locking, so the old content will be written back on unlock. This is also needed because locking the primary surface can be used to make a Screenshot of the whole screen. The problem with this is that it has terrible performance impacts - quicktime plays at one frame every two secounds. Crossover has a hack that limits the readback to read-write locks just because it makes QuickTime happy, but it is not correct because a write-only lock has the same problem.
A workaround is to enable the OpenGL DirectDraw implementation. This works because it reads the opengl buffer into it's own surface copy, and the gl buffer is the screen content. However, the buffer modification tracking is not designed for this, so it may happen that an outdated copy of the Desktop is written back.