https://bugs.kde.org/show_bug.cgi?id=492148
--- Comment #2 from Freddie Witherden <fred...@witherden.org> --- (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. -- You are receiving this mail because: You are watching all bug changes.
