I also agree. Except the statement "... this is somewhat ridiculous" (such statements can be thought but should be avoided in the XnView forum.).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.
Read one image backward (reverse pre-cache)
Moderators: XnTriq, helmut, xnview
Well I think we all can agree that Pierre and the whole XnView team is doing a fantsatic job.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.).
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...
-
- Posts: 251
- Joined: Sat Nov 17, 2007 7:53 am
- Location: Germany
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.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.
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:
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.
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).
Needs some refreshing after 3 years, though...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.
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
Backward caching is the only XnView weakpoint
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
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
Re: Backward caching is the only XnView weakpoint
?? You have read ahead and cache behindbugmenot 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.
Pierre.
Re: Backward caching is the only XnView weakpoint
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".
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
Olivier got it right
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!
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!
Re: Olivier got it right
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.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
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
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