Loading the previous/next image is slow

[QasimK]

I love the simplicity of imv. It does everything I want.

The biggest issue I have had with any image viewer is the time it takes to show the next image, and this affects imv was well. It's noticeable on normal photos taken on a camera, but it is particularly bad for panoramas. I am using modern, fast hardware and Wayland.

Concretely, this is the behaviour I observe:

• I press the right arrow key
• imv updates its title from imv - [1/2] [10x10] img1.jpg to imv [2/2] [10x10] img2.jpg
• A full second passes (it feels like an eternity)
• imv updates its title to imv [2/2] [12000x1000] img2.jpg and actually shows the image.

So I note the image filename and imv index changes before the resolution and image is shown.

I'm not familiar with how imv and the libraries used operate, but I suspect this is because imv does not read and parse the next image file until it actually needs to be shown.

If so, I would absolutely love it if imv buffered the previous and next images, ready to be shown immediately. I have plenty of memory to spare and I want imv to use it! In fact, I would love it if this was configurable, so that I could flick through several images very quickly.

[tabell]

I noticed this delay as well, but rebuilding with FreeImage disabled and instead using libjpeg seems to be noticeably snappier. I also noticed that wordexp is doing a lot (forking new processes) and is being called a lot (once or twice every time the window is rendered).

This might be a discussion for another thread but I wonder if it would make more sense to track variables internally for printing to the overlay/window title and only set them in the shell when actually invoking a shell command.

[cshapeshifter]

This is my main issue with imv as well. On a modern, fast machine, from SSD, it takes about 1 second to load a JPG made by a modern digital camera (5472x3648 pixels, 10-20MiB). Sometimes it even takes 2 to 3 seconds.

If I read the source correctly, images are loaded ad-hoc, not pre-cached.

I also tried recompiling without freeimage, but I can't say that image loading is much faster. If there is any improvement, it's barely noticable.

I would love a feature where the next N images (maybe default to 1) are cached in advance.

[Logarithmus]

I put this issue into my long-term TODO list.