| Summary: | Selecting items is slow and laggy | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Ken Rushia <ken> |
| Component: | Albums-IconView | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 8.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Ken Rushia
2025-03-20 01:50:46 UTC
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 Revisiting this again. This has absolutely nothing to do with the right sidebar. According to perf, most time is spent in Digikam::ItemInfoCache::getImageGroupedCount How do you know that ItemInfoCache::getImageGroupedCount is a problem? Yes, this function is called very frequently, which is why it's needed when drawing/redrawing items. But the database access only occurs once, when the view is loaded; after that, the result is read from a memory cache. This has absolutely no impact on execution speed. Maik I'm not experiencing any latency when selecting multiples of 10,000 items. Are you using Wayland? Maik I use X11. I ungrouped all images (about 120,000 raw+jpgs) and there is no lag anymore. There is clearly a performance problem that worsens at the rate of number of items in the view multiplied by number of rows in imagerelations table. 1. There seems to be a signal/slot that is causing info cache to be invalidated on selection (not sure which) 2. ItemInfo::hasGroupedImages() is not optimized for its task (it runs getImageGroupedCount(), which ultimately has to iterate over the entire imagerelations table. Even if cache hasn't been invalidated, this is silly. https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/item/containers/iteminfo_groups.cpp#L23-26 https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/item/containers/iteminfocache.cpp#L71 I debugged it again; while selecting items, there is no database query of the relation table; everything comes from the cache. The cache is only rebuilt when the album is loaded or items are grouped. If there is an invalidate signal, you have some other database problem. Please create a debug log of the process, as described here for Linux: https://www.digikam.org/contribute/#linux-host Maik Ken, Do you seen the last Maik comment ? Gilles Caulier |