[compiz] update on xdevconf07 and beryl situation

[David Reveman]

I'd like to get all of you updated on the compiz related things
discussed at the X developer conference that was held last week.

The slides I used for my talk are available from here:

http://people.freedesktop.org/~davidr/xdevconf07/

and you can also find some notes from all talks here:

http://wiki.x.org/wiki/XDC2007Notes

My talk was mainly focused on "what's next" and how to get desktop
compositing in X to the next level. Here are the main topics that I
touched during my talk.

Software cursor
Video interface
Drawing synchronization
Input transformations
Retained drawing interface

There's of course a lot more to be done but these things are what's
currently at the top of my TODO list and to some degree affect the X.org
community.

Here's some notes about the current status of these things:

Software cursor - Mostly done, some minor work left. I'll post patches
to the xorg list and update compiz sometime soon. This will allow us to
apply effects to the cursor and always be able to provide a flicker-free
cursor independent of the graphics hardware used.

Video interface - Getting a simple prototype of this working is not
going to be very hard, the fragment attribute interface we have in the
core now will allow us to integrate this properly. This will improve
video playback performance significantly as well as reduce resources
currently used for XVideo extension to work on a composited desktop.

Drawing synchronization - GLX_EXT_tfp doesn't provide any application
drawing synchronization mechanism. This was left outside the spec to be
either done at the client level or as an additional extension to the
server. There's already ways to synchronization mapping and resizing of
windows on the client side and compiz supports that already. I believe
that Søren Sandmann have done some work in gtk for more general drawing
synchronization and we should add support for that in compiz and try to
push this to other toolkits as well. This kind of drawing
synchronization will improve client drawing performance a bit but more
importantly provide a much more polished desktop where application
drawing is properly synchronized with desktop compositing. A server-side
mechanism for this might also be interesting for legacy application
support but I think we should get the client-side solution in place
first.

Input transformations - This is currently holding back a lot things that
we want to do. I've started implementing this in the X server and I'm
convinced that I'll be able to complete that very soon. I did some quick
hacks to the scale and zoom plugins at xdevconf to demo this a bit and
proper adjustments to the core will be made which allow plugins to fully
utilize this. This together with support for xrandr 1.2 will be a major
leap forward.

Retained drawing interface - We're adding interfaces that provide a
limited way for applications to use compiz for retained drawing. E.g.
the decorator interface, the thumbnail interface that we discussed on
the list earlier and the video playback interface mentioned above. I'd
like to unite all these interfaces into a more general extensible
interface. It will make the existing interfaces better defined and allow
us to experiment with retained drawing using the existing plugin
architecture, which I think is a good idea.


There were some other topics at xdevconf that also relate to compiz. 

Xrandr 1.2 - We should make compiz support this perfectly asap. This
together with input transformations will make it possible to finally get
multi-head to work the way it's suppose to.

XCB - This has always been something that I've planned to use in compiz
and now seems like a good time to start moving over to using XCB. There
are a lot of cases where we currently do round trips to the server and
block for replies. XCB allows us to potentially eliminate all such
blocking which will improve window management response time and it will
likely also affect rendering. Window property handling is the first
thing that should be redesigned to use XCB. A good window property
handling interface has never been written for compiz. Mostly because we
didn't want to do it twice and XCB is the way to do it properly. Getting
this done will be a major improvement.


Beryl situation

(My comments about beryl below are related to the fork of compiz core
and other compiz components that have also been forked. I have no
problem whatsoever with anything else that they work on, like new
plugins, decorators and configuration utilities. After all, I created
the plugin architecture so that this kind of experimenting could be
done.)

I had the chance to talk to Quinn Storm from the beryl project during
xdevconf. I would have hoped that the current situation with beryl could
be improved but it seems like Quinn at least isn't interested in that.
However, after talking to Quinn it's very clear to me that the fork was
partially motivated by assumptions that were wrong. 

One assumption is that compiz is some kind of Novell controlled project
that Novell will move in whatever direction it wants. This is completely
wrong. I started the project and no one at Novell has ever told me in
which direction it should go.

Another assumption is that I'm not willing to go in whatever direction
users and developers want. This is not true either. I listen to what
people want and make sure that the wishes of our complete user base is
reflected properly. Usability tests have been used to better know what
the less technical users want, which I believe is important and we'll
keep doing that.

So are there any good reasons for the fork? I believe not, but a lot of
people working on beryl would of course disagree. There are two
differences between compiz and beryl, though. To Quinn (I don't know
about other beryl people as I've only spoken to Quinn) these differences
are important enough for the fork to exist.

1. Temporary solutions and workarounds.

Beryl includes temporary solutions and workarounds that paper over
issues in the overall infrastructure. I've been very unwilling to
include such things in compiz as I believe that it hurts the open source
desktop as it hides the real issues and I don't want to do that for my
own projects benefit. Helping other projects by fixing issues where they
should be fixed is how we make the open source desktop unbeatable.
Temporary solutions can be maintained outside the official tree or in
branches for those who need them.

2. License.

compiz core is MIT licensed. I used the MIT license in compiz for two
reasons. When moving to a composited desktop, we're moving more and more
of the X server (which is MIT licensed) functionality into the
compositing manager and I want to make sure that this new composited
desktop that we're creating can be deployed anywhere a regular
non-composited X desktop is used today. I also believe that we're
currently at a stage where a lot of experimenting is being done and it's
impossible to know exactly where we're going to end up so using a less
restrictive license leaves more doors open and we're better prepared for
the unknown. Quinn, obviously don't share these opinions and using a
core that is MIT licensed seem impossible to him. I'm a bit skeptical to
to this though as they haven't made any significant improvements to the
core since they forked it (at least nothing near what's been done in
compiz since then) and they are OK with using MIT licensed X server, X
libraries, loading proprietary binary blobs that some call illegal into
the kernel and putting themselves in a situation where they feed on a
project which they can't easily contribute back to. But yet again, I've
only spoken to Quinn and I doubt that all people involved with beryl
share his opinions.

Some people would probably say that another reason is that the people
that work on beryl plan to do major changes that they don't think I
would be willing to accept. I find this ridiculous. I'm willing to
accept any changes as long as they are good but as long as they haven't
written the code or tried to get it accepted this isn't even an
argument.

So how does this affect us? I know that the temporary solutions and
workarounds that beryl includes might to some users give the impression
that beryl "works better". That they've also focused on implementing new
effects and taking the existing once even further have meant that
they've gotten a lot of attention recently, while we've been working
really hard here on compiz to get the difficult pieces together so we
can move to the next level. I know that some people are concerned by
this and the fact that they are forking everything we do without giving
anything back but there's nothing to worry about, people will sooner or
later understand where the real work is being done. I can admit that
it's a bit annoying to me too as we could be moving faster forward if
people were just a bit more interested in working together instead of
against each other.

I'm sure that there's people involved in the beryl project that will
sooner or later realize that they've made a mistake and like to work
together instead. I would never treat anyone doing so with less respect
and I suggest that everyone else working on compiz do the same.

We're currently working on writing up some project goals for compiz and
we're hoping that this will make it more clear to people where we're
heading. This as well as a more complete road-map will be sent the the
list for discussion sometime soon. I know that beryl got a lot of people
involved by accepting patches without asking a lot of questions about
the code. I'm not going to start doing this :) but I'd like to see more
people get involved and I'm going put aside some of the time I usually
spend on writing code and instead guide and help people learn how to
solve problems properly.

Thanks everyone,

- David