[compiz] [Annoucement] Compiz feature branch compiz++

[Dennis Kasprzyk]

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)