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

[David Reveman]

On Wed, 2007-03-28 at 19:11 +0200, Kristian Lyngstøl wrote:
> 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.

Don't worry, as long as we're open to other peoples opinions and
interested in solving problems by finding solutions that we can agree
upon, this shouldn't be a problem.

> 
> > 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.

With some small changes to the core, we could probably make it possible
to implement this in a plugin.

SLED and even though I haven't tested myself, I'm pretty sure there are
some other distributions out there that allow compiz to run out of the
box. It's just a matter of what hardware it's limited to.

- David