Bug 290025

Summary: High cpu usage after system start
Product: [Plasma] kwin Reporter: Etienne <etienne.rebetez>
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Severity: normal    
Priority: NOR    
Version: 4.8.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: information
sysprof profile after starup

Description Etienne 2011-12-28 16:38:05 UTC
Created attachment 67190 [details]

Version:           4.8.0 (using Devel) 
OS:                Linux

After starting kde kwin uses about 20% of the cpu. It stais there as a base load.

When restarting kwin (kwin --replace) the kwin cpu load goes back to 0% (see Bug 288948).

Reproducible: Didn't try

Steps to Reproduce:
Sessions should be saved and restored at statup.
Put some windows on different desktops and activitys.
Restart kde.

Actual Results:  
CPU usage is higher than normal.

Expected Results:  
When idle the kwin cpu should be 0%

At the same time, after startup, all windows from the session are shown in the taskbar. My settings are to show only the windows of the current workspace and activtiy.
When activeted, the window goes to it's place and the taskbare get cleand up until it shows only the windows according to my settings.

Also after the kwin --reset the only thing that seems to trigger a cpu leak is when using the taskbar. (from 0% to 2%)

The takbar thing might just be another bug, but it seams somehow related to kwin.
Comment 1 Martin Flöser 2011-12-28 16:45:25 UTC
Could you try the Show Paint effect [1] when you are in such a high CPU usage 
situation. Is it possible that the effect shows constant repaints of the task 

[1] Warning: the effect makes your screen flash in multiple colors. Do not use 
if suffering from epilepsy
Comment 2 Etienne 2011-12-28 18:44:28 UTC
Created attachment 67198 [details]

I could not see any repaints of the taskbar (or any other if that matters) that wehre not related to real updates. 
Usualy my taskbar does autohide, but deactivating the autohide didn't have any effect.

Once the loading of the programs was done, there where no other areas that where visible more active than others.
Comment 3 Thomas Lübking 2011-12-28 18:57:33 UTC
"kcmshell4 kwincompositing", 2nd tab, deactivate the login effect - is this with the new QML splash screen? Does the entire screen repaint constantly?
Comment 4 Etienne 2011-12-28 19:52:18 UTC
Tryed the following. (Restart after each change)

starting position: 12% (cpu of idle kwin)

Started with an empty session: 8%

Deactivating the login effect: 8% 
(short flicker of the whole screen)

Reactivating the login effect: 8% 
(flicker goes longer, also some local repaints of the kde logo)
I use the standard splash screen. How do i get the QML one?

Putting back some windows and resetting the restore session option: 10%

Dactivating desktop effects and starting them after the desktop has fully loaded: 0%
Comment 5 Thomas Lübking 2011-12-28 20:11:58 UTC
I think there's a theme for it on kde-look, no idea what the default one uses.
Last shot: activities. Get rid of all but one. Otherwise you'll have to go by sysprof (online* kernel level profiler)

*no. no internet ;-)
Comment 6 Etienne 2011-12-29 12:11:13 UTC
Hm, removing all activitys didn't help either. Still around 10% cpu usage after startup.

Hitting twice the alt+shift+F12 combo also resets the cpu usage.

Thanks for your hints, let me know if i can help in any other way.
Comment 7 Thomas Lübking 2011-12-29 14:28:25 UTC
Not many ideas left.
- You could try the XRender backend to see whether that makes a difference
- http://www.sysprof.com (your distro has it...) - just run it after startup, press play, wait a short time, save and attach the log here
- Do you compile yourself so you could add some debug code?
- please provide a list of all enabled plugins:
grep -iE 'kwin4_effect_.*Enabled=true' `kde4-config --path config | cut -d":" -f1`/kwinrc | sed -e 's/kwin4_effect_//g; s/Enabled=true//g'
Comment 8 Etienne 2011-12-30 11:36:14 UTC
Created attachment 67242 [details]
sysprof profile after starup
Comment 9 Etienne 2011-12-30 11:41:05 UTC
With XRender backend:
 - Changing the backend resets the cpu load.
 - After reboot kwin uses about 2% of my cpu. X however eats now around 5%.
 - Stopping and restarting the effects also fixes the cpu load.
 - Changing back to OpenGL has no effect to the cpu. Remains at 0%.

The active effects are in the first attachment.

Yes, i compile and have a kde development enviroment setup. Do you have a special branch in kde-workspace that i should try out?
Comment 10 Thomas Lübking 2011-12-30 14:29:36 UTC
a) thanks for the profile, looks indeed as compositor action
b) you could compile this https://git.reviewboard.kde.org/r/103572/ into any branch you like and run "qdbus org.kde.kwin /KWin activeEffects" after the start
c) i suspect "fade", "scalein" or "wobblywindows" to be the culprit, maybe "startupfeedback" (we should have gotten rid of QHash::operator[] in minimize)

in case it's fade, scalein or minimize and since you compile yourself, i'll go for shameless self-advertisement http://kde-look.org/content/show.php?content=145674
Comment 11 Etienne 2011-12-30 16:40:26 UTC
Ok, now i might got some usefull information. I tested each plugin i had activated separately and came up with two bad ones. 
Percentage are cpu load of idle kwin after startup.

Bad effects:
fade: 2%
slidingpopups: 8%

Good effects (all 0%):
Comment 12 Thomas Lübking 2012-01-02 17:54:38 UTC
Git commit 089aeee91b807d13c0c2b86fa18d05776bef5190 by Thomas Lübking.
Committed on 29/12/2011 at 23:33.
Pushed by luebking into branch 'master'.

add dbus debug "activeEffects"

REVIEW: 103572
Related: bug 288948

M  +7    -0    kwin/composite.cpp
M  +12   -0    kwin/effects.cpp
M  +1    -0    kwin/effects.h
M  +3    -0    kwin/org.kde.KWin.xml
M  +1    -0    kwin/workspace.h

Comment 13 Thomas Lübking 2012-01-02 18:22:55 UTC
Git commit 4d2f807179424424ac25df56b420622946fe505e by Thomas Lübking.
Committed on 29/12/2011 at 23:33.
Pushed by luebking into branch 'KDE/4.8'.

add dbus debug "activeEffects"

REVIEW: 103572
Related: bug 288948
(cherry picked from commit 089aeee91b807d13c0c2b86fa18d05776bef5190)

M  +7    -0    kwin/composite.cpp
M  +12   -0    kwin/effects.cpp
M  +1    -0    kwin/effects.h
M  +3    -0    kwin/org.kde.KWin.xml
M  +1    -0    kwin/workspace.h

Comment 14 Philipp Knechtges 2012-01-12 19:51:53 UTC
Git commit 2da6447499e363582e332f2e7a845265557c6353 by Philipp Knechtges.
Committed on 12/01/2012 at 20:40.
Pushed by knechtges into branch 'KDE/4.8'.

kwin: fixing high cpu usage in the fade effect

This is a condensed version of Martin's patch that fixes a high cpu
usage in KWin and X. It seems to be due to a window being created and
deleted at almost the same time, such that the fade effect never quits.
The bug was reliably reproducable with starting Amarok.
Related: bug 288948

M  +6    -4    kwin/effects/fade/fade.cpp

Comment 15 Philipp Knechtges 2012-01-19 14:38:58 UTC
Git commit d07964e0af95911a97c3f474b694570cb279878c by Philipp Knechtges.
Committed on 19/01/2012 at 11:38.
Pushed by knechtges into branch 'KDE/4.8'.

kwin: fixing high cpu usage bugs

In some unfortunate situations it is possible that a window is deleted
before it is marked ready_for_painting=true. The last point is
especially troublesome for effects that reference the deleted window.

Many thanks to Elias Probst for all the testing.
Related: bug 288948
REVIEW: 103733

M  +9    -0    kwin/deleted.cpp
M  +2    -1    kwin/deleted.h

Comment 16 Etienne 2012-01-29 18:26:23 UTC
I just installed the final kde 4.8 release. Fade and slidinpopus don't use idle CPU anymore.
Tank you very much for fixing that one. Kwin never run more smoothly on my lapotp:)