Bug 154270 - heavy Xorg and KWin CPU usage with Desktop Effects turned on
Summary: heavy Xorg and KWin CPU usage with Desktop Effects turned on
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal with 4 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
: 163783 (view as bug list)
Depends on:
Reported: 2007-12-18 14:06 UTC by Pjotter Tommassen
Modified: 2009-02-25 02:55 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In:

Results of ltrace and strace on Xorg and kwin (6.39 KB, text/plain)
2007-12-21 21:56 UTC, Pjotter Tommassen
Cachegrind output of kwin (377.73 KB, application/x-kcachegrind)
2008-06-09 10:02 UTC, András Manţia
lzma compressed complete strace output (347.29 KB, application/x-lzma)
2008-06-28 14:46 UTC, Frederik Himpe

Note You need to log in before you can comment on or make changes to this bug.
Description Pjotter Tommassen 2007-12-18 14:06:59 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

When using KWin with desktop effects enabled, the CPU usage of the Xorg process rises to about 20%, even when not touching the computer at all. KWin keeps using about 7% of the CPU. When turned off, the CPU usage becomes negligible.

This problem doesn't occur immediately after turning on the desktop effects, and I haven't been able to reproduce it consistently; it just seems to occur randomly.

The following information about my system might be useful:
- OpenSuse 10.3
- X.org 7.2.0
- Proprietary NVidia drivers, version 100.14.19
- GeForce 7600 GS
- OpenGL works (i.e. GPU-intensive games like UT2004 or Doom 3 run without problems)
- A konsole with 'top' running is open, as well as a konqueror window with just this bug entry form. The problem also occurs without konqueror.

I'd be happy to provide more information if necessary.

Hope it helps!
Comment 1 FiNeX 2007-12-18 23:34:15 UTC
Confirmed. With effects enabled, xorg use lot more of CPU.
Comment 2 Lubos Lunak 2007-12-19 14:52:20 UTC
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.
Comment 3 Pjotter Tommassen 2007-12-19 15:45:55 UTC
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.
Comment 4 Pjotter Tommassen 2007-12-21 21:56:05 UTC
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

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 :)
Comment 5 Pjotter Tommassen 2007-12-28 23:40:25 UTC
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.
Comment 6 Pjotter Tommassen 2007-12-28 23:52:38 UTC
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.
Comment 7 Mike 2007-12-29 00:48:45 UTC
See also #154281
Comment 8 Pjotter Tommassen 2007-12-29 01:18:41 UTC
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?
Comment 9 Urs Wolfer 2008-01-09 22:09:21 UTC
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):

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..
Comment 10 Lubos Lunak 2008-01-17 17:24:34 UTC
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
Comment 11 FiNeX 2008-01-22 18:56:37 UTC
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
Comment 12 Marcus Better 2008-05-01 10:12:17 UTC
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.
Comment 13 Marcus Better 2008-05-01 10:22:04 UTC
The problem remains even if I disable all the effects.
Comment 14 Marcus Better 2008-05-01 10:33:44 UTC
Sorry, that was unclear. The problem remains when "Desktop effects" is enabled but all the individual effects (plugins) are disabled.
Comment 15 Lubos Lunak 2008-05-02 17:08:54 UTC
Despite the widely-spread (and mistaken) belief, the so-called accelerated desktop does not generally make things faster, but slower.
Comment 16 Marcus Better 2008-05-02 17:13:11 UTC
> 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).
Comment 17 Martin Flöser 2008-05-02 17:29:49 UTC
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.
Comment 18 Marcus Better 2008-05-02 19:50:12 UTC
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.
Comment 19 Martin Flöser 2008-05-13 11:40:26 UTC
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.
Comment 20 Luca Gambetta 2008-05-27 10:49:10 UTC
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.
Comment 21 Marcus Better 2008-05-27 11:10:59 UTC
> 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.
Comment 22 Lubos Lunak 2008-06-06 16:25:21 UTC
Reopening. There's still not much to do with just "it's slow", it can be anything.
Comment 23 Sean Wilson 2008-06-08 17:28:58 UTC
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.
Comment 24 John 2008-06-09 08:56:12 UTC
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.
Comment 25 András Manţia 2008-06-09 09:47:20 UTC
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. :)
Comment 26 András Manţia 2008-06-09 10:02:08 UTC
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
Comment 27 Sean Wilson 2008-06-10 15:38:44 UTC
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.
Comment 28 lucas 2008-06-11 16:14:17 UTC
*** Bug 163783 has been marked as a duplicate of this bug. ***
Comment 29 Alejandro Nova 2008-06-20 21:02:58 UTC
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.
Comment 30 Ambroz Bizjak 2008-06-21 23:44:06 UTC
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.
Comment 31 Frederik Himpe 2008-06-28 14:43:04 UTC
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

Comment 32 Frederik Himpe 2008-06-28 14:46:16 UTC
Created attachment 25663 [details]
lzma compressed complete strace output
Comment 33 adibudeen 2008-07-22 04:04:39 UTC
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.
Comment 34 Unknown 2008-08-01 15:25:55 UTC
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).
Comment 35 lucas 2008-08-06 06:20:16 UTC
*** Bug 168470 has been marked as a duplicate of this bug. ***
Comment 36 Leo Spalteholz 2008-08-08 20:27:45 UTC
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.
Comment 37 Carl-Erwin Griffith 2008-08-10 19:37:26 UTC

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?

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

Comment 38 lucas 2008-08-11 03:29:07 UTC
That patch Carl-Erwin just causes KWin to skip every second frame or so. Half the framerate; half the CPU usage.
Comment 39 Lubos Lunak 2008-08-22 18:02:31 UTC
Comment 40 Alejandro Nova 2008-08-25 06:10:49 UTC
You are our hero, Lubos. Thanks! ;)
Comment 41 Nadav Kavalerchik 2009-01-06 18:46:19 UTC
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" 
Option "UseCompositeWrapper" "True" 
Option "AllowIndirectPixmaps" "True" 
Option "PixmapCacheSize" "200000" 
Option "OnDemandVBlankInterrupts" "True" 
Comment 42 Marcin Ciosek 2009-01-14 22:35:23 UTC
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.
Comment 43 Martin Flöser 2009-01-14 22:55:38 UTC
@Marcin: could your problem be related to bug #177985? Can you try to disable minimize and magiclamp effects and test if the problem remains?
Comment 44 Marcin Ciosek 2009-01-15 01:15:53 UTC

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 !!!
Comment 45 Jonathan 2009-02-09 23:45:05 UTC
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.
Comment 46 lucas 2009-02-10 06:11:52 UTC
(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).
Comment 47 Jithin Emmanuel 2009-02-25 02:55:19 UTC
Is the fix part of 4.2 release. I am facing the same problem.