Version: 4.0 (using KDE 4.4.4) OS: Linux If "enable animations" is on in the widget style (tab transitions may be turned off) and/or "enable animations" is turned on in the window decorations for Oxygen then I find that my computer gets progressively slower throughout the day. After a day (or even 6 hours if I'm using many applications) it becomes very slow to open dialogs, open menus (eg: via right click), scrolling, selecting files (especially noticeable with rectangle select), etc. I then notice that my swapspace is being filled up. Turning animations off in both widget style and window decorations fixes this. Reproducible: Didn't try Steps to Reproduce: Start KDE. Ensure animations are turned on for both widget style and window decorations (with Oxygen, of course). Use the computer for a very long time. Actual Results: Try selecting files, opening menus, etc - it will be slow. Expected Results: Should be snappy and fast :) Changing widget styles and window decorations to one that does not use animations also fixes this. I have tested with Skulpture, Plastik and DeKorator. Changing one of the two (eg: widget styles but not window decorations) helps but does not completely eliminate the slowdown (or so it seems). After restarting KDE it returns to its snappy form but after many hours of usage it slows down again if animations are enabled.
Hey So. That is worrisome. I cannot reproduce here (work on my computer all day with all animations on, sometimes it stays on for multiple days in a row). What could help diagnose better: 1/ see if its more related to decoration or style (most likely it is decoration, because widget style objects are fully deleted every time you close an application, and so are the animations, pixmaps, etc; and restarted -from scratch- whenever you open a new one). Could you confirm that things run fine if you use the style only ? 2/ get xrestop running when your computer is in slow mode, and report what it gives (notably: kwin). 3/ provide your Qt version, and graphics card. 4/ well. 4 is if your would update to kde 4.5 or trunk. I added tools to limit cache sizes, for instance. But lets see with 1-3 first ;-)
Actually, the output of "top" might help too. To see who's eating up memory up to the point you run into swap.
1)Turning off animations in window decorations definitely results in an improvement, but the bulk of the improvement is noticed when I turn off animations in widget style. Note that I do keep a lot of "standard" applications running all the time, like Akregator, KMail, KJots, Amarok, Kopete and Quassel. 2) Please hold, was away and will obtain this information soon. 3) Qt 4.6.2. (Will upgrade to 4.6.3 soon.) I would like to note that I don't think this problem started recently with Qt 4.6.2. It's been like this for quite a while. Graphics card is NVIDIA GeForce 9100M G. As for the top output, what exactly should I be looking for? (as in, sort by what?)
> --- 1)Turning off animations in window decorations definitely results in > an improvement, but the bulk of the improvement is noticed when I turn off > animations in widget style. Note that I do keep a lot of "standard" > applications running all the time, like Akregator, KMail, KJots, Amarok, > Kopete and Quassel. Clear enough. > As for the top output, what exactly should I be looking for? (as in, sort > by what?) mmm. Memory allocation . Some background: It might be related to the storing of pixmaps into caches. The longer the applications run, the fuller the caches become, and there have been reports of troubles with storing/accessing stored pixmaps with NVIDIA. Also, (unfortunately), caches are independent (and very redundant) from one application to the other (something we might try to fix for future versions). The caches also gets much more content when running animations (because instead of having say 1 pixmap per style element, you have one per element and 'opacity' (for fade-in/out effects). Also unfortunately, there is no way of controling the caches size (from options) in oxygen@kde4.4. There will be such a thing in kde4.5 (together with the possibility to disable caches entirely). By then we should see if it fixes your issues (and thus validate my guess).
OK I have a series of screenshots. This one is just of htop, but doesn't look very useful: http://upload.failnation.com/files/1/map15.png Here's the information from xrestop: http://upload.failnation.com/files/1/map17.png The rest are all various information from exmap, sorted by the "effective mapped" column: http://upload.failnation.com/files/1/map18.png http://upload.failnation.com/files/1/map19.png http://upload.failnation.com/files/1/map20.png http://upload.failnation.com/files/1/map21.png http://upload.failnation.com/files/1/map22.png http://upload.failnation.com/files/1/map23.png I hope that's useful.
Hello Hugo, I'm not quite sure about the etiquette for bumping bug comment threads, but what is the progress on this bug? Has the information I provided helped?
I looked at the screenshots. Opera and Amarok do eat a lot of memory. (but opera does not use the oxygen style -right?- so that's not relevant here). And in fact looking at the exmap, well yes, all apps (including kwin) seem to use quite a large amount of memory (VM). XRestop as far as I can tell shows nothing really suspicious. Bottomline is, I am not sure what to make out of it (and can't reproduce here) :( The only help I can offer is, once you switch to kde4.5 (sorry it was not in the code before), to reduce the size of oxygen caches (and see if it helps). - To disable caching in the decoration you would need to type "oxygen-settings" (in terminal or krunner), go to window-decoration->shadows-> and set shadow caching to "disabled" - To disable the caching in the style you would need to edit ~/.kde4/share/config/oxygenrc, and add MaxCacheSize=1 under the [style] section. (sorry, no gui option yet for this: was added after string freeze). Again: would work only with kde4.5 In the meanwhile I'll see if I can have a more efficient way of sharing pixmaps in the style.
SVN commit 1171084 by hpereiradacosta: Added 'expert' option to entirely disable pixmap caching in oxygen style. CCBUG: 242653 M +7 -2 config/oxygenstyleconfig.cpp M +11 -4 config/ui/oxygenstyleconfig.ui M +3 -1 oxygen.kcfg M +4 -2 oxygenstyle.cpp M +0 -3 oxygenstylehelper.cpp M +4 -4 oxygenstylehelper.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1171084
SVN commit 1173689 by hpereiradacosta: Added a "steps" parameter to the animations, that limits the maximum number of different values a given animation can take. This should effectively reduce the size of the caches by a factor 10 to 20, improve performances, without any noticeable differences to the eye, and possibly fix some of the performance issues experienced by some users with NVidia graphic cards. The number of steps is configurable (as an hidden option) and is still to be optimized. Current value is set to 10. (was 256 in the past) CCBUG: 242653 M +1 -0 animations/oxygenanimationdata.cpp M +16 -0 animations/oxygenanimationdata.h M +5 -0 animations/oxygenanimations.cpp M +2 -1 animations/oxygendockseparatordata.h M +1 -0 animations/oxygengenericdata.h M +2 -0 animations/oxygenheaderviewdata.h M +2 -0 animations/oxygenmdiwindowdata.h M +4 -0 animations/oxygenmenubardata.h M +2 -0 animations/oxygenscrollbardata.h M +2 -0 animations/oxygenspinboxdata.h M +2 -0 animations/oxygentoolbardata.h M +4 -1 oxygen.kcfg M +3 -0 transitions/oxygentransitions.cpp M +2 -0 transitions/oxygentransitionwidget.cpp M +17 -0 transitions/oxygentransitionwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1173689
Hey, I'd like to thank you for paying so much attention to this bug despite "shooting in the dark" as you'd say. I read your blog post here http://hugo-kde.blogspot.com/2010/09/performance-issues-one-script-and-call.html but I'm not too sure - from what I gather, your script limits the pixmaps that are cached, whereas the changes above completely disable caches. So wouldn't disabling the above be more effective than simply limiting the pixmaps that are cached? Sorry for not testing and feeding back as much - I'm currently using it with disabled caches for both windeco and styles. It's only been 3 hours of usage so far and I'm not noticing lag. I'll update you if anything crops up.
Well: you're definitely not the only one that suffers from this issue, judging by various blog posts and comments on these blogs. There is a problem with the first commit, that allows one to totally disable pixmap caching: pixmaps are still asked for, and as many pixmaps as before, but they are not cached anymore, meaning, they are re-allocated, and re-painted every time, then deleted. The second commit on the other hand, limits the number of pixmaps that are asked for (whether for cache or directly created), so that would make the code more efficient, whether or not you disable caching. So that both commits are complementary. Does that make sense ? I actually believe that the second is more efficient for this nvidia bug than the first.
SVN commit 1174332 by hpereiradacosta: Backport r1173689 Added a "steps" parameter to the animations, that limits the maximum number of different values a given animation can take. This should effectively reduce the size of the caches by a factor 10 to 20, improve performances, without any noticeable differences to the eye, and possibly fix some of the performance issues experienced by some users with NVidia graphic cards. The number of steps is configurable (as an hidden option) and is still to be optimized. Current value is set to 10. (was 256 in the past) CCBUG: 242653 M +1 -0 animations/oxygenanimationdata.cpp M +16 -0 animations/oxygenanimationdata.h M +3 -0 animations/oxygenanimations.cpp M +2 -2 animations/oxygendockseparatordata.h M +1 -1 animations/oxygengenericdata.h M +2 -2 animations/oxygenmdiwindowdata.h M +4 -4 animations/oxygenmenubardata.h M +2 -2 animations/oxygenscrollbardata.h M +2 -2 animations/oxygenspinboxdata.h M +2 -2 animations/oxygentabbardata.h M +2 -2 animations/oxygentoolbardata.h M +4 -1 oxygen.kcfg M +3 -0 transitions/oxygentransitions.cpp M +2 -0 transitions/oxygentransitionwidget.cpp M +17 -1 transitions/oxygentransitionwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1174332
Did testing with the disabled cache tips above (not the patches). It feels slightly slower, but after a day of usage I have not noticed the slowdown over time that I did before. It definitely feels slow when I launch a few applications at once though. I noticed your last commit was a backport. Does this mean your fixes will be in 4.5.2?
@comment #13 So it makes sense: everything slower because pixmaps are re-created every time, no degradation over time cause things are not stored into cache. so I think things are clear. Last commit is the backport of the changes I advertise on the blog post, since it had positive impact for everyone who tested it. (and is consistent with your observation above. Smaller -or no- caches = no more lag). Yes it will be in kde4.5.2. Hopefully Nvidia users will be happy again with oxygen, and won't have to change style for any other reason than personal taste. Thanks for the feedback
Closing as fixed for kde4.6 Pixmap usage has been reduced significantly. The rest is a question of bad graphics drivers against which we can do nothing.