Webview2 runtime performance issues

[lucasfernog]

Describe the bug
The WRY implementation has a few issues regarding the webview2 runtime usage (Windows):

• There's no way to know if an async code finished running, so it uses a hack code that delays app initialization a couple seconds:

  wry/src/webview/win32/mod.rs

  Line 217 in a76206c

  // Wait until webview is actually created

• We've seen some performance issues on the latest webview2 runtime (version 90.0.818.62). A basic tauri application needed 5~ seconds to load a page, and reloads are also affected.

Steps To Reproduce
Clone the WRY or Tauri repo, and run one of the examples.

Expected behavior
The app loads as fast as possible. The loading is excellent on Linux/macOS.

Videos

Videos from @tensor-programming

webview.mp4

lag.mp4

[tensor-programming]

It seems that Microsoft is aware of the speed deficiency with the current evergreen runtime. As far as the other issue is concerned, its a matter of figuring out a method to deal with the async calls and not block the main thread.

[Boscop]

The initial load time is very annoying during development when the backend is restarted often (e.g. with cargo-watch).
I opened an upsteam issue here: MicrosoftEdge/WebView2Feedback#1298

[Beanow]

The multiwindow example is most pronounced here. Comparing vs linux on today's dev branch.

Screencast.2021-05-18.23.36.12.mp4

Screencast.2021-05-18.23.42.06.mp4

[tensor-programming]

lag.mp4

Heres an example of the multiwindow from my side.

[nothingismagick]

tauri-apps/tauri#1850 (comment)

[wusyong]

I just realized #315 actually fixed this issue. Lucas also confirmed that.
If it holds the same after patch version, I think we can close this issue.