Dear gwenview authors / maintainers, SUMMARY Memory consumption of gwenview seems to be quite high on folders with many pictures. It also seems that when I move to another directory, the memory of the previously opened folder is not (enough) released. When navigating though my photo archive for instance trying to find something quickly, this causes severe swapping out of other programs running on my computer (having 12GB RAM in total) and eventually when I have scrolled through a few directories, this results in OOM / system lockup. STEPS TO REPRODUCE When opening Gwenview to view images in quite a large directory, for instance this folder containing jpeg photos: ~/Camera2020$ du -hs 11G . ~/Camera2020$ ls | wc -l 2375 the memory consumption immediately is quite high, at least 2GB RES. When I click on one picture to enlarge it and start swiping though the directory, the RES usage quickly grows to 4,1GB. When I move to another directory, for instance Camera2021, also containing 10GB of jpeg photos, and I do the same, the RES memory consumption quickly rises to over 5GB. This increases further when continuing opening other directories. OBSERVED RESULT Increasingly high memory consumption EXPECTED RESULT Memory consumption at least drops when navigating away from folder SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 20.04 (available in About System) KDE Plasma Version: plasma-desktop: 5.18.5-0ubuntu0.1 KDE Frameworks Version: 5.68.0-0ubuntu1 Qt Version: 5.12.8 ADDITIONAL INFORMATION I've also tried recent versions of Gwenview from Flatpak and Snap, but I've seen same behaviour. I will try the steps on newer versions tomorrow.
I confirm this bug in OpenSuSE 15.2 using version 20.04.2 of Gwenview. When using Gwenview of a folder containing a large number of images, I can use KSysGuard or top/htop to monitor memory usage by Gwenview. Even when not changing images shown by Gwenview there is a memory leak going on, and I do not observe any memory being returned to the free list. Eventually the system responses slows down until the system is no longer usable and locks up. Only remedy is to perform a hard reset/reboot. I have also noticed that if I can close Gwenview before the system locks up, that after Gwenview closes the system responses to interactions with the desktop remain sluggish. If this has been fixed in a later version of Gwenview, please report what version has the fix before closing this bug report.
This issue is also reproducible for me with the latest Gwenview version as of today (sources). When opening a folder with around 50.000 images, it will take around 4 minutes for Gwenview to raise the memory consumption from 2/32Gb to 32/32Gb and eventually freeze my entire system (including all dedicated swap as well).
This was reproduced on an up-to-date Arch Linux with the latest Gwenview sources as of 09-Jan-23.