| Summary: | BusyIndicator stresses CPU | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] libplasma | Reporter: | Rinigus <rinigus.git> |
| Component: | components | Assignee: | Marco Martin <notmart> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | ahiemstra, kde, nate, plasma-bugs-null, rinigus.git |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Rinigus
2020-02-02 10:24:43 UTC
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! |