KWin, KDE's window manager, has been around since KDE 2.0 (replacing KWM in KDE 1.x) and has grown to be a mature and stable window manager over the years. For KDE 4, however, there were a few people rumbling about visual effects, and perhaps KWin was feeling a little envious of its younger cousins Compiz and Beryl. While these new effects have created a lot of buzz around Linux and UNIX, long-term KDE users have wished they can enjoy the effects of Compiz/Beryl while still having the tried and tested window manager that is KWin. As a result, for KDE 4, KWin has received a huge graphical upgrade, with composite and GL support. Read on for more details.
KWin has implemented effects in a way that allows a number of different rendering methods to be used, depending on your specific combination of hardware and drivers. These features have brought KWin rapidly into the era of dazzling eyecandy, along with some pleasant surprises on the usability front. This effort has been spearheaded by Lubos Lunak (a man known for his efficient code) and his team, with special mention to Rivo Laks and Philip Falkner for their contributions.
Effects are disabled by default at the moment, although that may change before KDE 4 ships, and distributions may decide to alter this setting anyway. When enabled, the effects are designed to degrade gracefully. If GL is not available, KWin disables GL effects but still allows Composite effects where possible via XRender. If XRender is not available, it falls back to plain X, running in the same fashion as the present KDE 3 version. To get the full array of effects, you need to have a video card (and driver) that supports AIGLX, XGL or use the proprietary Nvidia driver.
Once the effects are enabled, it's simply a matter of choosing which effects you'd like to activate. So far, Rivo Laks has been working on the effects plugin selection interface (see the screenshot below). The new plugin selection widget shown is making its way into various parts of KDE - it does automatic dependency checking, so once the dependency tree is known, it will intelligently enable or disable dependent plugins. This widget is also showing up in other parts of KDE 4.
(as you can see in the image, this dialog is quite new - less than a week old - and is missing all the icons...)
Lubos has been periodically blogging about the effects that KWin is now capable of, and has recorded a number of videos showing them off. Since video capture on my system is rather chunky, I will present his recordings instead. So, without further ado, I present some of the more popular of his flash videos, hosted by YouTube. If you are interested in more, please visit his YouTube User Page
The Present Windows Effect - a very useful effect that falls into both eye-candy and usability categories...
The Desktop Grid Effect - those familar with the Cube effect may note that this is not quite as flashy, but probably more useful. Doesn't mean there cannot be a Cube effect for KWin though.
This one shows the above two effects, as well as the Alt-Tab thumbnails, but it shows that the effects work great, even when the windows contain active videos.
Zoom Effect and Magnifier Effect: some accessibility related features that everyone may find useful, depending on your specific needs.
Effects like this one make people go "Wow". The first part of this video features the Fall Apart Effect, which basically has a window blow up. It's amazing how well this effect can be demonstrated in a low quality flash video...
Aside from Lubos, many of the new effects and underlying core components were programmed by Rivo Laks and Philip Falkner. They are responsible for many of the effects you see in the videos, including the Present Windows Effect, and the improved Alt-Tab dialog. There have been a number of contributions from others as well, and they are always looking for new and interesting ideas. In addition, KWin for KDE 4 builds on the already existing KWin version which has had dozens of people contribute to it over the years.
The window decoration shown above is called 'kwin3_crystal' and is still set as the default in SVN. It is simply a port of the existing KDE 3 Crystal window decorations, however, a new KWin window decoration is still in the works for KDE 4 - it hasn't been made the default yet, so I haven't been featuring it. When it does eventually become the default, you'll be sure to hear about it here (and likely in Danny's KDE Commit-Digest as well...).
KWin for KDE 3.x implemented a very simple composite manager, allowing simple effects such as window transparencies, fading menus, shadows, and so forth. The code was not too complex, but the infrastructure was not in place to seriously extend the effects to GL powered goodness. When the KDE 4 development series opened, it was seen as an excellent time to rewrite some of KWin's internal structures in order to support such effects. There were initial considerations of implementing support for the existing Compiz and/or Beryl system of effects via plugins, but there were technological hurdles that prevented this. I won't go into the technical details as to why this decision was made, however, it is important to note that KDE 4 will still work with Compiz/Beryl should the users choose to use that software instead of KWin.
Additionally, while KDE 4 will be supporting a number of platforms with libraries and applications, KWin is one of the applications that will not be making the switch as it is inextricably tied to X. This should be considered to be a Good Thing(tm), as it ensures that KDE will always be the best looking when used with Linux/UNIX, and hopefully it (and related KDE Workspace technologies, like Plasma) will remain a unique benefit of using a more open operating system.
KWin promises to ensure that KDE get the graphical boost it needs to keep the eye-candy folks happy, while providing new and usable features for the desktop environment that would not have otherwise been possible. Yet, it maintains the rock-solid foundation that a long history as an integral part of KDE has provided. It will still work (with reduced levels of effects) on any system that KDE 3 ran on, so no-one is left out in the cold. It is already the default for KDE 4 in SVN, and will be showing up in future beta releases.
On a personal note, I've found that KWin on my system was dropping down into XRender mode due to some X settings I need to fix, but it has been perfectly stable for me over the last two weeks. In fact, every week when I'm rebuilding KDE 4 to write these articles, I am more amazed at how quickly it is becoming stable and useful. If you are interested in testing it out for yourself, check to see if your distribution has packages available. I am aware of the existence of at least one live CD (where you don't have to risk messing with your system) that is available at the KDE Four Live website. They update the Live CD every few weeks, and currently has the KDE 4.0 Alpha 1 packages. Additionally, if you are brave enough to test the Composite features, and are having problems, have a quick look at the Composite HowTo.. If you have problems, please report bugs using the the KDE Bug Tracker by selecting the KWin program, and the "composite" component.
Until next time.
Comments
>AMD has claimed that they will be releasing ATI drivers as opensource [..]
If you're referring to the keynote at the Red Hat Summit, opinions diverge and there was nothing like a promise of any kind, except that AMD's marketing person claimed that AMD is willing to work on better Linux support for their drivers - like AMD/ATI did so often. Only (tabloid) news sites Slashdot and OSNews reported in a "It's coming soon" way, linking as proof to a blog of someone who thinks to have heard a promise of open graphics drivers.
Just to consider: AMD doesn't even care enough to clarify. And then recall again their promise of having to work better with the Linux community. All I'm saying is, don't get your hopes too high with AMD.
They'd rather just release their hardware's specs/documentation freely so we stop depending on them and their flawed drivers. Mind you, ATI drivers have never been good (never even MS Windoze's).
You're telling me. I have an old ATI Rage128 card that guarantees a WinXP blue screen (with the newest version of the driver) if you start up aMule but it works like a charm on the reverse-engineered X driver.
this question you have to ask the other way around. because the problem lies with the proprietary drivers. they dont support one extremely important fonction that all those fancy WMs use, and i think there is no way to make it work with the current ati drivers. But i'm no developer.
Change to nvidia or intel if you can. i'm out of luck too with my laptop.. at least those things work with the open source driver.
having laptop here as well. so changing is on option.
The open source driver neither supports OpenGL hardware accelleration nor directdraw. I know, thats not the developers fault.
sorry, "direct rendering"
With fglrx, Xgl is needed to run Compiz/Beryl. fglrx will run in GL Mode, Composite is somehow emulated or so by XGL (afaik).
I wonder if kwin_composite will work with XGL and gl enabled fglrx...
Since it is doing much the same thing as Beryl, it should work. I've never played with Xgl though with fglrx. I got so upset with the drivers for my fairly new (onboard) radeon express 200, that I went and bought myself an nvidia card just to avoid the driver hassle.
I share your pain, I have the same card, and it is absolutely atrocious. In the beginning it didn't even work in 2D mode. At least that works now, but the performance is dreadful, and fglrx is such an awful driver that I don't even want to try it anymore. I spent weeks on it in the past with more or less garbage results. My only hope now are the ATI open source drivers (if they actually release them).
Opensource or not, their drivers will remain buggy.
Our real hope would be pressuring them to release their docs so we can code our own decent drivers.
so now specs are better then code? the opensource driver community could easier write a new driver from scratch than fixing atis maybe-very-soon-opensource-driver?
"so now specs are better then code?"
As far as device drivers are concerned, it always has been.
"the opensource driver community could easier write a new driver from scratch than fixing atis maybe-very-soon-opensource-driver?"
Probably. That driver's just so buggy, it's code may be a complete spaghetti mess. I could be wrong about this thou, perhaps it may just be a matter of cleaning the code up.
I have a Radeon XPress 200M, and I installed the newest drivers from AMD. They are a completely new codebase and fully support AIGLX. I am running Beryl with few problems,so I am sure that this will work excellently with KDE4.
I mean, what are the minimum requirement to play GL or XRand efects? For example, Can I play the efects withslowdowns in a ati r128? Can we use a xinerama setup? And a remote X display?
It depends on what features you turn on. With all effects, it won't run smooth. But some basic effects should work fine... Maybe lubos knows some details here. And there's an article about performace, but it's about Beryl. Kwin won't be a 100 times faster I guess, so it should give a pretty good idea of what is needed. http://www.phoronix.com/scan.php?page=article&item=730&num=1
So us with older hardware can turn them All off. Excellent!
I could see some benchmarks of Intels latest chipset, but what about their older chipsets? Anyone knows?
It depends on what effects you're talking about. The most basic (and most useful) composite goodies should work flawlessly on an ancient TNT2 and a 300MHz CPU :). I have myself seen compiz work like a charm (and with negligible CPU usage) on my friend's old Pentium II with S3 Savage4 accelerator (not as powerful as a TNT2, though with comparable capabilities). If you have a PS 2.0 capable GPU like FX5200, you won't have any problems with any effects :). Compositing a desktop is really no burden even for very old graphics accelerators.
Your article are to me good.
You make it a way I so rarely have questions left after I read, you rock.
And good work kwin devs.
Now, past the thanks :
I am lucky enought to have an old ATI runing with OS drivers, with both comiz or beryl.
But I quickly returned to Kwin.
Why ? because even whithout the fancy eye candy, kwin is actualy usable. the two above can't claim the same. that's all
And no, I don't mean they are buggy ( ok, freezed the computer about two or tree times a mounth, but not so bad to stop using them if they had been good,hey )
until next time :)
Thanks for the kind words.
Basically, if it was supported by Compiz and/or Beryl (the two projects have now merged, but I still cannot figure out what the proper thing is to call them) then it should work in KWin as well. I haven't seen a side-by-side performance comparison, but Seli has done performance related profiling within KDE before, so I'll trust his capable hands.
Will be there a wobbly windows effect ? I know this effect can look useless (and I agreed at first) but now I like it a lot
If you check out Seli's youtube page, there is (or used to be) a wobbly windows video up there. I did see that effect when I was scrolling through the list :)
It wasnt wobbly effect, it was a wave effect - all windows were just waving, whether you moved them or not.
Oh, right. There are a number of plugins that implement 'demo' modes, and I believe that one was called the 'Drunken Windows' demo or somesuch :)
My personal opinion (hence a end user vote) -
wobbly windows *BAD*.
Specially the minimize effect in beryl (do not have good enough english to properly term it) really SUCKS.
I may be cool to have different shadows sizes : if a window is active, the shadow is larger (like if the windows higher) and if the window is inactif, the shadow is small, as if it is put on the desktop
this is already implemented in Kwin for KDE since 3.3 :D
But they'll have to rewrite it, so let's hope they don't forget this.
I think this work is great - what he has also done is provide a way to capture the screen shots, plus that rather neat red highlighting with the mouse. As far as I can see this will be a very usable desktop. In my opinion the eye-candy is useful in adding a tactile feel to the desktop. This is important and also provides useful accessibility options too.
As I have played with Compiz and Beryl they are pretty, but complex to configure (this already looks clearer), and miss the quality window management stuff described above.
Whatever the eye-candy brings the stability of Kwin is a great asset - I want to do work after all and I need a stable WM to do that.
i really hope they implement a filter field at the top of that configuration dialog (like most kde components have now) - finding any option in beryl configuration was PAIN when i tried it in knoppix 5.1 ;)
Great work, but it would be really amazing if these videos were also
available in theora format [insert the regular rant about
free vs closed formats here]. It's really depressing to miss out
on all the fun...
Also, off-topic but, is there some way for third party applications
to know when it's running under the gl version of kwin? Does it still
use "kwin" for _NET_WM_NAME or something distinct?
thanks
For the former question: part of the reason we're hosting on youtube is to limit our bandwidth consumption on the dot.
On a related note: one of the interesting features that KWin has implemented via the new effects system is a screen recorder which works almost as easily as ksnapshot does for screen caps. It doesn't do any encoding on the fly, as that would slow down the system taking the video, but it dumps to a raw format that just about any encoder, open or otherwise, can use. This means there is likely to be more videos of KDE 4 stuff showing up in the wild-- unfortunately, most of these will end up on youtube, simply because the price of hosting is the right price... c'est la vie.
Additionally, if not available via some other part of the NETWM spec, this information would probably be obtainable via dbus queries. KWin is still called KWin though, so no name change.
Maybe archive.org could provide a solution to the bandwidth problem?
>>On a related note: one of the interesting features that KWin has implemented
>>via the new effects system is a screen recorder which works almost as easily
>>as ksnapshot does for screen caps.
Actually , that's what's bugging me. I've noticed that some time ago on the
websvn and I'm looking for ways to "compete" with this feature :).
I'd hate to see my last year's effort (http://recordmydesktop.sf.net)
hit /dev/null and get obsoleted...
Thanks for answering.
KDE isn't microsoft; we're not going to crush you out of existence :) Take a look at the success of yakuake, konversation, or kommander, etc. as alternates to the applications that are shipped with KDE that do quite well.
Or, if you're intereseted, we can hook you up with an SVN account and let you design that part of KDE. As far as I know, there is no UI to configure or control this extension yet, and your expertise would likely be very welcome by the kwin developers :)
Either way, I didn't know your project existed until just now -- it looks pretty shiny already :)
Yes, recordmydesktop rocks. I wonder why it isn't integrated in Beryl, the beryl-vidcap thing is based on seom and produces really ugly videos in an inusable format. Maybe you should mail some Beryl-devs.
well, seom is certainly not producing videos in an ugly format, whilest it is not developed by me I still feel I shall argue here.
in fact, you just can't use XviD4/Ogg encoding to record the desktop on the fly, you just won't have the horse-power for that - trust me (as the recordmydesktop dev most obviousely noticed himself!)
the config part in the video record effect are hard coded as they've been actually used for demonstration by lunak only, so you are all welcome to improve this effect if you want to.
Although, recordmydesktop[1] is a standalone application, not ideal for integration into kwin, yet you could use it on your own, but there is a need for something more speedy, ideally not capturing via XImage/XShm source but via OpenGL, as kwin now primarily renders in OpenGL mode.
So the kwin maintainer tried out seom[2], while this looked promising, lunak still wanted more, that is: partial screen capturing, that can be integrated into an Xdamage-featured compositing desktop, so I implemented this requested feature in my the capturing framework I am developing myself[1] and showed him some demos using it.
[1] http://recordmydesktop.sf.net/
[2] http://neopsis.com/projects/seom/
[3] http://rm-rf.in/captury/
[4] http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/effects/videoreco...
Try swfdec or youtube-dl.
You don't need Flash to play videos on YouTube. They are encoded in Flash Video (.flv), which mplayer can handle.
1. Get mplayer and youtube_dl (http://www.arrakis.es/~rggi3/youtube-dl/)
2. youtube_dl http://www.youtube.com/watch?v=4WBLlc6xCQ4 && mplayer 4WBLlc6xCQ4.flv
If you want to download multiple videos in one go, get my (Ruby) script here: http://membres.lycos.fr/madleser/coding/yt
http://movie-get.org/link/
Makes MPGs via the website, or via downloaded script if you prefer that.
I appreciate your answer(as well as the others on this matter), but
the issue wasn't on whether it's technically possible to see the files
using only free software (and btw the previously pointed youtube-dl
+ mplayer requires the binary codecs. youtube-dl + ffmpeg2theora though
does the trick).
What I was trying to point out is that we should strive for solutions
that are accessible to everyone, without punishing people with extra
tedious steps, if they choose not to install a non-Free component
like flash.
Thanks for the kind answer(s), though.
While I agree with your viewpoint, I'd like to also point out that you're running an old version of ffmpeg in your MPlayer.
Gnash 0.8.0 with the GTK+ frontent and ffmpeg FLV-decoding backend works with only a few minor glitches relating to font rendering and widget positioning in the YouTube player. (the font rendering is fixed in current CVS) and current stable MPlayer on Gentoo decodes FLV (as well as the Sorenson codec (for Quicktime) that it's based on) using only ffmpeg.
And I'm on a native x86_64 system so I can quite honestly praise the progress that's been made. The only thing I need amd64codecs for is RealPlayer videos and the only thing I need mplayer-bin (32-bit) for is the Indeo 5 codec from win32codecs. (I collect AMVs and about half a dozen of them use Indeo 5)
Heck, I get full browsing functionality without needing nspluginwrapper, a 32-bit nspluginviewer binary, or a 32-bit Firefox. (I'm using Konqueror with KMplayer, Gnash, and 64-bit Java, Firefox with MPlayerPlug-in and Gnash, and I don't need Java in Firefox)
Why are the Kwin-Videos so laggy compared to the Compiz-Videos? And do I have to disable the effects everytime I want to play games like ut2004?
Would be great if I'm wrong.
I tried kwin_composite went it was merged into trunk and found it much, much slower than Beryl on the same hardware (an nvidia 5200) : Beryl was *wonderfully* smooth on that card, but kwin_composite was very poor - you could easily count the individual frames on even as simple an effect as the "minimise" one (about 3-4 fps).
So, lots of optimisation work still to do :) Based on progress so far, I'm sure they'll have no difficulties in getting it to run well in the long term, but I'm not sure about having a silky smooth kwin_composite for KDE4.0.
Well, you should try to play with the settings. it was very slow for me as well, until i changed a few things - now it's perfectly smooth.
A: I have no idea.
B: You probably wont have to, if you have a non-ATI card. (The others can do composite on the normal X server, ATI's can only work with XGL, which can't accelerate anything but the WM properly).
In one of the Youtube comments someone said it had something to do with the recording slowing down the system, rather than the actual performance of the effects.
Does anyone know the answer to the second part of the question? I had to get rid of xgl/compiz because it seriously degraded any other app that needed acceleration (Krita, Google Earth, games, etc.). I like cool desktop effects as much as the next guy, but I don't want to give up actual, usable features in apps I use regularly.
It does not depend on the window manager. If you use XGL it might be the case, that hardware-rendering can only be done by the window manager but no application. Using AIGLX this should not happen and every application can use the GPU's complete features/speed.
Blame XGL for having a brain dead design (running a Xserver in a Xserver?!?). But XGL is going to die anyway and AIGLX is the road to go (only support from AMD/ATI needed).
For me even Aiglx slows down applications. I use Ubuntu 7.04 and e.g. glchess is more laggy, ut2004 has 30% less fps, ... when Compiz is activated.
Would Xegl improve the situation?
Which hardware? Intel and NVidia should do fine...
Nvidia Geforce 6600
OpenGL and everything works, but it's slower.