XnView Software

Hello,

I just started using XnViewMp (Ubuntu version), and have a bug to report:

In "Browse" mode (with details list & the preview visible), you can hold the "down" keyboard key to quickly scroll through images. And as expected, when you see the image you are looking for, you can release the key, and it stops. However, if you do the same in the mode where it only shows the image (not Browse mode), then it continues scrolling for a long time after you have already released the key. Sometimes it can keep going for many seconds, and you have to wait for it to stop before you can start going way back to where you actually intended to stop.

This makes it difficult to find the photo you want, as almost all the time it is used in the "photo viewing mode", so hopefully it can be fixed. Otherwise, I love the software.

Thank you

Hi,

Was there maybe a difficulty reproducing this issue? Has anyone else seen it? It looks like all the bug posts that were more recent than this got a response, maybe I left out some info?

Thank you again

ok, i'll check how to fix this issue...

Thanks!

Any luck managing to repro this?

metal450 wrote: Sat Mar 19, 2022 3:36 am Any luck managing to repro this?

Reading Pierre's post above, I'd say that Pierre could reproduce the problem but he is still looking for a way to fix it.

I was more wanting to follow up, as he mentioned he'd look into it in January but the issue still seems to persist - this appears to be the same issue as I posted 2 years ago (viewtopic.php?f=62&t=40701&p=164113#p164113). In that case too he mentioned he'd look into it, but then ceased responding, even after I replied.

...Like even since that last reply, he responded to at least 12 other posts, yet this response - despite being reported far earlier - was ignored. So since there doesn't really seem there's any sort of "queue" system, I'm not sure how to ensure that one's issue reports aren't simply ignored indefinitely...

Hello?

currently i have no way to fix this issue, need to investigate more...

Maybe replicate whatever loading method is done in "browse" mode, since the issue never occurs there?

Your description sounds like a CPU- or GPU-related issue.

I find this very problem to be even worse with Windows' built-in image viewer. Rapidly scrolling through fullsize images happens faster than the program can render -> preload -> release from RAM/VRAM.

What is your CPU, GPU, and RAM?

Do you notice this issue is less obvious (and lags less) when dealing with smaller resolution images?

Do you notice this issue is less obvious (and lags less) when dealing with certain image formats?

Do you notice this issue is less obvious (and lags less) with the following settings?

• General -> ICC -> uncheck "Use ICC"
• View -> View -> High quality zoom: Never
• View -> Misc -> Cache, uncheck "Read one image ahead"
• View -> Misc -> Cache, uncheck "Keep current image"

You can revert the above settings back to how you prefer. This is only to gauge the issue.

Of course load delays would be more noticeable with larger files - that's a completely different issue. Whether each image takes 5ms or 500ms to load, the issue I'm addressing here is what it does *after the key is released.* Once it finishes displaying whichever is the current image, it should not continue to load any further additional images. This is regardless of the speed that each image loads.

As a counterexample, you can try Nomacs (Linux). You hold the pagedown key, it cycles between images, you release the pagedown key, it stops. This is true whether you're flipping through giant images that take 1s to load or tiny thumbnail size images. In XnView, it may continues loading a further 10 or 20 photos after releasing the key.

I still think it's related to the CPU/GPU, but not for my original reasons.

I did some more testing, and the rendering of images in "Browse" mode seems worlds more efficient than when in "View" mode.

What' I'm guessing is that the CPU is being overburdened with rendering, that it interferes with the input (such as releasing the arrow key). This is the same principle for decoding a modern video format of a high resolution without proper acceleration. The controls and buttons of the media player, as well as keyboard inputs, will lag.

Whatever method is being used to render the images in "Browse" mode should be used in "View" mode.

I'm noticing substantially more CPU usage when scrolling through images in "View" mode; yet not that much when using "Browse" mode.

I'm going to test something out with an older version of XnViewMP.

Could be. In any event, the author has been ignoring this since it was first reported over 3 years ago, here: viewtopic.php?f=62&t=40701&p=182087