[PATCH 0/1] MR3416: ieframe: Forward WM_PAINT messages to the document host and all its child windows.
Windows gives this content special protection from being painted over, by some means that I have not investigated yet. Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416
From: Torge Matthies <tmatthies(a)codeweavers.com> Windows gives this content special protection from being painted over, by some means that I have not investigated yet. Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window. Signed-off-by: Torge Matthies <tmatthies(a)codeweavers.com> --- dlls/ieframe/dochost.c | 8 ++++++++ dlls/ieframe/iexplore.c | 6 ++++++ dlls/ieframe/oleobject.c | 6 ++++++ 3 files changed, 20 insertions(+) diff --git a/dlls/ieframe/dochost.c b/dlls/ieframe/dochost.c index 97b86d481b9..c07d7977c28 100644 --- a/dlls/ieframe/dochost.c +++ b/dlls/ieframe/dochost.c @@ -377,6 +377,14 @@ static LRESULT WINAPI doc_view_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM l switch(msg) { case WM_SIZE: return resize_document(This, LOWORD(lParam), HIWORD(lParam)); + case WM_PAINT: + { + LRESULT ret = DefWindowProcW(hwnd, msg, wParam, lParam); + HWND child = NULL; + while ((child = FindWindowExW(hwnd, child, NULL, NULL))) + RedrawWindow(child, NULL, 0, RDW_INVALIDATE | RDW_ERASE | RDW_ALLCHILDREN); + return ret; + } } return DefWindowProcW(hwnd, msg, wParam, lParam); diff --git a/dlls/ieframe/iexplore.c b/dlls/ieframe/iexplore.c index acf7a18e3f3..2d835defc64 100644 --- a/dlls/ieframe/iexplore.c +++ b/dlls/ieframe/iexplore.c @@ -693,6 +693,12 @@ static LRESULT WINAPI ie_window_proc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM return process_dochost_tasks(&This->doc_host); case WM_UPDATEADDRBAR: return update_addrbar(This, lparam); + case WM_PAINT: + { + LRESULT ret = DefWindowProcW(hwnd, msg, wparam, lparam); + InvalidateRect(This->doc_host.hwnd, NULL, TRUE); + return ret; + } } return DefWindowProcW(hwnd, msg, wparam, lparam); } diff --git a/dlls/ieframe/oleobject.c b/dlls/ieframe/oleobject.c index 742e78ce4e4..ae0a240c378 100644 --- a/dlls/ieframe/oleobject.c +++ b/dlls/ieframe/oleobject.c @@ -89,6 +89,12 @@ static LRESULT WINAPI shell_embedding_proc(HWND hwnd, UINT msg, WPARAM wParam, L case WM_KILLFOCUS: notify_on_focus(This, FALSE); break; + case WM_PAINT: + { + LRESULT ret = DefWindowProcW(hwnd, msg, wParam, lParam); + InvalidateRect(This->doc_host.hwnd, NULL, TRUE); + return ret; + } } return DefWindowProcW(hwnd, msg, wParam, lParam); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/3416
It may be a long shot, but I think that native behavior may be explained by using d3d11 for rendering, see: https://learn.microsoft.com/en-us/troubleshoot/developer/browsers/core-featu... Gecko has similar features, but we disable them because they were never worked well. It's been long since I looked at it so remember details (and Wine D3D changed a lot since then), but the disablement mostly happened in: https://gitlab.winehq.org/wine/wine-gecko/-/blob/master/modules/libpref/init... The attached [patch](/uploads/cff88f1c622acd4103512ec83f56250d/patch.diff) is a quick attempt to force enable it for testing. Unfortunately, it crashes if I attempt to launch iexplore.exe, but it would be interesting to try to get it working and see if it fixes your problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_40335
Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window.
I believe this trivial case should already be handled by the `WM_CLIPCHILDREN` flag of the iexplore frame window and the shell embedding window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_40339
On Wed Jul 26 14:52:43 2023 +0000, Jinoh Kang wrote:
Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window. I believe this trivial case should already be handled by the `WM_CLIPCHILDREN` flag of the iexplore frame window and the shell embedding window. The `WM_CLIPCHILDREN` flag is what caused this problem in the first place. The window having the `WM_CLIPCHILDREN` flag is prevented from drawing over its children, but the parent/ancestor windows of that window are not. However the browser window does not care and is immune to being painted over anyway.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_40340
On Wed Jul 26 14:56:16 2023 +0000, Jacek Caban wrote:
It may be a long shot, but I think that native behavior may be explained by using d3d11 for rendering, see: https://learn.microsoft.com/en-us/troubleshoot/developer/browsers/core-featu... Gecko has similar features, but we disable them because they were never worked well. It's been long since I looked at it so remember details (and Wine D3D changed a lot since then), but the disablement mostly happened in: https://gitlab.winehq.org/wine/wine-gecko/-/blob/master/modules/libpref/init... The attached [patch](/uploads/cff88f1c622acd4103512ec83f56250d/patch.diff) is a quick attempt to force enable it for testing. Unfortunately, it crashes if I attempt to launch iexplore.exe, but it would be interesting to try to get it working and see if it fixes your problem. Thank you! I will try this out later
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_40344
On Wed Jul 26 14:56:15 2023 +0000, Torge Matthies wrote:
Thank you! I will try this out later Hello @jacek, the patch you attached sadly doesn't fix the issue, and I played around with those preferences and didn't get any change in result (setting `layers.acceleration.draw-fps` draws the fps so the prefs are definitely being applied). It doesn't crash on Proton btw.
I also somewhat doubt that getting gecko to render using d3d will change much on Wine compared to the software/GDI path. But I'm open to being proven wrong on this point. In the meantime, while this merge request may not be the ultimate solution, I don't think it's entirely wrong, and I don't think it has much potential for regressions. After all, all the code does is forward some WM_PAINT events to some child windows, of which only the Wine-Gecko component actually draws anything. So I propose that we merge this until there is a better solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_40749
I also somewhat doubt that getting gecko to render using d3d will change much on Wine compared to the software/GDI path.
On Windows, it would imply a separate node in compositor for MSHTML, which then may rely less on WM_PAINT. Anyway, it'd be far off for Wine. One more possible experiment is to see if the bug happens on Windows with disabled acceleration.
After all, all the code does is forward some WM_PAINT events to some child windows, of which only the Wine-Gecko component actually draws anything.
While ieframe is usually used for embedding MSHTML, it may be used for any other OLE document in theory. You can't just assume it will be Gecko. There are some special cases in ieframe for MSHTML, but building on that does not seem great. There are also various OLE interfaces that ieframe uses to notify documents about actions. Maybe we miss something there? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_40900
On Tue Aug 1 10:08:48 2023 +0000, Jacek Caban wrote:
I also somewhat doubt that getting gecko to render using d3d will change much on Wine compared to the software/GDI path. On Windows, it would imply a separate node in compositor for MSHTML, which then may rely less on WM_PAINT. Anyway, it'd be far off for Wine. One more possible experiment is to see if the bug happens on Windows with disabled acceleration. After all, all the code does is forward some WM_PAINT events to some child windows, of which only the Wine-Gecko component actually draws anything. While ieframe is usually used for embedding MSHTML, it may be used for any other OLE document in theory. You can't just assume it will be Gecko. There are some special cases in ieframe for MSHTML, but building on that does not seem great. There are also various OLE interfaces that ieframe uses to notify documents about actions. Maybe we miss something there? I will need to find those OLE interfaces, but that still sounds like it would be a hack since on Windows it probably really just uses hardware accelerated rendering that is protected from being drawn over.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_44157
On Mon Sep 4 10:24:34 2023 +0000, Torge Matthies wrote:
I will need to find those OLE interfaces, but that still sounds like it would be a hack since on Windows it probably really just uses hardware accelerated rendering that is protected from being drawn over. I could not find a relevant interface that contains a Redraw/Invalidate/Repaint/Paint/Draw function in the .idl files.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3416#note_47991
participants (4)
-
Jacek Caban (＠jacek) -
Jinoh Kang (＠iamahuman)
-
Torge Matthies
-
Torge Matthies (＠tmatthies)