| Summary: | Kwin cpu leak | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Marian Kyral <mkyral> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | thilo |
| Priority: | NOR | ||
| Version: | 4.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | sysprof file captured while kwin repaints the whole screen | ||
|
Description
Marian Kyral
2011-12-14 09:34:21 UTC
Please check whether suspending / resuming the compositor is sufficient in this case and whether it happens with all window decorations. Created attachment 66742 [details]
sysprof file captured while kwin repaints the whole screen
Same here:
Qt: 4.7.4
KDE Development Platform: 4.7.90 (4.8 Beta2 (4.7.90)
KWin: 4.7.90 (4.8 Beta2 (4.7.90)
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OpenGL version string: 2.1 Mesa 7.11
x11-drivers/xf86-video-intel-2.17.0.-r3
It turned out, that when the CPU usage is unusually high, the whole screen is reported as damaged, thus everything is constantly repainted (the whole screen flickers when enabling the "Show Paint" effect).
Attached is a sysprof file which probably provides more information.
(In reply to comment #1) > Please check whether suspending / resuming the compositor is sufficient in this > case Yes, suspend/resume composition help. > and whether it happens with all window decorations. Sorry, I don't understood. Option 1:
some window (would be plasma-desktop) has constant relatively small repaints but the damageratio is iscalculated / not reset ("kquitapp plasma-desktop" would resolve the issue as well)
Option 2: (more likely, relatively high load in builtin effects and QTimeLine)
some effect didn't catch the exit
@elias:
please post your enabled effects for a cross check:
grep -iE 'kwin4_effect_.*Enabled=true' `kde4-config --path config | cut -d":" -f1`/kwinrc | sed -e 's/kwin4_effect_//g; s/Enabled=true//g'
@Marian:
Deco aspect is atm. likely no more relevant
@Martin and ftr:
"qdbus org.kde.kwin /Compositor activeEffects" ... =)
(@anyone else: no - this doesn't exist atm.)
> "qdbus org.kde.kwin /Compositor activeEffects" ... =)
> (@anyone else: no - this doesn't exist atm.)
qdbus org.kde.kwin /KWin toggleEffect "nameofeffect"
not elegant, but should do the same, shouldn't it?
i meant mor like this:
QStringList activeEffects;
for(QVector< KWin::EffectPair >::iterator it = loaded_effects.begin(); it != loaded_effects.end(); ++it) {
if (it->second->isActive()) {
activeEffects << it->second->metaObject()->className();
}
}
return activeEffects;
ah that makes more sense now :-) and yeah that could help in such cases a lot Hi, I just tested 4.8 RC1, situation still the same. I have to restart composition/kwin from time to time. please cross check bug #290025 and disable the "sliding popups" effect. Also report on the outcome (so we can dupe the other bug in case) Ok, I'll do it and let you know next week as I'm offline for next two days. 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 290025 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 http://commits.kde.org/kde-workspace/089aeee91b807d13c0c2b86fa18d05776bef5190 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 290025 (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 http://commits.kde.org/kde-workspace/4d2f807179424424ac25df56b420622946fe505e Hi, I disabled the "sliding popups" effect and now it is much better. I don't need to restart kwin anymore. The activeEffects function shows me, the kwin4_effect_translucency is always active. I don't know, if it is correct. $ qdbus org.kde.kwin /KWin activeEffects kwin4_effect_translucency 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 290025 M +6 -4 kwin/effects/fade/fade.cpp http://commits.kde.org/kde-workspace/2da6447499e363582e332f2e7a845265557c6353 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 290025 REVIEW: 103733 M +9 -0 kwin/deleted.cpp M +2 -1 kwin/deleted.h http://commits.kde.org/kde-workspace/d07964e0af95911a97c3f474b694570cb279878c Closing the bug as fixed. If somebody should still experience the issue, feel free to reopen. |