Bug 206910 - use 15% of my cpu as idle
Summary: use 15% of my cpu as idle
Status: RESOLVED DUPLICATE of bug 184859
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-09 22:21 UTC by BRULE Herman
Modified: 2009-12-11 00:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Manage the timeline hash in prePaintScreen (2.29 KB, patch)
2009-09-10 21:54 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description BRULE Herman 2009-09-09 22:21:43 UTC
Version:            (using KDE 4.3.1)
Installed from:    Gentoo Packages

Hello, my kwin with propretary driver of nvidia card use 15% of cpu! I'm with the default effect, but with 8 activity & 8 virtual desktop & lot of application.
Thanks to solve it. If you have question or test, tell me.
Comment 1 Thomas Lübking 2009-09-09 23:39:14 UTC
I assume you use compositing and as soon as you suspend it, the cpu cools down.

In case you use the OpenGL backend:
from my personal experience the nvidia CSS driver prefers TextureFromPixmap and direct rendering.

If the cpu's still hot there may some constant repaint of a larger screen area, please activate the "Show Paint" plugin to visualize repaints.

If there' re no such repaints or you use the Render backend anyway, some plugin may run wild.
Though unlikely, this could be the deco, so try top switch it (esp. if gentoo uses a distro specific decoration by default)
Then disable all FX plugins.
If the cpu is now cold, try to enabled them one by one again and watch the cpu.
Comment 2 BRULE Herman 2009-09-10 09:40:28 UTC
After desactiving and reactiving compositing, kwin use only 1% of cpu.
I wait few time... and kwin reuse 15% of my cpu.
When kwin use 15% it repaint all.
For product this bug:
kmail in the systeme tray, restore (double click) and re hide it (cross on top right).
Comment 3 BRULE Herman 2009-09-10 10:11:44 UTC
Is the "minimize animation" which product this bug.
Comment 4 Thomas Lübking 2009-09-10 17:14:34 UTC
i can't reproduce it myself - but from the code, there /might/ be a trap that could lead to infinite action (if one or more windows aren't removed from the animation hash)

Do you compile yourself, i.e. can you test a patch?

Btw:
this might be connected to the global double click setting, but i just single click kmail to bring it up...
Comment 5 BRULE Herman 2009-09-10 18:03:59 UTC
> Do you compile yourself, i.e. can you test a patch?
Yes
Comment 6 Thomas Lübking 2009-09-10 21:54:27 UTC
Created attachment 36849 [details]
Manage the timeline hash in prePaintScreen

background:
The hash count manages the fullscreen effect state, but the entries used to be erased in the prePaintWindow call
In case an EffectWindow could manage to drop out of the list before its timeline exceeded, its entry is never removed - thus the count remains > 0 forever and thus triggers a permanent fullscreen effect state.
I could not reproduce the issue as described in this bug, neither with nor without the patch, therefore rarely tested. Use with care!
Comment 7 BRULE Herman 2009-09-12 14:48:56 UTC
Note: I have dual, and all op is on the second screen.
Comment 8 Guido Berhörster 2009-12-10 23:47:55 UTC
This also happens occasionally with KDE 4.3.1 on openSUSE 11.2 (see https://bugzilla.novell.com/show_bug.cgi?id=541711). As a workaround desktop effects can be disabled and re-enabled.
Comment 9 Thomas Lübking 2009-12-11 00:02:06 UTC

*** This bug has been marked as a duplicate of bug 184859 ***