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

Glad to hear it, that's enough for me for the time being.

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

Good, sounds like the right way of doing it. Would there really be
anything but bindToTexture that would need to be wrappable to achieve
this? Considering the plugins see the damage events already.

-- 
Regards
Kristian Lyngstøl