Page 1 of 1

What ultimately ruins XnView for me: Handling lots of images

Posted: Sun May 29, 2016 12:34 pm
by Aerensiniac
- Completely unable to handle larger amounts (5000+) of images in one directory. This leads to:
a.) Extreme memory usage (over 2gb)
b.) Extreme loading times (over 30 seconds)

- Unable to handle gif files in browser/thumbnail mode
a.) Second long freezes when trying to play thumbnail
b.) Out of memory messages (got 8gb of ram, literally havent seen any oom messages in 10 years and a frikin image viewer triggers it)
c.) File format bigotry (could not determine, etc)

TL;DR: If you have larger numbers of animated images, especially gif, XnView becomes not only inconvenient due to its speed and memory usage, but also 100% useless, refusing to read files.

Possible reasons:
- As far as i can see XnView aims to always fully read the entire directory before actually letting the user do anything. This leads to the half minute long loading times of any directory.
This is a pretty stupid idea when working with larger number of files. acdsee resolved it by never loading the entire directory. What is being loaded are only the files on the screen. Once those are loaded, the program continues to load the directory/files not on the screen currently.
- I have no idea about programming or coding, but its obvious that the way the software handles animated files is somehow screwed up. Literally no image viewer i have ever used had as much trouble with gif and other files as much as XnView does.
- The caching system of XnView works in reverse. It actually slows things down and results in extreme loading times when working with larger files. Also fails to cache animated files. In fact, i have no idea at all wtf the cache does. It sure as hell does not reduce any form of loading times involved with images.

Re: What ultimately ruins XnView for me

Posted: Sun May 29, 2016 6:46 pm
by oops66
Aerensiniac wrote:...
- As far as i can see XnView aims to always fully read the entire directory before actually letting the user do anything. This leads to the half minute long loading times of any directory.
This is a pretty stupid idea when working with larger number of files. acdsee resolved it by never loading the entire directory. What is being loaded are only the files on the screen.
Hello,
Right but for me, it depends of the cases of uses ... If you want to search, for example, after browsing into a dir., some IPTC/XMP keywords then all data must be loaded into the data base before... If this is only for opening a pic, then, building thumbnails only for pictures displayed on the screen is enough in a first time.

Re: What ultimately ruins XnView for me

Posted: Sun May 29, 2016 7:32 pm
by Aerensiniac
oops66 wrote:Right but for me, it depends of the cases of uses ... If you want to search, for example, after browsing into a dir., some IPTC/XMP keywords then all data must be loaded into the data base before... If this is only for opening a pic, then, building thumbnails only for pictures displayed on the screen is enough in a first time.
Not sure i understand. File name search should be available to you without thumbnails, but even if not, loading thumbnails without being (LITERALLY) frozen, would be common sense.
I mean, you stroll into a directory with 5k images, and the program stops responding altogether. If you click on it windows asks you if you want to close it.
One way or another, i have absolutely no idea why its mandatory to load the entire directory and in such a manner too.

Re: What ultimately ruins XnView for me

Posted: Sun May 29, 2016 8:00 pm
by XnTriq
XnView MP is capable of “lazy loading” and allows you to deactivate Create thumbnails for whole folder (Tools » Settings... » Thumbnail » Misc).

Re: What ultimately ruins XnView for me

Posted: Mon May 30, 2016 4:49 am
by Aerensiniac
XnTriq wrote:XnView MP is capable of “lazy loading” and allows you to deactivate Create thumbnails for whole folder (Tools » Settings... » Thumbnail » Misc).
Thank you for bringing this to my attention.
MP seems to have no loading time issues. As far as i can see the gif issues persist, but are less significant than on the normal version.