Bug 154270

Confirmed. With effects enabled, xorg use lot more of CPU.

If I'm getting it right, the problem is that KWin normally uses no CPU when idle (i.e. even no cursor blinking), but somewhen later starts doing so? Can you try to find out which effect is reponsible for this? Also note that AFAIK currently some Plasma animations run a while longer than there's any visual difference possible to see, so wait longer in the idle state.

Not entirely. When the composite effects have just been turned on, the CPU usage is negligible. However, after a while it suddenly spikes to around 20%, and stays that way until the composite effects have been turned off again.

One relatively consistent way to recreate this (7 attempts out of the 8 worked) is to activate the present windows effect (with two windows), rapidly switch between hovering over the one or the other (i.e. move your mouse around like crazy ;)), and then select one of the windows. While it is to be expected that the CPU usage of kwin and Xorg rise during and immediately after the present windows effect, the CPU usage remains around 20% even minutes after the window was selected.

Note that the rise in CPU usage also occurred at other moments, when not using the present windows effect, but I haven't been able to find out when exactly.

Created attachment 22647 [details]
Results of ltrace and strace on Xorg and kwin

If it's any help, I ran strace -c and ltrace -c on Xorg and Kwin, both with and
without composite. The traces ran for about 20 seconds, while I wasn't doing
anything else except waiting (i.e. no moving windows or changing focus or
whatever).

In this case, Xorg used about 50% of the CPU, and kwin about 3%, with composite
turned on. Turned off, Xorg used somewhere around 2% and kwin 0% (all reported
by top).

Hope this helps :)

And more information; when using the "Show Paint"-plug in, when Xorg and kwin are behaving nicely (i.e. when just started), only parts of the screen that actually change are updated. However, when the "Present Window"-effect is used, the screen starts flashing wildly, thus meaning that the entire screen is being repainted. This would not be bad per se, except that the flashing continues after the window is selected, suggesting that the entire screen keeps on getting redrawn even when no reason is given.

Apologies for commenting this soon.. Some other instances of "Show Paint" flashing the entire screen, and the Xorg CPU usage being raised disproportionately I found are when showing the window thumbnails in the taskbar and, even more disconcerting, when moving the mouse. However, in these cases, the flashing and CPU usage returned to normal after I moved away from the taskbar (thus hiding the thumbnails), or stopped moving the mouse respectively.

See also #154281

Ah, yes, that is indeed the same issue as 154281. The "Present Windows" problem still remains; I tried using only the "Present Windows" and "Show Paint" plugins, to make sure it wasn't caused by anything else, and the screen still keeps on flashing after using the effect. It does disappear as soon as the the "Present Windows" plugin is disabled, so it seems to be the culprit.

Should I close this bug and open a new, more descriptive one, or should this remain open?

I have also a high CPU load when I have open a lot of windows (let's say when I have 20 windows open, top looks like this (on a Quad Core CPU with an Nvidia card, using the OpenGL renderer):

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20   0  141m  34m  17m R   60  1.0  64:58.02 kwin

I don't know if that is really releated to this report..

SVN commit 762660 by lunakl:

Clean up properly.
BUG: 154270



 M  +2 -0      presentwindows.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=762660

Now I'm using a dual monitor setup with the latest NVIDIA graphics drivers (169.09).
I'm running the latest KDE from SVN (revision 764637).
I've enabled desktop effects and I've opened a konsole window (with top for monitoring RAM and CPU usage) and this konqueror window with some tabs opened on various kde bugzilla pages.
Actually kwin is using CPU from a minimum of 3% to a max of 26%, even in idle.
Memory usage is ever lower than 10%.
X use from a minimum of 1% to a maximum of 10%, Memory usage for X is ever at 10%.


some useful hardware specs:
- P4@2600
- 1Gb RAM
- GeForce FX 5900XT

I still have the issue of high X.org CPU usage with desktop effects turned on, so I think it's not resolved yet. Without desktop effects, X.org CPU usage is at 2-6% or so. With desktop effects on, the usage climbs to 15-20% when idle (with a dozen or so windows open).

However if I move the mouse around quickly, CPU usage climbs to 50%, and if I use the mouse wheel to scroll in a Konqueror window I can easily drive up usage to 90% or so. In general scrolling is visibly much slower, and makes the desktop feel sluggish.

The system is a Thinkpad T61, Core 2 Duo at 2 GHz, 3 Gb RAM, Intel GM965 graphics, kernel 2.6.25 (x86_64), X.org 7.3 with Intel video driver 2.3.0, dual monitor setup.

I'm running svn rev 794641 (Debian kde-window-manager 4:4.0.68+svn794641-1).

Please reopen the bug and tell me if I can provide any more info.

The problem remains even if I disable all the effects.

Sorry, that was unclear. The problem remains when "Desktop effects" is enabled but all the individual effects (plugins) are disabled.

Despite the widely-spread (and mistaken) belief, the so-called accelerated desktop does not generally make things faster, but slower.

> Despite the widely-spread (and mistaken) belief, the so-called accelerated
> desktop does not generally make things faster, but slower.


That's understandable, but if it causes a new dual-core laptop to use
90% CPU then there's a serious bug somewhere.

Problem remains in 4.0.72-1 (Debian).

Marcus could it be possible that your actual problem is related to bug #161434? I noticed some relative "high" cpu usages, too and disabling minimize animation solved it for me.

I doubt it. The problem persists after disabling all the effect plugins. I don't see the screen repainting, and then there's the mouse movement issue.

OK, I just encountered the same problem. I tried around and disabling direct rendering stopped KWin to use 90 % of the CPU. Perhaps this helps for others, too. Btw I have an NVIDIA chip.

I've got the same problem: in a idle desktop (without windows) the kwin cpu usage jumped regularly at 90-100%. The solution to the problem was disabling VSync in advanced options. I keept "Direct Rendering".
I'm on a NVIDIA 7600GS with beta drivers 173.01 and 2.6.25 kernel.

> The solution to the problem was disabling VSync in advanced options.


I had it disabled in the first place. Problem remains in Debian
kde-window-manager 4.0.74-1.

Reopening. There's still not much to do with just "it's slow", it can be anything.

Disabling VSync dropped the CPU usage down to normal for me.

Nvidia 7800GTX, 169.12, KDE 4.1Beta, compiled from source. Seems it's VSync thats the problem.

Same problem for me. Even when all effects are disabled, enabling desktop effects (ie checking the box "Enables desktop effects") causes a high cpu usage. Sean's solution works: disabling VSync and the problem is solved.

My configuration: NVIDIA Quadro NVS 110M, 169.12, KDE 4.1 beta1, debian packages.

I see this problem in trunk. x86_64, NVidia 7600GS, nvidia driver. Only Present Windows and Cover Switch is activated. Just looking at the top output in konsole without doing anything else (including mouse movement)30-70% KWin cpu usage. Disabling vsync seems to help, thanks for the tip. :)

Created attachment 25219 [details]
Cachegrind output of kwin

I tried to get a cachegrind output of kwin. I don't know if it is usable
though.

Just tried latest nvidia driver 173.14.05 stable and I'm running SVN trunk. Enabling VSync still gives Kwin a High CPU load.

The main reason for enabling this is because it makes windows not tear when dragging and (for me) makes window movement much smoother. There's no jerking when moving windows if VSync is off, they just seem to glide smoother.

*** Bug 163783 has been marked as a duplicate of this bug. ***

Running KDE 4.0.82 under Fedora Core 9, NVIDIA driver 173.14.05 stable.

- VSync makes everything jerky, and rises my CPU usage (X.Org + KWin combined) to over 40%. I disabled it.
- With VSync disabled, I was experiencing a CPU usage in idle (no mouse moving, only top running in a Konsole) between 20 and 30%.
- I only got reasonable idle CPU usage numbers (5% with Firefox running... my PC is old) when I disabled the "Direct Rendering" check box in "Advanced Settings".

To be fair with you, Compiz had here the same kind of bugs in its start (and Beryl was even worse). Now Compiz idles here at 0.6% of CPU.

In my case (Quadro NVS 130M, driver 173.14.09) cpu usage with compositing is as follows:
- when both Direct Rendering and VSync are enabled in the Advanced dialog, idle CPU usage goes randomly between 0% and 100%, but is always about 20% when moving a window,
- with any other combination of Direct Rendering and VSync, idle CPU usage is negligible, and around 20% when moving a window.

powertop on my system with only konsole and firefox running:

Wakeups-from-idle per second : 1286.8   interval: 5.0s
no ACPI power usage estimate available

Top causes for wakeups:
  55.1% (421.6)              kwin : schedule_timeout (process_timeout)
  13.2% (100.6)       <interrupt> : ehci_hcd:usb1, eth1
  13.0% ( 99.8)          knotify4 : schedule_timeout (process_timeout)
   8.0% ( 61.0)       <interrupt> : nvidia
   2.6% ( 20.2)           beagled : futex_wait (hrtimer_wakeup)
   1.8% ( 13.8)       <interrupt> : sata_nv
   1.4% ( 10.8)       <interrupt> : ide0
   1.4% ( 10.8)       <interrupt> : ide1
   1.0% (  7.4)     beagle-search : futex_wait (hrtimer_wakeup)
   0.4% (  3.0)           xfsbufd : schedule_timeout (process_timeout)
   0.3% (  2.2)   hald-addon-stor : schedule_timeout (process_timeout)
   0.3% (  2.0)           ifplugd : schedule_timeout (process_timeout)
   0.3% (  2.0)           klipper : schedule_timeout (process_timeout)
   0.2% (  1.4)           beagled : do_nanosleep (hrtimer_wakeup)

top shows kwin using up to 93% of CPU time just when being idle (active maximized console showing top output).

According to strace, the problem seems to be the looping:
     0.000032 read(13, 0x63df14, 4096)  = -1 EAGAIN (Resource temporarily unavailable)

strace -c output of a running kwin process:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 47.82    0.018346           0    404982           clock_gettime
 28.02    0.010750           0    404981    385742 read
 11.67    0.004476           0     19238           writev
 10.69    0.004102           0    183264           poll
  1.70    0.000653           0     38465           select
  0.10    0.000040           0       415           sched_yield
  0.00    0.000000           0         7           ioctl
  0.00    0.000000           0       140           getpid
  0.00    0.000000           0     19238           gettimeofday
  0.00    0.000000           0         1           restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.038367               1070731    385742 total

Created attachment 25663 [details]
lzma compressed complete strace output

I am now only experiencing this problem in one instance:  If I start kmail 1.10.0 and then minimize it to the system tray, then open it and minimize it again, kwin starts repainting constantly ("Show Paint" effect reveals this).

If I turn off the effects and turn them back on with kmail still in the system tray, all returns to normal.  This is with vsync and direct rendering off.

I can approve this.

Normally X uses roundabout 3-5% of cpu time on my system, but if I minimize KMail 1.10.0 to system tray and re-open it a few times, the cou usage first increases up to 20%, later on up to 35-40%.

I'm running an openSuSE 11.0 with KDE 4.1 and an ATI Mobility Radeon X1600 graphics adapter (using the fglrx driver).

*** Bug 168470 has been marked as a duplicate of this bug. ***

Disabling vsync fixes the CPU usage of kwin on my system (Geforce 7900, prop drivers)

The interesting behaviour I see is, with VSync enabled, computer idle, kwin CPU usage is around 20-40%.  However if I grab a window and quickly move it around the screen, kwin cpu usage goes down to about 5% consistently.  So it an idle kwin takes more cpu usage than when it actually has to repaint stuff.

Hi,

concerning kwin High CPU  usage  it seems kwin hits timeout too often.
After using this patch kwin behave nicely with any combination of direct rendering and vsync


Index: composite.cpp
===================================================================
--- composite.cpp
+++ composite.cpp
@@ -355,7 +355,7 @@
         // if vsync is used, schedule the next repaint slightly in advance of the next sync,
         // so that there is still time for the drawing to take place
         int untilNextSync = compositeRate - ( lastCompositePaint.elapsed() % compositeRate );
-        compositeTimer.start( qMax( 1, untilNextSync - 10 )); // 10 ms in advance - TODO maybe less?
+        compositeTimer.start( qMax( 1, untilNextSync /* - 10 */ )); // 10 ms in advance - TODO maybe less?
         }
     lastCompositePaint.start();
 #endif


 test machine 
GeForce 6600 GT using nvidia prop beta driver 177.13  
AMD Sempron 2800+ 

That patch Carl-Erwin just causes KWin to skip every second frame or so. Half the framerate; half the CPU usage.

r850941

You are our hero, Lubos. Thanks! ;)

after setting my xorg.conf as suggested by different sites on the internet...
problem seem to solve and now it works fine.

here are the "works fine" setting:

hp dv7 + debian sid 64bit + kde 4.1.86 
+ nvidia 9600M GT + nvidia 177.82 + Xorg 1.4.2 

nvidia section from xorg.conf: 
Section "Device" 
Identifier "Device0" 
Driver "nvidia" 
VendorName "NVIDIA Corporation" 
BusID "PCI:1:0:0" 
# compiz(fusion) recommands for nvidia 
Option "RenderAccel" "True" 
Option "AddARGBGLXVisuals" "True" 
Option "DamageEvents" "True" 
Option "UseEvents" "False" 
Option "TripleBuffer" "True" 
Option "BackingStore" "True" 
Option "NoLogo" "True" 
#http://userbase.kde.org/GPU-Performance#NVIDIA 
Option "UseCompositeWrapper" "True" 
Option "AllowIndirectPixmaps" "True" 
Option "PixmapCacheSize" "200000" 
Option "OnDemandVBlankInterrupts" "True" 
EndSection 

I'm suffering this behavior on openSUSE 11.1 with KDE4 4.1.87 and 4.1.96 with nVidia Quadro FX 570M and 180.22 drivers.
Whenever I send Kontact into tray KWin CPU consumption goes up to 30-50-90% (90 is if I turn off VSync). Switching composition effects OFF and ON removes the problem till I restore and send back Kontact to tray.

@Marcin: could your problem be related to bug #177985? Can you try to disable minimize and magiclamp effects and test if the problem remains?

@Martin:

YES, that was "the thing".

Thank you, I had the Magic Lamp turned on (hardly noticed the presence).

I will be more careful in following the bugs reports in the future.

Thanks !!!

I also had problems with high cpu usage with desktop effects enabled, but none of the issues in this report fixed the heavy load.

Using the "Show paint" effect I found out that two areas of my desktop are repainted very often. Even if all windows are minimized. It turned out that in my case Amarok 1.4.10 is the reason. The two parts of Amarok which get repainted very often are the Analyser and the dimming box around the current playing track.
The Analyser even gets repainted when the track is paused and therefore no animation is showed. Disabling the Analyser solved my issue.
Pausing playback stops the dimming box to dim and CPU usage is back at normal.
It also helps if I close Amarok to the system tray.

If I disable Desktop Effects CPU usage is at normal even if Amarok is maximized, playing and Analyser activated.

Maybe its a Amarok 1.4 or qt3 issue. In this case it shouldn't be relevant anymore. But maybe it's an issue which also occurs with other programs in kde4.

At least I hope to help other people who couldn't solve their CPU usage problem with the other suggestions in this report.

(In reply to comment #45)

There's nothing that can be done in KWin about an application requesting a repaint due to changing its appearance. The glowing of the active track in Amarok 1 works how it's supposed to but the analyzer has a bug (I've had to just live without using it at all).

Is the fix part of 4.2 release. I am facing the same problem.