[FusionDev] [ANNOUNCE] 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)