[PATCH] winex11.drv: Redraw window on Expose event if window surface has no region set.

Paul Gofman gofmanp at gmail.com
Mon Apr 6 06:49:02 CDT 2020


On 4/6/20 13:23, Alexandre Julliard wrote:
> Paul Gofman <gofmanp at gmail.com> writes:
>
>> Otherwise the window (partially) obscured by the other window sometimes fails
>> to update when the obscuring window is moved or destroyed.
> That's not correct, there shouldn't be any reason to repaint the entire
> window when the contents are still valid.
>
> Note that not flushing the bits right away is deliberate, that's a
> performance fix. The window will get repainted when the app waits for a
> new message.
>
> If you have a real app where this is an issue, the heuristic could maybe
> be tweaked to catch that case, cf. check_for_driver_events in
> dlls/user32/message.c.
>
I was trying to fix menu glitches in Diablo 1. This particular patch was
fixing leftover menu elements (left from previous menu when navigating).
The application destroys child window and expects the parent to receive
WM_PAINT with appropriate rectangle in PAINTSTRUCT. Tweaking
check_for_driver_events() (or otherwise enforcing extra
flush_window_surfaces()) helps drawing in my test I attached previously,
but not the game. Test program (and the game) still does not receive
WM_PAINT event for (partially obscured) parent window. I suppose it
fixes the drawing in my test program because the bits of parent window
gets restored from x11 image in x11drv_surface_flush(). But Diablo 1
does not draw on GDI surfaces. It uses user32 window management
infrastructure and reacts on the window events, but all the actual
drawing goes into ddraw primary surface in exclusive fullscreen mode.
And it depends on receiving the WM_PAINT event the same way as on
Windows to do the necessary updates. I should note that ddraw primary
surface drawing currently does not work correctly as the fullscreen
window gets obscured by the other windows. I use some WIP workarounds to
make exclusive fullscreen mode to work.

So should I maybe think of how to introduce WM_PAINT generation from
within check_for_driver_events()? Or leave this for now since exclusive
fullscreen mode does not work right anyway at the moment and this is
actually a bigger problem?





More information about the wine-devel mailing list