webview slowing down the GUI

steve64

I'm facing a use case where using a webview inside my app slows down the refresh of other widgets.
If I set web.visible to false, then the refresh come back to normal speed.
It seems that a visible Webview triggers some kind of additional background task, what's your opinion?

Note: I just found a workaround, setting web.visible = true or false BEFORE changing the visibility state of other widgets apparently solves the issue

Samir

I will check this. Any code to share that reproduces the issue ?

steve64

too complicated, sorry; by the way, I placed the webview inside a Tab, maybe this has an impact on the visibility of the webview contents when I switch to the web tab from another tab; the page seems loaded and the visible is true but sometimes a white page is shown;

note: a new workaround: in the tab onSelect() event handler I put for each tab item case:

web.visible = false
... update other widgets ...
web.visible = true

with this trick the refresh looks fine

Samir

I cannot reproduce this bug even with tab items.
Maybe it's related to the HTML/JS content of the Webview ?

What kind of widgets are on the same tab as the Webview ?

steve64

There are no other widgets in the same tab.
The HTML page is static with no JS.
I'm not sure it's an issue of the Tab usage.
It seems that, since the slight slowdown is due to webview reinitialization or page loading mixed with UI update. This happens only if the webview .visible is currently set to true.

steve64

Anyway, there's something strange with the webview.
During the phase in which it is hidden (created, loaded from a URL and becoming ready) it seems slowing down other stuff. When you show it for the first time, something changes and the app speed goes back to normal.

Samir

Yes Webview init is quite slow (hence the onReady() event) and not dependent on LuaRT but on Microsoft implementation.

By the way LuaRT Webview2 initialization is one of the fastest out there even compared with C# or WinRT

steve64

Ok, but I wait for onReady event and even later the UI main loop seems slower.
For the time being I had to replace HTML with RTF in the Edit widget, quite fine for static documentation but the webview strange behavior would need more investigation for other use cases. I will try to test it with a separate top window.

Samir

steve64

Use ui.run(win);wait(), it should be more smooth

Samir

Yes I will investigate it

steve64

But I have to call a custom function inside the UI event loop to simulate a periodic task.
How can I do this with your proposal above?

Samir

just use the async() function before ui.run(win):wait()

function periodic_task()
...
end

async(periodic_task)

ui.run(win):wait()

Tell me if the ui is still slow with this approach

steve64

It works but it is still slow as before...
Actually I have found a new workaround. I just quickly switch the tab items one time at app launch time:

    tab:onSelect(tab.items[3]) -- switch to tab item with webview
    tab:onSelect(tab.items[1]) -- switch back to initial tab item

If the webview is visited once, it seems that then the slowdown effect disappear forever...
I hope this can help you to understand if there are issues behind.

Samir

Can you give me some code that reproduces this ? Does it occurs with the provided Webview examples ?

Samir

Did you try hiding the Webview at start ?
If so it will effectively slow down webview init as Webview2 component expects to be visible to ends its initialization

Samir

Try this test, it works fine on my side without any slowdown :

local ui = require "ui"
require "webview"

local win = ui.Window("Webiew test")

local tab = ui.Tab(win, {"Tab1", "Tab2", "Tab3"})
tab.align = "all"

for i=1,3 do
    local wv = ui.Webview(tab.items[i], { url = "https://large-type.com/#*Webview"..i.."*" })
    wv.align = "all"
    wv.onReady = function (self) print("Webview"..i.." is now ready !") end
end

ui.run(win):wait()

steve64

Your test works file. Thanks.
I think the issue shows up with more complex GUIs.

It's really difficult to debug but for sure is something related to the webview.
Replacing it with an Edit widget and RTF works perfectly in the same LuaRT application.
It also does not depend on the URL used on the test.

It seems that, even after the HTML page is loaded and visible, some strange background task caused by webview initialization still slows down the LuaRT event loop.
Is this maybe related to this sentence fromMS docs: "The WebView2 control is based on the Component Object Model (COM) and must run on a Single Threaded Apartments (STA) thread." ?
I'm not saying it is related to LuaRT-side...it could originated on MS side...but still is an issue in using the webview widget in a general scenario.

steve64

I made another experiment that confirms my idea. I created a second independent top-level window just hosting a webview.
When the second window is visible, the main windows still slows down but LESS that with the single windows initial scenario.
Moreover,if I minimize the second window, the speed is back to normal...
So there must be some thread working only inside the webview and only when it is visible....
Using the Task Manager I discovered that it is the "Webview2 GPU Process"
I read later that seems to be quite a common problem.
If so, it is a big limitation in using embedded webviews based on WebView2. I need full performance for the rest of my app...
Am I missing something?

Samir

I think about a MS Webview2 issue too....
Do you use Webview:hostfromfolder() in your app ? It is also known to slowdown DNS resolution from the Webview 2

Samir

Some users have reported issues with NVidia drivers, TeamViewer or Zoom apps...