| Summary: | Significant CPU penalty for using Kwin effects. | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Alexander <vo.zaeb> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Alexander
2010-05-29 12:58:06 UTC
Please see the following blog post by a Compiz developer for an explanation for the CPU penalty: http://smspillaz.wordpress.com/2010/05/21/beware-the-benchmarks/ All this is very interesting and in theory all sound good. Everyone always trying to find easy ways, but in practice we have a lot of lags and errors, and I do not think Kwin has already reached perfection there. But almost everywhere, where I had posted a bug report, devs are trying to convince me that it seemed to me :)
When Kwin and X load CPU at least twice as much more than VLC, this does not looks like a "semi-significant overhead". And, for some unknown reason, the author of the article forgot to mention bugs, which were made during the writing.
> Our recommendation: Use nouveau.
Haha :) Too early for that, in my opinion.
a) An overhead on the current OpenGL compositing renderstack is unavoidable. period. try using xrender. (the trick is to pass it to the gpu) b) arbitrary measures using top make bad benchmarks as it's not possible to say what causes your issues... use sysprof to profile the offending processes (x11 & kwin) c) tried compiz? if it's not significantly faster (it's not for me) that would be a hint that you're running into system restrictions. d) personal experience (nvidia 7600gt, 195.36.15, arch) -> i do not suffer from similar X11 cpu load at all. extrapolating to your system it'd be ~4% for 1050p, xrender or opengl doesn't matter. kwin ~3% on opengl, "nothing" on render (just playing, nothing else) but: - i use the 32bit variant and - i don't use the glib event dispatcher (put "export QT_NO_GLIB=1" into your ~/.xprofile) - haven't tried glib for ages. and - to gain these values, you must NOT use any indirect rendering. whether by setting or the use of a shader plugin (sharpen, inversion, blurring) otherwise the driver -as smart as possible- can not bypass the expensive theoretical stuff mentioned in the blog ;-) using indirect rendering, my performance drops significantly (but is still not as bad as your experience) It's amazing, dude! I've just put this string "export QT_NO_GLIB=1" into my /etc/profile, and Kwin really does not use CPU so hard any more. 5% — It is maximum on how much I was able to load it, I just can't believe it :) Thanks. Given comment #4 I think we can set this bug to invalid. I really have to try this option ;-) I do not know what is the glib event dispatcher and how important is its role, but think, you should be use "export QT_NO_GLIB=1" (and/or perhaps another tricks you know) by default. I am certainly happy now, but others could still have this CPU penalty. Simply put, not all pay attention to some miserable 5-10%. Regards and good luck. SVN commit 1137645 by fredrik: Disable the glib event loop integration, since it seems to be responsible for several bug reports about high CPU usage. CCBUG: 239963 M +4 -0 main.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1137645 |