Read one image backward (reverse pre-cache)

Ideas for improvements and requests for new features in XnView Classic

Moderators: XnTriq, helmut, xnview

User avatar
helmut
Posts: 8705
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Post by helmut »

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.).
eque
Posts: 9
Joined: Wed Jan 30, 2008 3:43 pm

Post by eque »

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...
pic_viewer
Posts: 251
Joined: Sat Nov 17, 2007 7:53 am
Location: Germany

Post by pic_viewer »

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.
thibaud
Posts: 274
Joined: Sat Dec 02, 2006 12:41 am
Contact:

Post by thibaud »

More than obviously ...
watch out ! you're doing it again :wink:
bugmenot
Posts: 69
Joined: Sun Sep 16, 2007 10:29 pm

Post by bugmenot »

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.
Koogle
Posts: 147
Joined: Wed Sep 20, 2006 3:23 pm

Post by Koogle »

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?
User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G »

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... :D

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.
Olivier
bugmenot
Posts: 69
Joined: Sun Sep 16, 2007 10:29 pm

Backward caching is the only XnView weakpoint

Post by bugmenot »

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 :)
User avatar
xnview
Author of XnView
Posts: 43442
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Backward caching is the only XnView weakpoint

Post by xnview »

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
Pierre.
User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Backward caching is the only XnView weakpoint

Post by Olivier_G »

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
bugmenot
Posts: 69
Joined: Sun Sep 16, 2007 10:29 pm

Olivier got it right

Post by bugmenot »

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 :D

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

Thanks again for this fantastic image viewer!
User avatar
XnTriq
Moderator & Librarian
Posts: 6336
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: Olivier got it right

Post by XnTriq »

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 :D
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.
ccollomb
Posts: 6
Joined: Sat Dec 27, 2008 8:48 pm
Location: San Francisco

Post by ccollomb »

> 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
Koogle
Posts: 147
Joined: Wed Sep 20, 2006 3:23 pm

Post by Koogle »

well I hope said feature isn't too far away :)
ccollomb
Posts: 6
Joined: Sat Dec 27, 2008 8:48 pm
Location: San Francisco

Post by ccollomb »

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.
Post Reply