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

[Denis F. Latypoff]

Hello Kristian,

Thursday, March 29, 2007, 12:11:41 AM, you 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.

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


I'm a regular user and I do not need the second vista like beryl. I
tried both beryl and compiz from latest git and svn: compiz is really
much faster than beryl in the same configuration and plugins set. I
have too old video card (mobility radeon 7500) and compiz proved that
my card can be used more efficiently, beryl did not, beryl says me:
hey man, buy new laptop with the video monster ;)

Compiz source code is beautiful, I will be very glad if there is new
general option in the gnu indent: -compiz ;) I will immediately apply
indent -compiz to the all my code. I am viewing community patches to
the compiz and wondering: is it difficult to follow compiz code style
rules? Respect David, he is wonderful hacker. He tries to make your lifes
easier offering such perfect code.

Do not merge monster with garbage.
Compiz, stay clean.



-- 
Best regards,
 Denis Latypoff                          mailto:latypoff at yandex.ru