Apart from the scripting interface KWin will not ship any major new feature in 4.6. Most of the work I did for 4.6 was to improve the overall performance of our compositing engine. One of the first improvements I added was for the text and icon overlays in our effects. Now the texture and geometry is always cached and Texture from Pixmap (TFP) is used instead of costly QPixmap/QImage conversations.
Another area which saw great improvements are effects which transform one window. These effects used to cause the whole screen to repaint even if only a small region changed. Most prominent visible is this with the Show Paint effect enabled and for example Sliding Popups or Wobbly Windows. Those effects are now repainting only the changed area which is a great improvement, especially considering that there is less blurring involved. The changes seem to make a difference as developers running trunk asked in #kwin if we changed something in Wobbly Windows. Of course not each effect does benefit from this change. It is an ongoing issue and one effect after another has to be improved.
Another area for optimization is not directly in the compositing engine but more in making use of the advantages of compositing in general. 4.6 will include a new effect to render the startup notification ("bouncing cursor"). The current way involves resizing and shaping a window and moving this window. With compositing enabled this can be a costly operation (for me the performance was so bad, that I disabled the notification completely). The new effect does the same animation as the legacy system without using a window at all. It is just a texture rendered on the screen. This means the whole window transformations are not needed and also the costly TFP operations are not required. Another nice side-effect is that the icon can now use an alpha channel – the old animation transformed each icon to a RGB-only icon. If compositing is not used the system will fall back to the legacy rendering which is btw. not part of KWin.
During the last week I worked on another optimization for our Lanczos filter. Especially in Present Windows the filter was causing some performance regressions. Highlighting one of the windows causes the complete screen to repaint (optimization opportunities see above) which caused a new Lanczos filtering for each visible window. The highlighting animation lasts for something like 200 msec with constant fullscreen repaints. It is obvious why this caused a performance regression. My changes cache each generated texture and use this whenever a repaint without change of content is required. So the highlighting does not require a recreation of the texture (the highlighting is added in a later step). So Present Windows in 4.6 will have the performance as it used to be in 4.4 with the improved thumbnails from 4.5. Of course the cache is useful to all places where the Lanczos sampling is used – be it Box Switch or Taskbar Thumbnails.
I hope that with this change the blacklist is no longer required for performance problems but can be used for driver problems only as intended. Also this allows to integrate the Lanczos improved thumbnails in more effects – e.g. Desktop Grid as in the image.
Improving the performance is of course an ongoing issue and there are still some areas where we can get some clever caching in place. For example blur might be a good candidate for improvements. But this is topic for a blog post "Optimization in KWin 4.7".
=-=-=-=-=
Powered by Blogilo
Thank you very much! I really appreciate this kind of work on “boring” optimization.
Great work, KWin 4.6 is running smooth here 🙂
I agree with Naproxeno.
It’s fantastic to read about these sorts of ‘boring’ things being done.
Thank you very much, the KDE Desktop is much stronger for it!
Good work! Its great to see how quickly things are coming along 🙂
Any chance of seeing some of these optimisations backported to the 4.5 series? Or some sort of blur caching in 4.6? I’ve had to switch off blur and lanczos on open source radeon drivers (4670 kubuntu 10.10) because the desktop was just too laggy with many windows open.
Sorry changes are too heavy for backporting to 4.5. Currently my caching is also not yet regression free. Improving blur for 4.6 (caching) is also not possible as we are already in feature freeze.
If a feature gets unusable because of lack of performance that is a bug for me and fixing that would be a bugfix, not a new feature.
So personally I don’t see why that shouldn’t be in 4.6.
But in fact best in such a case is to ask on the correct ml/irc-chat what others might think on that issue.
Well it depends. First we need the patch (we do not have it yet), then it depends of where in the cycle we are (probably way after feature freeze) and how much regression potential there is (very high) and how much we can expect it to get tested (something like nil given the experience from last cycle). So in summary I don’t want patches which add changes to the rendering stack after feature freeze due to the problems we saw in 4.5
Thanks for the response, I can definitely appreciate going the more conservative route after the round of issues with 4.5 and distributions.
Is it out of the question for 4.6.1/4.6.2 as well, as April round of distribution updates feels like a long way off now?
I’m not sure how to test this, but it ‘feels’ like there might be a locking issue or some form of video memory leak issue that’s causing most of the perceived lagging. E.g.
– Windows dont start lagging until quite a few are open and desktop still doesn’t return to previous responsiveness levels after closing all windows; could something silently be ‘leaking’?
– There is a ‘delay’ at first when moving windows when things are ‘lagging’, especially with plasma’s blurred backgrounds or desktop grid effects as though it’s waiting on something.
(PC is quad core, 8 gig ram, ati 4670 1 gig (open source driver), intel ssd with plenty of free ram, low cpu usage and no swapping during this)
Xrestop doesn’t reveal any issues unfortunately..
Just shooting in the dark here, but would it be possible to have a compromise where kwin applies effects in an async manner so it’s never ‘stuck’ waiting on things like blur?
Maybe some heuristics where “only blur when fps > 30 AND cost of blur is 60” or maybe “blur has 100 milliseconds to blur as many windows as it can starting with the topmost window so that the blurred framerate is different to the hopefully higher kwin framerate”
Sorry about the lengthy block of text and keep up the good work! =)
KWin4 is awesome already, just the performance can never be good enough. Thank you for your work, Martin!
My desktop is damn fast now!
So there’s no improvements for the blur effect?
There are some changes in the rendering stack which should also improve blur.
Nice work!
I do have one small concern though. A couple places in KDE 4 have used pixmap/texture caching to speed things up, but unfortunately they tended to cache too much data, causing horrible slowness with the nvidia driver, and out of memory issues in the intel driver (ever had X crash a lot with the intel driver?). Does this new code make sure to clear items in it cache when necessary, or limit the cache size in some way?
Yes the cache is automaticially cleaned 5 seconds after the last cache hit and whenever a window changes. And the cache is always just one item for one window, so the caching strategy is very different to the one used in Oxygen.
This is far more exciting news than any possible new features. Thanks for the work, even if it’s not as flashy to users plenty of us appreciate it!
Yay!!!!! Optimization! 😉
On a serious note, while we are at it, you have possibly solved one of the Desktop Grid problems with the caching, but I’m not sure. The problem is, that when you invoke the Present Desktop effect, then if your current screen is say number 1, and you the zoom back into desktop number 1, the animation is perfectly smooth. However if you zoom into say desktop number 2 or any other desktop, the animation waits for a second and is totally jerky. Could your update solve this problem? (I know I should file a bug, just in case this is related to what you’re writing about I’m asking it here)
Great job. KWin scripting and optimizations for 4.6… it will be an awesome release.
I guess this should probably fix the sluggish window resize performance with desktop effects enabled?
No that one is unrelated and mostly caused by bad drivers. At UDS we discussed some ideas how to improve the resizing. But till those improvements hit kwin it will take at least one more year.
Hi Martin,
This is great news and thanks for all your efforts on improving KWin. I hope you don’t mind that I report this here, but I couldn’t find a better place to report this:
There seems to be some sort of conflict between the two of the Kwin compositing effects: blur and shadow. I have noticed that when the blur effect is activated, window shadows (menu shadows, exactly) get corrupted, or drawn badly (noticed this both on ATI and NVidia cards) .
Again, sorry I had to post this here 🙂
yes known and reported issue
Just wanted to say “Thank you Martin, keep it up”
Thanks Martin for your work, Kwin really need to get some speed, not only with dozens of effects enabled, keep rockin 😉
You rock, I have to offer you a beer next time we’ll catch up 🙂
Wonderful news. You are great! 🙂
Once more, thanks for all your work behind the scene… “Small” changes like those greatly improve usability, and my personnal use for what it’s worth.. Thanks !
I dont know if it is fixed, dont think so. If you copy two images lets say image1.png and image2.png and delete image2.png and then rename image1.png to image2.png, then image2.png thumb will look like the deleted image2.png
sorry, no idea. Not kwin specific
I just wanted to say: thanks a lot for your work.
KDE is great and one of the main reasons is so wonderfull is because of kwin
🙂
Sorry to bother again, will kwin scripts be available via ‘get hot new stuff’ or similar?
It could be a great way of easing the workload on core developers while seeing what the community ‘actually’ uses 🙂 And if it was easy to include custom shaders with simple javascripts… wow, you guys would be all over youtube in the same way compiz was in 2006 😉 Thanks!
Actually optimization isn’t that boring. It is a challenge of the mind and usually in project like this everybody praise you 🙂
Maybe I might not be up to date, but does KDE turn off compositing when a window is in fullscreen? If I want to play a game, my computer does not handle the game and compositing very well. My mediacenter does not handle HD-movies and compositing very well either. I hope KDE will be smart enough to turn off these things when I start up XBMC and such.
There is something which is calld unredirect fullscreen windows. It disables compositing for the screen, but is not the same as turning compositing completely off. The option is enabled by default
And this is enabled by default from 4.6 or is it already in 4.5? If it is in 4.5 it isn’t sufficient to give me a smooth movie experience in my asrock ion 330ht.
unredirect fullscreen window is by default on since 4.1 or 4.2 (can’t remember). But there are distributions which turn it off by default. Starting with 4.6 we have a GUI config option to turn it on.
Here is how you can optimize the blur filter: use a linear texture filter (instead of nearest) and modify your sampling coordinates to fall halfway between two texels (instead of completely on each texel). Now you can achieve the same amount of blurring with fewer samples and *no* quality loss: the hardware will linearly interpolate between adjacent texels for free!
This is a relatively not well-known trick used for blur filters in games. See here for more information: http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/
Do you seriously think we do not know such things?
Is it possible to somehow fix this bug https://bugs.kde.org/show_bug.cgi?id=177495 ?
It’s sometimes really annoying. For example when you want to volume up (using multimedia key on keyboard – it shows volume bar) or when you want to show menu (moving cursor down) in SMPlayer. When i’m doing this the screen blinks. Setting UnredirectFullscreen=false in kwinrc solves that problem but performance of fullscreen applications is bad. I don’t know how this situation looks in compiz…
Have a nice day!
sorry, my blog post is not a bug tracker. We already have a bugtracker and I don’t answer to bugs at two places.
Your the best!
Thank you sooo much!
It works alot better!
Is there any chance that the blur plugin will run on my computer, if in 4.5 it writes “kwin cant enable: blur; cube (and some other effects)” ???
I heard its a bug in plugin, but i just havent found any solution..
Please refer to forum.kde.org, thanks
I am always very happy for performance improvements, even for a little bit…
i wonder if kwin is working with intel x4500. in kubuntu 10.10 with kde 4.5 it was not working… i kubuntu 10.04 with kde 4.4 it was ok, albeit performance could be better… what about 4.6, it is working?
Thank you very much!
It seemed you made a great job.
Free software community is so strong because of such members as you!
it’s good that you work on it, but kwin still needs a lot of performance improvements. it’s hard to say what’s wrong, but it feels dead slow compared to gnome+compiz. even switching a virtual desktop is very choppy on high end systems on KDE, and extremely smooth on compiz – wtf ?:p
The blur effect still eats 15% cpu with a completly idle desktop. Worse, everything wich was running smooth before (cube, wobble even resizing) feels jerky as long as blur is enabled.
This is on a Nvidia GTX 460 OC and a quad 4 GHz Intel with the 270.18 drivers, the 260.19 is no better. Maybe you should add the G104 GPU to the blacklist, it definitly is too slow to render the blur effect ^^
The blur effect uses 0 % cpu when completely idle. This sounds like something is consistantly repainting. Furthermore e.g. cube disables blur completly and wobbly has never been smooth with the NVIDIA blob.
Well for me it seems to be different: Wobble is _really_ smooth, constant 60 fps while constantly moving a window around and kwin load at about 25% of one core. So is almost every effect.
But if I enable blur with _nothing_ blurred on my screen, no transparency etc, i get an additional 5% when idle. If I dare to use some transparent window decorations I get more load, the more windows are visible – currently with four visible window decorations I am reading 50% of one core.
It has been like this since the blur effect was enabled again (I think 4.4). Please tell me if I can provide any logs etc. which may be helpful.
I am really sorry, but KWin is really unusable compared to Compiz, and no one addresses this issue. It’s slow, unresponsive, and takes up all my CPU. I really don’t think anyone is even following the bug that’s been reported at least 4 or 5 versions back.
My system, when idle, consumes 2-3% CPU under Compiz, and a whopping 20% with KWin.
At least the KDE guys should give us the option to seamlessly use Compiz. KWin sucks!
I am sorry for you that you have bad experience. But please note that my blog post is neither a bug tracker nor a user support forum. Your issue sounds solvable and beleive us: we work on improving the performance each and every day!
Now concerning Compiz: Plasma is the only remaining modern desktop shell to allow switching window managers and we even offer an option to switch to Compiz. Furthermore we are collaborating with Compiz developers to ensure that we don’t create a vendor lock-in. The actual integration on the other hand needs to be done by Compiz developers.
Sorry, for being rude. I didn’t realize you were a Dev, and thought this was a user review.
As for KDE 4.6 : I love every bit of it. I actually blogged about how much I loved it. (http://auralspectratech.blogspot.com/).
Sadly, I have been a critic of KWin4 since its inception. I absolutely love the idea of an integrated WM but at times, one gets the feeling that a few things in KWin are still in the Alpha/Beta phase (blur? I know users on ATI, NVidia and Intel who cannot get it to work without it being a resource hog)
I won’t trouble you with issues, and that was not the original intention either. I am not questioning the commitment, or competency, of KDE Devs – who have all, imo, done an excellent job of putting together the most capable DE that we know of. At times, I just find it weird, and annoying as a user, that KWin – the most visible module of KDE – is the chink in its armor.
You know that KWin has a history of something like 12 years? I doubt you have been a critic ever since 😉
Concerning the Blur effect: this one was introduced in 4.5 and hit serious driver bugs introduced in the latest driver serious released at that time (Mesa 7.8). I have had a blog post about this situation. Right now with Mesa 7.10 the worst issues are gone and I have had very, very positive feedback on the performance of KWin in 4.6 and Mesa 7.10. Lately I have read very often that users start to recommend the usage of nouveau instead of NVIDIA blob.
I recommend to you to update to the latest available drivers and KDE version. Especially drivers have improved very much. And we are (as illustrated in this blog post) improving the situation each and every day.
hi…
i m using pardus 2011. it has kde 4.5.5. how can i upgrade it to kde 4.6?
reply asap.
ankur
Please understand that my blog is not a user support channel. thanks
This is the kind of optimizations that switched IMHO kde from the unusable state to the usable one. I now use kde 4.6 plasma-netbook on eeepc and it’s working like a charm (1.5, 2x speed improvement) and I’m not using netbook remix anymore.
You rock.
i haven’t even used KDE sc 4.6 yet (waiting for Kubuntu 11.04) and i’m already excited. minds are changing, opinions are improving and KDE gets better and better.
also, THANK YOU for your efforts. i know thank yous have lost meaning, but this is coming from a really grateful user that enjoys using Kwin (and, by extension, KDE).