[compiz] Beryl and Compiz Merge: What's actually going on?

[Kristian Lyngstøl]

On 3/28/07, David Reveman <davidr at novell.com> wrote:
> I think you're making this into a bigger thing than what it is. Lets
> focus on solving the technical part first, most importantly move to
> having one core. I'm only talking about the code that's currently built
> into the compiz binary, none of the plugins. Merging plugin code is not
> nearly as important as the move to having one core.

Specially since most of the plugins are more or less the same anyway.
I would consider it mostly a non-issue. There are obviously some
differences, but those shouldn't really be that hard to figure out on
a plugin by plugin basis when the core is merged.

> We're not very far away from having one core as I understand. There's
> clearly not 3 times as much code in beryl core as in compiz core, you
> must be talking about plugins here. The differences that been brought up
> to me have all been minor changes that I don't see any reason why they
> can't be resolved.

I couldn't really get those numbers to add up either, all I can
imagine is indentation differences? Unless libberylsettings is 50k LOC
or something else equally crazy.
As far as I can remember off the bat, there is the recently added
beryl logger code, which is quite small, the paint attribute locking
mechanism, some multihead changes, copy rendering, some differences in
settings, and maybe some other things I've forgotten, but nothing that
would double the amount of code.

> The merge is done by moving changes made to beryl into compiz or by
> adding alternative solutions to compiz. No changes are made to the
> design of compiz and 99% of the code is still code being written as part
> of the compiz project so I'm having a hard time to justify a name change
> of the core and I know that most people in the compiz community are
> firmly against such a name change. A more plugin oriented side-project
> under a new name could make sense, though. Like what compiz-extra is
> supposed to be but my opinion is not as important here as I'm not as
> involved in that part.

Personally, I would prefer a name change for the sake of the community
(People are sheep, if they see Beryl disappear and the compiz-name
remain... well, you get the point), but it isn't an agenda I'm going
to push. A name for the whole package might be an idea. I know this
will never be a DE, so don't take this the wrong way, but much like
how GNOME has Metacity... Or Debian has Linux at the core, for that
matter. While you would generally never use Debian without Linux (IE:
Plugins without Compiz), it's possible in theory. I guess that sort of
separation is what you were aiming for in the first place?

> Regarding leadership, having anything but a technical leadership of the
> core where the people who write the code and the people with most
> knowledge gets to decide is silly to me. Community leadership, who's in
> charge of the web site and such is a different thing and maybe a bit
> harder to solve but I'm sure it can be worked out in time.

I think there's a common misunderstanding here. I don't think anyone
really wants a person who doesn't contribute a significant amount of
code to lead the project. But at the same time, we're (at least I am)
a bit afraid of letting a single person have veto-powers. An informal
understanding that the lead developer could be overruled if there is a
large majority of other developers who disagree with him is most
likely what we're after. Again, those people would have to actually
work on the core actively, and there shouldn't be a need for a too
strict set of rules here. If you say you're OK with this general
concept, that's fine by me.

> The technical part of the merge seems pretty straight forward from my
> point of view and I've got the understanding that so is also the case
> for the main contributors to the core of beryl.

Yeah, mostly.

There is one issue I'm a bit concerned about myself though, and that's
the infamous copy rendering.

I know it's "broken by design", but the number of times this has come
in handy for users is hard to count. While there are often ways around
it, most users aren't concerned about the extra resource usage this
introduces if it "just works" until their driver is fixed (for
instance), and gets them out of several hours of trying to find the
proper solution.

If we could find a way of keeping it without reducing the quality of
the code when it's not being used, that would be something I think our
users would appreciate. Maybe a build time option, if it's practical?
I don't know the details of the implementation in Beryl beyond what
I've seen in the damaging code and partly the texture code, but it
seems to me that it wouldn't be too hard to leave it in without
reducing the overall quality.

The way I see it, the biggest problem with both Beryl and Compiz from
a users point of view is the hassle of getting it to work. The
situation with drivers and possibly the need for Xgl, combined with
the amount of different terms and technologies seems to be the major
reason why users hesitate to start using Compiz/Beryl, and I believe
copy rendering has helped improve this, even if it is not the ideal
solution. It will be quite a while before you can "just install"
Compiz/Beryl and  have it work out of the box, but having copy
rendering until that time doesn't strike me as a bad idea.

> - David

-- 
Kristian Lyngstøl