(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
Code: Select all
QT_QPA_PLATFORMTHEME=qt5ct /path/to/your/xnview.sh
* 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
(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
Code: Select all
# Inside AppRun
unset QT_QPA_PLATFORMTHEME
# ... launch binary
[ ] 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.