Compiz and Fedora
s.adam at diffingo.com
Mon Aug 13 22:44:00 UTC 2007
What are the plans (if any) for compiz-fusion?
On Mon, 2007-08-13 at 16:30 -0400, Kristian Høgsberg wrote:
> I read through the entire "Enabling Compiz by default" thread and
> decided to send out a braindump/status/roadmap type of writeup, to
> explain what we're doing in this area and where we'd like to go:
> 1) We are working towards being able to enable a compositor by default.
> Redirected direct rendering, Xv, Java problems, these are
> problems in the drivers and X server and affects all
> compositors. To get this done, we need to land a big chunk of
> code in the kernel (the DRM memory manager), we need to update
> the X server, the 2D drivers and the 3D drivers to take
> advantage of the new memory manager. We need to fix Xv.
> Hopefully the OpenGL support will broaden to support more
> chipsets (nouveaou, avivo). Getting all this to a shippable
> state may take years, and in the mean time, the composited
> desktop, whether it's compiz, kwin4 or something else will only
> be an opt-in tech demo.
> 2) Once we get there, the default compositor will be compiz.
> Some people can't get over on the wobbly windows and spinning
> cube, and claim it's over the top or apparently get nauseous.
> At the core, compiz is just a very efficient OpenGL redraw loop
> with a flexible plugin architecture. Compiz allows burning
> windows and spinning cubes, but we ship it in a very toned down
> default configuration that looks a lot like good old metacity.
> Consider xeyes; like wobbly windows, it's a neat tech demo and
> shows off the flexibility of X, but just because nobody runs
> xeyes for more that 2 minutes at a time that doesn't mean that X
> (or shaped windows) isn't useful.
> A valid point about compiz is that it is not yet a great window
> manager. Metacity has a few years of head start there, but that
> doesn't mean that we can't fix compiz or that it'll be
> duplicated effort. For now, our efforts have gone towards
> fixing the big underlying shortcomings in the X and OpenGL
> stack, which has left compiz with a set of minor (but certainly
> annoying) windows manager bugs.
> Other spins (Fedora KDE or Fedora XFCE) can set up different
> default compositing managers, and they will of course benefit
> from the infrastructure work mentioned in 1).
> 3) Metacity as a compositing manager.
> We tried it and decided that the metacity code base was not a
> welcoming place for a compositor. When we put down the work in
> metacity, the conclusion was to leave this very stable and well
> tested code base alone instead of injecting an OpenGL based
> compositor. The flip side of this decision is that we can now
> do a clean break in compiz and assume throughout the code that
> we're an OpenGL based combined compositing and window manager.
> 4) Compiz configuration tools
> desktop-effects is close to what we should ship by default,
> perhaps we want to fold it into the new
> gnome-appearance-properties capplet as a new tab. At the same
> time, we want to allow installation of other compiz
> configuration managers for people who like the tweak-ui kind-of
> 4) Power consumption and other hand-wavey fud arguments.
> Clearly running a 3D screen saver at the full frame rate is
> going to burn more battery than the blank screen saver, but
> that's not really relevant here. When idling, compiz and
> metacity use exactly the same amount of power. There are no
> code paths anywhere in the stack that "turn on 3d powerplanes".
> My bet is that it's more power consuming to wake up all
> applications to redraw their exposed areas under the window
> you're dragging than it is for compiz to just recomposite that
> out of textures already in video memory.
> 5) If you don't know what you're talking about, will being excessively
> dismissive and assertive make you right?
More information about the fedora-devel-list