SUMMARY Random Wallpaper module causes large delay on login due to needless scanning of wallpaper corpus STEPS TO REPRODUCE 1. Configure wallpaper module for random wallpapers. 2. Point to directory/directories with dozens of thousands to a hundred thousand images 3. Login. OBSERVED RESULT After logging in the default wallpaper will show, sometimes the bottom bar and desktop icons will show, then Plasma freezes. During this time the wallpaper module is scanning the entire corpus of wallpapers. With a small amount of wallpapers, this is not noticeable. With a large set of wallpapers (tens of thousands) this delays completion of login by dozens of seconds to several minutes. On my system I have... grey@morpheus ~/Pictures % ls -1R Wallpapers | wc -l 109582 ...109k images that it is trying to scan through. On an NVME drive this takes the module 2-3 minutes to complete. Once it completes the scan, it picks 2 wallpapers to display (dual monitor, different images per monitor), displays them, and the rest of the desktop resumes operation. I believe the wallpaper module is not just scanning the directories for filenames, but it is opening each file to gather meta-data about the images for whatever purpose. However, none of that is needed. When I was on a standard HDD and this process took 15-20 minutes to complete I set the wallpaper module to static images. I then wrote a simple Python script to scan the directories, pick 2 images, copy those images over the 2 files that were statically picked. This was less than ideal as doing so after the desktop had loaded meant the wallpapers did not change. I would only get one wallpaper rotation per startup. The random module is set to rotate every 2 hours. NOTE: the lag does not appear during normal rotation, only at startup as it scans the directories. The python script was able to complete this task in a fraction of a second: grey@morpheus ~ % time Code/swappapers.py swap both Code/swappapers.py swap both 0.07s user 0.06s system 91% cpu 0.148 total EXPECTED RESULT When a large corpus of wallpapers is configured, the wallpaper module should not lock the entire desktop during its scan. Ideally this scan should not be performed. If it must be performed (which I do not see any use for this scan what-so-ever) then there should be a cache of that data saved so, after an initial scan, it only scans new images. Barring both of those, the rest of the desktop should not be frozen while this module completes this task. SOFTWARE/OS VERSIONS Windows: N/A macOS: N/A (available in the Info Center app, or by running `kinfo` in a terminal window) Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION I initially noticed this in KDE 5.x. But as development on 6.x was underway I held off on reporting the bug on the off chance that it was fixed in the 6.x series.
I forgot to mention that I know this is the random wallpaper module as when I set it to 2 static images, the desktop completes its startup and is responsive in ~1-5 seconds. So short I don't really notice it. I tried to find logging to show how long it is taking with this module scanning those directories but have yet to find one.
Thank you for the bug report! Debian advises users to not submit bugs upstream (https://www.debian.org/Bugs/Reporting), and Plasma 6.3.6 is no longer eligible for support or maintenance from KDE. It's possible that the issue exists only in Debian at this point. Could you report the bug to Debian using the report bug utility (https://packages.debian.org/stable/utils/reportbug)? If necessary, the maintainer of the package will forward the bug upstream. Thanks for understanding! Thanks again!