tauri-apps / tauri

Build smaller, faster, and more secure desktop applications with a web frontend.
https://tauri.app
Apache License 2.0
81.61k stars 2.44k forks source link

[bug] Really high memory usage while resizing a window in Linux (V1 and V2) #10102

Open TypicalAuthor opened 2 months ago

TypicalAuthor commented 2 months ago

Describe the bug

In both Tauri V1 and V2, if you resize the app constantly, memory usage will go up really fast, and it wont really go down unless you close the app and wait for the process to end.

Also I found that sometimes while resizing, the app will randomly just stop resizing, even if you try again, its just after a few seconds that the app will let you resize it again, but after that resizing becomes really slow/laggy

While I was testing in V1, memory usage went up to +95%, my whole system became so unstable that I had to perform an emergency restart On V2 it takes a bit longer to see the memory usage go up like in V1, but it eventually does.

In both V1 and V2 memory usage goes down when you stop resizing, but really slowly, leaving the system borderline unusable for a while.

This is not a behavior I see in other web-based apps (in discord memory usage goes up a bit, but also down constantly)

My system: Ryzen 5 3400G 16 GB RAM (only 14GB is usable by the system) Arch Linux + KDE 6.1 (Wayland) I dont know is this is important, but I also have a dual monitor setup Also, I only tested this in Debug builds.

Reproduction

Run npm run tauri dev on any V1 or V2 and resize the window constantly

Expected behavior

No response

Full tauri info output

> wavewolf@0.0.0 tauri
> tauri info

[⚠] Environment
    - OS: Arch Linux Rolling Release X64
    ✔ webkit2gtk-4.0: 2.44.2
    ✔ rsvg2: 2.58.1
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10) (Arch Linux rust 1:1.79.0-1)
    ✔ cargo: 1.79.0
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 22.3.0
    - npm: 10.8.1

[-] Packages
    - tauri [RUST]: 1.6.8
    - tauri-build [RUST]: 1.5.2
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - @tauri-apps/api [NPM]: 1.5.6
    - @tauri-apps/cli [NPM]: 1.5.14

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../build
    - devPath: http://localhost:1420/
    - framework: Svelte
    - bundler: Vite

Stack trace

No response

Additional context

In the attached video you can see how simply resizing an app makes the system ram usage go up, and also the whole system becomes really laggy, and it doesnt stop until I close the app. The image is for the same test but on a V2 app, the same thing happens.

https://github.com/tauri-apps/tauri/assets/66720930/2eb979b6-1a2b-4257-b15f-05b1224a221d

Screenshot_20240622_172304

FelisDiligens commented 1 month ago

I think I ran into the same (or similar) issue. For me, when running npm run tauri dev inside the built-in VSCodium terminal, resizing the webview window increases RAM usage of the app. But if I run the command in GNOME Terminal instead, the window resizes normally and it doesn't lag at all. (I'm using Fedora Workstation 40 on GNOME 46 Wayland)

@TypicalAuthor, have you tried running npm run tauri dev in Konsole instead of in the built-in VSCode terminal?

TypicalAuthor commented 1 month ago

Oh wow you're right! If I run the app trough konsole everything works fine,but as soon as I launch the app trough the built-in console in vsc memory usage goes trough the roof Here is a video of the same app launched in debug mode trough konsole

https://github.com/user-attachments/assets/147b5869-1963-4d35-8c2f-0724e4a8d6d0

Really weird behavior, never thought vsc terminal would be the cause (btw I want to add that I recently reinstalled my arch system, but like I said the bug persisted when launched trough the vsc terminal) EDIT: going trough my vsc config it seems that it uses xterm for the built in terminal, so I switched from wayland to xorg for a bit to test it but the same issue happens again.