Resizing without window menu causes visual bugs

[metkm]

Using WebView2 without the default window menu causes visual bugs. Adding the window menu drastically increases resize performance and reduces visual bugs.

I've used WebView2 with Tauri wry package https://github.com/tauri-apps/wry but I think this happens with every package that uses WebView under the hood. To make things easier here is a small video.

With Menu

2022-08-24.17-15-41.mp4

Without Menu

2022-08-24.17-16-25.mp4

[nishitha-burman]

Hello,

Thank you for reaching out! How are you creating the menu?

[metkm]

@nishitha-burman Hey, Thanks for answering.

It's just a normal menu that is created using windows API (tao is what they are using to handle windows under the hood).
window.rs This is how they create the window.
menu.rs and here how they create the menu.

I also made a repository here in case you might want to try it. https://github.com/sibyl666/resize-visual-bug.
I remove the menu after a while to show how much difference there is.

[johna-ms]

I'm unable to repro this with a Win32 C++ app, or at least the performance difference is not as pronounced. Moreover I'm not seeing any resize logic in your sample code which I'm taking to mean WRY takes care of this under the covers? Please correct me if I'm wrong. If I'm right, I'm thinking this is an issue with the WRY.

Btw in the example you posted, are the captions supposed to be reversed? Looks like the video 'with menu' has better perf but you said the perf improvement comes without menu.

[metkm]

@johna-ms actually yeah captions should be reversed. Sorry about that English is not my native language.

@amrbashir I was wondering if you can help with this issue. You were saying issue is with webview itself.

[metkm]

It looks like here is where wry tells Webview2 to resize. But I couldn't see anything different that would cause a performance difference. Also, this "bug" happens with clean HTML too, so this is not something that has to do with the webpage probably.

[amrbashir]

The resizing is done using ICoreWebView2Controller::put_Bounds in reaction to the win32 WM_SIZE message using the window client rect.

@Sibyl666 could you try these samples below and see if you can observe the same behavior? I made them using the getting started win32 sample.

The one with menu just has this addition

--- a/GettingStartedGuides/Win32_GettingStarted/HelloWebView.cpp
+++ b/GettingStartedGuides/Win32_GettingStarted/HelloWebView.cpp
@@ -99,6 +99,10 @@ int CALLBACK WinMain(
                return 1;
        }

+       auto menu = CreateMenu();
+       AppendMenuW(menu, MF_STRING, 0, L"Hello World");
+       SetMenu(hWnd, menu);
+
        // The parameters to ShowWindow explained:
        // hWnd: the value returned from CreateWindow
        // nCmdShow: the fourth parameter from WinMain

No-Menu.zip
With-Menu.zip

[metkm]

It looks like there isn't that much of difference. @amrbashir

Without Menu

without.menu.mp4

With Menu

withmenu.mp4

[amrbashir]

is it worse or the same as or better than tauri without menu?

[metkm]

@amrbashir It looks pretty much the same to me. But I still don't understand how adding a menu works way better than without a menu when using Tauri.

[amrbashir]

Idk tbh, and if without menu feels the same to you for tauri without menu, I wouldn't consider this as a bug in tauri and I wouldn't waste my time trying to figure out why it feels better with tauri and menu.

[johna-ms]

FWIW, I think Tauri without menu looks the best of all 4 examples. Tauri with menu and Win32 with and without menu look about the same to me. So if anything it feels like there may be an optimization happening with Tauri that's maybe unapplicable when adding menu?

Unsure what could be going on here either, but the way Tauri updates size using put_Bounds on WM_SIZE is consistent with our getting started guide so theoretically there shouldn't be any difference. I'm closing this issue for now. If this needs more attention please reactivate.

[metkm]

@johna-ms Hey, In the last issue I mentioned we found a weird way to hack around this performance issue of resizing. Just sleeping the thread for even a nanosecond increases the performance drastically. I'd like to know if there is something you can do about this.

My Webview 2 version: 110.0.1587.50. I had the same problem on older versions, 108 and 109

For example, I tested this code from another Microsoft employee using windows APIs to use webview 2.
sample.rs Here, sleeping the thread is enough to increase the resize performance.

I posted some videos for everyone to see the performance difference in this issue
tauri-apps/tauri#6322 (comment) and tauri-apps/tauri#6322 (comment)

WindowsAndMessaging::WM_SIZE => {
    let size = get_window_size(hwnd);
    std::thread::sleep(std::time::Duration::from_nanos(1));
    unsafe {
        webview
            .controller
            .0
            .SetBounds(RECT {
                left: 0,
                top: 0,
                right: size.cx,
                bottom: size.cy,
            })
            .unwrap();
    }
    *frame.size.lock().expect("lock size") = size;
    LRESULT::default()
}

[metkm]

@nishitha-burman can we reactive this again?

[Legend-Master]

I'm having this problem even with the official example

video.mp4

https://github.com/MicrosoftEdge/WebView2Samples/tree/main/GettingStartedGuides/Win32_GettingStarted

Also I don't know if it's related, seems like WinUI3 has a similar problem microsoft/microsoft-ui-xaml#5148