https://bugs.kde.org/show_bug.cgi?id=327891
Tuomas Nurmi <tuo...@norsumanageri.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tuo...@norsumanageri.org
--- Comment #35 from Tuomas Nurmi <tuo...@norsumanageri.org> ---
I've had a look at this, too, while working on other CPU usage improvements (
https://invent.kde.org/multimedia/amarok/-/merge_requests/98 ). I don't know if
this is more common with Qt5 than it was earlier, but at least I'm experiencing
notable CPU usage caused by current track indicator with Nvidia, Intel and
VirtualBox systems.
Analyzing a bit deeper, the two major factors of the load seem to be the fact
that a redraw is requested approx 444 times every second (although the actual
rate of repaints is limited by the UI update rate, which seems to be something
like 30 FPS), and the fact that every repaint involves building the currently
playing delegate from the ground up, including text rendering, possibly cover,
moodbar, and rating painting, and rendering the pulsating overlay svg pieces.
As the playlist is QWidget based, optimizing the repainting or offloading some
steps to GPU is not quite as straightforward as it could be with some other
technical implementations. Limiting the repaint rate to e.g. approx 10 FPS
would reduce the CPU usage somewhat, although it still seems to remain
notable.
I'm considering limiting the FPS as short-term solution, as the effect on
visuals doesn't seem to be that bad. Assessing the technical foundations of
playlist painting might be something to do during/after Qt6 port.
--
You are receiving this mail because:
You are watching all bug changes.
