|
|
Subscribe / Log in / New account

Debates on the future of Compiz

January 7, 2009

This article was contributed by Bruce Byfield

Is Compiz dying? Possibly not, but the consensus among developers of the compositing window manager seems to be that the project is in serious need of reorganization if it is going to survive.

Founded three years ago, Compiz quickly gained recognition as one of the first projects to deliver 3-D graphical effects on the desktop. Probably its best-known effect is the presentation of multiple workspaces on a rotating cube. The current state of the project dates from the merger of Compiz and Beryl, a fork of Compiz, at the end of March 2007.

Since then, development has been divided into two projects: Compiz, which includes the core functionality and basic plugins, and Compiz Fusion, which includes utilities and more plugins. In theory, the two projects were supposed to merge, but in practice, that has never happened. The projects still maintain separate web sites, mailing lists, and bug trackers, despite the fact that most developers of one project also work on the other.

The community appears to lack both organization and direction, with many developers working on their own branches of Compiz in secret rather than face endless discussion about their goals. Still other developers have drifted away from the project. Under these circumstances, the community has not only been unable to manage a 1.0 release, but, 18 months after the last stable release, is still struggling to complete version 0.8.

More recently, the community has been affected by the withdrawal of Compiz project leader David Reveman. Reveman's departure, apparently made without any official announcement, has led to a lack of leadership, since no experienced Compiz developer appears willing to assume the role of community organizer. Just as importantly, Reveman's refusal to respond to emails after his withdrawal has caused practical difficulties for other developers because much of the Compiz code base is undocumented.

The result is that Compiz, once seen as an exciting, leading-edge project is now being openly denigrated in some circles. For instance, one commenter on a recent Compiz video on YouTube wrote:

Dramatically ugly, unusable, slow, badly animated and unconsistent. Open source development without a serious, expert maintainers can result in chaotic growth of the project and waste of human resources into pointless code. The Compiz-Fusion project is certainly the most representative example of all this.

The situation came to a head in late December when developer Dennis Kasprzyk announced the creation of a new compiz++ code branch. This new branch is written in C++ as opposed to the C programming language of the main branch, and would require numerous changes in the behavior of plugins. A few days later, Kasprzyk's announcement motivated Kristian Lyngstol, another developer, to begin a thread on the Compiz mailing list on "The Future of Compiz." This thread was echoed in an article called "Compiz is dying and we need to fix it" by Kevin Lange. Since then, discussions about the state of Compiz have emerged on numerous other mailing lists, especially those dedicated to specific distributions.

According to Lyngstol, "there has been the equivalent of no progress since the merger. We've basically been in maintenance mode. The reason for this, from my point of view, is a complete lack of direction and leadership."

Lyngstol sees several reasons for the current state of Compiz. To start with, he suggests that project members have been waiting too long for "something that will change everything," and the result has been too many code branches, many of which are incompatible with each other. "The reality is that all these branches are counter-productive, regardless of how fun or flashy they are," Lyngstol writes. He continues:

If we are to have a healthy development environment, and any hope of bringing Compiz out of a constant alpha-stage, we need to have clear development goals and a way to cooperate. Before somebody puts 6+ months of development into their work then present it as a final solution.

Next, Lyngstol notes that the community remains small, with less than 20 people contributing code, if the subscription list for Compiz-Fusion Planet is an indication. In fact, Lyngstol writes, "Unless I'm missing something obvious, we haven't seen a single new core developer that contributes significantly to [the main branch] since the merge. We have, however, lost a few."

Lyngstol goes on to suggest the reasons for the lack of developers. Because the project has no direction, he writes, "all development and design is done as a solo race. There's no way to know whether you can work on something without losing your work because some obscure branch gets merged."

Even worse, the merge of Compiz and Compiz-Fusion that was supposed to happen never has, resulting in a duplication of effort that Lyngstol describes as "messy". Much the same state of chaos exists in the code, which is both "undocumented" and "not particularly pretty". Moreover, when new code is added, its functions "do more than C functions should do". But the basic problem, according to Lyngstol, is that "Compiz is a research project", in a constant state of change and is not focused on producing a stable release.

To solve this situation, Lyngstol suggests a merger of the various code branches — or perhaps, an agreement that some or all are forks — and some serious attention paid to project management. "We should have clear goals for every major release," he writes, "and finding those goals should be the top priority after a stable release. For each point-release in a development series, we should also have a clear goal. This will make it easier to predict releases and for developers to help."

Perhaps the greatest indicator of the state of the Compiz community is not Lyngstol's critique, but the polite agreement with which it has been greeted so far. Perhaps the greatest indicator of the state of the Compiz community is not Lyngstol's critique, but the polite agreement with which it has been greeted so far. To date, those who have responded to Lyngstol's posting have quibbled over the details of some of his points while not seriously contesting his overall observations or his suggested solutions.

Another, more unfortunate indicator is that, while posters have agreed that leadership and direction are needed, so far none of them have come forward to offer it. Instead, Lyngstol and several other active developers have gone out of their way to state that, while they would support change, they were unwilling or unable to take on any leadership role.

So far, no one has suggested possible external reasons for the diminishment of Compiz. But it may be that, now that the novelty of 3-D special effects have worn off, few reasons exist to develop them; the few practical effects, such as zooms, are too slight to encourage the majority to move away from standard 2-D desktops.

Another possible factor is that 3-D video drivers that are both stable and released under a free license are taking longer to arrive than anyone anticipated, and their lack reduced users' interest in projects like Compiz that require them.

Still another suggestion was made in an anonymous comment on Lange's article: Perhaps Compiz has served its purpose by proving that the free desktop could surpass Windows or OS X in eye candy. However, not everyone would agree — developer Quinn Storm, for example, posted a comment to the Compiz mailing list in which she makes clear that she thinks that Compiz has that goal, but has yet to reach it.

Whatever the reasons and whatever happens, one consolation is that, in free and open source software, nothing is really lost. But, as things stand now, with no one willing to assume the leadership of the project, a very strong possibility exists that the the Compiz will continue to diminish, with its members aware of the situation but unable or unwilling to change it.


Index entries for this article
GuestArticlesByfield, Bruce


to post comments

Debates on the future of Compiz

Posted Jan 8, 2009 3:02 UTC (Thu) by filteredperception (guest, #5692) [Link] (4 responses)

I'm the quintessential example of someone who just doesn't care about 3D desktop effects. I've even spent two and a half years working for a GPU startup 10 years ago, and I totally agree with the premise that the GPU should be running the desktop. But until it's 100% rock solid, I truly don't care. I'm here with my 7 virtual desktops hotkey switched with ctrl+up and cntrl+down, and can't imagine why anyone would seriously prefer the added animation delay of watching a cube rotate. Of course, that is just me the esoteric linux using engineer.

I just checked wikipedia which answered my confusion reading the article. I.e. that beryl was part of the merge, and that there doesn't appear to be an alternative... except android. It seems like it will take an OS that needs to fit on a cell phone, to truly dictate that things like zooming windows are absolute requirements. So I think once we see the same OS being used on our cell phones as our workstations, is the day when the motivation will be in place to have a rock solid 3D desktop implementation.

$0.02...

Debates on the future of Compiz

Posted Jan 8, 2009 3:28 UTC (Thu) by pynm0001 (guest, #18379) [Link] (1 responses)

KDE 4's KWin has integrated many of the features from Compiz, and this code
is still being actively worked on and maintained.

http://techbase.kde.org/Projects/KWin/4.0-release-notes#W...

Debates on the future of Compiz

Posted Jan 8, 2009 8:32 UTC (Thu) by aleXXX (subscriber, #2742) [Link]

"this code is still being actively worked on and maintained."

The "still" is not necessary in this sentence :-)
I installed OpenSUSE 11.1 with KDE 4.1 on my notebook and everything just
worked out of the box, including all the 3D effects, completely
integrated with the DE. The effect are not only the desktop cube, but
also translucent windows, e.g. a translucent panel, which does make
sense, grayed out windows if a modal dialog is open (very useful),
overview over all desktops and more.

Alex

Debates on the future of Compiz

Posted Jan 8, 2009 9:45 UTC (Thu) by njs (subscriber, #40338) [Link]

> things like zooming windows are absolute requirements

Unfortunately, real zooming windows as seen in the iPhone aren't hung up on details of Compiz development or GPU drivers, but something worse: an annoying low-level limitation of X's architecture. To get real zooming, you need to munge windows on their way to the display -- that's easy, we have it -- and you also need to munge mouse events on their way back to the window (to rescale the coordinates). This is a big mess, because of the interaction between the compositing manager (who knows how the X events should be munged) and X grabs (which can lock out clients, including the compositing manager, during input handling). Last I checked the X folks have given up on dealing with this for now...

Debates on the future of Compiz

Posted Jan 10, 2009 5:59 UTC (Sat) by lonely_bear (subscriber, #2726) [Link]

I have the same feeling. Most of the "cool" features are just a waste of computing resources and decrease productivity.

Debates on the future of Compiz

Posted Jan 8, 2009 5:36 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

It's hilarious that Compiz still doesn't know how to resize windows. Didn't dragging the outline of a window go away in the mid-90s. (yes, I know that there are esoteric ways of fixing this on some machines but enabled by default)

It also consistently fouls up video playback, even on Intrepid and Fedora 10.

I guess the one good thing about Compiz is how easy it is to turn off.

Debates on the future of Compiz

Posted Jan 8, 2009 7:36 UTC (Thu) by tajyrink (subscriber, #2750) [Link] (2 responses)

The video playback problem is one clear thing that is not a problem of compiz, but the video drivers. For intel, all the quirks of it should be fixed with 2.5 series of drivers, ie. Fedora 10 should work unless they have forced Xv overlay output. For ATI with open drivers it should work. ATI closed source drivers are broken (or at least have been), again a driver problem.

Debates on the future of Compiz

Posted Jan 8, 2009 15:27 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link] (1 responses)

No, DRI2 solves this problem which is not the same as the 2.5 branch. You need Mesa 7.2, Xorg 1.6.99.x and a suitable DRI2-capable video driver. Incidentally, it also fixes video and OpenGL app. rendering on Metacity Xrender and Mutter and KWin4.

With DRI2, rendering contexts just work the way you'd expect.

Debates on the future of Compiz

Posted Jan 9, 2009 16:50 UTC (Fri) by daenzer (subscriber, #7050) [Link]

DRI2 is not a requirement for properly integrating XVideo with a compositing manager. The driver just needs to provide a textured XVideo adaptor for that (and the video player application needs to use that, obviously :).

DRI2 is indeed a requirement for properly integrating accelerated client OpenGL rendering output with a compositing manager though.

Debates on the future of Compiz

Posted Jan 9, 2009 16:55 UTC (Fri) by daenzer (subscriber, #7050) [Link] (1 responses)

> It's hilarious that Compiz still doesn't know how to resize windows.
> Didn't dragging the outline of a window go away in the mid-90s. (yes, I
> know that there are esoteric ways of fixing this on some machines but
> enabled by default)

Can you elaborate? If you're referring to the old-school rubberband effect, that certainly isn't the only option, and I don't think it was enabled by default for me either. Maybe you're actually seeing a distribution default configuration issue?

FWIW I'm enjoying smooth and quite snappy opaque window resizing with compiz.

Debates on the future of Compiz

Posted Jan 17, 2009 19:48 UTC (Sat) by bronson (subscriber, #4806) [Link]

I guess I'm falling behind the times. While the latest Ubuntu still does the rubber band effect (!), Fedora 10 appears to do a proper resize. Excellent! It appears that this will not be a problem for much longer.

Debates on the future of Compiz

Posted Jan 8, 2009 10:08 UTC (Thu) by jpetso (subscriber, #36230) [Link]

Er, wow. I always have known that I personally will prefer KWin over Compiz
anytime, but I had no idea that Compiz faces such a desperate situation.
LWN coverage ftw!

Debates on the future of Compiz

Posted Jan 8, 2009 15:23 UTC (Thu) by marduk (subscriber, #3831) [Link]

I think Compiz has reached a state where it has accomplished the needs of the everyday user. I don't think most users are interested in most of the eye-candy stuff that Compiz delivers. They make great Youtube videos but are mostly impractical. I use compiz, but with a minimal setup. I do use translucent borders, drop shadows and a few of the animations (mostly just fade). I'm a GNOME user and I have to admit the main reason I don't use Metacity is because I want new windows to appear in the center of the screen (not the top left corner) and there is no option to do that with Metacity. If/when Metacity chooses to implement that option then I would consider switching to metacity with compositing enabled. Until then Compiz with minimal effects works just nicely.

WM vs. Library

Posted Jan 8, 2009 16:23 UTC (Thu) by mrfredsmoothie (guest, #3100) [Link] (3 responses)

I've never understood why people were working on a "compositing window manager" vs. a compositing library which could be used by any window manager.

I like eye candy, but not enough to make it be the primary criteria by which I select a window manager.

WM vs. Library

Posted Jan 10, 2009 0:20 UTC (Sat) by Tet (guest, #5433) [Link] (2 responses)

Hmmm. I was just about to post about my lack of understanding of the need for Compiz, when what we really need is libcomposite.so and for other window managers to make use of it. But I see you've already done that for me :-) It's been a long time annoyance for me.

WM vs. Library

Posted Jan 10, 2009 15:24 UTC (Sat) by kirkengaard (guest, #15022) [Link] (1 responses)

And, in this age of desktop environments, how valuable is the WM paradigm, anyways? I realize that Gnome uses several as options, but even they have trimmed down (consistent with their philosophy). A decade ago, when even KDE was still a desktop environment that used window managers, compiz made sense, but it's increasingly a bolt-on in a built-in world. Making it a library might see its demise come sooner, but it also stands a chance of bringing the benefit compiz actually has to all sorts of desktop environments through compiled-in support for 3d effects in the DE itself.

Except for the fact that KDE has gone the built-in-effects-library route for themselves, in a big and usable KDE-internal way, and lobbying freedesktop.org to make it a standard library will just make it a Gnome compile necessity, something Gnome is just *begging* for more of.

(Cue flames from the remaining FVWM users out there... :) )

The free software ecosystem is like any other evolutionary environment, in that it pursues all branches into all niches, and lets the environmental and competitive constraints do the pruning. We've seen it before, and we'll see it again. A project's value proposition is a description of the niche value, not the value of the specific code that occupies it. Competition is for niche occupancy, and maybe the niche is taken, in which case the survival option is to evolve to a niche that is more available.

WM vs. Library

Posted Jan 10, 2009 15:50 UTC (Sat) by Tet (guest, #5433) [Link]

And, in this age of desktop environments, how valuable is the WM paradigm, anyways?

For me, it's essential. Whether people realise it or not, they're still using a window manager, even if they're using GNOME or KDE. And having a capable window manager makes the user much more productive. Perhaps that's why I'm one of those remaining FVWM users you mentioned...

Debates on the future of Compiz

Posted Jan 15, 2009 14:23 UTC (Thu) by Luyseyal (guest, #15693) [Link]

What this project needs is a big ass kicking by Keith Packard. :)


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds