I will try to make a video …for me it is the most severe in edit as well…so if I use the short cut or arrow to go to the next image it can almost refuse to go…then I press a few times… i found zooming with the mouse wheel trigger the main display to update. Many times the top left preview would finally update but not the main one…
I guess this should almost be moved to a new thread and I will also try to play around later or tomorrow and be more specific and show as you did with a short video…
Here is short video… these are simple jpg files…
Ill try to test on Linux tomorrow…when I find some time…
In case its hard to see I am mouse wheel scrolling to trigger the main preview update…
I don’t normally use Windows, but on my Linux machine everything works as usual. I’ll try in a VM asap…
I can reproduce this with official build and jpgs. Allthough it seems faster on my PC. It’s also when entering a photo from file browser. And a left-click is enough to trigger updating the edit view. I feel like having seen this bug before…
.
.
Edit:
My directory has the JPG raw pairs but I will look at folders with only one or the other
Maybe related?
I can confirm all good on linux. I have PopOS on a second drive on the same machine…its fast and behaves as I remember…
Looking at the build info it is compiled on an older version of GCC…
Version: cd9ef5025
Branch: master
Commit: cd9ef5025
Commit date: 2022-09-20
Compiler: cc 11.2.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: 3.24.5
Lensfun: 0.3.2.0
Exiv2: 0.27.5
LCMS2: 2.12
LibRaw: N/A
OpenColorIO: N/A
Build type: release
Build flags: -std=c++11 -ffp-contract=off -march=native -Werror=unused-label -fno-math-errno -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags: -march=native
OpenMP support: ON
Mi-malloc: N/A
Build OS: Linux
Build date: 2022-09-21T05:39:08Z
EDIT:
This was WIndows…
Version: 1.16.2-18-gcd9ef5025
Branch: master
Commit: cd9ef5025
Commit date: 2022-09-20
Compiler: gcc 12.2.0
Processor: alderlake(hybrid)
System: Windows
Bit depth: 64 bits
Gtkmm: 3.24.6
Lensfun: 0.3.95.0
Exiv2: 0.27.5
LCMS2: 2.13
LibRaw: 0.21.0
OpenColorIO: 2.2.0
Build type: release
Build flags: -std=c++11 -ffp-contract=off -march=alderlake -Werror=unused-label -fno-math-errno -Wl,–stack,4194304 -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -Wno-aggressive-loop-optimizations -DNDEBUG -O3 -ftree-vectorize
Link flags: -march=alderlake -s -O3
OpenMP support: ON
Mi-malloc: V1.7
Build OS: Windows
Build date: 2022-09-20T16:16:54Z
Another data point…
It takes anywhere between 10 and 30 seconds to move from one image to another, all are local images on my SSD.
Hi all,
can you try with this version for windows? Just uncompress it somewhere run:
https://drive.google.com/file/d/1_xndvWPO-qUfQJR8lZzrjiahh2zhoyKa/view?usp=sharing
Thanks!
No noticeable speedup in the file browser for me.
I was more concerned with the lags in the editor, sorry if that was unclear
You mean this switching between jpgs stuff? This has not changed either.
Thanks for checking. On my windows VM I see none of the two effects, everything seems to work as normal…
I tried 1.16.2 in a W10 VM-Ware-Player. Indeed the switching-jpg-issue did not occure. But the file browser is incredibly slow.
I’ll try building 1.15 with the current toolchain. If that is still slow, it might indicate that the problem is not caused by a change in art. Because honestly I have no clue what it might be otherwise 
Downloaded your google link.
I don’t really find the browser window to be slow but the editor is messed up for me on Win 11.
So I now still have the editor issue… I have a folder with DNG and the matching jpgs. If I select next image and the image is a raw it will advance and load…still really slow but it will… the jpg I have not been patient enough to see if it will advance without me triggering it by altering the zoom…
Much faster for me in general when moving through images while in the editor (~5 seconds, maybe a tad less).
However, in the browser the sort order is a bit unexpected. 
Note it’s set to filename order, but it sorts with two outliers up front:
IMG_1337.CR3
IMG_3564.CR3
IMG_0343.CR3
IMG_0607.CR3
IMG_0855.CR3
…and correctly thereafter.
Do I need to hang onto this zip or will you make an official release?
Thanks.
I need to understand what is going on before a new release…
Just to rule out any weirdness in the files they sort correctly in other contexts, for example here in XnView MP:
…and so forth. 0343 is the first file as expected.
Thanks.
Uh Alberto… don’t waste your time. There’s something weird going on with my instance. 
i launched the 1.16 release version and it sorted correctly except now it puts IMG_0343.CR3 (only) dead last when sorted by filename. I changed the sort order to a few others and back with the same results. But after I renamed my personal folder and relaunched, it sorts correctly. Weird…
So something is going on with my installation. I’ll have to track that down…