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

Paul Gofman gofmanp at gmail.com
Mon Apr 6 07:12:17 CDT 2020


On 4/6/20 14:49, Paul Gofman wrote:
> 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?
>
>
I have updated the test program to illustrate this. With the updated
test programs, the rectangles exposed after moving or deleting obscured
window are now filled with blue on Windows. If I force
flush_window_surfaces() in Wine, the old window bits are restored and
the exposed rectangles stay green.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: expose_redraw_test.c
Type: text/x-csrc
Size: 8673 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200406/6c3f7940/attachment-0001.c>


More information about the wine-devel mailing list