Version: SVN (using Devel) OS: Linux I'm testing using my Dell Mini 10v netbook with integrated graphics and the vesa graphics card. I'm using KDE 4.5 RC1. Both Amarok and Juk cause this problem: whether desktop effects are enabled or not, having either of these windows open causes e.g. plasma to be less responsive to mouse actions (there is a noticeable lag between moving my mouse over an element and the element highlighting, and again when clicking on the element). When these two applications are closed, responsiveness picks up again, even when multiple applications e.g. KMail, Akregator, Blogilo, KWord etc. are running. It's only noticeable with Juk and Amarok windows. Additionally, when the applications are running and playing music, but are minimized to the system tray, responsiveness returns to normal. Reproducible: Always
Could you enable "Show Paint" KWwin effects plugin to see if they constantly try to paint their views?
Amarok only ever repaints its music progress bar (when the mouse is idol), as expected. Strangely, even when interacting with other application windows, the FPS rarely drops under 30. When idol or doing some less intensive activity, the FPS often stays above 60. With Amarok running, though, FPS stays under 30, often dropping to as low as 10. Juk exhibits similar behaviour: only its progress bar is re-painted, as well as a timer at the bottom-right that updates as the song plays. However, the FPS behaves in a similar fashion to Amarok's.
Marcus, what exact KDE, Juk and Amarok versions are you using? I don't have a netbook, just a normal laptop, but I can't reproduce this here at all, on the contrary, both Amarok and Juk are rather economic in ressources.
KDE: 4.5.90 Amarok: 2.3.1 Juk: 3.5 The thing is, neither of them are using much RAM or CPU resources, but I get the impression they're somehow thrashing the GPU because actions like moving windows (KWin effects on AND off), KWin effects animations and plasma animations become slow and stutter. Even stuff like scrolling web-pages begins to stutter.
Thank you for the feedback.
After more testing, I've realised that this behaviour is only noticeable with the Oxygen widget theme set. Other widget themes, such as Plastique or Ubuntu's Ambiance GTK theme, don't reproduce the slowdown.
I use the default Oxygen theme, and as I said above, I can't reproduce this at all. Could it be Plasma related?
No, it's not. Killing plasma, removing the plasma-driven context view in Amarok or using Juk (and just recently, I've noticed with Dragon as well) results in the same behaviour. Recently, though, I have noticed that this only occurs with maximised windows (with plasma-netbook, the titlebar is hidden but the window is not, "full screen": it is standard maximise). When, "restored" to a floating window, the lag disappears. This is especially noticeable with Dragon player when playing a video, and reveals a strange detail: When playing as a floating window, no lag is noticeable; When the window is maximised, it produces lag - every three seconds or so, the video lags for a second; When playing full-screen (using the toolbar button), no lag is noticeable. After further testing, the same thing occurs when the using plasma-desktop with, "ordinary" desktop maximising (when the titlebars remain).
Reassigning to Oxygen, then.
After more testing: launching the applications using the Raster graphics system instead of the default results in my being unable to reproduce the bug again: responsiveness stays high as I e.g. play through the same video or interact with KDE with Amarok maximised while playing music etc.
what is your graphic card, and driver ? Might be related (notably because of comment #10). As for the lag being more obvious with oxygen, could you try disable oxygen animations (for both the style and the decoration ?). You can type 'oxygen-settings' in krunner or konsole and you get full control on oxygen animations. My suspicion is that the lag is triggered by some paint events, and due to animations there are much more such events in oxygen than with any other style. Hugo
I have similar problem. When player window is not minimized, X server eats much more cpu and it depends on program. For Amarok it is cca 20%, Clementine cca 40%. When window is minimized, problem is solved. I tried disable animations at oxygen settings and it is much much better, but minimized window has still less cpu use (a little). There is no difference if I am looking at workspace with player or any other. I am using fresh fglrx driver, kwin effects on.
I've disabled the oxygen style animations, and you're right - I've noticed the system returns back to the responsiveness experienced when these applications are closed.
ok. Looking at the repainted frames, I believe the ellapsed time transitions are responsible for the slowdown. Maybe you can try disabling only this animation and report back. Todo that, with kde4.5, type "oxygen-settings" (in konsole or krunner), select the "animations" tab, and deselect the "label transitions". I will try optimize this animation in the meanwhile (it uses pixmaps and some grabbing to do the job, which is quite suboptimal. I might have some ideas to make it more efficient).
I no longer experience this bug, using Kubuntu 11.10 beta with KDE 4.7.1. Closing.