http://bugs.winehq.org/show_bug.cgi?id=58210
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #1 from Paul Gofman gofmanp@gmail.com --- Created attachment 78521 --> http://bugs.winehq.org/attachment.cgi?id=78521 PoC patch
The controls in question are comctl32 buttons (painted by the launcher itself though through WM_DRAWITEM). The main window is not a dialog but just normal "WS_POPUP WS_VISIBLE WS_CLIPSIBLINGS WS_CLIPCHILDREN" window, the buttons are created by the launcher itself. It initially creates those with "WS_CHILD WS_VISIBLE WS_CLIPSIBLINGS WS_TABSTOP 0000000b" and size of 100x100. Then, right after creation, without processing messages / getting WM_PAINT, it does:
InvalidateRect( button, NULL, FALSE); SetWindowPos(button, NULL, -1,-1, (329x46), SWP_NOMOVE | SWP_NOZORDER | SWP_NOREDRAW | SWP_NOACTIVATE);
Then it processes messages and gets WM_PAINT for control (sent as WM_DRAWITEM to parent window by comctl32), and does all the drawing. However, update region in Wine is 100x46 (100 because it is what is left in invalidated rect on the server after InvalidateRect, 46 because that was intersected with window rect during SetWindowPos). SetWindowPos did not extend invalidated region because of SWP_NOREDRAW. So that paints only the leff 100 pixel part of the button (while the text and the rest of its background is left behind). Upon hovering mouse it will do the same InvalidateRect() again and now correctly sized button will be invalidated as full and properly painted upon WM_PAINT processing.
I did some ad-hoc testing on Windows recreating essential parts of this process and dumping BeginPaint box in WM_PAINT, and without InvalidateRect() before resize Wine behaviour matches Windows: the window is not invalidated to the bigger resized part and stays unpainted. However, with the InvalidateRect() before SetWindowPos, there are two WM_PAINT messages and the second one covers the full window.
I've attached the patch mostly for future reference, it needs more testing and maybe a proper fix is more complicated than that (e. g., I don't know so far what is supposed to happen if InvalidateRect has explicit rect specified, what if the full window invalidation with NULL rect has a special meaning here). I am going to get back to properly testing and fixing that later.
The blamed commit is not wrong, the prior changes in 10 cycle without the blamed commit only fixed Bug 38975 only by chance (and maybe that even vary across different window managers / desktop emulation mode, I didn't check). Without the commit x11 Expose event (which is received after the mentioned sequence once the launcher processes messages) does RedrawWindow() invalidating everything and so that button paint has the full button area invalidated. But that RedrawWindow on X11 expose event should not be there (and was already breaking other launchers).