XnView Software

Upgraded from 1.8.3 to 1.9.2. When vieweing images in fullscreen, changing to the next or previous image has a load time depending on the size of the image. I was able to downgrade and the load time is gone.

could you describe the problem?

@Pierre,
I think I know exactly what the OP is experiencing, since I have the exact complaint, though I haven't written a bug report yet: Ever since precisely those days of 1.8.3 or so, in one of the changes -- I think probably to the 1.9.x or perhaps one of the previuos one, I can't tell now -- I noticed immediately that the program became much, much slower in rendering directories, and in operations as simple as Save as... or selecting a portion of the image and then Save as..., etc.

The situation is, that first, just entering in any directory that has several hundreds or much worse when it's thousands of pictures, the program becomes completely irresponsive for many seconds more than it used to be. Same for the operations that I mentioned before: When I select a portion of an image that is in full mode, then Save as..., then the program is again frozen for many seconds: one can see only the exterior frame of the Save as... dialog, and only after several seconds, in my case sometimes between 5 and 10 seconds, depending on the directories' sizes, (can go to more than 30 seconds if huge directory of ~6000 or more files), then the dialog is visible and accessible for keyboard input. This is a very big difference compared with the previuos version (around 1.8.x). Also, when in full screen mode, to make "Copy to...", (something which I have been doing intensely in every session, since many years, thus my experience is significant), I have to wait about 4 seconds of irresponsive program to get the "Copy to" dialog visible and available for input.

I have been delaying to make a bug report on this, even though it's extremely irritant and disrupted, because I no longer have any of the installers of the old versions, to determine exactly which one was the "good" one and when this annoying problem started. I have tried going to this forum, to the change log section https://newsgroup.xnview.com/viewforum.php?f=115, where there are links to the AppImages of older versions, I downloaded several of them and started doing experiments, only to find that there were no difference: All behaved bad. That's strange, I thought, but then I realized: All AppImages links there point to the LATEST version! So all the 6 or 7 files I downloaded from this site are exactly one and the same: the v1.9.3.

So I wasted a lot of time.

But I can guarantee you that the only thing that changed in my system was the XnView version, when all of a sudden the program became very slow and annoying with those operations, the exact moment when I installed and tried the newest deb of that time, exactly as the OP describes. To the point that I wanted to downgrade, but I had already deleted the older debs.

That's something that now I can't do, since you don't provide the older AppImages (I don't know about the deb installers). If I would have an old deb installer, I would not like to downgrade that way, because it's already integrated with the whole apt system, but if I would have access to AppImage files of older versions, then I can easily run tests to compare and as possible to measure timings.

However, all in all, you know exactly what you have done in those new versions, and it must be easy for you to guess what can be contributing now to delay so significant those actions, anything that may block the GUI while accessing the directory and listing their files or whatever that you were not doing in older than 1.9.x . You can test yourself, just create several directories with say, at least 2000 files each (the more, the better and easier you'll see what I mean), and then spend time just doing those operations. Tell me if you don't see your program irresponsive for a longer time than before.

Please try to reproduce the issue yourself, because I have little time to do troubleshooting and write bug report, plus I don't have the AppImages. I have already filed a bug report on another issue that I am sure it must be related, in any case, to the bad performance in general, please have a look: https://newsgroup.xnview.com/viewtopic.php?t=49512

Thanks a lot for putting some attention to the issue of performance!

xnviocumo wrote: Thu Aug 21, 2025 7:49 pmI no longer have any of the installers of the old versions

Previous versions

xnviocumo wrote: Thu Aug 21, 2025 7:49 pm Please try to reproduce the issue yourself, because I have little time to do troubleshooting and write bug report, plus I don't have the AppImages.

I've tried on ubuntu 24 to reproduce, but no problem with a big folder, and no delay with 'save as'. The 'save as' dialog is the one from system.
Please try an older version?

@user0, Thanks for the link
@Pierre, I will try with the AppImage of older versions vs the AppImage of latest version. I don't know whether there's a difference in performance between an AppImage vs installation via .deb file, but if there would be (probably not), it would affect all versions in the same way, so I hope this test is useful. Thanks

Hi Pierre,

I have performed a set of extensive and carefully thought experiments. The detailed report is too big to post it here, so if you agree, I'll send it to you via PM. There you'll find what exactly I did and why my conclusions. I think it is better to put here just a summary of the main conclusions, while you can study the details. Let me know. Meanwhile:

Conclusions of the experiments

These are facts that were very clearly established:

1. Versions 1.9.3 and 1.9.0, (the first installed via .deb file via `apt install` and the other is an AppImage), have significant performance issues compared to AppImages versions pre 1.9, I tested intensively v1.8.2 and v1.8.8 AppImages. That in fact, confirms the original post of this thread.
Note, again, that I have not tested installed pre-1.9.x versions in these experiments: only AppImages of those. However, I can assure you that the versions tested behave exactly as my previously installed 1.8.x versions and older did (dozens of them), with the same "speed" or performance that I have been used to since long time. (I would have complained long ago, if they weren't )

2. Having tested the following methods to launch the program:
- From terminal: Enter either with `xnview`, or `/opt/XnView/xnview.sh` for installed version, or `/path/to/XnView_MP....AppImage`;
- From double-clicking the original XnView.desktop launcher for installed app, or by creating a XnView.desktop launcher for AppImages and double-clicking that, or by simply double-clicking the icon of the AppImages;

It was demonstrated, in all cases, but with one notable exception (see below), the results of the experiments are consistently the same: versions 1.9.x (installed or AppImage) have a bad, slow performance in basic tasks (refer to my report), compared to "older" versions pre 1.9.x, which have a significantly better performance in the exact same tasks under the exact same conditions. This has been determined with numerous repetitions on the same environment.

UPDATE 2025/08/26 - 00:48: This part of the conclusions mentioned an exceptional case. The case exists, and continue to be exceptional, but after more and more testing, it is not possible to always reproduce it -contrary to the other conclusions, which have been always reproducible-. Therefore, I have removed the mention to the exceptional case, because not being 100% of the times reproducible, it doesn't add much. The extra testing has only confirmed the above conclusions.

That said:
I can say with absolute confidence, that something has changed in the newer versions, for sure after 1.8.8, (both .deb installer and AppImages), which creates conditions for a noticeably poor performance in basic tasks -at least under certain conditions. The pre-1.9 branch, at least tested in AppImages, continues to perform normally as it was always the case (that's what the OP basically says). It may be the case that these problems are more noticeable in certain systems and/or conditions (e.g. operating system and/or desktop, amount of directories, amount, type and size of the image files, etc.) and perhaps this is not affecting everyone, but the problem exists and it was introduced with the new branch.