This weekend I worked on some KWin OpenGL Shaders. That is I wanted to bring back the blur effect. It seems like many users want to have the effect and well with translucent window decorations a nice blur is kind of needed (yes we get compared to Windows 7 and that blur is really well done). The first results look very promising: it’s fast and doesn’t render artifacts to the screen. But I decided to not rush it into 4.4 as there are still some minor glitches around the decoration shadows which render the nice Oxygen glow useless. As well the blurring is not yet as nice as one produced by Krita. I will merge the branch as soon as trunk is open again and so we will have a blur effect in 4.5 again 🙂
But blurring is not the only OpenGL shader I started to work on this weekend: I started to implement a shader to replace the complete fixed functionality rendering of KWin. Our current rendering uses lots of OpenGL 1 commands as we also want to support older hardware. We have some OpenGL 2 shaders like the blur which replace parts of the fixed functionality.
In OpenGL 3 the fixed functionality is deprecated, in OpenGL ES 2.0 it’s even completely removed and replaced by the programmable pipeline. So getting the rendering completely into a shader is a prerequisite for using the new awesome stuff of OpenGL 3 like geometry shaders as well for porting KWin to OpenGL ES.
So why porting to OpenGL ES? Well I would like to see KWin running on Hardware like the N900 🙂 I think that KWin although developed for the desktop would be a nice window manager for small devices. We have some outstanding effects and a great decoration API as well as a nice SVG decoration engine when you don’t want to write your own decoration. And of course we see that some projects use Clutter based window managers for their small screen systems and it would be nice to provide an alternative, a window manager which is rock solid and has been used with compositing enabled by default for now almost a year – in some distributions already since KDE 4.1. And last but not least optimizing for small devices is useful for desktop systems as well.
So after spending some hours hacking the basic window rendering is implemented in a shader and if the shader is bound no deprecated OpenGL functions are used. Not only the basic rendering is supported, but some effects like present windows, desktop grid or even cover switch (as long as not using multiple screens) work as well. Other effects like cube, all shader effects or important benchmarking tools like fps are completely broken 😉 (Nevertheless my completely unprofessional benchmark called “top” looks very promising – kwin is not shown any more when idling or just doing a few repaints).
I don’t know when I will have something that could be shared as my development time is currently very limited and I only work on KWin at weekends. As well for the OpenGL ES part it could be a problem that I don’t have any hardware 😉 For OpenGL 3 it’s no problem as the drivers I use support it. I hope to have it in a state to push to trunk when it gets unfrozen.
=-=-=-=-=
Powered by Blogilo
You absolutely rule! Its great that someone picked up the blur issue.
With this, KDE will shine in every possible way. Im looking so forward to KDE 4.4/4.5.
Thanks alot!
Martin, I am stunned every time I read about Kwin development these days. So much has happened since the port to Qt/KDE 4 and so much might happen in the future… 🙂
I wish you guys the best of luck!
yeah, bring back the glow :D. i hope it will work with free radeon and intel drivers.
I can’t be the only one who thinks blurred windows is one of the worst interface decisions Microsoft has made lately(and I actually like a lot about windows 7 look and feel). It looks ugly as hell and is confusing. Transparency should be used rarely(probably not panel, definitely not window decorations, probably best to have the window be transparent when moving it).
I hope that by the time your changes reach trunk the intel driver will have implemented the new OpenGL 3 functions.
As I already said to you via identi.ca iirc I’m a completely fan of the new super-awesome-effect 🙂 congrats for everything!
I actually don’t care if it’s a nice blur, a crappy blur or whatever. If it’s a blur (or something like it, like the mipmap LOD fallback that Compiz tried to do), and does not destroy all other effects, it must go in KDE 4.4. Later we can make a perfect blur, adjust intensity through opacity, and all those things you are remarkable for. But, first, please, get a stable blur into KDE 4.4 😉
I really hope you get this blur to 4.5 then. Because I am sad it did not made to 4.4. But better to have a correctly working version than gripled one, even I do not use Oxygen style.
Is there any kind screenshot of this blur state? I checked the Krita one and I must say that by default settings the blur with 5-10 effect looks nice. I just hope we would get ARGB working on the KDE same time as this. So we can get a some parts of windows as glass like with Bespin style. But I do not want to have all graphics but just the basic window and toolbars/menubar. But sidepanels and the middle context example on the Dolphin would stay visible totally and all buttons.
The OpenGL 3 sounds nice. But it is even more nice to hear you plan to support older HW. Just keep it going and tell us your process 😉
Mmm, KDE 4.5 on the Touchbook… This is going to be sweet 😉
Hell yeah! And please make plasma panels and dialogs blured too. It’s going to rock!
How about reconsidering putting it in 4.4?
There are still month of development and stablilzation ahead before the release of 4.4.
Letting it in the 4.4 branch will at least allow broader testing, and maybe result in ironing out the bugs… In case of too many bugs it can still be withdrawn after e.g. beta2 has been released.
Anyway, thanks for your work on it!
Can’t put it to 4.4 branch due to string freeze on Wednesday. Blur needs new strings and I don’t have the time to code on it till Wednesday.
How about putting some “empty” Strings in there ? As much as needed or more and fill them with life from time to time 😀
Well string freeze means that you are not allowed to do such things.
You could wrap all required strings in Q_UNUSED(I18N_NOOP(“Foobar”)). Of course this requires that a) you know all strings and b) any actions comply with the hard feature freeze on Wednesday. (I think that b) is harder.)
I really hope you reconsider putting it into 4.4 – destroying the “nice” oxygen glow isn’t IMO a showstopper, since the “glow” makes windows look ugly anyway. That glow effect is the most stupid thing put into kwin since sliced bread – if blur can destroy it, then it’s two birds with one stone! Success!
You know you can turn of the glow. And yes to me adding a regression is a show stopper and it looks ugly. So that is a no go.
I’ve looked for it, but no I didn’t find it 🙁
I’m sorry that my comment came off a bit more harsh than I meant to – to me disabling glow would be a killer feature, not a showstopper 🙂
But please let me know where the glow can be turned off!
It’s a new feature in KDE 4.4 and can be turned off in the Oxygen configuration interface.
If you are using KDE 4.3 you can install Nitrogen from kde-look. It supports switching off the glow as well.
Great, that one feature will be enough for me to upgrade to 4.4 when it’s out (not that I wouldn’t anyway) 🙂
I’ve tried numerous times installing nitrogen, but either somethings wrong with kubuntu packaging or I just don’t have the fu. Or both.
Btw, you guys are doing a great job with the kwin effects though, they look smooth 🙂
Oh, and who do I talk to if I want to have the “transparent cube” effect always on, like compiz lets you?
Sorry, I’m not so well educated in KDE 😛 Does this glow mean that blue “frame” around the active window? I’m even a bit confused 🙂 Hope my english is understandable
That sounds super awesome to be honest. Can’t wait to see screenshots/videos of the proper working stuff in early 2010 or whenever 🙂
Why don’t you use Qt3d? I know it is just coming, but then it will run on Maemo6 and everywhere directly without duplicate functionality between Qt and KWin.
Qt3D won’t be available till Qt 4.7. It would provide some advantages. But currently it’s not yet an option. But my new implementation uses some of the new possibilities in Qt 4.6 like QVector3D.
Other comments are talking about blur… I’m most interested in opengl es/3 🙂
I think you’re right to not include your work on 4.4, regression on a window manager could ruin the whole image of kde in reviews 🙁
I’m quite impressed that “after spending some hours hacking ” you already had a basic implementation… For me this means that a) you are very skilled, or b) that kwin code base is ultra clean 🙂 (maybe both who knows :D)
Anyway, good luck for the rest !
When we’re talking about OpenGL ES/3, I’m missing some information: Will you keep compatibility with graphics drivers that do not support the new, shiny OpenGL 3 features?
Of course I will keep the compability with the old world. That is there will either be a new backend or the OpenGL backend is changed in a way that it does not use the old code when shaders are used. Currently I’m working on the second approach. But I don’t know yet if that will work as for OpenGL ES we have to #ifdef away the old world.
For new stuff in effects using OpenGL 3 functionality it will be the same as currently with OpenGL 2 – additional features will only be available if the hardware supports it or an optimized version is used. So I want to implement the Magic Lamp effect with a geometry shader and of course I can keep the old code.