Main window is sluggish and unresponsive when being moved or resized

Forums: 

When the FRV main window is moved (via dragging, or by window managers), it takes 2-3 seconds to start moving. Once the move is finished, the GUI is completely unresponsive for another 2-3 seconds before I can interact with it again. It gets quite annoying since I use a tiling window manager that moves windows around.
Something I noticed is that when resizing a window, the issue only happens when resizing from the top or left edges of the window. Resizing from the right or bottom edges doesn't cause the GUI to become unresponsive.
I've tried both OpenGL and DirectX11 engines.

  • Operating system/version
    • Edition    Windows 11 Pro
    • Version    25H2
    • Installed on    ‎5/‎27/‎2025
    • OS build    26200.8655
    • Experience    Windows Feature Experience Pack 1000.26100.315.0
  • General Hardware specs: AMD Ryzen 9 3900X, NVIDIA RTX 3080 Ti (12GB VRAM), 32GB RAM
  • FastRawViewer version: 2.0.11 Release Build 2088

 

Since we have never received such complaints from other users: could you please test with the standard Windows window manager?

--

Alex Tutubalin/FastRawViewer team

The issue persists even without a separate window manager (just native Windows).

We can't reproduce the issue you described, even on the exact same version of Windows you specified. Furthermore, we haven't received similar complaints from other users. (although AMD CPU, NVidia GPU and the latest version of Windows 11 are one of the most common setups today).

What you're describing appears to be a situation where one GPU is used by a rendering program, and the display(s) are connected to a different GPU. In this case, the system/graphics drivers create a complex frame buffer structure (offline rendering on one graphics card, then transferring the entire result to the other graphics card and re-rendering it), and this can indeed be slow (especially when one of the graphics cards is connected via a slow link, such as 1-2 PCI lanes).

However, your description only indicates one graphics card, and the CPU doesn't have integrated graphics.

Perhaps your tiled window manager is still creating separate virtual screens for each application, even when disabled.

Try switching FRV to the most compatible DirectX9 (Legacy) mode.

If you have a clean Windows installation on your computer without any additional complications (for example, a backup copy of Windows), it would be interesting to know if the problem can be reproduced there.

--

Alex Tutubalin/FastRawViewer team

The issue persists in DX9 mode.
It also happens in Windows Safe Mode.
I also find it odd that there isn't a performance problem with any kind of image processing (whether RAW or non-RAW), multithreaded thumbnail generation/loading, etc in the app. The issue occurs even when no files are loaded.
I also have no issues using other RAW viewers/converters as well or any program that uses the GPU heavily.
I wonder if it has to do with handling window refreshes specifically with the Windows API or window hooks? It seems to be very specific to moving the window and resizing it leftwards or upwards only. I've tried all the GPU compatibility settings, including all the "Refresh window after image changed" options to no avail.

I did some more testing and I noticed that the slowdown is more noticeable when I've expanded a directory in the Folders view that has subdirectories containing a lot of RAW+JPG files (in the tens of thousands distributed across multiple subdirectories). When that directory is collapsed, it's still a bit sluggish, but not as much. Expanding directories without RAW+JPG files behaves the same as when nothing is expanded.
Here's a screen recording demonstrating the issue.

Thank you for your video. It shows that things aren't as bad as we imagined from your initial post.

Yes, redrawing a tree with a large number of elements (the folders panel) is indeed not that simple and requires a lot of calculations. As a result, resizing that doesn't affect the folder panel (on the right or bottom) is faster, while other resizing directions are slower.

We don't think this is a big deal: it's unlikely that anyone's work involves constantly resizing the FRV window, and a one-time resizing can be tolerated.

Nevertheless, we will try to implement deferred redrawing of the window's internal contents when resizing. This should reduce the number of redraws during resizing, and therefore, resizing will be faster.

Implementing this feature will take some time; it's difficult to say exactly how long that will take.

--

Alex Tutubalin/FastRawViewer team

Thanks for the update. 
It's not so much the resizing for me but rather window moving (whose performance is also affected). I would argue that being able to multitask and play nicely with other windows/apps without much friction is a reasonable expectation while working and that sometimes involves window organization.
I understand that it might not be a priority to fix, though, since it doesn't really make FRV unusable and that's fine.
A few more things to note:
1. Even with all of the left panels closed (including the Folders panel), the issue still persists. And it's still slower if my RAW parent folder is expanded before closing the folders panel. Maybe something to consider when optimizing the redraw.
2. The biggest slowdown seems to happen when expanding my RAW+JPG library which has a lot of subfolders. But doing the same with other folders with a large number of subfolders that don't contain RAWs (such as music libraries organized into artists > albums subdirectory tree) doesn't reduce performance. Could it be affected by the contents of the subfolders rather than the number of subfolders themselves?

Add new comment