SUMMARY Observed in Angelfish, but probably similar in other places. Using style Plasma and having BusyIndicator running leads to general slow down of application. Its not minor and, in case of Angelfish, makes it very slow. Just setting BusyIndicator to false removes this effect. Same was observed by few other styles with Default being an exception where BusyIndicator did not have an impact on Angelfish, as far as I can tell. Material, Fusion, Universal - all led to slowdown. This was observed on Sailfish OS device, running via Flatpak. From searching Bugzilla, similar has been observed earlier as well: https://bugs.kde.org/show_bug.cgi?id=373368 Probably some more careful implementation will be needed to reduce the animator impact. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Sailfish OS 3.2.1.12, KDE 5.12 Flatpak runtime
Might be nice if we could move to a GPU-accelerated circular graph or something.
The most likely cause of this is a lack of vsync in whatever driver your system uses. There are a few related bugreports, but for example https://bugreports.qt.io/browse/QTBUG-59300 mentions how animations will run as fast as they can when vsync is disabled. There are also some KDE bug reports related to that, but I can't quickly find them at the moment. FWIW, the implementation of the BusyIndicator basically just rotates a single item. Assuming Plasma.SvgItem does nothing silly, this is pretty much the maximum performance you can get for such an item.
You can test if it's the known vsync issue by setting the render loop to basic in kcmshell5 qtquicksettings
Also, as I'm curious if we can fix it, output of sudo cat /sys/module/nvidia_drm/parameters/modeset
Since this is a Sailfish OS (so presumably ARM) device, I doubt that is going to provide anything but "file not found". :)
Its ARM device, no nvidia here. As its using libhybris (originally Android phone), no surprise if something is off on GL level. So, vsync suspicion makes sense. Any tips on how I can check whether vsync works properly?
As David mentioned: (In reply to David Edmundson from comment #3) > You can test if it's the known vsync issue by setting the render loop to > basic in kcmshell5 qtquicksettings
Alternatively, launch with QSG_RENDER_LOOP=basic
QSG_RENDER_LOOP=basic has been tested and improved the performance. Sorry, that we did a while ago while discussing at Plasma Mobile IRC. Question is where its set in Qt or GL, so I could start digging into why its wrong.
It's a Qt only variable, GL has little to do with the render loop. Since you mention flatpak, most likely that overrides or ignores the value.
Thanks! I presume that variable is acquired from underlying video card. Do you know how that's done?
The default for the render loop is primarily based on platform. It will check to see if threaded OpenGL is available and if so, default to the threaded render loop. See https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/qsgrenderloop.cpp#n223
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
As it sounds like its an issue with the hardware port that I use, I am closing it here. If it will be found that it's more general issue, we can always reopen it. Thanks for all the help!