tauri: `asset://` protocol does not release the memory properly

webview2 104 was release a couple of days ago and some people reported that the leak was indeed fixed 🥳

Please reach out to us if you still notice leaks even after upgrading to 104 (should have happen automatically)

@nathanbabcock @ksumarine looks like you are facing this issue https://github.com/tauri-apps/tauri/issues/6375 which is already fixed in a PR and waiting for merge

Now…how do we go about making sure the fix is included in our Tauri app?

We unfortunately have to wait for it to be part of the stable channel. Once it is, it should be automatically deployed to all tauri users (both, devs and end-users alike).

@amrbashir that’s fantastic. Thank you!

Yes, that does look like the exact issue we’re facing! Thanks for your work on this @amrbashir.

@ksumarine I did not revisit the streaming example, I reverted back to a localhost server I had set up previously. It’s basically the same thing though. If it helps you as a reference I’ll put it in a gist:

https://gist.github.com/nathanbabcock/c819ff70803c70708687196b4fe658ac

There’s a little more in there than strictly necessary, for security purposes, like restricting the mime type and requiring an access token. If I were starting from scratch today, I would try the streaming example again and use the built-in security settings inside of tauri.conf.json, but this got it working for me at least!

I don’t think this is caused by leaking. Asset protocol will return whole data no matter what headers from requests might have. We have a streaming example showing how to do this in macOS and Windows.

Looks like this has been fixed! See: https://github.com/MicrosoftEdge/WebView2Feedback/issues/2171#issuecomment-1138895187

Now…how do we go about making sure the fix is included in our Tauri app?

FYI someone started looking into the webview2 issue yesterday: https://github.com/MicrosoftEdge/WebView2Feedback/issues/2171#issuecomment-1121332830

That PR was specific to macOS

Thanks for the report @tedbyron I just opened a wry PR to fix that issue.

@aleksey-hoffman Thanks for the quick reply! I’ll see if it can work in our case!

@wusyong on MacOS, Linux you can run the app with –force_high_performance_gpu Chromium flag (not sure if it will work on Tauri)

On Windows, I’m switching to high performance GPU by changing a registry value, like this:

let deviceNumber = 2
let registryPathGpuPrefs = 'HKEY_CURRENT_USER\\Software\\Microsoft\\DirectX\\UserGpuPreferences'
let appBinPath = electron.app.getPath('exe')
let command = `[microsoft.win32.registry]::SetValue(\\"${registryPathGpuPrefs}\\", \\"${appBinPath}\\", \\"GpuPreference=${deviceNumber}\\")`

require('child_process').exec(`powershell -command "${command}"`)

The issue is most likely caused by Webview, and Chromium in particular.

I see the same issue in my Electron file manager app. In my case (and probably yours as well) the issue is caused by Chromium’s GPU process. It usually takes ~200 - 500 MB of RAM to decode a video. Chromium caches the whole video in memory, so even when the source is gone from the drive, the video will keep playing,

The only solution I found for this is to run the app on a dedicated GPU, which offloads decoding and the decoded data to the dedicated GPU’s memory. In my case the RAM usage drops significantly (I didn’t push the feature to Github yet).

I think the problem is on wry’s response (https://github.com/tauri-apps/wry/blob/b300e7ac3da481b12fe5bc6559e06c0f3a0bf794/src/webview/webview2/mod.rs#L431). cc @wusyong @lemarier @amrbashir it’s not directly a webview issue since loading over HTTP doesn’t memory leak, but our custom protocol does.