With the first Beta for KDE Plasma Workspaces 4.7 out of the door it is time to look back what we achieved in the last half year for the KDE Plasma Compositor and Window Manager. Personally I think this will become a very great release with hughe improvements for our users. The best about it is, that users should not even notice that anything changed at all. Almost everything we did is under the hood improving performance, stability and rendering.
Programmable Pipeline
The Compositor received a new OpenGL compositor based on OpenGL 2.x or OpenGL ES 2.0. Our default rendering nowadays uses the programmable pipeline instead of fixed functionality as in 4.6. In order to support the programmable pipeline quite some parts had to be rewritten and got optimized at the same time. Overall this brings a vast performance improvement for all users. From my experience this can even be increased when using the OpenGL ES 2.0/EGL backend which is unfortunately a compile-time switch (as not all drivers and hardware support EGL). I hope that distributions will provide an additional package.
As with all such changes there is the chance that on some hardware/driver combinations the performance decreases due to the raise of requirements to OpenGL 2. If that is the case the user can switch back to the legacy rendering mode by unchecking the option “Use OpenGL 2 Shaders” in the advanced Desktop Effects settings. This will disable all GLSL Shaders. Nevertheless Blur and Lanczos are still useable as they will fallback to ARB Shaders.
Blur Effect
Fredrik has done some great work to improve the performance of the blur effect. Effects can know recommend whether they should be enabled by default and for Intel hardware, the effect does not get enabled any more by default. Users can still manually enable the effect. But there is also some real optimization to ensure that less screen estate gets blurred in each rendered frame and some optimizations on the shader giving a ~60 % improvement in shader performance with R600G.
Blocking Compositing
Thomas worked on a way to allow applications to block compositing. The primary goal is to have video players or OpenGL Fullscreen games be able to block compositing as for such use cases compositing is only a bad overhead. We have heard interest from VLC and Wine to support this new flag, but users can even make use of it if the application does not yet provide support for it by using a window specific rule. Given that we have now this new way to suppress compositing we disabled the unredirection of fullscreen windows by default.
New Shadows
Together with Jacopo, Hugo and Aaron we worked on adding a new Shadow system allowing to provide their own shadows. This is currently used by Oxygen Qt and GTK to render shadows for so-called unmanaged windows. As the control for the look is with the client, the widget style is able to adjust the shadows for e.g. Mozilla Firefox. Also Plasma is making use of the new Shadows for the Panel and KRunner fixing some annoying issues with the old implementation like window snapping to the panel shadow and clickable shadows in KRunner. Not to mention that the new shadows look way better 🙂 Special thanks to Jacopo for writing the XRender code for the new Shadow system.
Outline
Arthur, our GSoC student, did some refactoring already before the GSoC project and brought all outline related code together in one class. This allowed me to add a new Effect to render the outline using a nice looking Plasma FrameSvg. If effects are not active the old X11 code is used. I am looking forward to Arthur’s GSoC, what I have seen so far looks very promising.
Graphicssystem Raster
Very short before the release we received a Patch from a new contributor, Philipp, allowing KWin to support the graphicssystem raster. Before KWin enforced the native system. In the beginning I was reluctant to integrate it, but got convinced that this is a hughe improvement. Especially with the NVIDIA blob this is a nice addition as we circumvent the slow transparent filling of XPixmaps improving the performance of resizing windows (caused by decorations) and the effect frames in e.g. Present Windows effect. There are more improvments to come from Philipp like a heap optimization for glibc in KWin, scheduled for 4.8.
And of course much, much more happened which I just don’t remember at the moment 🙂 And for the next release cycle we can expect more great things to happen, more about that on Desktop Summit.
=-=-=-=-=
Powered by Blogilo
Awesome work, all of you! 🙂
Can’t wait to see the performance improvements!
Thanks to all for this awesome work.
Where can I find the list of hardware / driver combinations which should work with OpenGL ES/EGL?
I am not aware of any list. In general everything that uses Gallium drivers should work.
I’m running the beta in a laptop with a GMA950 and the performance improvement vs 4.6.3 is very noticeable. Very nice job Martin and all the KWin team!
Wow, thanks guys!
KWin is already the best window manager/compositor in the world, great to hear it will be even better in 4.7… 🙂
One question though: What do you mean by “Outline”? Is that the “rubber band” you see when dragging a window to the top/left/right screen edge to maximize/semi-maximize it?
yes
Thanks for this amazing work 🙂
One question … does (open source) radeonhd driver support OpenGL ES 2.0?
You shouldn’t use radeonhd any more, use radeon which supports GLES
I’m using radeonhd because it works (or at least it did when I tried AMD’s drivers some time ago). AMD’s driver was always a bit problematic to install and also it had to be reinstalled when a kernel update was installed.
So now it should be better to switch to AMD’s driver or are you talking about open source radeon driver that supports (supported?) only older cards?
I am talking of the open source radeon driver. The Ati driver is called fglrx or catalyst.
Sorry for getting a bit of topic, but I didn’t know that radeon driver was getting better even for new cards.
I own a radeon HD 4350 card (RV710) and use openSUSE 11.4 with KDE 4.6 which comes with radeonhd by default.
So my question is this, is radeon better even in KDE 4.6 for my card or should I switch only when I’ll start using KDE 4.7?
I am honestly surprised that openSUSE still ships radeonhd. Work on that has stopped quite some time ago if I remember correctly and radeon provides more options. But I recommend to check your distro support channels.
Thanks, I’ll do that. (this was probably an answer to my question 🙂 )
Why they still use radeonhd … if I remember correctly they are devloping or at least did develop it…
radeonhd is *only* used as fallback when KMS isn’t available. Normally the “radeon” driver is used (that’s what I see in my several openSUSE installs).
@Djuro: according to the X.org wiki (http://www.x.org/wiki/radeonhd) radeon seems to be in better shape than radeonhd:
Status 09/2010: Linux distributions, including Novell’s openSUSE, have now abandoned radeonhd as the default driver, instead using the radeon driver. radeon has more features, including Kernel Mode-Setting support and more 3D support, and it supports all Radeon generation from original R100 Radeons to R800 Radeons (HD 5000 series). Radeonhd can be continued to be updated as long as there are people find it useful.
radeon and radeonhd are the 2D x.org drivers, neither one has any support for anything 3D. Also, i’m pretty sure radeonhd was abandoned quite a while ago, even by OpenSuse. The new KMS system in the kernel replaced most of the functionality, and all remaining developers chose to stick with radeon for all cards rather than splitting the work.
3D support is given by the Mesa drivers, named r300, r300g, r600, and r600g. The “classic” r300 and r600 drivers aren’t really supported anymore either, although they may still be in use in some distros. The g drivers are gallium based, and receiving all current development work.
Re. improved performance for window resizing: this was INCREDIBLY bad with Arourae(?) window decorators downloaded with GHNS. Has this improved Arourae decorations? A lot of them are attractive, but I don’t want to use them simply because they’re SO slow.
yes that should be improved, but it mostly depends on the theme – some are really badly made
Great work guys! We’re working on 4.7 packaging for Fedora (yes, splits made it more time consuming, so stay tuned), gles subpackage is in my TODO list 🙂
I was shocked (not kidding) when I read that you weren’t going to fix blur on Intel cards… you’re going to DISABLE IT BY DEFAULT! Oh yeah – that’s an impressive solution.
So please stop writing useless “OH MOM LOOK AT HOW GREAT KWIN IS” posts and start working on improving the compositer, especially for Intel cards.
We know you don’t care about them because you don’t own one – but they are very very used in laptops.
First I have a system with an Intel card, second there are systems not able to perform blur due to hardware limitations. For those it is better to not enable the feature by default (c.f. Windows 7 Starter Edition). But if you are able to write better code for resource restricted hardware: patches welcome.
Resource restricted hardware?!
Blur works GREAT on Windows, why wouldn’t it on GNU/Linux?!
And I swear it DID work in 4.5.
Blur is slow on Windows on my netbook (and it’s disabled by default)
But it is NOT on my notebook. It works great, and it should work great on GNU/Linux too.
have you thought about the possibility that the drivers for windows are better? Just saying it works on Windows and therefore should work on Linux is kind of naive. These are completely different architectures and there are things which work better on Linux and some working better on Windows. No need to deny it.
If by limitations you mean intel’s max 4 texture indirections, then these can be fighted with by using multitex coordinates, so the texture lookups become direct 🙂
I’ve recently successfully changed OpenGL SuperBible’s gaussian blur shader example this way (so 3×3 kernel can be used without problems), so it works on my i945.
OK, I’ll look into kwin code and will, possibly, make a patch.
Hello Martin! kudos to you guys! but i have an issue 🙁 i cannot use opengl compositing in kwin, it gives me an libegl error, i guess kwin is trying to use opengl es backend, but i’m on the binary blob, so how do i force it to use opengl?
complain to whoever did the package. OpenGL ES as default is not possible and I explained that to the distributors (if it were possible as default, we would use it as default).
Blocking Compositing?
Does that mean I have to set a window specific rule (how do I do that for games?) for any game which does not support this flag?
Thus any game at the moment and for sure any proprietary game in the not so distant future.
Did you get in touch with entities like Linux Game Publishing et al. makeing sure that they use that flag in the future?
No we haven’t as the flag is currently proprietary and not yet proposed to EWMH. I consider the chances to get it accepted as a standard rather low given the in general currently broken state of freedesktop and the fact that GNOME Shell and Unity only support compositing making Plasma the only desktop shell actually being able to support it. But at least Wine developers and VLC developers are informed about it.
So that means as mentioned above that I have to do that for _every_ game myself?
If that is the case then that would be a bad default imo. I don’t know how to set window rules for games and suppose that most people do not know either.
well there is no way to recognize a game or full hd video. Also it very much depends on the system. My system handles watching FullHD video on one screen even if compositing is turned on. This is nothing we can match with one glory default. We have implemented the support in 4.7 and did not expect at all that any application would make use of it when 4.7 is there.
I thought the “unredirection of fullscreen windows” would work. Am I wrong here?
Yes you are 🙂 With unredirect fullscreen windows compositing is not really stopped, just one window (or screen) is taken out of the scene. This means the OpenGL Context is kept, all the resources are still blocked. It also has the disadvantages of restarting compositing when another window is opened on top of the fullscreen window (e.g. a tooltip or the statusbar in rekonq) causing a nasty screen flash. Another issue is that at least the Intel driver just crashes KWin when unredirecting a fullscreen window.
Ah ok.
Then I totally misunderstood this at first. 🙂
Btw. how can I set the window rules for games, so that I could use this feature?
see: http://wiki.ubuntuusers.de/KWin/Fensterregeln though the articel is not yet adjusted for 4.7