With KWin GLES shortly before the merge into workspace master (after git transition), it’s time to look back what I promised to deliver half a year ago, when I first talked about the idea of porting KWin to OpenGL ES at Akademy.
At the time of Akademy I had not yet started to write any code as I considered 4.5 more important and waited for the git transition. Obviously I stopped waiting for git or there would not be any code written 😉 My schedule presented at Akademy looked like that:
- Remove deprecated OpenGL code
- Remove unused code in Scene and E?ects Lib
- Drop XGL support
- Port to OpenGL ES 1.1 till 4.6
- Port to OpenGL 3 and ES 2.0 till 4.7
Removal of deprecated OpenGL code is mostly done. With GLES KWin has a forward compatible code path, though we still have OpenGL 1.x code for legacy systems and that won’t be dropped in the near future. Considering deprecated OpenGL 1.x code it’s looking quite good, e.g. glBegin/glEnd is removed in the GLES branch. Rendering of geometries is abstracted and the backend performs a runtime check whether legacy or modern rendering is invoked.
For 4.6 I started to port some effects to newer functionality which allowed to drop some then unused code. The remaining functions have been marked as deprecated, but are not yet removed in the GLES branch as they are still used by the Shadow effect (though unavailable in OpenGL ES and broken with OpenGL 2 backend). Given that Shadow is difficult to port, in general broken and unmaintained I consider to just drop it. I am already gathering ideas for a new replacement effect.
The XGL code (XGL was needed to run Compiz before AIGLX was integrated) is still in KWin and should really be dropped. It has been removed from X git tree for quite some time and I doubt anybody has ever run KWin with XGL. There are more things we can now consider to remove: shared memory and "fallback" compositing. Together this will mean a requirement to Texture from Pixmap. That’s pretty well supported nowadays on all drivers and anything else cannot be recommended.
The next bullet point is OpenGL ES 1.1. Well I noticed that it would really clutter the code, so I stopped working on it and switched to going to ES 2.0 directly. My initial plan was to provide 1.1 support at the time of the 4.6 release. Instead we now have ES 2.0 support at the time of 4.6 😀
In 4.7 we will not only have an OpenGL ES 2.0 backend available, it will be integrated into the release. As a side effect it gives us a complete OpenGL 2.x backend which should benefit all users having decent drivers. I’ll soon integrate an option to the advanced settings tab to choose between OpenGL 1.x, 2.x and 3.x. With the 2.x code there, it’s really easy to go to 3.x. We won’t default to it, we will hardly use it (I want to experiment with Geometry Shaders in MagicLamp effect), but I hope that the drivers supporting OpenGL 3 (that’s for us only the NVIDIA blob at the moment, fglrx is only usable with OpenGL 1.x in the composited case) are more efficient if run in a forward compatible profile.
There is still lots to do and I want to concentrate on improving the rendering stack throughout the 4.7 release cycle. It’s quite fortunate that the new rendering stack can be integrated directly after the git transition. So I hope that lots of developers will be using it and can provide feedback for various hardware.
=-=-=-=-=
Powered by Blogilo
ok, it’s great to hear but what about kwin without compositing? since kde 4.0 up til now with 4.6rc2 on radeon (xf86-video-ati) and nvidia (nvidia) i can’t get rid of black corners – http://bugsfiles.kde.org/attachment.cgi?id=53975 – I mean what the hell is up with this? Am I doing something wrong? And what about speed and stability? – I mean speed not only for couple specific graphics card models with particular drivers version, and i mean stability with and without compositing
Im not trying to sound bitter, I love kde but it’s been 3years, every release is a big step forward but We really need ROCK stable and rocket fast kde, (especially when gnome is in weak position) meanwhile enabling/disabling effects can easily crush kwin, enabling/disabling composition leave glitches till logout…
But hey! great work and I’m waiting for next releases, hopefuly one step closer to perfection 🙂
The uncomposited KWin has hardly changed since 3.5 and is as rock solid and fast as ever. In the uncomposited case KWin is not involved in any rendering so it’s not KWin’s fault if there are black corners.
I’m sorry that you have stability problems in the composited case, but trust me that is not a general problem. I would not use a crashy windowmanager and our bugtracker does not indicate any stability problem.If the drivers are crashy there is nothing we can do about it, sorry. At least we do not depend on compositing and provide an XRender backend.
thanks for clearing things up 🙂 actually I notice not long ago that compositing is quite fast & usable these days, I can’t wait to try final 4.6 🙂
Uncomposited KWin is’t fast, e.g. new windows are filled by background color for about 0.5 sec, or rock solid, e.g. resizing windows in transparent mode will freeze everything running under X.
Sorry, but in the uncomposited case KWin is not responsible for rendering. It’s not KWin’s fault if it is slow.
Then what is responsible? It’s ok in any other WM, e.g. openbox (well, except windowmaker and resizing bug).
*shrug* no idea and sorry, but my blog comments are neither a bug tracker nor a support forum. If you need help on investigating that please address the right places.
http://bugsfiles.kde.org/attachment.cgi?id=56097
Here current screen shot, I think it‘s just some lazy developers who forgot to add alpha channel to the other corners 😀 I experience it on all machine, doesn‘t matter whether it‘s nvidia, fglrx or intel drivers.
Can you post the bug report where you found this attachment since I added my own and so it seems a duplicate: Mine is http://bugsfiles.kde.org/attachment.cgi?id=56097
https://bugs.kde.org/show_bug.cgi?id=258559
> I think it‘s just some lazy developers who forgot to add alpha channel to the other corners
I have investigated in this bug quite a bit of time as I developed a Plasma theme in which it is even worse.
See: http://bugsfiles.kde.org/attachment.cgi?id=40871
https://bugs.kde.org/show_bug.cgi?id=199965
I can confirm that it is NOT a problem in the theme. And I couldn’t find any failures in the codepath of plasma. I don’t have any idea where this comes from. 🙁
“[…] but I hope that the drivers supporting OpenGL 3 (that’s for us only the NVIDIA blob at the moment, fglrx is only usable with OpenGL 1.x in the composited case) are more efficient if run in a forward compatible profile”
Based on the information on slide 97/113 of a presentation by NVIDIA’s Mark Kilgard on GTC 2010, I would not expect the core profile to be faster. He actually said the contrary: it might go slower because of extra checks.
http://www.slideshare.net/Mark_Kilgard/gtc-2010-opengl
but the extra checks should not hit us, as we are already core compatible due to the ES work. But yeah given how NVIDIA thinks about the deprecation it’s possible that it won’t improve anything to use core profile only.
It’s great to see KWin progressing this fast!
Will KWin live in its own repository when moved to git? It would be nice if KWin allowed for standalone builds (w/o needing to recompile kdebase every time).
kwin stays in workspace and needs to be there as it depends on shared libs. It’s nevertheless possible to just compile kwin without the rest of workspace
A pitty that none of a serious commercial sponsor isn’t making some power to a usable direction. I love kde but hate kwin slowing down the game. So it is openbox I stay with a kde-session.
Why not a usable 2dimensions window manager like canonical showd it is easy to produce: unity-qt-2dim
Shadows would be of much help. But they will be droped…
There are two weaknesses that should be the stronghold for kde:
– a usable kwin, helping with shadows to orientate, no animations needed there for older people!
– nepomuk, mail and semantical helpful activities, where some kind of artificial intelligence should show up!
I think you are slightly miss informed: Unity 2D is a desktop shell and not a window manager. KDE’s desktop shell Plasma also provides animations and translucency in the shell without a composited window manager. Unity 2D will also not be able to provide window shadows without compositing as that’s just a technical limitation of X.
Concerning shadows in KWin: they will be dropped because they are broken and unmaintained. As mentioned in the blog post I am gathering input for a new implementation. There are months to go till 4.7 and I am pretty sure that 4.7 will have a better shadow system than any other compositor for X11 out in the wild 🙂
Perhaps better clear words in german because my englisch is bad:
Es ist einfach nicht akzeptable, dass Kde4 nach so einer langen Stabilisierungsphase immer noch keinen Fenstermanager hat, der länger als 6 Stunden durchhält ohne langsamer zu werden.
Bitte denke auch an die Leute, die Kde nicht nur mal kurz anschauen wollen, sondern es tatsächlich extensiv über längere Intervalle benutzen!
Dann sind Animationen meistens eher störend. Aber so etwas wie Schatten, oder Abdunkelung, wenn ein modales Fenster erscheint, äußerst hilfreich zur Orientierung, besonders für ältere Menschen wie mich!
Also meinen PC auf Arbeit schalte ich am Montag morgen an und am Freitag abend aus und ich habe da keine Performanceprobleme. Also ich nutze das auch selbst 😉 Mein Privatcomputer hier hat jetzt eine uptime von 12 Tagen, jedoch wird hier ab und zu Compositing oder KWin neugestartet. Wenn du da Probleme hast, empfehle ich in einem Forum um Hilfe zu bitten.
Nun zu den Schatten: die Standardschatten werden nicht von dem Schatten Effekt gezeichnet sondern von der Fensterdekoration. Wenn wir den Effekt entfernen, haben wir trotzdem noch Schatten und wie ich schon sagte wird 4.7 auf jeden Fall wieder einen Schatten haben.
Ich kann mich hier über kwin nicht beklagen. Es läuft auch nach etlichen Stunden noch stabil und schnell.
Mich wundert aber hin und wieder die Auslastung von kwin. Wenn ich mir z.B. mit Kaffeine über DVB-T etwas ansehe, dann ist die Auslastung mit aktiviertem 3D-Desktop für kwin bei 17% und X bei 11%. Mit deaktiviertem 3D-Desktop ist kwin bei 0 und X bei 4%. Dabei schaue ich nur Fern, und mache sonst nichts am Desktop.
Video ist so ziemlich das schlimmste was man einem Composited Window Manager antuen kann. Wenn ich Video schaue, deaktiviere ich die Effekte.
That’s really good to hear. The KWin shadow effect really makes much nicer shadows than the Oxygen windec does. I like my shadows to be relatively big and soft and offset to the lower-right. Oxygen only makes small, hard, ugly shadows downwards.
I’m sorry to disappoint you: the Oxygen shadows will stay and most likely the new Shadow implementation will use the Oxygen shadow, too. Given the Oxygen light model a shadow to the lower-right is wrong. We won’t support something like that. Shadows belong to the widget style and we developers trust the decisions of our designers.
I’m not saying you should remove the Oxygen shadows, I have no problem with them existing. 🙂 The current situation where you can choose between Oxygen shadows and KWin shadows (even if I have to go into oxygen-settings for it) is good enough for me. And I don’t see why KWin should restrict itself to only supporting Oxygen-style shadows — there are, after all, a lot of other widgets styles and window decorations besides Oxygen.
(Though perhaps something is unclear: in your comment you say that KWin shadows will be dropped, and also that you are gathering input for a “new implementation”. But it’s not clear whether this new implementation will also be a KWin effect plugin, though I had assumed so. Wrongly?)
We will implement the shadows in a way that also other widget styles can make use of it. Similar to the situation with window decorations where we already have quite some decos supporting shadows although the code was added primarly for Oxygen. Oxygen is one of our most important stakeholders so getting things there first is a normal procedure. As like always there are users unhappy with changes, but this is normal.
Whether the new implementation will be an effect or not, is not yet decided and depends on the gathering of information. Most likely it won’t be an effect.
I see. Thanks for the info. In any case precise positioning of the shadows (below vs. below-right) is not as important to me as the ability to make them big and soft. : )
Nice post 🙂
Congrats on getting everything ported over so quickly – compiz is also getting some similar work done and your work in this field is actually quite useful to us.
It is strange though that you are dropping support for non tfp implementations of getting window textures, since tfp doesn’t allow you to split up a pixmap into parts and get each “part” as a texture, which means that if you have a pixmap size greater than your texture size then openGL will freak out at you. I’m sure the usecase for this is fairly small, but I am thinking about older hardware here. Was the reason you are thinking of this because doing copy-mode texturing not really something that is possible with GLES?
As for the shadows, it might be worthwhile looking into whether a fragment shader can be done to paint “correct” shadows into an FBO, and then blitting that FBO behind the window. That way, it could be possible to do “realistic” shadows with a kind of single light source
Oh KWin does not support splitting up textures at all. So I did not even consider that and only based it on the TFP is available everywhere part 😉 I don’t think we will ever add support for it – there is only one reported incident on bugzilla.
Concerning shadows you probably have a mail in your inbox soon
Thanks for these great enhancements!
I’m running KDE on my netbook and my “normal” computer. Both of them just run much better now with much lower cpu load – Finally I can see a good improvement here 🙂
One of the most annoying things: Resizing windows.
That really lags as hell. I’ve tried Enlightenment 2 weeks
ago and there it was a lot smoother (i had enabled compositing
there too).
But that said, keep up the good work!
Just activate the resize effect and it’ll be fast and smooth
A couple of years ago I briefly looked into KDE code and got impression that only KWin used OpenGL directly. Given the fact that Qt can use OpenGL ES too, can I assume KDE can run over OpenGL ES only system with this changes (well, X is needed too 🙂 )? Can I build basic KDE (kdelib, plasma, etc.) too with GL ES lib only?
Difficult to say. More applications are nowadays using OpenGL – e.g. KStars or Marble. I don’t know what version they use and how they interact with the GL layer. But from kde-workspace module only KWin uses OpenGL (without QtOpenGL for mostly historic reasons).