Ever since its inception, there have been problems with Compiz; people unsatisfied with the direction of the project forked it, then they merged again. Recently, the project, now known as Compiz Fusion, faced other problems, such as multiple branches and a lack of direction. A major reorganisation of the project is supposed to fix all this.
Compiz came out of Novell, pioneered by David Reveman, but was soon forked due to dissatisfaction with the way Novell handled the project. The fork, known as Beryl, would eventually merge with the original Compiz to form Compiz Fusion. With Reveman’s involvement declining, the project got into disarray, leading to various contributors managing their own branches with severe architectural differences. With Kristian Lyngstol’s effort to push the developers towards consensus, the project has now been unified once again.
During several conference calls, Compiz developers have created a council which will lead the Compiz effort. The council consists of five established Compiz developers, and will “work openly and will
encourage open discussion and decision-making, but will take charge where it feels it is necessary to retain momentum.” First order of business for the council was to set a roadmap, which looks like this:
- Merge Compiz and Compiz Fusion both in name and support systems. We are now using just Compiz as the name, and Compiz is moving away from Freedesktop entirely. Details are still being worked out.
- Release Compiz 0.8.0. Expect a release schedule later this evening.
- Merge Compiz++ to master.
- Release Compiz 0.9.0. This will happen shortly after the merge of Compiz++ is finished to allow for testing and feedback.
- Release Compiz 0.9.2. This will happen a few weeks after 0.9.0 as a pure bug-fix/cleanup release, with no major changes.
- At this point we will look at Nomad. If Nomad is ready to merge, we will aim for a 0.9.4 release which will include Nomad, and a 0.9.6 release which, similar to 0.9.2, will be a bug-fix/cleanup release.
- If Nomad is not ready, we will go over the option handling in 0.9.4, and push Nomad back as necessary. Otherwise, the option handling will be overhauled in the release after the Nomad bug-fix.
During the 0.9 development cycle, the developers will also focus on code cleanup, and they warn that the 0.9 development bracnh will be highly volatile.
KWin in KDE4.2 is far superior to Compiz in most ways IMNSHO.
All except in name.
Kwin is nice, but needs KDE… On an EeePC, compiz allows me to reduce the dependency…
But I agree I’d prefer to use kwin!
KWin does not need the KDE desktop, it needs only the KDE libraries. You can use it also in GNOME, Xfce or even standalone if you would want to ( http://www.kdedevelopers.org/node/3848 ).
Yes indeed, but installing it from a package manager will pull everything… I tried it using ArchLinux and it was great, but I was too much for the ssd drive. I had to choose :S
Maybe I’ll look at a standalone package.
would be nice if compiz and kwin merged somehow and stopped reinventing eachothers wheels. Not sure if that would even be possible since kwin is most likely heavily dependent on kde.
merge? no that would be bad. what would be usefull is code sharing and idea sharing between the 2 projects. But I am in the Kwin boat too, good stuff.
Definitely not possible. The architecture is completely different and there really isn’t any possibility to do significant code sharing. However luckily most of the effects are quite simple, so there isn’t much to share except ideas (which has been happening).
Except that it’s dog slow compared to Compiz (at least on my PC: Athlon 64 3500+, GF 6800GT, Fedora 10). It’s actually true for the whole KDE 4.2 – starts up almost twice as long as GNOME (from GDM screen to actual desktop) and window animations are jerky. None of this happens with GNOME + Compiz.
Which Nvidia driver? I had the same problem with all drivers < 180.22. Nvidia has stated themselves that their previous drivers had issues with KDE4.
It’s smooth for me (some 7600 geforce or so) but I don’t know what compiz is like.
I’m using the most recent driver from RPM Fusion which, as of now, is:
kmod-nvidia-180.25-1.fc10.x86_64
I hope this is the driver bug, because the video playback (in GNOME) is much slower now after recent updates. I’m not sure whether the latest xorg update caused this or if it’s the nVidia driver (I don’t have time to investigate this now). Regardless, the whole KDE 4.2 seems slow even with Desktop Effects disabled in KWin, which should rather eliminate nVidia bug from the suspected causes.
Seems that KDE (or actually, the latest QT) exposes a number of deficiencies in the nVidia binary driver.
nVidia is aware of this problem and trying to fix it.
You may want to try the InitialPixmapPlacement and GlyphCache settings. [1] (In theory, they are no longer needed, but I’m stilling using them and both 2D and kwin composition seem to be working just fine)
– Gilboa
[1] http://www.nvnews.net/vbulletin/showthread.php?t=118088
Seems that the KDE (or maybe the latest QT) devs did not do proper (or really any) research on the driver support they were depending upon when they were blindly making those decisions and blindly writing all that code. It’s not like people weren’t trying to point it out to them for the last several years. Go KDE…
Edited 2009-02-11 23:12 UTC
You got it completely backwards!
As long as the KDE (or actually QT developers) stick to documented API’s (be that OpenGL or xlib), they can, or actually, they must assume that who-ever sits on the other hand (of the API) has taken the time to implement and test each and every code path in their driver as dictated by the API.
Tell me, should QT disable support for a certain feature just because 10% of the drivers do not support it and/or support it badly? How far are you willing to go to appease broken driver developers?
What’s next? Should the Linux kernel developers stop developing the Linux kernel just because a certain binary driver developer has a hard time keeping up?
– Gilboa
* And I’m not talking nVidia; If anything, as much as I dislike binary drivers I must admit that nVidia is doing it’s best to give the best possible support for Linux users
EDIT: Removed a redundant comment.
Edited 2009-02-12 10:56 UTC
It works beautifully using the 180.22 nVidia drivers on F10 64bit.
If you have a Geforce, try updating the driver.
Edited 2009-02-10 20:29 UTC
Wish I could say the same – I have a GeForce 6600GT and the 180.22 driver didn’t fix anything for me.
I’m definitely still a fan of KDE 4.2 and Kwin but my desktop effects have been jerky right from the start(mainly the fade-in/out of windows, incl the fade-in to the desktop on startup).
I’ve been using 180.22 since it was in the nvidia repo and it didn’t change anything for me. I’m led to believe there is no point making changes in the xorg.conf since most of the successful options are now on by default in the new driver.
The ONE thing that gave me success is turning OFF direct rendering within the kde control panel – desktop options. Made things much smoother…
This makes no sense whatsoever. Apparently direct rendering should lower cpu usage but I found it made almost no difference. The only problem was kaffeine didn’t perform quite so well when watching tv (dvb). but this was only slightly noticeable.
I’m still happy using kde 4 though – dont get me wrong. I just put up with the sub-par graphics performance. Linux seems to be going backwards in this area for me. Hopefully they can fix it soon, either through xorg or kde or both.
Even with Nvidia issues worked out, KDE4 is still slow. Plasma and Kwin are good designs with a lot of planning, but they still need a lot of work to knock out bugs and work out the bottle necks.
Kwin and compiz do share code. They’re called X extensions like composite, dri2, etc. Beyond that, they are two very different projects with little in common.
What they CAN do is collaborate better with Freedesktop (and Gnome) on standardizing how desktop elements are handled. Specifically, wallpaper (wallpaper in plasma sits above what all non-KDE apps consider wallpaper), “Desktop Activities” and “Widget Layers”
Really?
I’ve only tried KWin 4.1 (and only on two machines) but I found it significantly slower, not as pretty and a massively reduced number and range of effects.
Compiz Fusion massively trumps KWin 4.1 so unless KWin4.2’s rendering has progressed significantly in only a few months then I really struggle to see how you draw that conclusion.
That said, KDE4.x + Compiz Fusion is a killer combo.
KWin in 4.2 is much faster and looks much better than the one in KDE 4.1 – KDE development goes very fast 😉
Check the visual guide if you wanna know more.
http://www.kde.org/announcements/4.2/guide.php
Linux community is so ungraceful.
First. KWin is no superior than compiz, and second, KWin is a derivative of compiz with the goal of be more integrated with KDE. Is sad to see all the trolls in the “community” trashing other projects and not working together.
Im glad I stopped using Linux, I don’t want to be related with those kind of trolls.
So have you found the trolls of your OS of choice to be any better?
Yet you in a Linux Desktop talking about Linux trolls
There seems to be a lot of problems with Compiz, in terms of organization (not of function). I’m hoping this will settle it for once. It’s just with so many distributions relying on Compiz for their effects, I wonder how the “volatile” code changes will effect the overall stability of Compiz and the distributions that implement it by default?
Wasn’t Compiz Fusion the major reorganization of the project that was supposed to fix everything? What happened, did it fail in its goals?
there is no Direction in at compiz of releasing a stable compiz 0.8.0 so what makes people think compiz has any direction now?. i can see this as a dying project, sad to say it but Long live Kwin
didn’t realize that saying that kwin and compiz should merge or work together and not reinvent the wheel was such a bad comment. Marked down to 0…really?
Sure merging probably wouldn’t work. But I think we can all agree that sharing code or sharing techniques or sharing ideas is a good thing for both projects right?
The only thing worse than reinventing the wheel, is reinventing the same mistakes the other team already dealt with.
Which is why the KDE guys want to do compositing in kwm, rather than using Compiz.
KDE’s window manager was already a well-established window manager. As a window manager, it works far better than Compiz. It integrates with KDE better. It’s more configurable. It has better general window management behaviour (like focus-stealing prevention that actually works). It’s an established codebase with very few bugs by this point.
The KDE guys were not willing to throw away 11 years of bug fixes. Especially considering that Compiz doesn’t work with a non-composited desktop, so they’d still need kwm anyway. Using two WMs was not an option – there’s no way to make Compiz’s behaviour consistent with kwm’s. Hell, it’s not even consistent with metacity.
They decided that re-implementing the two year’s worth of work that had already gone into Compiz (and learning from Compiz’s problems, and benefiting from work done elsewhere in X to support Compiz) was better than re-implementing the 11 years worth of work that went into kwm.
I tend to agree with them. So do the maintainers of metacity (Gnome’s WM) – they are also working on adding compositing support. They just started a lot later than the KDE guys, so they’re pretty far behind.
Give it a couple of years, and Compiz will not be the primary compositing window manager. Metacity and kwm will be, with Compiz probably provided for people who want lots of crazy extra effects. Or it’ll be completely unmaintained, and nobody will use it.
I’ll add to this by saying that compiz went the wrong way by being a standalone WM. What should have happened is that all the compositing and effects work that went into compiz should have been put into a library that other WMs could have used and then have KWin, Metacity, XFWM, heck, even Fluxbox, be able to make use of those features, but otherwise integrating with the existing DEs/WMs that people actually want to use. As it stands now, Compiz has its own configuration system, its own theming system, its own horrible window management system, etc. Yes, there are plugins to try to connect to native backends, but that’s really the wrong solution. Compiz should itself be the backend, with existing WMs, configuration systems and theme systems working as they did before.
Do you know that Metacity supports compositing since 2006?
You just have to activate it in gconf. I use it since more than a year. I don’t think they started any later than the KWin guyz. I believe it is the other way around.
compiz was the first one and will always be an excellent project for experimenting with new features.
Edited 2009-02-11 15:41 UTC