XnView Software

pic_viewer wrote:IMHO this is somewhat ridiculous. There should be just one option called 'Preload Caching'. The fact that this functionality is not fully working (means as every normal user would expect), but is only partially implemented, is no reason to come up with three options and a cluttered settings dialog.

I also agree. Except the statement "... this is somewhat ridiculous" (such statements can be thought but should be avoided in the XnView forum.).

helmut wrote: I also agree. Except the statement "... this is somewhat ridiculous" (such statements can be thought but should be avoided in the XnView forum.).

Well I think we all can agree that Pierre and the whole XnView team is doing a fantsatic job.

Recently, I was browsing through the forum and was very impressed how fast Pierre reacts on so so many questions and suggestions. So I'm sure his work is not 'ridiculous'


But lets stay on topic...

eque wrote:Pierre reacts on so so many questions and suggestions. So I'm sure his work is not 'ridiculous'

More than obviously my statement referred to the discussion in this thread and to the upcoming proposals how to do it, not on Pierre's work.

More than obviously ...

watch out ! you're doing it again

ACDSee 2.4 was the best and fastest. Simple, non bloated.

Caching 3 images is useful, when I shoot raws I have many similar pics, I go back/fwd 3 pics and delete 1, then again compare 3 and delete 1, etc.

My Nikon viewer does this well.

Caching 3 images is useful, when I shoot raws I have many similar pics, I go back/fwd 3 pics and delete 1, then again compare 3 and delete 1, etc.

pretty much exactly the same workflow I have when sifting out images and removing ones I won't need.. any delay in comparing images because they aren't being cached just makes things take longer to do... that+frustration in not being able quickly/instantly compare 2 images in the same location without having to wait for xnview.. even though you had only just viewed the image ~1second ago.. I'd rather have it chew up lots of ram and be giving me the speed I want.

And it would be nice if xnview could have the option to cache the next image infront, that way if you ever stop to linger on 1 image, when you do goto the next new one its shows up instantly.

How does ACDSee older version compare to xnview.. which one would be the best to try out in terms of features compared to xnview.. and speed. And howcome the developers are so stupid that there new version is awful?

I think there are still some interesting bits in this old thread:

When navigating with the Viewer, the probability is higher for 'Next' than for 'Previous'. However, when the user has actually started to navigate, the probability gets higher for the selected direction (but going back also have a strong probability).

Because there can be several sources of caching (ie: Browser window, each Viewer window, Full Screen lite...) sharing the same memory and files, it should be managed as the union of several individual cache lists:
-> If an image to be loaded is not in any of those lists, it will be read from disk and added to the cache list of the corresponding source.
-> If an image to be loaded is already in any of those lists, it means that it is already in memory and doesn't need to be read from disk. It will however be added to the cache list of the source (without doubles).
-> An image to be removed from the cache of one source will first be removed from its own list. If the image is not listed anymore in any cache list, it will then be unloaded from memory.

Needs some refreshing after 3 years, though...

What I had in mind at that time was having current+next+previous in cache, but adding depth-levels (ex: 3 in same direction, 1 in reverse) would be possible too.

I really like XnView and chose it after a lot of comparisons with other softwares.

Its only weakpoint is really the backward caching which I think could be solved on the code side very quickly. Let's not over engineer it with several levels yet. Just provide a previous and next image caching, the one loaded first being dependant on the way you are parsing the image list.

I want this so badly that I am ready to hack the current executable just to get it

bugmenot wrote:I really like XnView and chose it after a lot of comparisons with other softwares.

Its only weakpoint is really the backward caching which I think could be solved on the code side very quickly. Let's not over engineer it with several levels yet. Just provide a previous and next image caching, the one loaded first being dependant on the way you are parsing the image list.

?? You have read ahead and cache behind

Let's summarize...

Based on your 'current' position, there is a 'next' image and a 'previous' image, in this order:
- Previous
- Current
- Next

What people want is to cache 'Previous' as well as 'Next'.
("Cache behind" only keeps 'current' in cache when you move forward, but it means that 'Previous' is not in cache when you move backward or from a new position)

So, to make a quick and simple system:
- XnView should notice in which direction the user is moving (forward or backward. For a new selection, use forward as default).
- If going forward, XnView should cache 'next' image, and then 'previous' image.
- If going backward, XnView should cache 'previous' image, and then 'next' image.
(of course, when you move, you only have to cache 1 image, as the other 2 are already in memory)

And this way, there would only be a single option: "Use cache".

Olivier seem to have perfectly understood my point.

Due to XMas and my daughter being born yesterday I did not have much time, but I have identified the cache code with the latest executable in case hacking is needed

ReadAhead is touched at 4DE31B and 4E1C0F and stored at 74797D, the code executed if this variable is set is at 4D7EFB and 4D83DC. I now just need some time to understand the caching code and then it should not take long to modify to have a perfect XnView

I am not too excited at hacking the official .exe but if there are no plans to fix this (really that should be a matter of minutes for those of you who have the source code) I will keep moving forward

Hopefully we all work smart and together and this will be in the next release

Thanks again for this fantastic image viewer!

bugmenot wrote:I am not too excited at hacking the official .exe but if there are no plans to fix this (really that should be a matter of minutes for those of you who have the source code) I will keep moving forward

Please be advised that it is considered inappropriate to log into a software's official support forum anonymously (with a BugMeNot account) and discuss the patching of the program's EXE — especially since there are already efforts underway to implement the requested feature.

helmut ([url=http://newsgroup.xnview.com/viewtopic.php?p=18941#18941]Changing associated icons?[/url]) wrote:For XnView, there is no need to modify the executable. And if there is a need, this should be communicated here in the forum to see whether a good solution can be found.

In no case any changed XnView or NConvert package must be given to other people or put on download servers.

> it is considered inappropriate to log into a software's official support forum anonymously

Apologies about that, I did not bother registering. It is done now

> the patching of the program's EXE

As mentioned in my previous email this is really last resort for me I am busy enough with my new born

> especially since there are already efforts underway to implement the requested feature

That is fantastic news! Thanks a lot for letting us know about it. I will look forward to the next release.

Have a great holiday!

Cedrick

well I hope said feature isn't too far away

Seems reasonable to expect it next year

Joke apart I have no idea how often XnView is released and I am not going to complain nor be impatient since the software is already amazing and it is going to be implemented at some point.