[compiz] [ANNOUNCE] Compiz feature branch compiz++
onestone at compiz-fusion.org
Wed Dec 24 04:48:17 PST 2008
I've currently pushed a new branch called "compiz++" to the freedesktop
repository, with some features I've been working on during last months.
Because most of the features also require (BIG) changes to the plugins, I've
decided to put them all together.
- No direct access to member variables: Everything is now done with getter and
setter functions. This helps with the problem where every variable addition
broke the plugin ABI. While this usually is not a problem in the development
tree, we can not do it in a stable tree. Even if it is needed to fix a bug.
It also gives us more control what other plugins can do, so that broken
plugins can not mess up our core structures.
- Composite/OpenGL seperation: All XComposite handling is moved into the
composite plugin and the opengl rendering into the opengl plugin. This allows
compiz to run also as normal window manager without compositing (still needs
some work and a few new plugins), but also the creation of other rendering
backends (XRender, clutter, ...).
- Tiled textures: Modifications to the texture system allow to have more than
one texture per pixmap and also to have other plugins that provide texture
from pixmap functionality. The new copytex uses the (slow) "copy pixmap
content to texture" approach to provide texture from pixmap functionality.
It's main advantage is that it supports pixmaps bigger than the maximum
texture size. In this cases a pixmap is split into multiple textures. Compiz
will use the glx texture-from-pixmap extension for pixmaps/windows but will
fall back to the copytex plugin if thex are bigger than the maximum texture
- Reparented decorations: Like other window managers, compiz now supports
reparented window decorations. This will allow compiz to run as a normal
window manager and to be able to have decorations for windows that are bigger
than the maximum texture size (copytex plugin). (Currently only implemented in
- Dropped multi display and multi screen support *: The multi display support
is not completed, and the multi screen support is almost unmaintainded.
Additionally, our normal proposal for bugs in the multi screen support is to
start one compiz instance per screen. Dropping multi-screen support has the
additional benifits of:
-- Per screen plugin lists (e.g. cube on one screen and wall on the other)
-- Rendering of one screen can not block the rendering of the other screen
-- Different libGL per screen (with LD_PRELOAD)
-- Simplier plugins
-- Simplier option handling
- New plugin interface: The compiz WRAP/UNWRAP interface is perhaps the most
efficient system to create a plugin funcion "call chain", but it is not the
the best for compiz. In compiz we have a lot of plugins loaded that hook into
the drawing functions, but do nothing most of the time. Only when activated
(keybinding/dbus/event) do they usually draw something. The end result is that
most functions get called, then the plugin checks if it is active. The plugin
then calls the function of the next plugin in the call chain. The following
plugin repeats the cycle. I've measured that we are loosing 8 - 15 % of CPU
time here. The new system allows plugins to dynamically disable "wrapped"
functions if they are not needed. The core then only needs to check some
boolean variables, and will only call the functions that are really in use.
I've kept the word "wrapping" in the system so that every compiz developer
knows what it does, even if it does not fit the new system well.
- CMake build system: Everyone is happy if the build system (autotools) works,
but starts to cry if it doesn't. At least that is my impression after more
than 2 years of compiz development. In compiz fusion we have already decided
to switch to cmake after the next stable release (0.8), and we also provided
cmake tarballs for a while. CMake provides a real great documentation, and in
my opinion it is much easier than autotools.
- Port to C++: With C we have to write almost the same code in each plugin and
run into the same bugs over and over again. A lot of this can be avoided with
C++. C++ allows us also to do more and this in a easier way:
-- Smarter function callbacks with Boost (boost::function/boost::bind)
-- Easier and smarter privates system (get the plugin struct for a given core
struct/old FOO_SCREEN (s), FOO_WINDOW (w) macros). The new system hides most
of the ugly handling from a plugin developer and provides a new simple and ABI
safe way to work with plugin plugins (plugins that expose
features/functionality to other plugins)
-- Constructors/Destructors allow easier initialisation/cleanup for a lot of
-- Containers avoid the implementation of lists and resizeable arrays over and
-- Containers like maps and other smart classes can improve performance in
This branch is my proposal for a possible compiz future. The decision to make
this the future of compiz is something that everyone involved in compiz should
make. Espesially because it would need a huge amount of work to get all
plugins ported. In my opinion, it would be better to stay with the old system
if such change would create a fork again.
I've also pushed compiz++ branches into the libcompizconfig, bcop and
crashhandler repositories. They contain some initial work for the compiz++
branch. The crashhandler branch also contains a modified (not finished)
version of the universal Makefile.
* multi display: Connect to multiple x servers
multi screen: seperated screens (usually different graphic cards) not
connected with xinerama
multi head: multiple monitors in a xinerama/randr 1.2 configuration (still
More information about the compiz