SUMMARY Selecting items from Icon or Table view becomes slower when more items are in the view. This appears to be caused by the loop in DigikamApp::slotImageSelected that totals the item sizes. STEPS TO REPRODUCE 1. Open an Icon view with 10000 images 2. Add some images to the selection 3. OBSERVED RESULT Each time the selection changes, the GUI lags or locks up EXPECTED RESULT No lag please SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.17 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.12.16-gentoo (64-bit) Graphics Platform: X11 Processors: 8 × AMD FX(tm)-8320 Eight-Core Processor Memory: 18.6 GiB of RAM Graphics Processor: OLAND ADDITIONAL INFORMATION Seems like this loop should be tied to refresh of the view instead of the selection. Also, if the status bar or properties pane aren't displayed then there isn't a reason to do the calculation.
It's reproducible with last 8.6.0 ?
The cause is more likely which right sidebar you have open. Calculating the file size of the selection isn't really a problem. The Captions sidebar causes a slowdown because it has to query the metadata status in the selection to determine whether different titles, captions, tags, color labels, etc. are present. This takes time, depending on when the search can be canceled based on the assigned metadata. However, we can't change this if we want to maintain functionality. Maik
The problem is calculating the total size of all DISPLAYED items every time the selection is changed. Removing this loop eliminates most of the lag for me: for (const ItemInfo& info : std::as_const(listAll)) { // cppcheck-suppress useStlAlgorithm listAllFileSize += info.fileSize(); } As currently seen at https://invent.kde.org/graphics/digikam/-/blob/master/core/app/main/digikamapp.cpp#L693-697 This loop might have less observable impact if using the baloo code path (I don't have baloo).
The solution to this problem will be to compute the properties of the selection, in a separated thread, and to update the GUI when all is done.
Something similar done with histogram computation from the Color tab.
Calculating the file size doesn't need to be done in a separate thread. The ItemInfo value info.fileSize() is a cached value. I tested it with 50,000 items on my old computer, and there was no delay in selecting. The problem only occurs if the Captions sidebar is currently enabled; in that case, reading the metadata status would have to be done in a separate thread. Maik