Version: 2.3.0 (using Devel) OS: Linux While playing a song and the Amarok window is not minimized, kwin and xorg CPU usage rises to between 50% and 80% each. If the window is minimized, or Amarok is not playing, CPU usage falls down to single digits. If the window is minimized but a preview is invoked either through the taskbar or through window switching (cover flow, present windows, slide), CPU usage spikes again. If the window is hidden behind another window, the problem persists. Switching to the slim toolbar and removing all dynamic content panels had no effect. Reproducible: Always Steps to Reproduce: 1. Play a song in Amarok 2. Observe kwin and xorg CPU usage spiking 3. Minimize Amarok 4. Note kwin and xorg CPU usage dropping to near zero. Actual Results: Abnormally high CPU usage in graphical components (kwin, xorg) while Amarok window is not minimized (i.e. not updated actively). Expected Results: CPU usage should not be affected by one more window with barely a slider moving in it. Lenovo T410 with nVidia NVS 3100, binary driver from repos Ubuntu 10.04.1 x64 with KDE 4.5 RC2 installed from kubuntu-ppa/beta Compositing is enabled, various visual effects are in place including transparency (on decorations, too) and blur
CoverBling, not CoverFlow :) Could you please remove the CoverBling applet (or remove selectively the other applets and check if that still happens? JFYI, CoverBling has been currently removed from 2.3.1, it will be implemented differently.
I actually did remove all applets from Amarok one by one and switched to the simple taskbar before I posted the bug report and had every intention to mention it, just forgot to :) Also, I was referring to kwin's window switching effect by "cover flow", not Amarok's. Finally, it looks like I have the version wrong -- the package version is 2.3.0-0ubuntu4 but the About dialog in Amarok lists 2.3.1 (KDE 4.4.90).
That sounds strange, what does the Amarok -Help -About Amarok dialog tell you about the version?
Mystery solved. apt-cache shows both versions (official and ppa), d'oh. The version installed is indeed 2.3.1-1ubuntu1~lucid1~ppa1 (confirmed with dpkg --status amarok) which matches what the about dialog says: Amarok Version 2.3.1 Using KDE 4.4.90 (KDE 4.4.90 (KDE 4.5 RC1)) Sorry about the confusion.
Thank you for the feedback. Setting version and component back to general. I can't reproduce this here with 2.3.1-git, maybe someone else can?
Is this still valid? If yes, please run Amarok with valgrind: valgrind --log-file=$HOME/amarok.valgrind.output --leak-resolution=high --leak-check=full --num-callers=40 -- amarok -m -d --nofork and attach the output.
please activate kwin's "show paint" plugin. Whatever causes the flicker, causes your cpu load. (w/o any idea i'm willing to bet for either the notification area or the taskbar :-P )
When I enable this plugin, basically my whole screen is blinking (no matter what application is showing, even with an empty desktop). Does it mean that all this gets constantly redrawn?
Created attachment 51104 [details] valgrind output
i'm having the same problem, x.org cpu-usage skyrockets when using amarok. i attached the valgrind-info you wrote about. i'm using amarok 2.3.1 on lucid (64 bit). amarok keeps telling me that i'm using kde 4.4.2 but i updated to 4.5 recently...
Looks like a leak in mysql-collection
Um, no it doesn't?
i upgraded to the latest beta, but the problem is still there. just resizing the window eats up to 65% of my cpu... could this be a (nvidia) driver issue not related to amarok itself?
Yeah, I'm thinking Nvidia driver issue. Try disabling compositing, does it help? Here it reduced KWin's CPU usage drastically.
nope, x.org still eats up between 50 and 60% cpu...
Try changing window decorations from oxygen to something else - plastik for example.
I updated to KDE 4.5.1 and changed the windeco, but no effect.
Created attachment 52190 [details] Valgrind log Yes, changing decoration only helps a little. For me the bug is triggered no matter if the Amarok window is visible, or not. I've upgraded KDE SC, Amarok and Nvidia drivers, but the bug is still there. Attached valgrind output.
This is an automated message from the triager: Amarok 2.4.1 has been released on May 8 already. Could you please upgrade and test if you can still reproduce this bug? Without feedback within a month we will close this bug as resolved. Thank you for your understanding.
Closing for lack of feedback. Feel free to reopen if you can still reproduce this with Amarok 2.4.2 beta 1 or later and provide the necessary feedback.
Sorry for the late response, but the bug is still there. Please reopen.
Thank you for the feedback. Please test with the final release ASAP and report back. It should be released within a few days now.
*** Bug 263338 has been marked as a duplicate of this bug. ***
Can you all please test with Amarok 2.4.3 and report back?
It's getting better in my system. With KDE 4.7.0 and Amarok 2.4.3, I only get 4-6% of my cpu for the xorg process. It's a long way from the 30% I got with Amarok 2.4.0. As I explain in Bug 263338 (marked as duplicate of this bug), I'm pretty sure the problem is in Amarok's progress bar. If you make it disappear (detaching the main bar and setting the focus on another window), xorg drops to normal levels. Also, if you make the Amarok window very narrow, xorg drops a little bit too (the slider moves more slowly because the progress bar is shorter). The same effect of the slider speed can be seen when playing very long songs, compared to very short songs. With other programs, such as Kaffeine and SMPlayer, I only get 1% of the cpu for the xorg process, so I think there's still something going on with Amarok. But it definitely got much better, so I'm not sure this is still something to worry about.
Changing component to the taskbar.
"Toolbar" ;-) I cannot spot any abnormal painting in the toolbar nor high CPU load on X11 or kwin (meaning: "none") Please run "kcmshell4 kwincompositing", enter the "all effects" tab, filter "show", enable the "show paint" plugin (in case you suffer from epilepsia, be WARNED that this will cause some colored flicker on your screen - hopefully on low rate though) Check what part of amarok (toolbar) flickers most to spot the culprit. Of course whenever the slider moves, it has to cause a (partial) repaint. Do you use the moodbar? Is it related?
Sorry for the late response. I've created a short video of the amarok slider moving when a song is played, with the "show paint" plugin activated. You can get it here: http://magnes.we.lc.ehu.es/~dce/amarok_video.mp4 Hope it helps. BTW, I'm not using the moodbar, as you can see.
No, sorry. This does not explain high cpu load in the compositor at all. Is there no other _hefty_ flicker on the screen? (sth. has to cause the X11 + kwin load and that combo usually means repaints) @Mark (sorry, i missed that) > When I enable this plugin, basically my whole screen is blinking (no matter > what application is showing, even with an empty desktop). > Does it mean that all this gets constantly redrawn? Yes. The source is either a persisting fullscreen effect in kwin or some plasmoid updating the entire desktop (like animated wallpapers etc.) Both is not a fortunate situation as those repaints are quite expensive (either some large area is constantly damaged, causing a lot of texture_from_pixmap calls or the fullscreen effect keeps the compositor in the unoptimized painting, what's esp. a problem when you've eg. blurring activated)
Is any of you using kopete? With now playing plugin maybe?
Confirm for me. - Gentoo Linux, KDE 4.9.0, Amarok 2.6.0 - xorg-server-1.12.99.904, xf86-video-ati-6.14.6, ATI Radeon HD6450 + integrated ATI Radeon HD4200 (not used) Use CFLAGS="-march=amdfam10 -O2 -ggdb -pipe" I change windows decoration from Oxygen to Plastik and disable all effects - the same cpu load presents. Amarok plays tracks in Dynamic mode. At start Amarok was runned and played tracks with no hard usage X. Then Amarok window was shown and the music isn't played for several days. The Xorg usage increase upto 100%. When I quit from Amarok it go down to 30%. If after that I run Amarok the Xorg not increase usage immediately - it still on the 30% level. My problem not only in Amarok, because Xorg's cpu usage in top in Konsole varies from 15 to 40% with no action. But in the case of using Amarok described above, Xorg use 98-100% CPU. If I kill plasma-desktop process, the Xorg usage go down to about 5% (in case Amarok still running). After login Xorg uses about 5-10% CPU, after several days running usage increases to 100%. If I start plasma-desktop the Xorg usage won't grows immediately. Don't know if this is another bug. The problem appears a long time ago (many versions or KDE, xorg-server and Amarok before). Think I will try to run plasma-desktop for several days without any activity in KDE and witout running any GUI app (only linux daemons) to see if this problem repeats.
Use 3 virtual desktops if this info is important.
Created attachment 73557 [details] Xorg.0.log
Also will try with new user - default profile (.kde4 files) and attach ~/.xsession-errors
There's probably some bug in either plasma libs, a plasma containment or a specific applet that causes recursive painting. Use the show paint event to figure the most active screen area - whatever is there will very much likely cause the high Xorg load (the net/cpu/etc monitors used to be culprits) If this is time dependent (suddenly raises after some runtime) it might be due to an uncatched data/time update.
Created new user and try on it. Xorg load from start less than 1% with no action (5-10% Xorg CPU in the current user after logon). "Show Paint" event in current session doesn't work - see log. Also I noticed that in new user (new KDE settings from default) the following info is presented int the log but not in current user log: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAICOS OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 Driver: R600G GPU class: NI OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 8.0.2 X server version: 1.12.99 Linux kernel version: 3.2.2 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes In current user's log I found: kwin: unable to claim manager selection, another wm running? (try using --replace) Usage: kcmshell4 [Qt-options] [KDE-options] [options] module That says kcmshell4 didn't loaded. Should I determine the problem setting in .kde4? Or just clean up the settings to use default? What files should I read/clean for this action?
Created attachment 73561 [details] Current (problematic) user ~/.xsession-errors log
Created attachment 73562 [details] New user with defaults KDE settings ~/.xsession-errors log
Answer to my previous questions: 1. OpenGL part of log due to: "Configure deskto effects" -> "Enable desktop effects at startup" option. Compositing? 2. Show Point only works with "Configure deskto effects" -> "Advanced" -> Qt Graphics System: "Native" I deleted system monitor with 1 sec updates and showing seconds in time applet. Will wait several days of using and see CPU load.
not reproducible with amarok 2.6
Both Xorg and Kwin don't change their CPU usage when Amarok is playing, using v2.6.0-422-gfc07990
My problem was in using Qt Graphics System: "OpenGL" instead of "Native", so not reproducable for me too from now.
I've this bug using Amarok 2.8.0, KDE 4.11.2. Here are some sample numbers. When the Amarok window is open showing media sources, playlist, and context (just current track), Amarok usage is ~16%, Xorg usage is ~7%, and Kwin usage is also ~7%. When the Amarok window is minimized to tray, Amarok usage is ~3%, Xorg ~1%, and Kwin also ~1%. When I close the playlist view, Amarok usage with window showing halves, dropping to ~8%. Closing the context view doesn't improve anything. Could this be due to the "pulsating" current track in the playlist? System: AMD 5800K (quad core, 3.8Ghz), Catalyst 13.11 beta.
enable the "Show Paint" effect to see what repaints. If you set KWin tearing prevention to full scene repaints, naturally every even minor screen update has a a bigger impact.
The Show Paint effect shows constant repainting for the pulsating current track, the progress bar, and strangely the separator for the context, playlist and media sources views. I have tearing prevention disabled. I'm using OpenGL 3.1 with Raster compositing.
(In reply to comment #46) > The Show Paint effect shows constant repainting for the pulsating current > track > and strangely the separator for the context Sounds as if the window widget would repaint. What happens if you hide everything but the toolbar?
If I hide everything but the toolbar, I get the same cpu usage as having the media sources and context showing with only the progress indicator repainting. So it's really just the playlist window that's causing the usage. Also, if I pause or stop a track so that the current track isn't pulsating, cpu usage again massively drops.
Ok, checked it. So for clarification: The pulsating entry in the toolbar (artist -> title -> blafoo -> artist -> ...) - what this was once somehow assigned to - behaves as expected and causes zero overhead (cross checked with the slim toolbar) What causes massive repaints and all overhead is the pulsating of the current title in the playlist which repaints as fast as possible (for whatever reason - i don't really see any update)
Great. So can we indicate current track in a less resource intensive way? My laptop would greatly appreciate it :)
No idea - my entire house uses MPD meanwhile (and i'm not responsible for that flicker ;-)
@Michael D: The playlist performance issue is unrelated to the original bug report, which was about the toolbar and was fixed long ago. Could you please create a new bug report?
I filed bug 327891.