Paul Gofman gofmanp@gmail.com writes:
On 4/6/20 13:23, Alexandre Julliard wrote:
Paul Gofman gofmanp@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?
If it's not painting to the window surface, then user32 should have been told that. Then the surface won't be used, and expose events will generate WM_PAINT messages.