fix: re-loading stale multi-frame images

4b67816 only partially fixed this issue. because imlib2's cache may not
have sub-second granularity, there still exists a time-frame while the
`mtime` has not yet been updated but we might be trying to reload the
image due to receiving an inotify event in which case imlib2 will end up
giving us the old frame.

imlib2 v1.12.0 adds a function that allows us to decache any frames
associated with a filename. this allows us to invalidate the cache
manually instead of relying on `mtime`.

but if that's not available due to older imlib2, then forcefully reload
the raw frames and decache them. this has the unfortunate cost that if
`mtime` *was* updated properly then we'll end up loading that image
twice.

fixes: https://codeberg.org/nsxiv/nsxiv/issues/456
pull/476/head
NRK 11 months ago
parent 53a43cb388
commit 80a71315de

@ -637,6 +637,22 @@ CLEANUP void img_close(img_t *img, bool decache)
if (img->multi.cnt > 0) {
for (i = 0; i < img->multi.cnt; i++)
img_free(img->multi.frames[i].im, decache);
/* NOTE: the above only decaches the "composed frames",
* and not the "raw frame" that's associated with the file.
* which leads to issues like: https://codeberg.org/nsxiv/nsxiv/issues/456
*/
#if HAVE_IMLIB2_MULTI_FRAME
#if IMLIB2_VERSION >= IMLIB2_VERSION_(1, 12, 0)
if (decache)
imlib_image_decache_file(files[fileidx].path);
#else /* UPGRADE: Imlib2 v1.12.0: remove this hack */
/* HACK: try to reload all the frames and forcefully decache them
* if imlib_image_decache_file() isn't available.
*/
for (i = 0; decache && i < img->multi.cnt; i++)
img_free(imlib_load_image_frame(files[fileidx].path, i + 1), true);
#endif
#endif
img->multi.cnt = 0;
img->im = NULL;
} else if (img->im != NULL) {

Loading…
Cancel
Save