Bug 234463

Please use CPU monitor tools such as "top" in Konsole or "ksysguard" to identify which process consumes CPU time.

No any processes that are CPU intensive, it's not what you think. But I have 95-100% of CPU when I scroll playlist or just moving the cursor above widgets. In this time Xorg and Kwin using CPU intensive. If I close any of big application that I have running (amarok, kmail, forefox etc) — scrolling becomes faster (not only scrolling), but not for long time. After 5-10 minutes this problem returns back. If I launch only one amarok (or firefox) this problem never happens, but after launching every next application entire interface becomes slower.

Assigning to KWin maintainers, as per comment #2.

if you're usign opengl compositing ensure you're using "direct rendering" and "texture from pixmap" mode ("advanced" tab in "desktop effects")

the oxygen deco seems to use quite some (V)RAM*, try another one (eg. KDE2)
*check the output of "xrestop"

if the problem remains, keep compositing active but disable all plugins.
if this helps ("fixes" it) re-enable them one by one and look for the culprit.

also please inform about you GPU hardware (nvidia, what chip, what/how much memory)

you can also try the xrender backend (in case the legacy nvidia driver is in use and has inferior GPU support for tfp conversion)

> if you're usign opengl compositing ensure you're using "direct rendering" and "texture from pixmap" mode ("advanced" tab in "desktop effects")
Compositing type: OpenGL
OpenGL mode: Texture From Pixmap
With enabled direct rendering and VSync

> the oxygen deco seems to use quite some (V)RAM*, try another one (eg. KDE2)
*check the output of "xrestop"
Decorations has been changed to Cleanlooks, but this not help.
http://img80.imageshack.us/img80/1517/34280528.jpg
http://img62.imageshack.us/img62/5206/14545556.png

> if the problem remains, keep compositing active but disable all plugins.
if this helps ("fixes" it) re-enable them one by one and look for the culprit.
Compositing enabled and I've turned off all plugins.

> also please inform about you GPU hardware (nvidia, what chip, what/how much
memory)
Nvidia, G96 9500GT with 1Gb of slow memory (128bit interface).

> you can also try the xrender backend (in case the legacy nvidia driver is in
use and has inferior GPU support for tfp conversion)
Xrender backend works, but not better :)

I've noticed, that scrolling in widgets, like the Amarok's music collection, works much faster after unset the checkbox in the system settings → appearance → style → configure → views → draw tree branch lines.

that's "unrelated" and more an (in this case) oxygen painting perfomrance issue (though painting treeview branches is slow in general)

Cleanlooks and Plastic not faster in this. They also draws tree branch lines and works same slow. So, I think this also can be a Qt issue. Anyway, scrolling isn't the only problem, all of the interface becomes slower after launching more than two-three applications and no difference what the deco used.

I also see what appears to be the same effect when using Kate.  The Xorg process spikes CPU usage when moving the cursor using the arrow keys.  I can open a PHP script in Kate (about 100 lines long), then arrow up and down, causing one core of the CPU to spike to 100% while scrolling.

I'm on a Dell Latitude D620 laptop, with an NVidia card and 2G ram.


I am using OpenGL compositing, Texture From Pixmap, Enable direct rendering

I'm also using Trilinear filtering, but turning it down to Nearest (fastest) has no effect.

I was curious, and disabled compositing.  The CPU usage during scrolling with the arrow keys became worse.  So, compositing seems to actually improve things.

I have just move the mouse http://img215.imageshack.us/img215/9499/105q.png

I am just can not resist to not ask, did you yourself tried to use it? I do not mean a limited range of software, like a web browser and a chat client. I am talking about using all the environment possibilities. Because I can not imagine how it is possible now, with so low performance.

A few days earlier I tried to use 4.4.80, but I have not noticed any improvements there, quite the contrary.

Could it be, that it is all nvidia fault? Should I roll back to the some previous version of this driver or something else? Can anybody confirm or refuse this issue? This, at least, would give me to know is it my specific problem or not.

I'm not really sure if this is the same behaviour that I observed on my machine. It wasn't as dramatic, but maybe it's just that my machine is fast enough (AMD Athlon64 X2 6000+; 4GB; 2.6.34; GF9500GT + 256.25).

Routinely, but not usually already after a few minutes, my kwin started to drag the system down. It only caused ~20% load then, but this slowed down the GUI noticeably. One factor that seemed to trigger it was the use of mplayer (HEAD; VPAU?). Turning compositing off didn't help here either (IIRC), but restarting kwin did -- at least for a while: kwin --replace.

What ultimately seems to have "fixed" it for me was the setting under Desktop Effects->Advanced->Keep window thumbnails: Never. (Don't remember which of the other two options I had before.)

(In reply to comment #11)
> I have just move the mouse http://img215.imageshack.us/img215/9499/105q.png
a lot of cpu is taken by plasma-desktop.
X11 cpu usage _could_ be induced by this (can be induced by anything, X is a server)

-> "kquitapp plasma-desktop" (desktop gone)

check whether the problems remain. if yes, you suffer from a plasma problem.

Ok, I have Arch Linux, of course I know what is X :) The problem disappears immediately after I stopped move the mouse cursor, CPU usage drops down to 2-5%. So if I run "kquitapp plasma-desktop" I get the same result.

The same problem happens when I move the mouse cursor above the dolphin or amarok widgets. But in this case dolphin/amarok use CPU instead of plasma-desktop (X, of course, still here).

I do not know, how can I explain my situation, but I will try, again :)
So, when I have launched only Firefox and Dolphin and performs the same actions (like in the screenshot above) — CPU usage is within 40-50%. So, I continue to run programs: Amarok, Kmail, Ktorrent, Kopete, etc. After 20-30 min, when I performing THE SAME ACTIONS (like in the screenshot) CPU usage already is 80-90%. And so on. But if I will stop all my actions CPU usage again drops down to <10%. So only GUI becomes slower, increases response time, switch between tabs in dolphin becomes slower and with unpleasant blinking, slow, affected scrolling in all applications (even in Firefox), very and very slow redraw contents of windows (which is already not fast), etc.

At the same time all the Kwin effects, like "All windows", "All Desktops", "Fade Desktop" works smooth, without any "particularly bothersome" problems.

so long story short: this is caused by hover events, yesno? (the pointer runs on the framebuffer by default, simply moving it causes events but no repaints or whatever)

_iff_ this is related to hover events

a) disable (as mentioned before) all effects (but keep compositing active) to check whether one of them runs wild
b) watch your GL settings (advanced tab) use "Texture from Pixmap" and "Enable direct rendering"
c) use xrestop and top to check for mem leaks
d) esp. in case this is (as in comment #10) not related to compositing you should check: 
     "nvidia-settings -q InitialPixmapPlacement"
meanwhile (....) "2" is the rather "bad" value - test "1"
     "nvidia-settings -a InitialPixmapPlacement=1"

in case you want to play with this values, be carefull to not do so in a productive session. dep. on your HW and the used mode your screen updates can go < 1fps

(->VT1, export DISPLAY=:0; nvidia-settings -a ...)

> so long story short: this is caused by hover events, yesno?
No. Only when an animation triggered under the mouse cursor. Switching between tabs in Dolphin, selecting files/folders on desktop or in Dolphin, all context menus, buttons, tabs, scrolling — literally everything that you can click or move (excepts the windows, they are okay). But when I move my cursor in an empty place on desktop (or window) this is not causes any problem.

> d) esp. in case this is (as in comment #10) not related to compositing you
> should check: 
I think that Cliff describes a different problem. Because when Kate works poorly for me — all work the same, and when that happens scrolling is not the only problem :)

> nvidia-settings -a InitialPixmapPlacement=1
I already tested it and 2 is the fastest value for me.

New thing I noticed — disabling animations in oxygen it significantly increases system performance (system settings → appearance → style → configure → general).

But none of this solves my problem. I will see good performance of the system after logging, but just for while.

(In reply to comment #16)
> No. Only when an animation triggered under the mouse cursor
that's what i meant (in contrast to just simply move the cursor around ;-)

> But none of this solves my problem. I will see good performance of the system
> after logging, but just for while.
then check for leaking pixmaps using "xrestop" (once you run out of GPU RAM your on system RAM and that's slow)

also do not forget to turn off all compositing effects (in case this is related to compositing)

Hi, thanks for reply.

xrestop - Display: localhost:0
          Monitoring 35 clients. XErrors: 0
          Pixmaps: 35229K total, Other: 224K total, All: 35454K total

Think there is no any leaking, but I am not sure, because I do not know, how it should look :) Maximum memory usage, what I can see after four hours uptime, not exceeded of 50000K. Is it normally?

But just now I opened /usr/lib in Dolphin and get this:
http://img46.imageshack.us/img46/707/107yj.png
http://img269.imageshack.us/img269/9705/109oh.png
Scrolling is affected too.

Interesting that even if CPU is not fully loaded (70-80%) I still have lags.
Switching between tabs lasts approximately 1 sec. Restarting Dolphin helps, but again just for a little while.
Regards.

I think it's related to an NVIDIA text rendering bug in QT

tried "nvidia-settings -a GlyphCache=1" ?

> tried "nvidia-settings -a GlyphCache=1" ?
Yep, I tried, and that is faster for me, subjectively.

Also I got some performance boost by inserting "export QT_NO_GLIB=1" in my /etc/profile. But it is basically just lowered Kwin and X appetite. So all of this is a bit not that I need, and same lags still here.

that comment was for cliff ;-)

Just put in my two cents and share a new trick. Hope Cliff got it.

I've been fighting similar issues for the better part of a week now.  Scrolling or redrawing in any KDE app is pure agony.  In any edit window (kontact, kate, konqueror, etc), typing lags badly and characters only appear about 1 per second.  

Oddly, I'm typing this in Firefox right now with no issues at all and scrolling in Firefox works fine.  Gedit works great as well.  Any GTK app seems to work fine while any KDE (perhaps QT?) app is not functional.  This all while running inside KDE.  In fact, I have 2000 or so characters buffered and slowing typing out in a Kate window right now while I type this with no real slow down at all in Firefox.  

As another side note, I am typing up e-mails in gedit and then copy/pasting them into a new kmail message.  While typing in the kmail new message window is super slow, pasting happens with no noticeable slowdown.

I'm running 
Kubuntu 10.04 x86_64, 
X Server 1.7.6, 
nvidia binary driver 195.36.15
KDE 4.4.4
Quadro FX 550
Intel(R) Core(TM)2 Duo CPU E4400  @ 2.00GHz
4GB RAM
Dual LCDs with Xinerama (I'm going to try disabling this next)

This problem started occurring immediately after my upgrade to Kubuntu 10.04 from 9.10. 

Cliff, do you have any details on the QT rendering bug?  My gut tells me you might be onto something.

shot in the dark, try "QT_NO_GLIB=1 kwrite", see whether speed is ok...

I believe it is related to QT's implementation of QTextEngine and QTextLayout.  There were quite a bit of bugs reported in QT's bug reporting pertaining to performance problems.  It looks like QT has attempted to fix most of them with the latest version QT 4.6.3

http://labs.trolltech.com/blogs/2010/06/08/qt-463-released/
http://qt.nokia.com/developer/changes/changes-4.6.3

There's still some more text rendering related bugs in QT's list, though, like:
http://bugreports.qt.nokia.com/browse/QTBUG-8389

If someone could try it out with the latest QT updates, it would be interesting to hear results.

You have to forgive me.  I have been slammed at work. I think my time will free up in a couple more weeks, and I'll be able to do some real detective work.  Right now, though, I'm guessing QT will have it resolved by then.

Qt 4.6.3 — http://img189.imageshack.us/img189/3044/112g.png (scrolling in dolphin), but just an hour ago I didn't have such lags. So, after the three hours uptime, all the problems returned back.

æcliff:
The referred textrendering bugs are quite specific to selecting text. I doubt /those/ cause any of the rather general issues pointed out here.

@inviso:
actually your experience differs from the original as apparently only Qt applications seem affected.
You should check cpu load (top) and whether this problem is related to compositing and iff, then try the "show paint" plugin to identify high frequent update areas.
Also to spot the text rendering: is scrolling eg. an image in konqueror or gwenview slow as well?

@alexander:
does suspend/resume clear the stage?

> does suspend/resume clear the stage?
Yep, it does, for some time. Do you think this is nvidia's blob fault?

i think it's someones fault (ie. thinking into the void won't get this fixed ;-)
it's however obviously induced by kwin (and/or just the compositing extension of Xorg, or opengl)

have you tried to
- disable all effect plugins (so just run naked compositing to ensure this is not a plugin runnig wild, increasing action on screen repaints over the time)
- setting window thumbnail keeping to "never"
- the xrender backend (to check whether this is a gl related bug)
- checked the show paint plugin 
- use sysprof on X11

>- disable all effect plugins (so just run naked compositing to ensure this is
>not a plugin runnig wild, increasing action on screen repaints over the time)
Done and nothing.

>- setting window thumbnail keeping to "never"
Done with the same result.

>- the xrender backend (to check whether this is a gl related bug)
Same lags here.

>- checked the show paint plugin 
Don't understand what should I do :)

>- use sysprof on X11
http://img814.imageshack.us/img814/7801/114.png

Sry, first link is broken — https://bugs.kde.org/show_bug.cgi?id=234463

Crazy, maybe the sun baked my... head http://img816.imageshack.us/img816/7801/114.png

(In reply to comment #31)
> >- checked the show paint plugin 
> Don't understand what should I do :)
there's plugin called "show paint" - it will tint scren regions on update and this way allow you to monitor repaints. (not for everyday use, just for debugging ;-)
 
> >- use sysprof on X11
> http://img814.imageshack.us/img814/7801/114.png
did you dump the results and could upload them here? (it's just nvidias blob, though. my driver module (195.36.15, arch as well) does not even contain _nv001707X ... do you use the legacy driver?

Alright, got mine worked out. It indeed was related to Xinerama in some strange way.  I switch to a single monitor and life was grand.  I then enabled my second monitor through TwinView rather than Xinerama and everything is snappy.  

I'm not sure if it's expected, but Compositing is not available in Xinerama anyway so I get nifty extra eye candy as well :)  If anyone is using Xinerama for dual display and seeing slowdowns, it's worth a try to switch it over to TwinView.

Thomas, I'm not sure I tried scrolling just an image, but text scrolling in Kate and scrolling in Konqueror while on a web page were both affected.

I've updated today my kubuntu10.04 and kde4.5beta2 was installed. With composite off I can experience the same situation described above.

My GPU is a "GeForce Go 7300" on an aspire 9420. Before the update no performance issues can be seen.

The xrestop output is:

xrestop - Display: :0.0
          Monitoring 48 clients. XErrors: 1
          Pixmaps:   79129K total, Other:     401K total, All:   79531K total

I hope this can help you

thanks
christian f.

Created attachment 48120 [details]
Sysprof log file

Scrolling /usr/lib in dolphin.

(In reply to comment #34)
Hello. I apologize for my absence, just landed in hospital, accidentally :)

> there's plugin called "show paint"
Ah, sorry, I remembered it :) But it hasn't show me nothing suspicious or
interesting.

> did you dump the results and could upload them here?
Done.

> do you use the legacy driver?
I use 195.36.15 too ('cause I have 9500GT).

I started suffering this issue from KDE 4.3.

Xorg uses heavily my CPU while I interact with Plasma objects, system slows down gradually while I'm working especially if amarok is playing.

My notebook:
IBM Thinkpad r61
Intel(R) Core(TM)2 Duo CPU T8300  @ 2.40GHz
4Gb Ram
Nvidia Quadro NVS 140M

My system:
Debian squeeze/sid
kernel 2.6.33
KDE 4.4.4
Qt 4.6.3

Every workaround mentioned on this page seems to help but does not solve the problem.

Switching to the legacy nv driver (or the newest nouveau driver) fixes the problem.

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

> have you ever checked your /var/log/Xorg.0.log
Yep, http://pastie.org/1023979

> is X11 load high using the XRender backend as well?
In case with mplayer and blu-ray xrender works well, and Xorg uses my CPU not so much (5-10%), but that's all. All troubles, that I've described here, are still relevant.

> sure you're actually using the nvidia css driver?
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 3.3.0 NVIDIA 256.35
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

ok, this is a stupid question, but just came to me:
you're NOT overriding application settings for antialiasing/filtering, are you?

(either globally by nvidia-settings or through an environment variable, grep /usr/share/doc/nvidia/README for ANISO and FSAA)

(In reply to comment #42)
Yes, I'm not. ANISO and FSAA are undefined.

Should I send a bug report to the Xorg team?

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

In truth, I happy to see, that not only I noticed it. I think, 95% of users (KDE + nvidia and maybe x86-64) simply do not notice this problem, but it is present for them too. I hope, the problem is in kwin or in x-server (that is unlikely), because if not and it's in the nvidia driver — the hope is dead.

Created attachment 48662 [details]
Sysprof file

I have the same problem. I'm using NVidia driver v256.35, KDE 4.5 RC 1 on openSUSE 11.2

Blur enabled but no Xinerama or any dual monitors.

X.Org X Server 1.6.5
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux linux-suse 2.6.31.12-0.2-desktop #1 SMP PREEMPT 2010-03-16 21:25:39 +0100 x86_64 x86_64 x86_64 GNU/Linux

Please, investigate this before the final 4.5 comes out. If you have to say it's an NVIDIA bug, then say that and I report it to them linking to this report. But that Xorg and KWin eat 1-1 core after an hour is simply amazing.

In KDE 4.4.92 performance generally fell to zero. Now scrolling works very and very slow. So, I can assume that this isn't a nvidia problem. Also I do not seen this problem in gnome. If release would looks like this, it would be a tragedy.

to add, I am running kde svn (4.6.xx) and I have the same problems described, sudden random high Xorg and kwin cpu usage that really slows down the alt+tab switcher for example.

using qt 4.6.3 (qt-copy) with latest 256.29 nvidia driver (twinview) with default FSAA, but with Texture filtering set to trilinear on xorg 1.6.1 (ubuntu 9.04) x64. I am running on core i7 with 6gb ram

I will try to get it tested with qt 4.7, could some one point me to the appropriate git repo?

I've also noticed significant slowdowns which are particularly noticeable when I scroll text in Kile/Kate/KDevelop. I also use Arch (kernel 2.6.34 x86_64) with KDE 4.4.5 and NVIDIA drivers 256.35 with TwinView. 

However, some of the workarounds have improved performance a *lot*. Maybe it would be useful to add a page in Techbase...

Created attachment 48795 [details]
ARGB pixmap "benchmark"

i'm pretty much confident that this is a problem in the nvidia driver alongside XOrg 1.8.x and the way Qt works.
The reason _is_ the pixmap allocation strategy, this is _not_ related to compositing (while the overhead will probably stress the issuw)

Attached is a simple benchmark to test generating ARGB pixmaps.
The fastest strategy turns meanwhile out to be "0", (~5-10x faster than 1/2/3 and ~50x faster than "4", all causing HIGH cpu load)

Unfortunately "0" also breaks the (indirect) rendering of the KWIn decorations (don't knwo why, maybe some sync/flush is missing - hits emerald/kde4-window-decorator as well, though) on the OpenGL backend and makes the XRender backend incredibly slow.

I tried to downgrade to 195.x.x, but the situation remained the same (while the 195.x.x series worked fine and fast with XOrg 1.7.x)


I recommand to compile* and run the benchmark on your machine, then alter the allocation strategies
nvidia-settings -a InitialPixmapPlacement=n | n=0-4

wait a short moment (few seconds...) and test the benchmark again

*the compile hint is pretty extensive, just "gcc bench_argbpix.cpp -I/usr/include -I/usr/include/Qt -I/usr/include/QtCore -I/usr/include/QtGui -L/usr/lib -lQtCore -lQtGui -o bench_argbpix" should do

@Alexander:
given all the other bug reports (notably #178269) you're attached to, you might hit the XSYNC protocol issue, this is entirely unrelated - unlike this bug, that one seems not nvidia exclusive (see comment #39)
but i'm really not sure whether you don't just attach to everything that sounds like "low performance" ;-P

On my laptop, strategies "1", "2" and "3" all yield similar results (~1s). "0" is ~3x *slower* and "4" is waaaaay slower (~50s).

I did a thorough study of htis problem .The results are as follows . The CPU used is a 2.4 Ghz Intel Core2Duo dual core CPU . Cpu usage values are in %

1. After some specific time intervals  , a peaking of CPU usage is seen . It is caused only by x.org and kwin. Average peak values are: X.org=20 ,Kwin=15
maximum values are X.org=29, kwin=19
2. If you move mouse in random, CPU usage of x.org and kwin(only for these two) increases . average values are X.org=35 , Kwin=25
3. When launching an application, Cpu usage increases . Average values of X.org=25 Kwin=20
4. To measure CPU usage, if you use ksysguard, and if it draw graph ie at system load tab(not in process table tab), it consumes CPU at about 35%
5. Raising a window increases CPU usage. Average values are X.org=30 , Kwin is 15to 17
6. Blur doesn't seem to have an effect on Cpu usage . Clicking kickoff increases Cpu usage but it is same as increase in raising a window . No problem with Alt+Tab 
7. Increase in CPU usage exists mostly associated with window management 
8. Switching off compositing reduces CPU usage considerably . But that change is only because of kwin . kwin uses less than 1% CPU . But X.org usage remains same .Ie an increase of about 17% at regular intervals
9. X.org initially use about 50MB .But increases to 150 MB after some time suddenly. It happened when I launched kmail in the first time. But that didn't happen when I launched kmail again (after restarting X.org). Don't know how it happens.
It anyway increases over time from 50MB and doesn't decrease

10. Chrome uses about 50% CPU after about 5 minutes and automatically close. It's the latest version . Not chromium

To see CPU usage with compositing at idle see http://img710.imageshack.us/img710/3245/snapshot2v.png

To see Cpu usage with compositing off see http://img25.imageshack.us/img25/6969/composingoff.png

To see memory usage of various processes, see http://img25.imageshack.us/img25/2822/memoryf.png

(In reply to comment #52)
No, man, I'm never did that and I've really got all of this troubles with kwin. I really see how window redrawn when I restore it from the task bar or from the system tray. I've really got very bad kwin performance. In KDE 4.4.5 it already was tolerated, but today I've upgraded to 4.4.92 and my happiness died.

Only one thing you can assume about me it's "why this man still using KDE?" or something like that :)

(In reply to comment #54)

> 1. After some specific time intervals  , a peaking of CPU usage is seen . It is
> caused only by x.org and kwin. Average peak values are: X.org=20 ,Kwin=15

you've likely cyclic repaints, probably due to some plasmoid (clock??)

> 2. If you move mouse in random, CPU usage of x.org and kwin(only for these two) increases . average values are X.org=35 , Kwin=25

Mouse moving should cause exactly NO cpu load at all, as the (HW) pointer runs on the framebuffer directly and more or less on the GPU. A minor load is caused by the move event interpertation of the X server, but that should be hardly even notable.
It's more important what the hover events cause in consequence (repaints, window activation etc.)

> 3. When launching an application, Cpu usage increases . Average values of
> X.org=25 Kwin=20

> 4. To measure CPU usage, if you use ksysguard, and if it draw graph ie at
> system load tab(not in process table tab), it consumes CPU at about 35%
ksysguard causes notable load on the X server itself, due to its large constantly repainting areas.

> 8. Switching off compositing reduces CPU usage considerably . But that change
> is only because of kwin . kwin uses less than 1% CPU . But X.org usage remains same .Ie an increase of about 17% at regular intervals

likely for the pixmap allocation and the constant cyclic repaint, this would then *eg.* be induced by plasma or whatever reallocates the pixmap.
this allocation would also impact composited window activation, notably for animated decorations such as oxygen (which fades in on activation)

if you've got an nvidia GPU + css drivers, see commet #52


> 9. X.org initially use about 50MB .But increases to 150 MB after some time

check "xrestop" for whether this is caused by offscreen pixmaps (map to RAM when you've no or exceeded V(ideo)RAM)

> 10. Chrome uses about 50% CPU after about 5 minutes and automatically

Chrome is absolutely not dealt here, bug google.

(In reply to comment #56)

> I really see how window redrawn when I restore it from the task bar or from the
> system tray.
This sounds _far_ more like the XSYNC issue and not so much like trouble with slow pixmap allocation.
The main difference is that the XSYNC issue (very likely) defers from broken timings and (thus) causes no CPU load. It's also not related to compositing, and the delay is (should be) much bigger than with slow pixmap allocation.

I didn't mean to offend you in any way, but it's important to bisect your (main) issue and hooking onto every "slow" bug makes all your comments "my system is slow", striking the "because" part.

So you should first benchmark your allocation strategies. select the fastest one* and see whether the probelm is gone.
If not, you've either really bad luck on the driver or face the XSYNC issue (which would immediately disappear by replacing the WM, while allocation troubles will likely remain when using eg. compiz in a KDE session)

*since the benchmark is everything but accurate, ie. the printed time is _real_ time, not process time..., run it two or three times and ensure there's no other load on your CPU while running it.

By default I have this results:

$ nvidia-settings --query InitialPixmapPlacement

  Attribute 'InitialPixmapPlacement' (arch:0.0): 2.
    The valid values for 'InitialPixmapPlacement' are in the range 0 - 4 (inclusive).
    'InitialPixmapPlacement' can use the following target types: X Screen.

$ ./bench_argbpix
8191 x new, (800x20 px): 791 ms

With 1 — 634 ms, with 3 — 632 ms, with 4 — 15348 ms. Subjectively 1, 2 and 3 are acceptable values.

Would be nice if Kwin will use your benchmark to find best InitialPixmapPlacement value and set it automatically in background. It's would be much more user friendly.

P.S. I am not offended, conversely, I think you're right and sometimes I was too carried away.

Using : Ubuntu 10.04 + Kubuntu testing PPA (KDE 4.5 RC2) + up to date nvidia drivers + geforce 9800 green edition 1 GB

There is definitely a major bottleneck in kwin here which makes the whole environment almost unusable.

For instance :

- when playing a video in VLC 1.1, even with hardware decoding (VDPAU), kwin itself (not vlc) consumes up to 50% of the CPU usage (so, the whole first core), with a 720p video (a little less when the video is *paused*, around 40 % !!!)

- when enabling the FPS count kwin plugin, you clearly see the FPS count plummeting from 60 FPS to 40 when playing a video.

- when playing games, framerates seem to be generally halved !

- there is no such issue when composition is disabled, and everything is perfectly smooth with compiz

- vsync enabled / twinview disabled (in order to get the right Vsync value)

In my very specific case, the situation gets much better (smoothness / CPU usage) when I disable the 3 following options / plugins *at the same time* :

- vsync
- blur effect
- slide effect (when changing virtual desktops)

OMG, people, this bug isn't about compositing :) As I wrote previously, I've got slow work with compositing and without it. It absolutely irrelevant here.

I think too many messages in the last time because people begin to try 4.5 and because kwin in this beta works much worse that in 4.4.5. Personally I was forced to revert back on 4.4.5. But I must notice that 4.4.92 works better than 4.4.90 and much better than 4.4.80. So, maybe release will be much better.

Hmm, indeed, we should open a distinct bug report for the CPU usage issue with compositing enabled (that is another actual issue :).

I found out a very strange behavior 
1. The CPU usage is 100% . Load in both cores ranges from 95 to 100 percent . The strangest thing is that ,adding the CPU usage of individual processes doesn't exceed 50%
2. The hard disk is spinning at maximum speed continuously 
3. At this time, the responsivity is really sluggish. It takes a long time to appear menu after right clicking, scrolling is really slow, moving windows is slow(first the mouse moves. after some times, window moves). Nobody can use the computer at this state
4. This happened when I right clicked on a video file in "DOLPHIN". To reproduce, right click on a video file, and move mouse over the menu appears . move mouse over the sub menu of "open with" . This happens in good quality video files ,not necessarily HD. Surely happens in all HD files(.mkv format) I tried
.Happened in some non HD files too
5. This happens when an HD is open(tried in VLC,Dragon) too
6. This happens regardless whether video preview is on or off or whether video preview is enabled or not in dolphin settings
7. This doesn't happen when file is double clicked in KONQUEROR

8. Another strange thing is that the gnome-system-monitor (shipped with ubuntu) doesn't show 100%. It shows less than 50% .

I found out a very strange behavior 
1. The CPU usage is 100% . Load in both cores ranges from 95 to 100 percent . The strangest thing is that ,adding the CPU usage of individual processes doesn't exceed 50%
2. The hard disk is spinning at maximum speed continuously 
3. At this time, the responsivity is really sluggish. It takes a long time to appear menu after right clicking, scrolling is really slow, moving windows is slow(first the mouse moves. after some times, window moves). Nobody can use the computer at this state
4. This happened when I right clicked on a video file in "DOLPHIN". To reproduce, right click on a video file, and move mouse over the menu appears . move mouse over the sub menu of "open with" . This happens in good quality video files ,not necessarily HD. Surely happens in all HD files(.mkv format) I tried
.Happened in some non HD files too
5. This happens when an HD is open(tried in VLC,Dragon) too
6. This happens regardless whether video preview is on or off or whether video preview is enabled or not in dolphin settings
7. This doesn't happen when file is double clicked in KONQUEROR

8. Another strange thing is that the gnome-system-monitor (shipped with ubuntu) doesn't show 100%. It shows less than 50% . 

One more thing the compositing was disabled when I tried

Please remove the bug number 64. Caused because of network error

> (In reply to comment #54)
The peaking in CPU usage is caused by wallpaper slide show . 
The CPU usage of course changes noticeably when mouse is moved

Please read the 7 th line as " This doesn't happen when file is RIGHT clicked in KONQUEROR"

The bug I described in #65 doesn't seem to be that of Nvidia driver . It appears in opensource nouveau driver too . It seems that the information sidebar should be there and preview of video should be switched on(in dolphin)

(In reply to comment #65)
This seems to me something different not kwin related - a preview is being created and your I/O subsystem gets really busy at that time, which causes
what you've described. There is nothing to do here, apart optimizing thumbnail generation process.

sorry guys this bug report does not help at all. We have here something like 
thousand different issues which are somewhat somewhere related to performance 
in KDE. Most of the issues are unrelated to KWin.

Please get this report to a point where it useful. Please try to investigate 
what is causing your performance problems and report a new bug for each found 
issue. That would be helpful. Having one huge report is not helpful.

wow yes... to sort out some things:

-----
a bunch of you has issues with the pixmap allocation in the nvidia driver.
this is an nvidia issue and cannot fixed from KDE side at all!

symptoms:
- you use the CSS nVidia blob
- no relation to compositing
- high cpu load whenever an (ARGB) pixmap is allocated (eg. when hovering a taskbar entry, but also when activating/resizing windows !when compositing is active!)

-> try the attached benchmark. the parameter "skip" runs the loop w/o actuall allocating pixmaps, so you can subtract the time from the one spend on allocating pixmaps.
best value here ("0", currently broken) is ~340 ms
mid values (1-3, working) are ~1200-2000 ms
nouveau driver: ~900 ms

this can be lowered for "normal" applications by not using oxygen or deactivate the animations.
for (composited, but i think it's not optimized away when not compositing) kwin try to set the no border option (only a titlebar) in the oxygen decoration as this will prevent allocation large pixmaps when rendering the decoration offscreen

----------

another fraction might (additionally) face the XSYNC protocol issue as reported in bug  #178269 and the list in comment #11, comment #10 explains howto deactivate this at compile time

symptoms:
- no additionally high CPU load (timer driven)
- not related to compositing
- not related to any GPU type
- updates are _really_ slow (the lag is up to 500ms)

---

Mahendra and maybe others probably face a bug in the slide desktop plugin, which apparently sets the fullscreen effect when activated the first time and fails to deactivate it (resp. sets it in every following cycle), preventing all optimizations as well as unredirection for fullscreen windows.

also be aware that the blur plugin prevents such optimizations and bllurring isn't cheap anyway (esp. on less powerfull hardware)

if you want to check whether unredirection happens
a) ensure this:
    grep -i unredirect `kde4-config --path config | cut -d ":" -f1`kwinrc
does NOT say:
    UnredirectFullscreen=false

b) to test at runtime i know only one test, that is to install BeClock from kde-look.org, activate it and enter a fullscreen mode. the clock should vanish if unredirection succeeded.

----

kristjan is right on bug #64: that's really no kwin issue at all, sorry. (esp. not since it's related to dolphin and the cpu load is likely not on kwin or even X11)

---

the wallpaper slideshow peak is expectable but might get worse due to the nVidia alloation issue.
Notice that it triggers load on
a) image loading
b) image to X11 picture conversion (+scaling)
c) X11 to OpenGL conversion of every repaint of the animation

there might be space for optimization in plasma (depending on the implementation, if it's painting images instead pixmaps,l doesn't cache the scaled variant or use unnecessarily high framerates) but not much kwin could do here, sorry.

----

In general opengl compositing is always an overhead as every client update has to be converted from X11 to OpenGL. Obviously this scales with size and framerate.
Use the XRender backend or no compositing if your system cannot bear this.

Also keep an eye on the used plugins, stuff like sharpen might look nice but is expensive (shader effect).
Additionally sharpen in particula is plain wrong for nvidia users, as the driver provides this w/o /any/ overhead!

Seems that beclock is a magic effect, it fix the bug #177495 :)

But if seriously, I already had noticed before, that flickering gone, when plasma notification is opened (those, that are placed in the system tray).

I think nvidia is not involved in this. Judge for yourself, just right now I tried 4.4.5 again and it works like a charm in comparison with 4.5. Scrolling works fast (at least for a while), but in 4.5 it is initially broken. It is working like a slide-show, even with small directories (again X using CPU at 75-80%), but this does not happen in 4.4.5! Even when the bug, that I have described in this thread, was showing themselves, even then scrolling was worked better. Maybe in 4.5 I am experiencing some new, advanced bugs...

Switching to Xrender does not helps. But, seems that if switch from "texture from pixmap" to "shared memory", for example, and the return back — seems that this fix the bug, whom this topic is devoted.

Also some kwin effects is broken ("Show all windows", for example, works at least several times worse, but in this case Xrender helps).

(In reply to comment #74)
> I think nvidia is not involved in this. Judge for yourself, just right now I
> tried 4.4.5 again and it works like a charm in comparison with 4.5.
You started this report on version 4.4.2 ...

Please: (and one more time) do not mix up everything about "KDE is slow" into one big bug report. That does not help at all.

What you face in 4.5 is either 
- a major slowdown through the blur filter (for your GPU: turn it off!) or
- you're (for what reason ever) permanently zooming on the lanczos filter, or
- you face the issue that occurs when gl compositing fails and kwin silently falls back to xrender (this has been removed and i also don't think this occurs on the nVidia driver)

> Scrolling works fast (at least for a while), but in 4.5 it is initially broken. It is
> working like a slide-show, even with small directories
Did you try _anything_ but dolphin? How does scrolling in xterm work (the bar uses the middle mouse button)

> But, seems that if switch from "texture
> from pixmap" to "shared memory", for example, and the return back — seems 
> that this fix the bug, whom this topic is devoted.
Humm... what if you just suspend/resume instead?

> Also some kwin effects is broken ("Show all windows", for example, works at
> least several times worse, but in this case Xrender helps).
That is the lanczos filter...

> a major slowdown through the blur filter
Yep, and I already disabled it and written a comment to the related bug report.

> you're (for what reason ever) permanently zooming on the lanczos filter
I use the left-top corner on the screen to show all windows and use it to switch between them. For this it was created?

Scrolling in xterm works fine, but Firefox works fine too if I will open plain text instead of kde.org. Very intensive this bug is manifested in these programs: Dolphin, Amarok and Firefox. But slow work of all interface components is noticeable in all applications, of course if they have these elements.

> Humm... what if you just suspend/resume instead?
No, that give nothing. I need to switch from "texture from pixmap" to "fallback". After that I get a warning that this mode does not work: "Failed to activate desktop effects using the given configuration options. Settings will be reverted to their previous values.". Then I switching back to "texture from pixmaps"... Crazy? Oh yeah! I have thought that I was crazy, when writing this. But after this actions scrolling in Firefox and Amarok becoming faster (in Dolphin too, but in 4.5 it is not so noticeable). All the rest applications becoming much more responsive. This is not a subjectively feeling.

> That is the lanczos filter...
Really, thumbnails of windows became more accurate and clear. Is sadly that the effect itself became almost unusable due to this "improvement". At the same time the "show all desktops" effect works more smoothly... yet, although and creates thumbnails of a low quality (for my opinion, this is quite enough). Interesting is fact that CPU usage during the "show all windows" effect works is 50-70%, so this looks like a just slow realization. And it should be optionally, if that is true and if KDE 4.5 pretends to be called stable.

(In reply to comment #76)
> I use the left-top corner on the screen to show all windows and use it to
> switch between them. For this it was created?
Yes, but that's a temprary effect. I feared you might permanently have a zoom factor != 1.0 what would a) "stress" the GPU and b) outperform your shaders on the lanczos filter introduced for scaling in 4.5
 
> Scrolling in xterm works fine, but Firefox works fine too if I will open plain
> text instead of kde.org. Very intensive this bug is manifested in these
> programs: Dolphin, Amarok and Firefox. But slow work of all interface
> components is noticeable in all applications, of course if they have these
> elements.
That hints a client issue, maybe a resource conflict as the client and kwin's compositing require your GPU at the same time ("new" kde.org is f**** slow, btw - and i mean in a browser profiler w/o compositing...)

As for iconviews like in dolphin:
the vertical (OSX-a-like) arrangement of QIconView is _far_ more expensive then the horizontal (XP-a-like) one
This however corresponds with the pixmap allocation strategy. "2" is slow here (256.xxx), while "0" is instant - compositing or not.
 
> > Humm... what if you just suspend/resume instead?
> No, that give nothing. I need to switch from "texture from pixmap" to
> "fallback". After that I get a warning that this mode does not work: "Failed to
> activate desktop effects using the given configuration options. Settings will
> be reverted to their previous values.". Then I switching back to "texture from
> pixmaps"... 

> Crazy? Oh yeah! I have thought that I was crazy, when writing this.
Yes, very crazy ... yet i _can_ actually reproduce this behaviour... %-\
Dolphin scrolling (vertical, composited or not) becomes _significantly_ faster, regardless of the pixmap allocation strategy (and i can show it in the benchmark)
This might cause sth. on the GPU powersaving, maybe related to the nvidiahack lib... i'll certainly have a look at this, since the impact is drastic - good catch!
(it's however not in kwin but rather a side effect on the GPU -> benchmark proof)

I am incredibly happy to see that though something from what I said could be reproduced :)

yes, it however seems some driver bug :-(

my observation (the argb bech, which should be relevant here)

InitialPixmapPlacement = 0 is really fast (~350ms) but ends up with broken decorations in kwin & emerald (-> fix that), just like the 19x.xxx drivers used to be on Xserver 1.7.x

InitialPixmapPlacement = 1||2 is incredibly slow (~1500ms & 3000ms, but i can _hear_ the condensators in "1") unless i crashrestart kwin attempting to use the fallback generation (on "2"), then it becomes pretty fast (~600ms) but starts to slow down over the time ... (and that's not related to compositing)
Eg. opening dolphin and selecting a bunch of files has very bad impact (the bench significatly drops during this, mode "0" remains ultimately fast)
closing dolphin then speeds up the bench a bit

by now changing the allocaion strategy to 0 !and using it!!! (eg. calling the bench) and back to 2, the latter mode gets an immediate boost (from 3000ms during dolphin is up over ~1300 after closing it to ~750 after swapping allocation strategies)

Conclusion:
there seem remaining problems in nvidias pixmap allocation strategies with xorg 1.8 and they seem related to some caching (given mode 0 is not really usable due to blind titlebars in kwin / emerald+compiz)

Optimal solution would oc. be a working mode "0".

Since i can reproduce things, i'm gonna contact nvidia on this... (this seems reall important and has nothing to do with compositing manager implementations)

Could you please post here the thread link you will open at:
http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

My kde also slows down over time, but on an older card IPP at 0 seems to be slow when using desktop effects.
Thanks!

$ ./bench_argbpix
8191 x new, (800x20 px): 5066 ms

$ nvidia-settings -a PixmapCache=0 && nvidia-settings -a PixmapCache=1

$ ./bench_argbpix
8191 x new, (800x20 px): 647 ms

confirmed, good catch again (i had cheked it for being active, but actually that slowed down even more...)

so the driver really might 
a) mess up the cache state 
b) leak 

occasional re-arming of the pixmap cache seems a nice workaround (for a simple user dameon bash implementation:

#!/bin/sh
while true; do
   nvidia-settings -a PixmapCache=0; nvidia-settings -a PixmapCache=1
   sleep 1800 # wait 300 minutes
done

(i'll test under "not kde" to ensure it's a plain upstream bug and not triggered by some KDE stuff)

I have added it as cron task ;)

ensure to "export DISPLAY=:0" then ...

F*** - it's in kdelibs

- I disbaled the rearming, rebooted and launched a "failsafe session" (xterm)
   -> IPP 2 benchmark @350-380ms - better then ever before
- Launched icewm
   -> IPP 2 benchmark @350-380ms
- Launched chromium (since it's a gtk+ browser) and opend plenty of webpages
   -> IPP 2 benchmark @350-380ms
- Launched arora (Qt only browser) and opend plenty of webpages
   -> IPP 2 benchmark @350-380ms
- Launched opera and opend plenty of webpages, dealt mailes
   -> IPP 2 benchmark @350-380ms
...
- Launched dolphin
   -> IPP 2 benchmark @660ms
  - selected a bunch of icons
       -> IPP 2 benchmark @1000ms
  - closed dolphin
       -> IPP 2 benchmark @470ms
- Launched kwrite
   -> IPP 2 benchmark @620ms
  - selected a bunch of icons
       -> IPP 2 benchmark @1000ms
  - closed dolphin
       -> IPP 2 benchmark @470ms

SORRY - I HATE ARORAS LAGGY KBD CTRL SHORTCUTS!

F*** - it's in kdelibs

- I disbaled the rearming, rebooted and launched a "failsafe session" (xterm)
   -> IPP 2 benchmark @350-380ms - better then ever before
- Launched icewm
   -> IPP 2 benchmark @350-380ms
- Launched chromium (since it's a gtk+ browser) and opend plenty of webpages
   -> IPP 2 benchmark @350-380ms
- Launched arora (Qt only browser) and opend plenty of webpages
   -> IPP 2 benchmark @350-380ms
- Launched opera and opend plenty of webpages, dealt mailes
   -> IPP 2 benchmark @350-380ms
...
- Launched dolphin
   -> IPP 2 benchmark @660ms
  - selected a bunch of icons
       -> IPP 2 benchmark @1000ms
  - closed dolphin
       -> IPP 2 benchmark @470ms
- Launched kwrite
   -> IPP 2 benchmark @620ms
  - opened a file
       -> IPP 2 benchmark @630ms
  - opened open dialog
       -> IPP 2 benchmark @690ms
  - closed kwrite
       -> IPP 2 benchmark @470ms
...
- Launched kwin (+compositing)
   -> IPP 2 benchmark @880ms
 - launched opera
       -> IPP 2 benchmark @950ms
  - playd with cover switch
       -> IPP 2 benchmark @950ms
  - suspended composition
       -> IPP 2 benchmark @950ms -> -> -> 1030

- lauched icewm
   -> IPP 2 benchmark @580ms
- lauched compiz+emerald
   -> IPP 2 benchmark @653ms

While it's probably ok for composited kwin to allocate more pixmaps then icewm (and even compiz, given the way kwin renders decorations)
There seems a severe issue with KDE applications on this, since kwrite or even dolphin should not cause as much load as complex webpages in >40 tabs in 3 browsers :(

king is kmail 650 -> 7500 [sic!] -> 780, so it could be related to QTreeView
(it's luckily NOT related to the style, tried with bespin, then with CDE)

Now you can imagine, what lags me enjoyed so long time, when using Firefox, Kmail, Amarok, Dolphin, Ktorrent, Korganizer and many another KDE applications together :)

*** This bug has been confirmed by popular vote. ***

After some time it happens to me, also. Kwin eats one core, Xorg eats the other. It's not so funny.

I tried that I killed and restarted Kwin (killall kwin && kwin) and after that +5 minutes, everything was ok. 

Btw, maybe it's related: http://www.kdedevelopers.org/node/4318
The blog about this problem says that changing the widget style may help.

it's likely caused by the leaking pixmap cache, see comment #82

It happened again. I executed the command
 nvidia-settings -a PixmapCache=0; nvidia-settings -a PixmapCache=1
but nothing happened (I waited for 10 minutes).

Next time I will use sysprof and attach its output.

(In reply to comment #92)
Seems that you have a some different issue and this bug should be renamed to avoid ambiguity.

I can confirm that executing ...

nvidia-settings -a PixmapCache=0; nvidia-settings -a PixmapCache=1

... fixes the problem for a while.

Same here, also gets "fixed" for a while by disabling/enabling nvidia's pixmap cache. Super annoying bug :(
Using the binary driver v. 256.44 and KDE 4.4.5... now, is that Kdelibs or Nvidia driver's fault?

probably kdelibs, see comment #86 - after some more testing it does however not seem to be the treeview... =\

Is there anything I can do to help resolve this bug? With the current situation it is really not possible to work a full day without restarting the X server - especially when using kontact. While "nvidia-settings -a PixmapCache=0; nvidia-settings -a PixmapCache=1" works quite well for the first few times, it seems to lose its effect after a while. Then I have to logout press Alt+E and relogin to continue my work.

> Is there anything I can do to help resolve this bug? 
You could have a look at http://hugo-kde.blogspot.com/2010/09/performance-
issues-one-script-and-call.html

I believe that Oxygen has its own opportunities for improvements :) but this bug is reproducible with another styles too.

Don't know how it is for others but I've not had this problem for a while now.

Currently running:
openSUSE 11.2 with KDE 4.5 (kwin ver: 4.5.2)
NVidia driver version 260.19.12 (installed 'the hard way') on a GeForce 6800 GS

It may be that somewhere down the line an upgrade of kwin or nvidia has fixed the problem - sorry, didn't keep track of just when the problem seemed to go away.

I'm going to keep myself CC'd to see if anyone comes up with a reason for the bug or knows when it got squashed.

$ ./bench_argbpix
8191 x new, (800x20 px): 967 ms

After running Kmail, Amarok and Kopete.
$ ./bench_argbpix
8191 x new, (800x20 px): 1565 ms

Qt: 4.7.0
KDE: 4.5.2 (KDE 4.5.2)
kde4-config: 1.0
Nvidia: 260.19.12, from Arch Linux extra repo

Some time later...

[heaven@arch: Desktop$] ./bench_argbpix
8191 x new, (800x20 px): 7041 ms

issue remains here as well (but arch like Alexander)
@Alan: what's the output of "nvidia-settings -q InitialPixmapPlacement -q PixmapCacheRoundSizeKB" and did you (SuSE) setup a specific 'Option "PixmapCacheSize"' in  /etc/X11/xorg.conf?

As requested -

> nvidia-settings -q InitialPixmapPlacement -q PixmapCacheRoundSizeKB

  Attribute 'InitialPixmapPlacement' (nikyo:0.0): 1.
    The valid values for 'InitialPixmapPlacement' are in the range 0 - 4 (inclusive).
    'InitialPixmapPlacement' can use the following target types: X Screen.

  Attribute 'PixmapCacheRoundSizeKB' (nikyo:0.0): 1024.
    The valid values for 'PixmapCacheRoundSizeKB' are in the range 4 - 1048576 (inclusive).
    'PixmapCacheRoundSizeKB' can use the following target types: X Screen.

I don't have /etc/X11/xorg.conf - having tried out various settings and ended up not being able to get 1680x1050 with sax without porting an old xorg.conf from an openSUSE 11.1 backup I thought I'd let xorg generate its own since it's supposed to be able to do that now.

ps. I got the high CPU usage with and without xorg.conf, it's just that since xorg seemed as happy without xorg.conf as with it, I thought I'd let it get on with it :-)

Hope it helps

Alan

I was having this problem using the Nvidia blob, however I just upgraded to F14 and tried nouveau + mesa-dri-experimental. I continue to have the same high CPU use by kwin and plasma:

top - 09:14:25 up  2:02,  4 users,  load average: 1.25, 1.53, 2.02
Tasks: 219 total,   2 running, 215 sleeping,   0 stopped,   2 zombie
Cpu(s): 19.5%us, 12.9%sy,  0.0%ni, 67.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4045584k total,  3913708k used,   131876k free,   191348k buffers
Swap:  6191128k total,        0k used,  6191128k free,  1909108k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                             
16823 malc      20   0  661m  38m  19m S 25.9  1.0   2:00.72 kwin                                
16582 root      20   0  187m  73m 6024 S 18.6  1.9   2:06.97 X                                   
16829 malc      20   0 1021m  71m  31m S 16.3  1.8   1:20.14 plasma-desktop                      
16952 malc      20   0  502m  22m  15m S  2.3  0.6   0:01.31 konsole     


From Xorg.0.log:

[  6821.613] (--) NOUVEAU(0): Chipset: "NVIDIA NV98"

(Nvidia Quadro 140)

sysprof file attached.

Created attachment 53429 [details]
Sysprof file, running KDE 4.5.3 with nouveau drivers 2.6.35.6-48.fc14.x86_64

I switched to Gnome - couldn't stand this bug anymore which has been around for too long and makes my desktop completely miserable.

Problem appears here too.

Debian/sid x64 (kernel 2.6.32-5-amd64)
Geforce 6600
Qt: 4.6.3
KDE: 4.4.5
NVIDIA-driver: 195.36.31
X.Org X Server 1.7.7

@mps
this is different from the original report.
it looks like sth. (probably some "plasmoid" on your desktop... possibly big) is constantly repainting.

for a quick test, "kquitapp plasma-desktop" should sanitize CPU usage, then (if) restart plasma "plasma-desktop" and use the "show paint" plugin to figure what it is and disable it - or use the XRender backend...

just curious, is there any of you guys that have this bug that can reproduce  Bug 251786?

I don't know about the bug you mention Charlieb000. Regarding the bug here with high cpu usage with kded4 This is how i can reporduce:

1. login kde then after everything is loaded on the desktop then *immediately* logout (kmenu->leave->Logout->logout btn)

2. now try to quickly login again and check your cpu usage: kded4 taking up all the cpu.

"2. now try to quickly login again and check your cpu usage: kded4 taking up all
the cpu."

That's not related to the WM therefore not related to this particular bug.
You should file one against kded.

Let's go back to the original problem. The problem still persists for me with the following configuration:

Debian/sid x64 (kernel 2.6.38-1-amd64)
Geforce 6600
Qt: 4.7.2
KDE: 4.4.5
NVIDIA-driver: 260.19.44
X.Org X Server 1.9.4

I confirm the problem with nvidia card slowdown. The slowdown stops with the tip described on comment #81. I don't know why this happens, but the slowdown is very noticeable. Restarting the xorg fix the slowdown too, but it's back randomly.
Nvidia 330M with driver 270.41.19
Xorg 1.10.1
Kernel 2.6.38.7

Hmm... it seems my experience with slowness is resolved with 275 version of nvidia drivers.

http://www.nvidia.com/object/linux-display-ia32-275.09.07-driver.html

And YES: I can confirm some improvement as well.

The "benchmark" shows sane numbers after KDE startup, launching (kapplication?) GUI processes slow down the "benchmark" (only) a little.

So launching kmail + akonadi + the latter ones many (semi-GUI) processes causes _slight_ slowdowns, shutting down them (kquitapp kmail, akonatictl stop) however "improves" (reverts) the situation, so the pixmap cache is apparently kept clean.
This is also supported by the fact that while turning it off, the "bench" performance and overall speed drops dramatically but turning it back on brings the benchmark to the previous numbers "only".

So, for resizing windows it's pretty significant (read: "impressive")
It should also cover the "hang on activation from any kind of effect" issue.

QtWebKit still prefers the native graphicssystem, but that's maybe not even an nvidia issue at all (unfortunately i've no qtwebkit benchmark to really test its check performance)

Amazing, now I haven't this bug any more:
 [heaven@arch: Desktop$] ./bench_argbpix
8191 x new, (800x20 px): 62 ms

It is feels better and without benchmark, all works much faster. Also it is possible that reason is in that I changed my system hardware, but the same graphics card... can someone else confirm that performance improvement?

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

as of comment #117 which is more than half a year ago I assume this issue to be fixed.

This is definitelly solved for me, but not sure if this is actual for another people participating in this bug.

Sad to say, but I started to suffering from it again, since updated to KDE 4.8.90 from 4.8.*

Tried this command nvidia-settings -a PixmapCache=0 && nvidia-settings -a PixmapCache=1 again and it helped.

Very noticeable on windows minimizing/maximizing, all mouse over effects works with lags, etc.

Same for me, with Lenovo Thidpad t510 (graphic card: Intel Ironlake Mobile)

(In reply to comment #122)
> Same for me, with Lenovo Thidpad t510 (graphic card: Intel Ironlake Mobile)

Whatever you observe is different because this bug focuses around some specific nvidia driver behavior.

You probably run into your GPU lying about capabilities and the blur effect using too much resources in return causing the IGP to use some software emulation - or just sth. on your desktop constantly repaints.

Deactivate all effects in "kcmshell4 kwincompositing" and set the scale method to smooth (last tab) and see what happens.
If there's no improvement, activate the "show paint" effect and see whether some area flickers like hell.

Anyway, "me too" on this kind of bug is by far not enough information (lacks KDE version) to assist you. Please head over to the kwin board at forum.kde.org  and start by posting the output of "qdbus org.kde.kwin /KWin supportInformation" (requires 4.9) and the observations made reg. the questions above.

@Alexander:
i suspect you updated more than KDE at that time?

Use the raster graphicssystem (and the OpenGL compositor) everywhere to bypass this problem as much as possible but from my personal experience

a) this comes and goes with the nvidia blob version
b) i haven't seen it for a long while

Given that flushing the PC temporarily "fixes" it quite much suggests that this is not a problem with kwin, but the general pixmap usage in KDE and how the nvidia blob reacts to it.

I would frankly not know how to fix within KWin at all BUT only to avoid it by redesigning the deco API, what imo will have to happen when Qt5 drops the native graphicssystem and we'll one day also want to support Wayland, but that's OT here.

Leaving the bug open, in case anyone else is (really, only nvidia users here, see commen #121) but the truth is, that it's "wontfix" :-(

(In reply to comment #124)
Yeah, a lot of things have been updated including nvidia f*** blob. This all about pixmap cache, when it is disabled even windows minimization is choppy. With pixmap cache enabled everything works like a charm but only for some uncertain time and then becomes choppy even with enabled cache.

For me this is especially noticeable when running GTK apps (using oxygen-gtk style), such as gimp, rubymine, smartgit, etc. The last two aren't actual gtk apps but they use bindings. After a while smartgit becomes very unresponsive and disabling and then enabling pixmap cache fixes that.

I even upgraded my graphic card supposing it could fix the issue... I am noob in graphic systems but I am also realize that wayland is very far from us. Is there any way to not use some nvidia "features" to avoid those lags?

Btw, I am already switched to the raster graphic system a long time ago and also use these optimizations:
### Qt optimizations
export QT_NO_GLIB=1
export MALLOC_CHECK=1

Removing `export QT_NO_GLIB=1` makes things much worse. At the same time the bench_argbpix script before, when lags happen, showed really big time delays (up to a few seconds). But now it always show less than 100ms (≈65 in average).

@Oleg Tsarev
You can also try to disable kwin decoration animations http://oi47.tinypic.com/2nkrv9x.jpg They makes windows minimization very slow for me.

Best,
Alex

1. All KDE effects disabled
2. problem stable reproduced time-to-time
3. problem reproduced more often when gtk-applications run (deluge, firefox, etc)
4. It is independed from driver, my friends received exactly same behavior with NVidia/Intel graphics.

(In reply to comment #123)
> (In reply to comment #122)
> > Same for me, with Lenovo Thidpad t510 (graphic card: Intel Ironlake Mobile)
> 
> Whatever you observe is different because this bug focuses around some
> specific nvidia driver behavior.
> 
> You probably run into your GPU lying about capabilities and the blur effect
> using too much resources in return causing the IGP to use some software
> emulation - or just sth. on your desktop constantly repaints.
> 
> Deactivate all effects in "kcmshell4 kwincompositing" and set the scale
> method to smooth (last tab) and see what happens.
> If there's no improvement, activate the "show paint" effect and see whether
> some area flickers like hell.
> 
> Anyway, "me too" on this kind of bug is by far not enough information (lacks
> KDE version) to assist you. Please head over to the kwin board at
> forum.kde.org  and start by posting the output of "qdbus org.kde.kwin /KWin
> supportInformation" (requires 4.9) and the observations made reg. the
> questions above.

(In reply to comment #125)

> For me this is especially noticeable when running GTK apps (using oxygen-gtk style)
does the style (try raleigh - yes, it's not very pretty ;-) have an impact here?

> I even upgraded my graphic card supposing it could fix the issue...
It's not about the power (just setting them to "performace" mode boosts memory clockrate and throughput beyond good and evil) and hoping for differences in the driver is russian roulette :-(

> noob in graphic systems but I am also realize that wayland is very far from
> us.
"Far" is a generic word - the bug is 2½ years old and i'll bet your right arm that you'll run wayland before another 2½ years ;-)

> Is there any way to not use some nvidia "features" to avoid those lags?
Stay away from ARGB pixmap allocation ...

> Btw, I am already switched to the raster graphic system a long time ago and
> also use these optimizations:
Ok, but that (not only for kwin but in general, i assume) only affects Qt applications. However, unless you're using some transparent UI style they should no longer acquire a significant amount of ARGB pixmaps at all.

> export QT_NO_GLIB=1
Be carefull with this.
The glib dispatcher is (yes, dear glib friends) clumsy, but whenever it comes to gobject interaction (including glib-dbus, esp. policykit, such as "polkit-kde-authentication-agent-1", but also gstreamer/pulseaudio invocation through eg. clementine or ns browser plugins - flash) it becomes rather inevitable for proper functionality :-(


> export MALLOC_CHECK=1
errr ... that is no optimization, but a debug function to protect against illegal heap accesses - and it's "MALLOC_CHECK_"

"Another possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down."

> Removing `export QT_NO_GLIB=1` 
kwin disables the glib dispatcher anyway since we had trouble with it's 1 cycle delay. Notice that this has no impact on gtk applications.

> At the same time the bench_argbpix script before, when lags happen, 
> showed really big time delays (up to a few seconds). 
> But now it always show less than 100ms (≈65 in average).

You mean the "benchmark" (we're not gonna call it like that, or have to apologize to phoronix =) produces (with the native system, on the raster graphcissystem it's expected to be constantly fast!) fast results despite graphics lag?
That would point a rather different issue then.

(In reply to comment #126)

> 4. It is independed from driver, my friends received exactly same behavior
> with NVidia/Intel graphics.

If it's not specific to the nvidia blob, it's not this bug, watch the repaints.

Hi, yes, the benchmark script always show the fast results despite the graphics lag.

(lags appeared)
./bench_argbpix
=> 8191 x new, (800x20 px): 70 ms 
nvidia-settings -a PixmapCache=0 && nvidia-settings -a PixmapCache=1
(lags disappeared)
./bench_argbpix
=> 8191 x new, (800x20 px): 70 ms 

Just upgraded to KDE 4.10 and still the same. The bug is much more noticeable when you have a lot of windows opened. And I am not only using KDE apps.

BTW, I did not noticed anything like that in Gnome.

Different bug then?
I bet on decorations.
Disable them (create an empty rule, force windows to be undecorated) and see what happens (alt+f3 popup will still work - so does alt+f4 and alt+lmb/rmb)

PS: for that time the benchmark will likely run on the raster engine, what is completely unrelated to the problem.
run it with "-graphicssystem native" for reasonable results

Hi, yes, with -graphicssystem native it does show reasonable results.
But in system settings I have graphic system: raster.

Also found that kwin becomes very and very slow depending on IO operations. Just copied a folder with ≈ 125k folders and few times more files from one partition to another. At this time Kwin worked at about 5-15fps (subjectively). All effects including minimization and re-sizing were almost unusable. And I can reproduce this:

nvidia-settings -a PixmapCache=0 && nvidia-settings -a PixmapCache=1
./bench_argbpix -graphicssystem native 
8191 x new, (800x20 px): 524 ms
(started copying from one partition to another)
8191 x new, (800x20 px): 874 ms
8191 x new, (800x20 px): 926 ms
8191 x new, (800x20 px): 1296 ms
(one minute later)
8191 x new, (800x20 px): 5515 ms
(one minute later)
8191 x new, (800x20 px): 12728 ms
Even scrolling in google chrome became very and very slow, each letter appear in this textarea with delay in ≈1 second
(one minute later)
8191 x new, (800x20 px): 26042 ms
Can't open yakuake, screen hung from time to time.

Stopped the copying and things get back to life gradually. Probably something similar happens when I am simply open many programs, a lot of files being opened which cause kwin or X to go down. I am not really know why this is related and how, but seems like it really is. And this also answers the question why when closing some apps things get faster again.

(In reply to comment #132)
> Hi, yes, with -graphicssystem native it does show reasonable results.
> But in system settings I have graphic system: raster.
Also for kwin?

> Also found that kwin becomes very and very slow depending on IO operations.
Try Xrender (and this time with the native graphicssystem) - you won't encouter this.

> files being opened which cause kwin or X to go down.
nvidia/X11 - the bechmark has no relation to kwin.
Ensure you're using the raster engine in "kcmshell4 kwincompositing"

Chrome scrolling has probably no relation to kwin, but to chrome using OpenGL internally as well.

> Also for kwin?
Sure, as I told before, in systemsettings I have graphic system set to raster.

> Try Xrender (and this time with the native graphicssystem) - you won't encouter this.
Xrender does not support a half of effects I am using and works like a crap so it could not be even considered as a solution. The fact that some lags are not reproducible with it does not help.

> Ensure you're using the raster engine in "kcmshell4 kwincompositing"
Again, as I told before, I have graphic system set to raster.

From your comment I don't understand what is the solution if everything is not related, etc etc...

What I told you is the fact — KDE sucks when copying files, that's what I can observe. Not only Google Chrome, but everything, the whole desktop is not responsive. As I told before, I even unable to open Yakuake (it takes 5-10 seconds and looks like a slideshow). And all this on Intel i7 3.6GHz with 8 cores, 14Gb of ram, rapid 10k rpm hdd and modern nvidia GPU. And I don't seen that with other DE and OS, even on windows which use same blob. This tempting to think that something is wrong somewhere in KDE :)

I don't know how, but when I start copying a lot of files "./bench_argbpix -graphicssystem native" show very big numbers and my desktop becomes a crap.

And what is even more interesting, when copying process complete/cancelled the benchmark numbers decrease, without resetting nvidia pixmap cache.

(In reply to comment #134)
> > Also for kwin?
> Sure, as I told before, in systemsettings I have graphic system set to
> raster.
There are modules (mostly used on ubuntu, though) to configure this "in general" - but that has no impact on the compositor. That's why i asked.

> > Try Xrender (and this time with the native graphicssystem) - you won't encouter this.
> Xrender does not support a half of effects
bullshit. we ported everything that makes sense and does not require 4x4 matrices.
Also I was /only/ interested in whether you can confirm to not experience this - nothing else.

> works like a crap
bullshit. please don't troll around. specify what "works like a crap" or stop fudding around to repend "oh nooo... he wants to escape with xrender" misassumptions.

> What I told you is the fact — KDE sucks when copying files, that's what I
> can observe. Not only Google Chrome, but everything, the whole desktop is
> not responsive. As I told before, I even unable to open Yakuake
irrelevant. all is waiting for the bottleneck, being somewhere in (likely, since you skipped the check) GL compositing on nvidia driver(s).
apparently I/O related. pot. the texture_from_pixmap extension.

> 5-10 seconds and looks like a slideshow). And all this on Intel i7 3.6GHz
> with 8 cores, 14Gb of ram, rapid 10k rpm hdd and modern nvidia GPU.
irrelevant. all is waiting for the bottleneck here. And the disk is slower than RAM or CPU by the order of some magnitudes, no matter how great you think it is. Compared to those elements, it's just slow.

Now, please don't ask me what it is - i'd need direct access to your system to check that.
From what you've explained so far, i'd actually assume you're operating on ntfs or the disk does not run DMA ("copying" should have zero impact on anything else, esp. on multicore systems - unless "else" is waiting for the disk. could be shared data cache - move "/var/tmp/kdecache-alexander" to some tmpfs mount)

But that's just a very wild guess.

Did you check the impact of the decoration (repaints)?

> And I don't seen that with other DE and OS, even on windows which use same blob.
certainly not the "same" blob on windows. It has an *entirely* different graphics stack which is not 30 years old.
Compiz was written towards a GL composited environment and afaik from the beginning on on xcb, not carrying around the issues with the decoration indirections nor X11 roundtrips. (neither has mutter, don't bring "unity" - that's just a compiz plugin)

> I don't know how, but when I start copying a lot of files "./bench_argbpix
> -graphicssystem native" show very big numbers and my desktop becomes a crap.
That means sth. in the driver (the "benchmark" does nothing but calling "QPixmap::fill(Qt::transparent)" a lot of times) is crucial on the CPU or the I/O.
(Or the X11 server on the disk I/O)

Next reasonable test would be on whether stressing the CPU (as root) only has similar impact and whether the slowdown you experience can be assigned to compoents like the decoration.

> Compiz was written towards a GL composited environment and afaik from the
> beginning on on xcb, not carrying around the issues with the decoration
> indirections nor X11 roundtrips. (neither has mutter, don't bring "unity" -
> that's just a compiz plugin)
nope, Compiz is XLib: http://packages.ubuntu.com/source/quantal/compiz
same for Mutter: http://packages.ubuntu.com/source/raring/mutter

we are modern :-)

Ok, relevant input:
i straced the "benchmark" with native resp. raster graphics.

The *major* difference during runtime (if you want to reproduce, increase "n" to eg 0xfffffff - lasts "forever" then) is masses of

poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"5\30\4\0p\203\240\2\216\2\0\0 \3\24\0\213\4\5\0q\203\240\2p\203\240\2D\2\0\0"..., 16380}, {NULL, 0}, {"", 0}], 3) = 16380
recv(7, 0x907b850, 4096, 0)             = -1 EAGAIN (Resource temporarily unavailable)

for the native graphicssysem.

fd 7 is a socket (you can check that by "ll /proc/<pid>/fd/7")

This is probably the communication with the X11 server and the major slowdown here.
I might do some other experiments (esp. what if the pixmap is not filled transparent etc.)

@Alexander
try (notice that this is a shot in the wild only)
KWIN_NVIDIA_HACK=0 __GL_YIELD="USLEEP" kwin --replace &

@Alexander:
did you try the environment setup to run kwin and does it have notable impact for you?
(For it has here and i've never believed in that hack solution - assignes all CPU to the driver, leaves nothing for kwin)

Hi, Sorry had no time for that, will try all that ASAP.

Ping.

@Alexander:
did you try
   KWIN_NVIDIA_HACK=0 __GL_YIELD="USLEEP" kwin --replace &
and does it have notable impact for you?

Created attachment 79867 [details]
Plasma memory leak screenshot

Hi, sorry for the delay, my previous craphic card died so I am not with a temporary $35 replacement and thought that results could differ because current card is slow and everything lags on it. So I thought would be better to wait until I get back to a normal device.

But just tried your advice and seems like KWIN_NVIDIA_HACK=0 __GL_YIELD="USLEEP" kwin --replace & does not make any difference.

And seems like I found the culprit, It is plasma-desktop. The slowness happen not because of the copying (as I supposed above) but because of the plasma notification And I can confirm and reproduce this.

To reproduce you need:
1. Start copying and pause it in plasma notification.
2. Run at least one QT application. I tried skype and oDesk team client, the first one is a 32 bit binary and use lib32-qt and the second one is a 64 bit one.
3. You can run xrestop or nvidia configuration GUI and check the memory usage. It will start growing.
4. Exist from skype/oDesk team and you will notice memory usage doesn't grow anymore
5. Run it again — memory usage grow again.
6. Stop the copying and see that everything become back to live, benchmark show good results again, the desktop is responsive again.
7. Memory usage does not decrease (in my case it was 470Mb)
8. Restart plasma desktop and memory usage will go down.

Please take a look at the screenshot, when I started the experiment memory usage was 76Mb, I started the copying but memory didn't grow, I was unable to reproduce the behavior I described a few posts above. So I started to run applications that I am using on my desktop. Once I started Skype and oDesk team memory usage started growing. Then I tried to run them separately — also reproducible. And memory leak stopped once I stopped the copying and plasma notification was closed.

Thanks for the detailed informations.

In addition:
- skype is and odesk seems binary releases, does it also happen with "regular" Qt clients (compiled and linked by your distro, eg. qupzilla or similar)?
- since the scrot lacks the xrestop output: who assigns the memory? plasma or kwin?
- the scrot shows X11 at 86% CPU - is that a permanent state under those conditons or just temp for moving/resizing/whatnotting some window?
- does it happen with blurring DISabled?

> does it also happen with "regular" Qt clients (compiled and linked by your distro, eg. qupzilla or similar)?
Hi, was able to reproduce with qt-recordmydesktop and with hplip. The last one is a driver for HP printers, on python (if I am not wrong) and uses py-qt bindings.

> since the scrot lacks the xrestop output: who assigns the memory? plasma or kwin?
The memory is assigned by plasma-desktop.

> he scrot shows X11 at 86% CPU
It's a permanent state, X11 uses 80-95% of CPU. But not at the very beginning, you should wait some time before it appear.

> does it happen with blurring DISabled?
Yes, and with all effects disabled also. But I didn't tried to restart Kwin after disabling the effects. Should I?

(In reply to comment #145)
Sounds more like a plasma bug, but isn't reproducible here.

> Yes, and with all effects disabled also.
Does that mean w/o compositing and if not, does this (plasma "leaking" - it's not actually leaking- pixmaps and high X11 CPU load (be aware that xrestop has impact here, but usually not /that/ much) happen
a) w/ XRender compositing
b) w/ Suspended Compositing

> But I didn't tried to restart Kwin after disabling the effects.
No, the effects are unloaded and while they might occupy few static memory from now unused plugins, they've no further impact on the process and most importantly the memory is not lost in kwin.

It's however no wonder that on memory shortage and loaded X11 Compositing performance will suffer.

@Alexander, please see bug #320354 for the copying issue.
There seems to be a problem with that window that does also affect r600 (radeon)

I'll close this long collection of various bugs as invalid (because it's close to impossible to say what here is a bug, an old bug, a new bug, a remaining bug, an nvidia bug, a kwin bug or plasma bug - iow: it's just a mess ;-)