Repository navigation
[Bug]: Mouse Wheel navigation even inside high-res cache loads low-res first and then high-res image. #213
Description
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.
Activity
riyasy commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 13, 2026
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 commentedon Jul 14, 2026
@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
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 commentedon Jul 14, 2026
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 commentedon Jul 14, 2026
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.
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
CacheSizeOneSideHqImagesvalue 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 commentedon Jul 14, 2026
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 commentedon Jul 15, 2026
@ittroll , yes that was what was in my mind.. Shall build a trial.
[-][Feature]: Preload/prerender upcoming full-resolution images for faster navigation[/-][+][Bug]: Mouse Wheel navigation even inside high-res cache loads low-res first and then high-res image.[/+]ittroll commentedon Jul 15, 2026
On the subject of VRAM, are you able to easily detect how much a system has?
If so, would be nice to have a slider which can be used to specify the GB or % available to the cache.
Folks with lots can then choose to ramp it up.
When navigating fast, Fly will keep displaying HQ if available.
Missed an underscore
riyasy commentedon Jul 16, 2026
Portable - https://github.com/riyasy/FlyPhotos/actions/runs/29470678280/artifacts/8364728339
Installer - https://github.com/riyasy/FlyPhotos/actions/runs/29470678280/artifacts/8364729186
Fly uses high-res if available even during high speed navigation.
Note - The suggestion of dynamic VRAM based settings is not implemented. It will need more investigation and thought.
bruhov commentedon Jul 16, 2026
@riyasy Thank you so much! That problem is resolved. And when combined with a high
CacheSizeOneSideHqImagesvalue, I don't see any previews at all anymore!Honestly, I had tried a great many image viewers before this - including ones that claimed to feature caching - but your program is the first, and perhaps the only one of its kind, to actually solve this problem.
syntetic-sudo commentedon Jul 16, 2026
Thank you—everything is working now, and thank you for the portable version (I hope that in the future, the "AppData\Local\FlyPhotos" folder containing the settings will be preserved in the portable version along with the main folder).
brmarkus commentedon Jul 16, 2026
Yessss, please!
riyasy commentedon Aug 29, 2026
Available in 2.7.2