Large covers causing heavy lag on song roulette navigation

[RattleSN4K3]

With covers with the size bigger than 1500x1500 a heavy lag can be noticed while browsing the songs. While keep holding one button (continuous browsing) the lag can be noticed easier. Even medium sized covers are causing some minor lag.

[basisbit]

I completely removed the horribly implemented cover caching from usdx 1.1 / world party. With SDL2 the loading of images is quite fast and the OS Cache also helps a lot to speed up on demand cover loading. The current solutions easily supports 10.000 songs loaded in usdx. The all-cover-textures-uncompressed-in-a-sqlite-file was fast once the game was loaded but takes a long time to genarate and load the caching-textures especially on old hardware. (and don't forget about all the gpu memory leaks the old code had^^) I spent some time on optimizing the new on-demand texture loading - if you have any idea on how to improve that any further, please tell me :smile:

PS: all cover images for songs that I found in the wild are usually 600x600p or smaller and load quite well. On some current hardware with OpenGL hardware acceleration and a SSD harddrive, even 1500x1500p covers load quite fast.

[RattleSN4K3]

Yep, USDX 1.1 (1.0.1, likely some other versions) was bad regarding the cover.db creation. But regarding the smothness of the roulette (where prior versions had more than 5 images visible on screen) the old method is unbeatable (IMO). I've checked both versions using the same content, the old way didn't had the lags which occasionally come up on the new version. This is somehow related to the video previewing and the faster scroll.

Maybe using both methods. Keeping loading HQ images but cache some biggers ones into the DB. Haven't checked if it depends on the image size or dimension but BMP or PNG files can be quite big in its file size. I've also seen JPG images with the dimension of 2500x2500px (6MP and up) and also some rare ones using BMP with 1200x1200px.

Another optimization could be keeping files a bit longer in memory while browsing. Switching back and forth when bigger images are being loading really looks akward (due to these lags, even on faster machines). Additionally to this, there could be a on-demand-caching instead of the initial cache cration back in USDX prior 1.3. Not sure how laggy such conversion can be but for images with 1MP and up, it might be real fast. And you can easily store a low-resolution cover for the current display solution as there is no real advantage having big images being shown for a app resolution of 800x600.

Just some random thoughts :smiley:

[RattleSN4K3]

Just tested another case. Pressing R for a random song rapidly for some time will decrease the FPS to like 1. Even pressing R only every second does make the FPS go down to 0..10. This is tested by having about 80 songs with at least 3 with a bigger image (> 3MP) but not more than 5.

USDX 1.1.0 does stay at steady 100 FPS even pressing R as fast as possible (or holding it which is actually slower).

Gonna check if I can make a video of it in the following days (or less).

[basisbit]

uh, what hardware are you using? Check that your video hardware acceleration is working properly. Also, no need for a video :) I think the proper solution would be to simply load the cover images in background in separate threads and to kill the threads if they didn't finish yet but covers aren't visible any more.

[natrius]

I just noticed that some big videos in the background will create a big lag, when downsizing the video it works again. Guess thats not related? You were just talking about pics but i thought it may be an additional input.

[barbeque-squared]

(just to add, this isn't limited to Roulette only, it happens in any mode. It's also generally more noticeable on png compared to jpg)