Version: unspecified (using KDE 4.6.2) OS: Linux When progress bar widget is animated (for example refreshing of available space indicator in Dolphin or in copy / move files dialog) then process X tries to use all available CPU resources (in case of Pentium 4 HT it uses 100% of one of virtual cores). It happens in both cases of animation, for known and unknown percentage and doesn't happen when progress bar is still (for example when free space is known in Dolphin). Also it doesn't happen when desktop effects are disabled. Tested on Radeon HD 5570 with Catalyst 11.3 (happened also on 11.2, but then I didn't noticed that it was caused by progress bar...), I've not tried to reproduce this with open source driver. Reproducible: Always
Hello, Could you also check with other styles (in order to know if this is oxygen specific, or lower level) Thx
I've checked CDE, Motif and Plastik, all of them cause increased CPU usage by X (jump from usual 5% to around 15%) for file copy dialog, and in case of free space indicator in Dolphin it jumped to around 11% (with Motif). After switching back to Oxygen I can reproduce this again: - 50% usage (one full core) for free space indicator - 25% usage for copy file dialog
Thanks for the double checking ! One more checkpoint (if you don't mind), since with my (Intel) driver I don't have such high cpu usage: could you try oxygen-demo (from konsole or krunner), and report the CPU usage for the previous to last tab which is named "sliders", and has an animated progressbar in there ? I'd use this (and comparison to my perfs) as a benchmark for possible improvements (here X uses about 25% CPU and oxygen-demo about 10%, on a dual core). Thanks ! Hugo
I can say that this doesn't happen on Intel graphics (I've switched from i915 recently), or at least for it didn't caused full core usage for me (probably using the same packages, my package manager get broken around that time ;-) ). Slider in demo causes around 33% (X) and 12% (oxygen-demo) CPU usage (both cores combined), when moving vertical or horizontal slider (using drag and drop) it takes around 35% (X) and 14% (oxygen-demo).
ok. Thanks a bunch. With this at hand I should be able to improve things. Will keep you posted
Thanks. :-) I hope that if there will be improvements then these will be backported to 4.6.x, if possible (my distribution will most probably stick with that branch for next major release...).
Could you try to run "oxygen-demo --style Oxygen --graphicssystem raster" As far as I know, non-linear gradients are extremely slow with the X11 drivers.
Yes, this helps, around 15% (combined) CPU usage by X.
@Christoph, Michal "As far as I know, non-linear gradients are extremely slow with the X11 drivers" That's the part I am confused about. As far as I know both the progressbar handle and hole are cached into pixmaps. So as soon as the caches are filled, it is all about copying pixmaps around. (and the cache is full immediately for animated progressbars since both hole and handle are fixed size. Besides, copying pixmaps around is all over the place in oxygen (since pretty much everything is cached), so that I would have expected *everything* to be slow. This to say, not sure how much more optimization I can do here ...
After upgrade to post KDE 4.7 packages and with Catalyst 11.6 it works fine.
*** Bug 279583 has been marked as a duplicate of this bug. ***
Same issue with nvidia binary blob.