XnView Software

Posted: **Thu Aug 28, 2025 9:17 pm**

XnView: MP 1.9.3 64-bit (Linux) - Libformat 7.226
(Installed with the .deb package)
OS: Ubuntu Linux 22.04.5 LTS (64bit)
Kernel 6.8.0-65-generic
Desktop: Xfce v4.16

1. Description of the Problem

On my system (Ubuntu 22.04, Xfce desktop), XnViewMP v1.9.x is extremely slow when entering directories with many files. The older v1.8.x versions do not have this issue.

The key symptom is that the "slow" version (1.9.x) uses my system's native icons (from my `qt5ct` theme), while the "fast" version (1.8.x) uses its own built-in icons.

As explained in details below, this issue is a regression.

This issue is demonstrated for Ubuntu 22.04 LTS, (I have not tested on newer versions), but 22.04 LTS is a major distribution officially supported until 2027.

2. The Root Cause

The performance slowdown is caused by the application using an external Qt platform theme engine. This is triggered when the `QT_QPA_PLATFORMTHEME` environment variable is set, which is common on desktops like Xfce, Cinnamon, or MATE where users try to unify the appearance of Qt and GTK applications.

My analysis: Not existing an obvious configuration in `xnview.ini` that controls the use of the system's platform theme, this doesn't look like a settings issue, and if so, the application's behavior is decided purely at runtime based on the value of `QT_QPA_PLATFORMTHEME`. In this case, the sequence goes like this:

i. - XnView's startup script forces the system to use its bundled `libqt5ct.so` because of the `LD_LIBRARY_PATH`.
ii. - That bundled plugin then loads the configuration files (e.g., `~/.config/qt5ct/qt5ct.conf`) that were created by the user's system version of `qt5ct`.
iii. - The v1.9.x application and its bundled `qt5ct` plugin has a problem interacting with the environment it's given, — a valid environment that v1.8.x and older handled well.

While this makes the app look native, this theme integration appears to have a significant performance overhead in XnViewMP, causing the slowdown.

3. How to Reproduce the Issue

The issue occurs on GTK-based desktop environments when a Qt platform theme is used to make apps look native. The most reliable way to reproduce this is on a non-KDE desktop (like a standard Ubuntu, Xfce, or Linux Mint installation).

* Step 1: Set up the Environment
On a GTK-based test system (or a virtual machine), ensure `qt5ct` is installed.

Code: Select all

sudo apt update && sudo apt install qt5ct

* Step 2 (Trigger the "Slow" Behavior): Launch XnView from a terminal, forcing the qt5ct platform theme.

Code: Select all

QT_QPA_PLATFORMTHEME=qt5ct /path/to/your/xnview.sh

Navigate to a large image directory. You will observe the slow performance and system-style icons.

* Step 3 (Confirm the "Fast" Behavior): Launch it again, but with the variable unset.

Code: Select all

QT_QPA_PLATFORMTHEME= /path/to/your/xnview.sh

The same directory will now be fast, and the icons will be the application's built-in ones.

(Note: If you are testing on KDE Plasma, your system uses a different native theme engine, so setting `QT_QPA_PLATFORMTHEME=qt5ct` may not work. Testing on a standard Ubuntu/Xfce/Mint system is the best way to see the bug.)

4. Suggested Solutions

This issue can be resolved by preventing the application from using the external theme engine. Here are a few potential solutions, from simplest to most robust:

4A) For the `.deb` Installer: Modify the /usr/bin/xnview launcher script to unset the variable. This is a simple and effective fix.

Code: Select all

   #!/bin/sh
   unset QT_QPA_PLATFORMTHEME
   # ... rest of the script

4B) For the AppImage: The internal AppRun script should always unset this variable. This is a common best practice for AppImages to ensure they are stable and look consistent across all systems.

Code: Select all

  # Inside AppRun
  unset QT_QPA_PLATFORMTHEME
  # ... launch binary

4C) In-App Option (Most Flexible): Add a checkbox in the Settings > Integration panel:

[ ] Use native system theme engine (may impact performance)

By default, this should be unchecked. When unchecked, the application should programmatically ignore the variable. This gives users who prioritize appearance over performance the choice, while ensuring the default experience is fast for everyone.

A Note on System & Library Versions:

As stated earlier, my testing is on Ubuntu 22.04 LTS, a widely used and fully supported OS.

I understand that the issue might even be a compatibility conflict between the libqt5ct.so plugin is bundled with XnView v1.9.x and the existing qt5ct configuration on my system.

However, this is still a regression, because the plugin bundled with v1.8.x worked perfectly with this same system and configuration. Even if the v1.9.x plugin would be "newer," it should ideally be backward-compatible with the settings generated by tools on a major LTS platform, or at the very least, fail gracefully by disabling itself instead of causing a severe performance drop on unaware users.

I hope this detailed report is helpful. By addressing this, you can ensure a fast and reliable experience for a wider range of Linux users.

Thanks for your time and dedication to this great software.

Posted: **Fri Aug 29, 2025 1:29 pm**

Thanks for the feedback...

xnviocumo wrote: Thu Aug 28, 2025 9:17 pm 3. How to Reproduce the Issue

I've tried with a new VM with ubuntu 22.04 (6.8.0-79-generic) with xfce, Xfce v4.16.1, qt5ct installed, 1.9.3 tgz and using QT_QPA_PLATFORMTHEME=qt5ct, i can't reproduce slow performance in XnView
could you try QT_DEBUG_PLUGINS=1?

Posted: **Sat Aug 30, 2025 8:34 pm**

Hi Pierre,

The logs

I have run XnView 1.9.3 and collected the logs by executing the following command

Code: Select all

QT_DEBUG_PLUGINS=1 /opt/XnView/xnview.sh > /tmp/logs-xnview_sh_original-with-QT_DEBUG_PLUGINS_set 2>&1

I'll upload it to you in an PM. It's a huge log, 23261 lines, just by opening two or three directories, waiting for them to be available in browser view, then double clicking one file, selecting a small area, hit `Save as...` and waiting an eternity until the dialog was fully drawn and the cursor was responding; then back to browser view and close the application. After that, I had to write an script to process those logs to "anonymize" the names of my personal directories and filenames, keeping the extensions, (not affecting any system XnView related filepaths or any other strings) while maintaining the full logic and coherence of the paths and the logs. So when you see paths that look like

Code: Select all

/word_0/word_1/word_2/word_3.jpg

it's a file that perhaps was something like

Code: Select all

/home/myuser/Pictures/somefile.jpg

, thus the words are irrelevant to the logs, except for the extensions, which I left intact, of course.

Reproducing

I am sorry that you were not able to reproduce the issue. Perhaps my own instructions to reproduce it are not detailed enough. So, for exampled, perhaps I should include other conditions, such as the need of configure the "Style" and the "Icons" in the Appearance section of the xfce Settings with the same values I have: In Style, I use Xfce-Simple-Dark, and in Icons, I use a Qt theme, Korla "dark icon theme for Linux desktops".

I also have Qt programs installed, such as Dolphin and Konqueror, which is the main reason I (or any other like me, who combines KDE programs in their Xfce/GTK desktop).

Please see if you can mimic at least those conditions, which I failed to include in the procedure.

I have spent so much time investigating this.

The incompatibilities for Qt widgets to look nice in a GTK system and vice-versa is an ancient battle no one has solved and probably never will. The only possibility is being done: using frameworks, such as qt5ct and some clever workarounds by programs to try and make it look nice in different desktops.

But regardless of whether we find the exact combination of configurations and environment that aren't supported by the new branch, (and remember, the original complain of this issue came from another user), it doesn't mean that there won't be other situations where someone has yet another way of configuring their desktop (using official procedures, not crazy hacks), and will get back again to this sort of complaints. It's not possible to cover all possible configurations of themes and icons that might not play well with XnView's bundled `qt5ct` platform theme.

In worst case, if it's not possible to have the program itself fail nicely with incompatibilities like that in runtime, the most flexible proposal that I make in the bug report, might be a good compromise: some checkbox where the user could easily say "hmm, it's rather slow. I'm gonna try not using the native system enging". And also, if some day later an user complains about something similar, someone in the forum could just suggest "Please try that option".

In case you try again with my configurations and still no luck, then I could try in another computer, although the challenge is the same: to discover one exact combination of configurations Qt/GTK that XnView 1.9.x doesn't like, and hope that's the only one.

Ultimately, not many people are willing (or have the skills or the time) to report this issue, even if they have the problem.

It would be very important if others who have had problems would contribute to this investigation. Just by saying "me too", would be a great help. But even in the original complain the user apparently "resolved" with a downgrade to 1.8.x.

Thanks again for your efforts and tremendously hard work!

XnView Software

1.9.x: Significant bad performance on some Linux Xfce/GTK Desktops

1.9.x: Significant bad performance on some Linux Xfce/GTK Desktops

Re: 1.9.x: Significant bad performance on some Linux Xfce/GTK Desktops

Re: 1.9.x: Significant bad performance on some Linux Xfce/GTK Desktops