Caching+deletion issue in Viewer

Bugs found in XnView Classic. Please report only one bug per topic!

Moderators: XnTriq, xnview

Post Reply
Mixer
Posts: 166
Joined: Fri Aug 28, 2015 6:24 am

Caching+deletion issue in Viewer

Post by Mixer » Wed May 18, 2016 11:49 pm

XnView 2.36
My settings possibly related to bug I'm about to describe.
Options->View->tab View->Only one window view opened = checked
Options->View->tab Misc->Loop on the file list = unchecked
Options->View->tab Misc->static box Cache: Read one image ahead = checked
Options->View->tab Misc->static box Cache: Keep current image in cache = checked

Viewer uses the same sorting order as Browser for displaying pictures.
Bug happens with any sorting order, but only if Viewer is launched straight from Explorer by opening image file.
Caching of images and keeping cache intact with list when images are being deleted is messed up.
Pictures IDs ("1st", "2nd" etc.) in text below mean their position in starting list according to sort method used by XnView, independently to number of pictures actually remaining in folder after deletion and independently to order they are displayed in Explorer.
"Bitmap" means just image in Viewer's window independently to format from which it was decoded.

[Example 1]
- You have 4 pictures in folder
- from Explorer open 3rd image
- delete 3rd
- Viewer switches to 4th
- delete 4th
- Viewer switches to 1st
- go to 2nd
- delete 2nd
- now you're stuck on "last deceased" 2nd bitmap
Going to Browser shows proper content of folder as one 1st picture.

You can get the same result in shorter way.
[Example 2]
- You have 2 pictures in folder
- from Explorer open 1st
- go to 2nd
- delete 2nd
- now you're stuck on "last deceased" 2nd bitmap
Going to Browser shows proper content of folder as one 1st picture.

[Example 3]
- You have 2 pictures in folder
- from Explorer open 2nd
- delete 2nd
- you still can switch back and forth between two pictures, even though 2nd is actually deleted
Going to Browser shows proper content of folder as one 1st picture.

[Example 4]
- You have 4 pictures in folder
- from Explorer open 4th
- delete 4th
- Viewer switches to 1st
- go to to 2nd
- delete 2nd
- Viewer switches to 3rd
- delete 3rd
- Viewer switches to 1st, but you still can switch between 1st "last picture standing" and ghostly copy, which has
name it got from 2nd and bitmap it got from 3rd.
Going to Browser shows proper content of folder as one 1st picture.

[Example 5]
- You have 3 pictures in folder
- from Explorer open 3rd
- delete 3rd
- Viewer switches to 1st
- go to 2nd
- is displayed bitmap of 3rd under the name of 2nd
Now you can go two ways: a) - switch to 1st again and back to 2nd, then 2nd image refreshes to its proper bitmap;
or b) - delete 2nd, then you're stuck on screen with name of 2nd and bitmap of 3rd, even though "last picture standing" is 1st.
Since XnView uses name of deleted image, attempt of using command "Reopen" will produce error message in this case.
Going to Browser shows proper content of folder as one 1st picture.

If in this last example you start Viewer with 3rd picture from XnView's Browser and delete it, then Viewer switches to 2nd picture, not 1st. As well if there are only two pictures in folder and you go to Viewer from Browser with 1st picture in list, then you switch to 2nd and delete 2nd, then Viewer switches to 1st. So if Viewer is started from Browser, those bugs do not appear.

You can inspect missing variants of order of loading and deletion on your own. Those examples only show that there is issue with refreshing of bitmaps and names cached from list when list changes and when Viewer is launched by Explorer.
If this issue was ever reported before, then it is still present in v2.36.

Post Reply