Robert Shearman rob@codeweavers.com writes:
Previously, using ddraw to write to a small area of the desktop (or even none at all) would cause the screen to go black because the contents of the screen wasn't copied to the surface before the surface was copied back to the screen. This patch fixes that.
Of course it's still corrupting the screen, it's just less obvious...
Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
Previously, using ddraw to write to a small area of the desktop (or even none at all) would cause the screen to go black because the contents of the screen wasn't copied to the surface before the surface was copied back to the screen. This patch fixes that.
Of course it's still corrupting the screen, it's just less obvious...
I'm pretty sure Windows NT doesn't allow you to have direct access to the video memory so surely Windows must be doing it like this too? How do you suggest to fix the problem?
On Wed, Jul 27, 2005 at 04:33:29PM +0100, Robert Shearman wrote:
I'm pretty sure Windows NT doesn't allow you to have direct access to the video memory so surely Windows must be doing it like this too? How do you suggest to fix the problem?
The only way I could think of would be to lock the X display between the call to the lock to the time of the unlock (a bit what WMs like FVMW do when a window is resized).
Lionel
Robert Shearman rob@codeweavers.com writes:
I'm pretty sure Windows NT doesn't allow you to have direct access to the video memory so surely Windows must be doing it like this too? How do you suggest to fix the problem?
Windows will certainly let you access the video memory, but since we can't do that I'm afraid there is no good solution. We could grab the server but that probably causes more problems than it solves.
Maybe we should simply not try to update the root window when no clip list is set, since it can't work right anyway. Apps that really need that feature could always be run in desktop mode.