i'm very interested in the solution too.
I think there are two (already mentioned) issues connected.
a) If you set "read one image ahead" and keep pgdown pressed in the viewer, you'll see your viewer stay on the current image and you'll see (caption; status bar) that at the same time all subsequent images are read in the background (without being shown), what obviously does not make sense.
That is true at least on win98 (maybe opsys-specific ?)
Obviously the "nexe image ahead" should been shown before processing the next-next-next one ... and so on
b) The other issue/thread is that you should be able to cancel a paint operation when meanwhile another image is requested eg. be pressing pgdown (go on to next one).
So obviously there is a conflict when constantly keep the pgdown pressed: show next image and cancel that show.
Imo that is a timing problem: Try to paint the next image; but when within a certain time period the pgdown message arrives, cancel the paint and proceed with the subsequent image ...
Am i understandable and does this make sense?
Same problem here, especially with pdfs and many jpgs in folder. One thing could be that XnView shows the numer of image files in the viewer window (e.g. "7/500"), so it must enumerate all the images. Since i do not know implementation details, it is too speculative to say that XnView could check the file content against the extension (*) or build the thumbnail somewhere to put it in the cache.
(*) That would mean that XnView while enumerating files in current folder checks the content of each file. This process would additionally be slowed down by an on-access virus scanner.