https://bugs.winehq.org/show_bug.cgi?id=57665
Bug ID: 57665 Summary: The Medium game launcher has no background image Product: Wine Version: 10.0-rc3 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs@winehq.org Reporter: andrey.goosev@gmail.com CC: rbernon@codeweavers.com Regression SHA1: 51b16963f6e0e8df43118deac63f640aee4698b7 Distribution: ---
Created attachment 77837 --> https://bugs.winehq.org/attachment.cgi?id=77837 before and after
As the title says.
https://bugs.winehq.org/show_bug.cgi?id=57665
--- Comment #1 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77841 --> https://bugs.winehq.org/attachment.cgi?id=77841 Fix
Thanks for the report, this should fix the issue.
The blamed change created the regression because it initializes the window surface clipping region to a rect region matching the visible rect when it was left empty before.
With an empty clipping region, when the window is being shown, the Expose event we receive is ignored by `expose_window_surface`, assuming there's no redraw necessary.
If a clipping region is set, we call NtUserRedrawWindow with RDW_ERASE which clears the window. Somehow this application doesn't redraw its window background in that case.
https://bugs.winehq.org/show_bug.cgi?id=57665
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Rémi Bernon from comment #1)
Created attachment 77841 [details] Fix
Thanks for the report, this should fix the issue.
I'd like to note that the patch reintroduces bug #38975 for me.
https://bugs.winehq.org/show_bug.cgi?id=57665
--- Comment #3 from Rémi Bernon rbernon@codeweavers.com --- Thanks for the notice. Another option for The Medium seems to be to avoid sending RDW_ERASE on expose events but I believe this causes the virtual desktop to stop refreshing its background when windows are being moved, so it's not correct either.
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.
https://bugs.winehq.org/show_bug.cgi?id=57665
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Rémi Bernon from comment #4)
Created attachment 77895 [details] Better fix
This might be a better fix for it, hopefully it won't reintroduce the other bug.
The patch works for the Alpha Protocol launcher, thank you.