| Summary: | Progress bar widget animation causes 100% usage of one CPU core when using Catalyst driver | ||
|---|---|---|---|
| Product: | [Plasma] Oxygen | Reporter: | Michał D. (Emdek) <emdeck> |
| Component: | style | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | cfeck, hugo.pereira.da.costa, sven.burmeister |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Mandriva RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Michał D. (Emdek)
2011-06-06 19:11:04 UTC
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. |