Read one image backward (reverse pre-cache)
Moderators: XnTriq, helmut, xnview
Read one image backward (reverse pre-cache)
Hello,
First of all I have to say this is a really great image tool, with tons
of superior features, which you will hardly find in any other application!
Really great work, thank you!
I have a small feature request:
right now xnview is able to cache pictures while viewing ('read one
image ahead') in only one viewing direction: forward.
this is nice, but xnview lacks the option to pre-cache pictures when you
view them backwards.
so if you start at image200.jpg and go back to image199.jpg, 198, 197,
..., it won't pre-cache the images and the loading of each image takes
alot time.
pre-cache only works in one direction and my suggestion is that it
should work in both directions: while viewing pictures forward and backward.
btw. old ACDSee 3.1 supports this
Many thanks and kindest regards,
-Eque
First of all I have to say this is a really great image tool, with tons
of superior features, which you will hardly find in any other application!
Really great work, thank you!
I have a small feature request:
right now xnview is able to cache pictures while viewing ('read one
image ahead') in only one viewing direction: forward.
this is nice, but xnview lacks the option to pre-cache pictures when you
view them backwards.
so if you start at image200.jpg and go back to image199.jpg, 198, 197,
..., it won't pre-cache the images and the loading of each image takes
alot time.
pre-cache only works in one direction and my suggestion is that it
should work in both directions: while viewing pictures forward and backward.
btw. old ACDSee 3.1 supports this
Many thanks and kindest regards,
-Eque
Re: REQUEST: read one image backward (reverse pre-cache)
You have 'cache behind'eque wrote: pre-cache only works in one direction and my suggestion is that it
should work in both directions: while viewing pictures forward and backward.
Pierre.
Yes I tried "Keep current image", but this is not what I am talking about.
This feature only caches one image - the current, nothing else.
Just try yourself to view 10 different 5MByte pictures backwards, from image200, then image199, 198, 197, etc. There is no pre-loading/caching
like there is, when you view them forward.
This feature only caches one image - the current, nothing else.
Just try yourself to view 10 different 5MByte pictures backwards, from image200, then image199, 198, 197, etc. There is no pre-loading/caching
like there is, when you view them forward.
Oh ok, sorry...eque wrote:Yes I tried "Keep current image", but this is not what I am talking about.
This feature only caches one image - the current, nothing else.
Just try yourself to view 10 different 5MByte pictures backwards, from image200, then image199, 198, 197, etc. There is no pre-loading/caching
like there is, when you view them forward.
Pierre.
Currently there are the following options:
- Read one image ahead
- Keep current image in cache
As I understand it, currently "one image ahead" always means the next image in ascending order according to the current sort order. When moving in descending order, this is the same as the previous image, and the actual next image in descending order will not be decoded in advance.
I would suggest to rename the options as follows:
- Decode next image in advance
- Keep previous image in memory
What is "next" could be automatically detected: If the user moves in ascending order, the next image to decode in advance would be the next in ascending order; if he moves in descending order, the next image to decode in advance would be the next in descending order. If he clicks on an image in the middle of the list, both neighbours could be decoded in advance.
- Read one image ahead
- Keep current image in cache
As I understand it, currently "one image ahead" always means the next image in ascending order according to the current sort order. When moving in descending order, this is the same as the previous image, and the actual next image in descending order will not be decoded in advance.
I would suggest to rename the options as follows:
- Decode next image in advance
- Keep previous image in memory
What is "next" could be automatically detected: If the user moves in ascending order, the next image to decode in advance would be the next in ascending order; if he moves in descending order, the next image to decode in advance would be the next in descending order. If he clicks on an image in the middle of the list, both neighbours could be decoded in advance.
-- Karl
-
- Posts: 251
- Joined: Sat Nov 17, 2007 7:53 am
- Location: Germany
Hi again,
being back from a 1-month-trip I downloaded the latest XnView
version and noticed, that the pre-cache is still not improved.
I am really sorry to complain, because I love XnView. But
when it comes to 7000 pictures, each 3-5 MByte, browsing
and viewing speed is one of the most important things, really.
It would be very nice, if the pre-caching would be improved
in XnView.
I know its the last thing you would like to hear, but ACDSee 3.1
is simply alot faster browsing through large images - and this
tool is from 2001..
Thanks again, regards
-Eque
being back from a 1-month-trip I downloaded the latest XnView
version and noticed, that the pre-cache is still not improved.
I am really sorry to complain, because I love XnView. But
when it comes to 7000 pictures, each 3-5 MByte, browsing
and viewing speed is one of the most important things, really.
It would be very nice, if the pre-caching would be improved
in XnView.
I know its the last thing you would like to hear, but ACDSee 3.1
is simply alot faster browsing through large images - and this
tool is from 2001..
Thanks again, regards
-Eque
Hi there,
well, I don't know the number of pictures ACDsee (v3.1) is caching
while viewing and I don't mind too much about technical details.
What I know from my experience while viewing thousands of
pictures: XnView is slower than ACDSee v3.1.
Not only it is much slower viewing pictures backwards (as
described in the first post), but it is also slower viewing pictures
forwards (the difference here is however not too big). Just compare
yourself.
I am using a 3.2 GHz PC with 2 GB RAM and a brand-new 500 GB
S-ATA II hard disk.
Cheers,
-eque
well, I don't know the number of pictures ACDsee (v3.1) is caching
while viewing and I don't mind too much about technical details.
What I know from my experience while viewing thousands of
pictures: XnView is slower than ACDSee v3.1.
Not only it is much slower viewing pictures backwards (as
described in the first post), but it is also slower viewing pictures
forwards (the difference here is however not too big). Just compare
yourself.
I am using a 3.2 GHz PC with 2 GB RAM and a brand-new 500 GB
S-ATA II hard disk.
Cheers,
-eque
Hello there,
I was wondering about what happened with my suggestions
many months ago? Is there any chance this will be included
in one of the next releases?
As you can see, I am not alone with this problem (Karl02).
And I believe its a simple thing to fix.. no?
It would make browsing pictures in fullscreen much faster..
greetings,
-eque
I was wondering about what happened with my suggestions
many months ago? Is there any chance this will be included
in one of the next releases?
As you can see, I am not alone with this problem (Karl02).
And I believe its a simple thing to fix.. no?
It would make browsing pictures in fullscreen much faster..
greetings,
-eque
Nobody knows but Pierre.eque wrote:And I believe its a simple thing to fix.. no?
It may work by reversing the image list and always skip forward internally, instead of having a fixed image list and skipping back and forth.
But then again... Nobody knows but Pierre.
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
I can't agree more with that.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.