[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 Maik Qualmann changed: What|Removed |Added Status|REPORTED|RESOLVED Version Fixed In||8.0.0 Resolution|--- |FIXED Latest Commit||https://invent.kde.org/grap ||hics/digikam/commit/20602a0 ||74e1c14095e20c1323329be2049 ||c6c13d --- Comment #12 from Maik Qualmann --- 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-1NEWS M +14 -4core/libs/threadimageio/preview/previewtask.cpp https://invent.kde.org/graphics/digikam/commit/20602a074e1c14095e20c1323329be2049c6c13d -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #11 from Maik Qualmann --- 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 -7core/app/views/preview/itempreviewview.cpp https://invent.kde.org/graphics/digikam/commit/41efc2706c3770687e8773c1b713c19b3c57cecb -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #10 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #9 from Philipp Keck --- Created attachment 140166 --> https://bugs.kde.org/attachment.cgi?id=140166&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #8 from Philipp Keck --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #7 from [email protected] --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #6 from Philipp Keck --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #5 from Philipp Keck --- FTR, this reproduces with 6.4.0 under Mint. I'll try 7.3.0 next. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #4 from [email protected] --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 [email protected] changed: What|Removed |Added CC||[email protected] --- Comment #3 from [email protected] --- There is already a preview image cache mechanism in digiKam core. Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 --- Comment #2 from Maik Qualmann --- 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-2core/libs/threadimageio/fileio/loadingcache.cpp https://invent.kde.org/graphics/digikam/commit/5eb72429c888eb1dfce676269064e709a1008ec7 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 435377] Speed up image preview
https://bugs.kde.org/show_bug.cgi?id=435377 Maik Qualmann changed: What|Removed |Added CC||[email protected] --- Comment #1 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
