[Bug 9506] One-line Java program causes screen to go black

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Sep 13 19:10:29 CDT 2007


Stefan Dösinger <stefandoesinger at gmx.at> changed:

           What    |Removed                     |Added
                 CC|                            |wine-bugs at winehq.org,
                   |                            |stefandoesinger at gmx.at
         AssignedTo|wine-bugs at winehq.org        |stefandoesinger at gmx.at

--- Comment #3 from Stefan Dösinger <stefandoesinger at 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.

Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the wine-bugs mailing list