Version: unknown (using 4.4.00 (KDE 4.4.0), Arch Linux) Compiler: gcc OS: Linux (x86_64) release 2.6.32-ARCH Using nvidia driver 190.53 and nvidia 7600GT 512MB pci, some desktop effects seriously slew down in kde 4.4.0, which were smooth and continuos in kde 4.3.4 (almost even on an 8MB Intel integrated graphics) Mostly effected is the slide back effect (when a windows loses focus), that's never continuos for me but sometimes the magic lamp animation, and even the new slide up of the kickoff launcher can be non-continuos. The strange thing is that the kwin fps counter always shows that the fps is over 40 My Xorg.0.log doesn't return errors.
Just guessing: animations in decorations? Could you please try one that does not use animations? E.g. plastik?
Just tried, with plastik, it's OK, it's only bad in oxygen (with more styles)
No idea what we can do about it, except disabling the animations in Oxygen. But that would propably also require the animations in the widget style and not only in the decoration. It makes sense that it results in slowdown - at least in the decoration. The only solution I know of to fix this problem is multithreading which does not work as we need to access pixmaps. (And of course multi threading is a bad idea in a window manager anyway.)
*** Bug 226634 has been marked as a duplicate of this bug. ***
In bug#226634 c#4 Thomas presents a possible solution which could work. I will try that one, when I have time again.
*** Bug 229963 has been marked as a duplicate of this bug. ***
*** Bug 231523 has been marked as a duplicate of this bug. ***
To all NVIDIA users experiencing the issue: please try the latest driver 195.36.15. The release note mentions that they fixed some performance issues with KDE 4 and it *feels* more smooth here on my system.
Yes, 3d effects are much better with the new nvidia driver, but konqueror and opera smooth scrolling became crappy, and it was good with nvidia 190.53 (I have chrome smooth scrolling plugin too, it's OK)
Yeah, the Release notes for 195.36.15 do say: * Fixed a performance regression with non-antialiased text in KDE4. http://www.nvidia.com/object/linux_display_ia32_195.36.15.html Everyone should update
mmm. Marking this bug as upstream. Especially since there is now an option to disable the oxygen decoration animations in the config. Feel free to change status if disagreeing.
I haven't experienced this problem (or at least I haven't noticed it) until now. I updated to KDE 4.5.1 and NVIDIA 256.53 on my openSUSE 11.3 and using Oxygen windows decorations makes kwin very slow. However, when I use skulpture or plastik, the performance (at least my subjective notion of it) is ok. I se that the bug is marked as RESOLVED - UPSTREAM, which would mean that it should be fixed in somewhere else outside kwin. Is it known which component causes the problem? Is it really the Oxygen window decoration animations or somwhere down the stack?
In fact it isn't solved for me at all. If i set Aurorae it get really slow, but if switch animations to false (in the aurorae config file) it seems to be smoother. The same happens with Oxygen turning animations on means decreasing performance with kwin. I also wonder why is it marked as resolved.
"resolved upstream" is a really bad term and rather should be "someone elses problem" - it's no qualification of the situation but just saying: "we're not responsible to deal with this issue" :-( the issue is caused by a) the nvidia driver which is bad at allocating ARGB offscreen pixmaps (there're various ways to impact this, like setting UseEvents=true in xorg.conf, device section; changing (at runtime) the pixmap allocation strategy "nvidia-settings -a InitialPixmapPlacement=$n" | $n=[0..4]) or flushing the pixmap cache by de- and reactivating it. "nvidia-settings -a PixmapCache=0; nvidia-settings -a PixmapCache=1" - in fact it was better with xorg 1.7x and the 19x.xxx drivers b) the fact that kwin renders the decroation into ARGB pixmaps to provide translucent decorations (+decoration side shadows) as well as support for uncomposited usage (the decoration API at some point will have to be extended to handle this better, it's however no way possible in a minor update :-(
I don't have this bug in Archlinux with KDE 4.5.1 and the newest NVidia, it was way worse, when I reported it. It's completely OK since KDE 4.4.4
I must admit, that at the moment, I don't have problems with kwin + oxygen, too. I removed some packages which are no longer available for openSUSE 11.3 (they removed the KDE4:Community repository) including aurorae, dekorator, sculture. And now everything is ok... I don't know what to think... :)
Hi ! Been experiencing a pretty bad experience with KWin in the last few years (slow minimizing, windows "staggering" when grabbing and moving them etc.), and just figured out all became **butter smooth** again when disabling the Oxygen windows decorations animations. (Nvidia 9800 GTX, proprietary driver & Nouveau, Arch Linux, Kubuntu 11.10...) Maybe this bug should be re-opened ? Cheers !
See comment #14 - nothing we could really do to fix this in general (but turn off animations in oxygen by default, ask Hugo) We might start to avoid the indirect painting with 4.9 and a bumped deco API, but even then allocating memory on nvidia GPUs is either horribly slow or flying fast. You can run kwin on the raster graphicssystem to avoid pixmap allocation on the GPU and use the CPU/RAM instead. (yes, if nvidia drivers and settings are slow for you, the cpu is ways faster) 4.8 has a config item for this, but no GUI (to show up with 4.9)
Thomas : thanks for taking the time to reply ! Are the Nvidia developers aware of this issue ? (if not, I can make a report) Hugo : indeed, disabling this option meanwhile should be considered, IMHO. Many people are affected without their knowing it. I reported this on a French Kubuntu forum, and many people there realized there was a huge improvement when disabling those animations. Thanks again to all of you !
> Hugo : indeed, disabling this option meanwhile should be considered, > IMHO. Many > people are affected without their knowing it. I reported this on a > French > Kubuntu forum, and many people there realized there was a huge > improvement when > disabling those animations.! Disabling that option means to punish everyone for the problems of the NVIDIA driver. This is an absolute no-go. In fact with graphicssystem raster it should be usable and that is the default in the latest version of Qt anyway.
Martin : this is perfectly understandable. Actually, if we had figures (what % of users are affected ?), maybe we would have a different perspective. If all Nvidia users were affected, this would be a major issue, for instance. About the raster graphicssystem : if I'm not mistaken, it's already selected by default (I double checked), and makes no difference here, as far as this specific problem is concerned. Sorry for annoying you with this old issue ! :-)
for ubuntu and qt >= 4.8 - yes but if your issue is not related to the nvidia driver (nouveau) or the graphicssystem, it's likely sth. different -> opengl or xrender backend? -> does initial pixmap placement or flushing the pixmap cache have any impact? -> cpu load (sysprof) when animations take place?
I second martin in _not_ changing the default. Reason is: works fine on intel (which also represents a significant amount of GC). works fine on some NVIDIA (mine, for one, though I don't have access to the specs at the moment). Also, I believe the biggest issue is about the window shadow to glow transition. This might be moved upstream (from oxygen to kwin) for next release, and would not necessitate as many pixmap allocation as the current implementation. (to be confirmed). Cheers, Hugo
Thomas : 1) the problem appears in both XRender and OpenGL mode. They are solved, likewise, by disabling windows decorations animations. 2) flushing the pixmap cache makes no difference 3) I have to learn how to use sysprof, but, roughly, with XRender, CPU load it maximum with animations disabled and moderate without ; with OpenGL, CPU load is high with animations and moderate without.
(In reply to comment #24) > 3) I have to learn how to use sysprof, but, roughly, with XRender, CPU load it > maximum with animations disabled and moderate without ; with OpenGL, CPU load > is high with animations and moderate without. a) What kind of CPU are we talking about here? b) if you activate the advanced settings, can you identify a specific animation as culprit?
Thomas : a) Core2Duo 3 GHz b) indeed, this is the 3rd one in the list ("window activity state transition", roughly translated from French ;). In can enable the others with no slow down.
I triple checked a couple of things ; I hope you don't mind if I give the results of my investigation below : * the aforementioned behaviour or bug occurs (very slow overall kwin performance when one particular window decoration animation is enabled) completely regardless of the : - distro (tried several Kubuntus, Arch, Chakra, OpenSUSE versions) - Nvidia driver (several versions of the proprietary AND open source Nouveau driver) - QT engine (raster / regular / OpenGL) - Kwin engine (XRender / OpenGL) - Kwin settings. Xorg.conf settings. (tried every possible combination ;-) When disabling this single option, it's like night & day (from horrible to perfect performance). Hope this is helpful. I'm available if you need some help pinpointing this ! Cheers !
If i'm not mistaken that the shadow change, which will supposingly be redone for 4.9 anyway - pot. alongside the paint redirection Since this requires full deco size repaints, it's no wonder that it causes most stress if allocating ARGB pixmaps isn't fast for you, but the fact it's slow for you on raster/GL still makes me wonder. If you can compile the oxygen decoration, you should ask Hugo for advice esp. on how to debug the pixmap cache usage (to ensure you don't re-render the shadow on each frame)
Hi guys Just wanna let you know that I experience this behaviour too and I have a ATI graphic card. It happens with both drivers, the opensource driver and catalyst. It is very annoying and the only thing I can do is disabling the animation effect of the window decoration. My kde is compiled from source (last weekend). Thanks for help!!!
Hi ! Just a friendly reminder to mention I still get this problem under KDE 4.13.0 (LTS Plasma), Kubuntu 14.04. Windows animations are very jerky (minimize/maximize) unless I disable "window active state change transition" ; it occurs with : Nouveau, Nvidia proprietary, and I also see this on another machine with ATI OSS drivers. Would it be possible to disable this effect by default ? Most people will overlook the solution and it makes the desktop 100% smooth and feels much more pleasant to use :) Cheers & thanks to everyone ! :)
I would like to second Mahendra's suggestion to disable "window active state change transition" by default. I always turn it off on every KDE install I do, because the performance is noticeably smoother with it disabled.