https://bugs.winehq.org/show_bug.cgi?id=57665
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #77841|0 |1 is obsolete| |
--- Comment #4 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77895 --> https://bugs.winehq.org/attachment.cgi?id=77895 Better fix
This might be a better fix for it, hopefully it won't reintroduce the other bug.
The issue is that The Medium launcher uses a dialog window procedure, and implements its background by doing a StretchBlt call on WM_PAINT in the dialog procedure call, which happens before the window message loop.
It then itself calls InvalidateRect(hwnd, NULL, 0), which queues a WM_PAINT as well but with only the RDW_INVALIDATE flag.
Next, when the window message loop is executed, the WM_PAINT message is being processed as it should, but as we've invalidate the window with RDW_ERASE ourselves from the expose event, the WM_NCPAINT handler erases the entire window, clearing the pixels that the launcher has just painted.
Using RDW_ERASENOW we make sure that the erase happens right away on expose, and before the WM_PAINT message is being processed.