[Tauri related "bug"] Extremely slow with large music collections on Linux

[eprudspk]

Description

The UI freezes for a few minutes when loading the 'tracks' tab with only 7K songs. It doesn't freeze for as long in the albums and artists tabs, seemingly because there are fewer entries.

Possible solution

I think the tracks list should be in a virtual scroller instead of having everything rendered in the DOM at once. Especially since with Tauri the Linux version runs on the slower Webkit2gtk instead of Webview2 on Windows. Webkit2gtk slows to a crawl when there are a lot of DOM elements.

I've had this exact problem with my web app, and it was fixed using a virtual scroller.

For reference, I used this one: https://tanstack.com/virtual/v3

[tranxuanthang]

I'm hoping I can get some time to work on LRCGET this weekend, and this is one of the problems I'll take a look at. Also thank you for the referenced link!

[eprudspk]

Hey, I just tested on commit 8343ba6

It does greatly improve performance, it no longer freezes at all when loading any tab.

It seems there is no visible scroll bar anymore. However, I can still scroll, and even click where the scroll bar is supposed to be and it will scroll correctly.

Thanks for working on this !

[eprudspk]

It also seems to fix the memory issue I've been having while downloading lyrics.

It was using up to 9 GB (!!!) of ram just to download the lyrics, now it seems to stay at about 254 MB

[tranxuanthang]

Thank you for testing this and some early feedback! I think I have similar setup with you (KDE Plasma 5 on Wayland), but does not face the same scrollbar problem. I'll do some more testing before making a release, but if you can help me debug to see what went wrong about the scrollbar it would be great!

Edit: maybe because your music collection is large, so that the scrollar becomes too small to be visible?

[eprudspk]

KDE Plasma 5 on Wayland

Indeed, that's what I'm running.

maybe because your music collection is large, so that the scrollar becomes too small to be visible?

Don't think that's it, because:

1. the scroll bar was visible before the update
2. if I increase the height of the window, the scroll bar still doesn't show. (I have a vertical 16:9 monitor and tried it with LRCGET fullscreen)

[eprudspk]

I can confirm I have a scroll bar at least up to ed63eda

[eprudspk]

And from 503c842 I no longer have a scroll bar (might be a commit or two earlier, but I can't get them to compile)

[eprudspk]

The plot thickens, I tried setting the GTK style to something other than 'breeze' and it shows the scroll bar correctly… Setting it back to breeze still doesn't show the scroll bar.

I do find it strange, but that means if you override the default theming on the scroll bar, there's a good chance it'll show up.

[tranxuanthang]

I do find it strange, but that means if you override the default theming on the scroll bar, there's a good chance it'll show up.

@eprudspk The library overlayscrollbars-vue could be the reason. I'll create a commit to remove the leftover code of it.

lrcget/src/main.js

Line 2 in 0216c6c

import 'overlayscrollbars/css/OverlayScrollbars.css'

(Or adding it back might also fix it too, but I remember I couldn't get it to work with virtual scroller)

Edit:

The plot thickens, I tried setting the GTK style to something other than 'breeze' and it shows the scroll bar correctly… Setting it back to breeze still doesn't show the scroll bar.

I did not face the same with my Breeze theme. I'm using Arch Linux. What is your Linux distro, and is it possible that it is a bug from old KDE versions?

Edit 2:

Could you test the latest commit?

55a849d

[eprudspk]

Hey, the latest release seems to fix the scroll bar issue.

Thanks for your hard work !

What is your Linux distro, and is it possible that it is a bug from old KDE versions?

It's openSUSE Tumbleweed, it's on Plasma 5.27.10 and KDE Frameworks 5.115.0