When one rates an image the UI flickers in the sense that the preview image for the file being rated momentarily disappears before immediately reappearing. The same thing happens when tagging an image. (I have observed this with metadata stored in XMP sidecar files but presume it happens in other modes too.) A similar flicker occurs when one asks digikam to rescan or reprocess a collection (with each image flickering as it is rescanned assuming that image is visible on screen). As a user I find this unnecessarily draws my attention away from what I'm doing (usually rating the next image) and so it would be nice if this could be avoided. For most cases (tagging, rating, and geotagging which should not impact the preview displayed on screen this should be avoidable.
Since the modification date changes, it must be assumed that the image content may have changed as well. Therefore, we delete the image in the cache and initiate a reload, which leads to flickering. You can deactivate the option to update the modification date in the digiKam metadata settings (the modification date then remains the same), then the thumbnail will not flicker. Maik
(In reply to Maik Qualmann from comment #1) > Since the modification date changes, it must be assumed that the image > content may have changed as well. Therefore, we delete the image in the > cache and initiate a reload, which leads to flickering. > You can deactivate the option to update the modification date in the digiKam > metadata settings (the modification date then remains the same), then the > thumbnail will not flicker. > > Maik If the metadata is being written to the file that makes sense. However, when XMP sidecar files are used all that changes is the modification date of the sidecar and not the image file itself. If the view keeps track of the image modification date it can double check this before doing the reload. But, even on a reload of the image does the thumbnail itself have to flicker? Can double buffering not be used here to avoid having the thumbnail ever disappear? So we allocate a new image/pixmap object, draw the thumbnail into it (or otherwise extract it), then swap it out for the current pixmap once everything is ready.
Git commit 8401b4c636cbdeecc1769a67c0f30c0b4731d078 by Maik Qualmann. Committed on 01/09/2024 at 13:02. Pushed by mqualmann into branch 'master'. use buffered thumbnail pixmap cache when items are changed FIXED-IN: 8.5.0 M +14 -4 core/libs/database/models/itemthumbnailmodel.cpp M +24 -2 core/libs/threadimageio/fileio/loadingcache.cpp M +1 -0 core/libs/threadimageio/fileio/loadingcache.h M +32 -0 core/libs/threadimageio/thumb/thumbnailloadthread.cpp M +7 -0 core/libs/threadimageio/thumb/thumbnailloadthread.h https://invent.kde.org/graphics/digikam/-/commit/8401b4c636cbdeecc1769a67c0f30c0b4731d078