What are the plans (if any) for compiz-fusion? Stewart On Mon, 2007-08-13 at 16:30 -0400, Kristian Høgsberg wrote: > Hi, > > 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 > tools. > > 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? > > No. > > Kristian > > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
