Bug 435377

I cannot reproduce the problem here, I can easily switch between 2 images without delay. My computer only has a dual core CPU. digiKam has a cache for preview images and also loads images in advance. The cache has a maximum of 200 MB, which may not be enough for extremely large images.

Maik

Git commit 5eb72429c888eb1dfce676269064e709a1008ec7 by Maik Qualmann.
Committed on 05/04/2021 at 10:36.
Pushed by mqualmann into branch 'master'.

allow up to 400MB preview cache

M  +2    -2    core/libs/threadimageio/fileio/loadingcache.cpp

https://invent.kde.org/graphics/digikam/commit/5eb72429c888eb1dfce676269064e709a1008ec7

There is already a preview image cache mechanism in digiKam core.

Gilles Caulier

Phillipp,

Can you double check if the problem remain with the digiKam 7.3.0 daily pre-release bundles published here:

https://files.kde.org/digikam/

Gilles Caulier

FTR, this reproduces with 6.4.0 under Mint. I'll try 7.3.0 next.

7.3.0 isn't faster under Windows either.

Now that I had the direct comparison, I noticed that it is faster under Mint. I recorded it with a screencasting tool on both OSes. On Mint, around 150ms pass between pressing the key (specifically, the keypress being visualized by a tool like Screenkeys) and the new image being rendered. On Windows it's around 300ms (which aligns with my original ~500ms estimate). Both OSes use the same SSD.

150ms isn't super bad, but I can still hit the arrow key much more frequently than that (roughly every 80ms), and also with Picasa I could "see" the images flying by at that speed, so ideally the images would render in <50ms or even <10ms, which would allow me to stop at the right image while moving fast, i.e. not overshooting. Also it just makes for a much smoother user experience overall, if the delay isn't noticeable.

Phillip,

Check well the Setup/Views/Preview dialog page and look the preview settings:

"Previews shows embedded preview if available (faster)"

In the same page, for Raw file enable also the option to use 8 bits color depth. It's faster. 

Gilles Caulier

Thanks. Those preview settings were already set the way you suggest. FWIW, flipping them the other way doesn't help either. And FTR my images are JPG, so the RAW settings shouldn't matter.

Created attachment 140166 [details]
DigiKam extra log statements when displaying an already-cached image preview

I've inserted some log statements. When measuring the delay very approximately (with my eyes), I think it's around 300ms. The log messages (see attachment) account for 200ms, which I think is a good start.

70ms are lost between calling ItemViewCategorized::setCurrentIndex() (which is in between the ItemViewCategorized::toIndex() log statements) and when DImgPreviewItem::setPath() is hit with the new path. I haven't figured out how exactly this call works -- maybe there's just a whole lot of (non-essential) statements on the way that consume this time, or maybe it uses some kind of event mechanism that takes a while for the UI thread to get around to doing the work.

Another 100ms are lost on painting, specifically the scaling in GraphicsDImgItem::paint(): https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/widgets/graphicsview/graphicsdimgitem.cpp#L260-270
While there's a cache (elsewhere) for file previews read from disk and there's a cache for resized images (cachedPixmaps), the latter is cleared when switching to another image (because it's not keyed by the filepath and presumably only serves to make zooming/panning faster). So when switching back and forth between images that are already (pre)loaded, there's no cache and the scaling has to happen every time.

I think extending that cache to retain previously painted pixmaps of other images/files isn't enough, as when moving forward through an album, all images are rendered only once. So much like the image preloading, the scaling would have to happen before the image is rendered for the first time. That might be hard to do in practice, as it requires knowing the rendering details like size/coordinates from GraphicsDImgItem::paint().

So while I'm convinced and can measure that this delay is real, and Picasa was certainly much faster in this regard (no noticeable delay), there doesn't seem to be any low-hanging fruit wrt. optimizing this.

I'll definitely have a look at it in the future, but I don't find digiKam to be slow, at least not here under Linux - on the contrary - I don't want to name any names - but I find other image viewers slower. My computer is still just a double core. I only know Picasa in the VM and don't find it any faster than digiKam.

If I switch between 2 images under Linux that are already in the cache, I don't see any delay, 300ms would be extreme ... 

Maik

Git commit 41efc2706c3770687e8773c1b713c19b3c57cecb by Maik Qualmann.
Committed on 31/01/2022 at 18:07.
Pushed by mqualmann into branch 'master'.

load faces and focus point only if enabled
It takes time if change images quickly when the focus point
is loaded every time, even if the focus display is deactivated.

M  +57   -7    core/app/views/preview/itempreviewview.cpp

https://invent.kde.org/graphics/digikam/commit/41efc2706c3770687e8773c1b713c19b3c57cecb

Git commit 20602a074e1c14095e20c1323329be2049c6c13d by Maik Qualmann.
Committed on 05/06/2022 at 20:12.
Pushed by mqualmann into branch 'master'.

store color converted preview image to cache
Depending on the color profile, the conversion can take a long time.
FIXED-IN: 8.0.0

M  +2    -1    NEWS
M  +14   -4    core/libs/threadimageio/preview/previewtask.cpp

https://invent.kde.org/graphics/digikam/commit/20602a074e1c14095e20c1323329be2049c6c13d