[Bug]: Mouse Wheel navigation even inside high-res cache loads low-res first and then high-res image.

[bruhov]

2026-07-15 RYF EDIT

The original post was created as a feature enhancement and contained a proposed solution which is a feature already in place. Editing for future clarity.

What's happening?
During mouse wheel navigation, images that are already present in the high-resolution cache still render the low-res first and swap to high-res a moment later. Since the high-res version is already decoded and cached, it should display immediately with no intermediate low-res frame.

Expected behavior
When the target image is already in the high-res cache, navigation should paint the high-res version directly, skipping the low-res-then-high-res transition.

Steps to reproduce
Open a folder and let the surrounding images populate the high-res cache (caching sliders at max).
Mouse wheel back and forth across images known to be cached.
Observe the brief blurred/low-res frame before high-res appears, even on cache hits.

ORIGINAL POST (Ignore)

What problem would this solve?

When navigating quickly through a gallery, the app briefly displays a blurred, low-resolution version of the image before loading the full-resolution one. This loading delay is noticeable especially when images are stored on a network drive (NAS). Currently, the rendering and loading speed during fast scrolling feels slower compared to Picasa Photo Viewer. I hope to overcome this difference with such aggressive caching.

Proposed solution

Implement a background caching/pre-rendering mechanism. Ideally, while the user is viewing the current image, the app should silently pre-load and decode the full-resolution versions of the next and previous 'N' images into RAM/VRAM.
It would be great to have a setting in the preferences to configure the number of images to pre-cache (e.g., pre-load 3, 5, or 10 images ahead), allowing users to balance between RAM usage and navigation speed.

Alternatives considered

No response

Additional context

I have attached a video demonstrating this issue. It shows three images. In the app settings, the caching sliders are set to the maximum value.

output2.mp4

[riyasy]

You can increase the count in settings cache section.

There is preload threads running in background for both low-res and high-res. How many neighbours to cache (in memory) can be set in Settings.
Also When we navigate fast (keeping the next button pressed for e.g) , the high-res thread is paused to reduce friction and CPU load.
Also to speed up the previews and thumbnails, recent low-res are also cached to disk so that you get the thumbnail bar instantly next time you take the folder.

Browsing network drives can be slow as file operations can be slow and I don't think Fly can do much about that as I don't plan to put high-res images to disk cache.

[bruhov]

As I mentioned earlier, the caching sliders are maxed out—set to 3 for high-resolution images. The demo also features three images. In theory, they should all display in high resolution immediately; however, the video shows a loading phase where a blurry, low-resolution version appears first.

[riyasy]

If its maxed out, then it seems strange. I don't face this if the clicked image is in the high-res neighbour hood as defined in settings.
Are you facing this in all folder and all types of images?

[bruhov]

The demo was recorded using PNG screenshots (9 MB each, at a native screen resolution of 2560x1440) on a local NVMe SSD.
The same problem occurs on a local SATA SSD with 3 JPG files (500 KB – 1 MB).

Here is my settings file:
usersettings.json

[riyasy]

I replaced my settings with your settings and it loads directly as high-resolution.
Can you give info like OS, x64/arm64, GPU etc?

[bruhov]

Sure.
Windows 11 Pro 25H2 (26200.8655), Ryzen 9 9950x3d (x64), RTX 4090 (driver version: 596.49), 64 Gb DDR5 6000 CL30, NVMe SSD PCIe 4.0 x4

Just to add, when I simply press the forward arrow on the keyboard once, the next image loads immediately in high resolution. In the demo, I scroll the mouse wheel directly from the first image to the third.

[riyasy]

Oh..
Discrete clicks are always treated as user intending to see that photo. So high-res is loaded first if it is available at the moment.

But mouse wheel/holding down next button etc are treated differently.. Fly treats this as cues for fast navigation and waits till current gesture stops to load high-res. Button may still feel instant as we get button up event. For mouse wheel there is no event like mouse wheeling stopped. So whenever there’s mouse wheel, Fly waits for x milliseconds to make sure there is no subsequent one coming before loading high-res. This is by design.

[bruhov]

I see - that makes sense. Is it possible to add a setting, even a hidden one, to treat the mousewheel event as a single button click, or to configure the duration of that pause?

[syntetic-sudo]

Yeah, there is this problem (to be honest, it's really annoying), and the higher the photo resolution, the more noticeable it becomes. I’ve tried adjusting the cache, but it doesn’t help on my system (Win11, i5-13600k, 4070 Ti, 64 GB RAM, 4K monitor). Here’s an example (there are 4 photos in the folder):

test.2.mp4

[riyasy]

@bruhov , @syntetic-sudo

Please confirm that what you're are seeing matches the intended behaviour to make sure we are on same page.

Fly has two navigation modes:

Single-step navigation

• Instant Press and release of the keyboard < or > keys.
• Click the on-screen < or > button without keeping pressed.
• Click a thumbnail.
• A single discrete mouse wheel step over the thumbnail strip or the </> buttons.

For all of the above, if the destination image is already in the high-resolution cache, Fly should display it directly without briefly showing the low-resolution version.

Continuous navigation ("Flying" mode)

When multiple navigation events (greater than one) arrive in quick succession (holding a key, rapidly scrolling the mouse wheel), Fly switches to a mode optimized for speed. It rapidly displays images from the low-resolution cache and upgrades to the high-resolution version once navigation stops. For e.g a two finger swipe over thumbnail bar in a trackpad can send tens or hundreds of the same mouse scroll event to Fly.

Fly understands user stopped navigation when user releases keyboard key or when stops scrolling. For button release, we get event from OS and so we can instantly switch to high-res if available. The mouse wheel is slightly different because Windows doesn't provide a "wheel stopped" event. Fly can only infer that scrolling has stopped after waiting a short idle period. I'll look into whether this transition can be made less noticeable.

Also on a side note, Increasing high res cache manually is not a good idea and can affect system performance. Both the low-resolution cache (up to 800 px on the longest side) and the high-resolution cache are kept in GPU memory (VRAM) for fast switching. Making the high-resolution cache much larger can put pressure on GPU.

[ittroll]

For mouse wheel there is no event like mouse wheeling stopped. So whenever there’s mouse wheel, Fly waits for x milliseconds to make sure there is no subsequent one coming before loading high-res. This is by design.

So Fly displays the low resolution image because, for a few milliseconds, it doesn’t know that it is the image the user intends to view rather than skip.
Could extra logic be added so that Flying mode is only activated when the number of navigation events (capped to total number of photos) is greater than the cache count?

[bruhov]

Please confirm that what you're are seeing matches the intended behaviour to make sure we are on same page.

Overall, yes. I noticed a slight difference in "flying" mode. If I hold down an arrow key on the keyboard, the final image loads the fastest. If I click and hold an arrow on the screen, it takes a bit longer to load. And using the mouse wheel results in the longest load time.

Also on a side note, Increasing high res cache manually is not a good idea and can affect system performance. Both the low-resolution cache (up to 800 px on the longest side) and the high-resolution cache are kept in GPU memory (VRAM) for fast switching. Making the high-resolution cache much larger can put pressure on GPU.

I understand, but I have quite a bit of free RAM/VRAM, and I don't mind if FlyPhotos consumes more if it improves my image viewing experience ^^ For example, a high CacheSizeOneSideHqImages value currently helps load high-resolution images instantly when I click any thumbnail (not just those within 3 spots of the center), even when I'm viewing images from a NAS.

[syntetic-sudo]

Yeah, the on-screen < and > buttons work perfectly fine - everything opens instantly with virtually no delay. The only issue is with scrolling using the mouse. So it's the same as what the @bruhov mentioned above.

[riyasy]

Could extra logic be added so that Flying mode is only activated when the number of navigation events (capped to total number of photos) is greater than the cache count?

@ittroll , yes that was what was in my mind.. Shall build a trial.