Qt (maybe 5) became sluggish recently. Any ideas why?
-
In the last week or so something happened and any program that uses qt became sluggish when rendering "open file" dialog windows. It's even slower when I click on bookmarked locations in these dialog windows. I made a video of that slow performace, hopefully this will help you see the problem.
My hardware is not the problem, of that I am sure bc in the last 8 years (ever since I built this computer) I never had such a problem with any software, qt included.
https://www.mediafire.com/file/x2d7xablfgsg94y/simplescreenrecorder-2023-10-09_17.57.56.mkv.zip/file
-
Hi,
Any chances you have now network discs connected to your machine ?
-
@SGaist Nope, nothing like that.
[rado@arch]: ~>$ listdisk NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda └─sda1 xfs 1000GB 748b51b7-bca4-46e8-bffe-da71c4bf053a 643,4G 31% /media/1000GB sdb ├─sdb1 ntfs Windows 10 7D602C160768142A └─sdb2 ntfs 420GB 6B5CAACE7C089605 239,5G 39% /media/420GB sdc └─sdc1 xfs Arch 1a2db951-3fc5-4880-9e2a-be94175245eb 87,6G 22% / sdd └─sdd1 xfs 1000HD d3e0a4a4-69b8-4c1b-9b25-2f2ba17faa54 487,5G 48% /media/1000HD sde └─sde1 xfs 4000GB 2187e619-dee6-4a99-9b16-512f456df9e6 2,8T 23% /media/4000GB sdf ├─sdf1 exfat 1.0 Ventoy B46D-C682 └─sdf2 vfat FAT16 VTOYEFI 79CB-53D7 sr0
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
became sluggish when rendering "open file" dialog windows
If not done explicitly differently by the programmer these are nativ Dialogs & API calls.
Did you update your system ? or drivers? Do you do that manually or maybe it happened automatically ?
-
The most of strace (I ran kolourpaint) is full of EN0ENT about missing icons from hicolor and breeze but I doubt that's what causing the sluggishness, cuz I've always used these programs without their icon themes and never had this problem before.
The rest of the strace is in this text file. It's way too long for the code tag, so I figured I'd put it in a text file: https://www.mediafire.com/file/i30uf1hssfqii4f/strace-of-kolourpaint.txt/file@JonB , I thought that me using Qt software kind of implies that I'm running Linux (Arch, if it matters what kind of linux), so I didn't think it was necessary for me to say that. Qt is a Linux-only thing.
@J-Hilk, I do the updates manually, nothing is automated. The nvidia driver has been the same for about 6 months (525.89.02) and will continue to be so until nvidia finally fix their hundreds of problems. The kernel is LTS, if it matters. Whenever there are qt updates, I let it update everything there is to update.
-
@JonB If it's not a linux-only thing, I couldn't know that. The Windows 10 you see above in the disk listing exists there only for 2 games that won't run properly in linux, it has only audio and video drivers and nothing else. For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
So when drawing with MS Paint every day, you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool? :)
Well, haha, some might say that the truth is not far off, but you'll get the point :)) -
@Pl45m4 "you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool?"
It IS, I don't have to assume anything. I used to be a Windows sheep for 20 or so years - since 1996 until 2015. The proof that the whole Windows is bloated?Arch Linux installation with ALL the programs I need and use every day (they're about 20 or 25 programs) - 24.1 GB.
Windows installation with just audio & video drivers and nothing else - 31.1 GB.If that's not bloated, IDK what it is. :D
But that's not what I came here to discuss, so let's leave it at that.
I'm more interested to know which qt5 and qt6 packages control these dialog windows that get sluggish. Maybe if I downgrade the packages, the dialogs will return to normal performance.
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
I'm more interested to know which qt5 and qt6 packages control these dialog windows that get sluggish. Maybe if I downgrade the packages, the dialogs will return to normal performance.
There is no such "package". As @J-Hilk said here:
If not done explicitly differently by the programmer these are native Dialogs & API calls.
the OS is triggered to show an "open file dialog", like the one you would see when browsing for a file in Windows Explorer
-
@Valso
There are both "native" and "Qt" versions of "File Dialogs". Which one is used is determined by you in code (where available, some functionality uses only one or the other). You might start by identifying/discovering which one your code uses.If it is the "native" one then whatever problems likely lie there, not in Qt code.
-
@JonB They all look exactly the same way (like on the video in the first post), no matter the program, that's why I thought it was a single package that controls/renders them and also that's why I thought the cause was qt. Qt is the only thing in common these programs have. It can't be a coincidence that the dialog window looks the same way for all qt programs and is equally sluggish for all of them: kolourpaint, mkvtoolnix-gui, audacious, qbittorrent, smplayer, simplescreenrecorder, etc.
I wish there were a way to force "native" on qt programs, cuz the GTK dialogs work just fine.
Edit: I just remembered about qt5ct and qt6ct. Maybe there IS a way, after all! :D
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
I wish there were a way to force "native" on qt programs
There IS :)
QFileDialog::DontUseNativeDialog
Don't use the native file dialog. By default, the native file dialog is used unless you use a subclass of QFileDialog that contains the Q_OBJECT macro, or the platform does not have a native dialog of the type that you require.
You have to force not to use the OS native file dialogs
-
@Pl45m4
"You have to force not to use the OS native file dialogs"Actually, that's exactly what I did. IDK about Windows, but here on Arch Linux there's no such a thing as "native file dialogs". The dialogs type depends entirely on the desktop environment and since I'm using Cinnamon (a fork of GNOME) with a few programs from KDE Plasma, the "native dialogs" are those of GTK. The few programs from KDE Plasma use qt (KDE Plasma runs on qt as well) but with the help of the small programs named qt5ct and qt6ct, you can force them to use the GTK file dialogs. I simply had forgotten about their existence. Now I installed these two and forced them to use the GTK file dialogs, so no more waiting for an eternity for the dialog to load. :D
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
Now I installed these two and forced them to use the GTK file dialogs, so no more waiting for an eternity for the dialog to load.
Then it sounds like a problem of KDE and not Qt. Yes, KDE is closely related to Qt, but it also extends Qt. Most likely it provides its own "native" file dialog for Qt. There is a difference between plain Qt programs and KDE programs. And you were (almost) right initially that KDE would imply Linux as OS, but Qt actually does not (as mentioned before). (Just for completeness sake: the official KDE programs are also available on Windows. I even have Kate installed.)