compiz - Dec 2008 - [Annoucement] Compiz feature branch compiz++

Hi,

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

- 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 the
kde4-window-decorator)

- 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
systems.
-- Containers avoid the implementation of lists and resizeable arrays over and
over again.
-- Containers like maps and other smart classes can improve performance in
several areas.
-- ...

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.

Merry Christmas
Dennis Kasprzyk

* 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
supported)