Hello,
would it be possible to implement a freely definable setting to define the amount of pictures XNViewMP is reading ahead?
Currently only 1 picture is read ahead.
It was proposed in the past as far as I could find, but this was never implemented:
Proposition from 2016: https://forum.xnview.com/viewtopic.php?t=33693
Mention of implementation by official xnview-account (Mon Oct 02, 2023 6:38 am): viewtopic.php?t=46134
I would very much appropriated it as a sometimes have to browser very large images from a NAS and if it could be possible to just preload every image in a folder or every x images than I would not have to wait so long.
Thanks in advance for a reply and maybe an implementation
Cheers
Read x pictures ahead
Moderators: helmut, XnTriq, xnview
-
purpleguy
- Posts: 9
- Joined: Wed Mar 16, 2022 3:28 pm
Re: Read x pictures ahead
This would be useful for me especially in the following circumstance, I believe:
I have folders full of .avif image files which are slow to decode -- often, I view one image full-screen and scroll to and fro looking for a specific image -- and this can be quite frustrating because of this newer format's decode burden/complexity. This is not XnView MP's fault -- AVIF is an image codec based on the relatively recent AV1 video codec and it's well-known that implementing a decoder in hardware, e.g., calls for much more real estate than the typical ASIC hardware decoder of yesteryear. It stands to reason that the software decoding that we use for avif image files would also quite some resources, I don't question that at all. I'm sure he's using ffdshow/dav1d and one can't get better than that. If our extremely generous author ever decides to implement pre-decoding several images in advance, that would help me out, quite tremendously in fact. I am only one person though and things could be left exactly as they are and my gratitude for this software would stay maxed out. XnView truly is a magnificent piece of software.
I have folders full of .avif image files which are slow to decode -- often, I view one image full-screen and scroll to and fro looking for a specific image -- and this can be quite frustrating because of this newer format's decode burden/complexity. This is not XnView MP's fault -- AVIF is an image codec based on the relatively recent AV1 video codec and it's well-known that implementing a decoder in hardware, e.g., calls for much more real estate than the typical ASIC hardware decoder of yesteryear. It stands to reason that the software decoding that we use for avif image files would also quite some resources, I don't question that at all. I'm sure he's using ffdshow/dav1d and one can't get better than that. If our extremely generous author ever decides to implement pre-decoding several images in advance, that would help me out, quite tremendously in fact. I am only one person though and things could be left exactly as they are and my gratitude for this software would stay maxed out. XnView truly is a magnificent piece of software.
-
blubbeh
- Posts: 2
- Joined: Sat Apr 06, 2024 12:30 am
Re: Read x pictures ahead
The following are just observation of the read ahead setting on Windows, even if they seem to contradict what should be happening... something is.
I'm actually fairly certain it's already reading multiple images ahead, despite what the setting says. What I'm not certain about is if it's done in the best possible way right now.
Resource Monitor shows a myriad of file handles open on the XnView process when preloading and having a decently fast but far from silent HDD, I can definitely hear that as well.
Preloading seems to fall short on non-tiny images of large amounts however. I haven't dug deeper but from noises alone it might be doing the preload on multiple threads, which is good on SSDs, but thrashes read performance on HDDs as disk access is all over the place. Cherry on the cake is that you keep hearing the HDD read stuff the whole time (it does finish eventually but on large folders that can take a long time), yet there's audible seeking and delays when actually advancing to the next image. In my case I still get like 40 MB/s read activity shown in Task Manager, so one would hope that's enough to not have to wait to seek through 2 MB - 5 MB images.
With 26 GB free RAM I should also have enough room for some preloading.
I feel like while well-intentioned, preloading falls short in the scenarios I need it most.
These days I actually use a small tool that just takes a folder and reads all its files once. This causes them to be cached by Windows for the next read, provided you have enough spare RAM so it's not thrown out again right away. The sequential access pattern of that is much faster and quieter than the preloading XnView does. Browsing with XnView afterwards results in a quiet HDD, though I'm not sure leaving preload on during this is a good thing.
This pattern does get wasteful or useless if I want to access a few images in the middle of a large folder, though, so I'd prefer if XnView preloading worked better.
Not sure if preloading does any decoding ahead of time. That wouldn't be a bottleneck on my system so I'd prefer to be able to toggle that off if it lets me hold more images in RAM instead. Generally some customization of the preload behavior would be neat (amount of memory used (image count would work too but sizes vary), threads (though detecting a HDD then using 1 thread might be better), etc).
No idea if these observations help. I'd imagine the dev knows what's happening in the application code already. Well, here's to signal I care and would love improvements in this area.
I'm actually fairly certain it's already reading multiple images ahead, despite what the setting says. What I'm not certain about is if it's done in the best possible way right now.
Resource Monitor shows a myriad of file handles open on the XnView process when preloading and having a decently fast but far from silent HDD, I can definitely hear that as well.
Preloading seems to fall short on non-tiny images of large amounts however. I haven't dug deeper but from noises alone it might be doing the preload on multiple threads, which is good on SSDs, but thrashes read performance on HDDs as disk access is all over the place. Cherry on the cake is that you keep hearing the HDD read stuff the whole time (it does finish eventually but on large folders that can take a long time), yet there's audible seeking and delays when actually advancing to the next image. In my case I still get like 40 MB/s read activity shown in Task Manager, so one would hope that's enough to not have to wait to seek through 2 MB - 5 MB images.
With 26 GB free RAM I should also have enough room for some preloading.
I feel like while well-intentioned, preloading falls short in the scenarios I need it most.
These days I actually use a small tool that just takes a folder and reads all its files once. This causes them to be cached by Windows for the next read, provided you have enough spare RAM so it's not thrown out again right away. The sequential access pattern of that is much faster and quieter than the preloading XnView does. Browsing with XnView afterwards results in a quiet HDD, though I'm not sure leaving preload on during this is a good thing.
This pattern does get wasteful or useless if I want to access a few images in the middle of a large folder, though, so I'd prefer if XnView preloading worked better.
Not sure if preloading does any decoding ahead of time. That wouldn't be a bottleneck on my system so I'd prefer to be able to toggle that off if it lets me hold more images in RAM instead. Generally some customization of the preload behavior would be neat (amount of memory used (image count would work too but sizes vary), threads (though detecting a HDD then using 1 thread might be better), etc).
No idea if these observations help. I'd imagine the dev knows what's happening in the application code already. Well, here's to signal I care and would love improvements in this area.