https://bugs.kde.org/show_bug.cgi?id=435377
--- Comment #9 from Philipp Keck <philipp.k...@gmail.com> --- 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.
