Infos at: http://lists.compiz-fusion.org/pipermail/dev/2008-December/001127.html

Merry Christmas

To thank Mark Shuttleworth for the invitation to UDS in Prague, I’ve asked him what he would like to see in Compiz. He send me a mockup of a new switcher plugin based on the idea of Matthew Thomas. And here is my implementation of it as Compiz plugin called stackswitch.

You can download it from Compiz Fusion git:
git clone git://anongit.compiz-fusion.org/fusion/plugins/stackswitch

I’ve merged cubecaps into cubeaddon, to be able to transform the cube caps. With this functionality I was able to create a full sphere deformation of the cube. I’ve also fixed the rotate plugin to report proper progress for the inside cube mode to allow deformation in “inside cube”.

A lot of people asked for a sphere deformation of the cube. I can’t realize a full sphere, due to limitations how the cube caps are painted, but maybe I will find a solution for this in a FAR future. I’ve also haven’t found a better name, so that the new deformation is called “Sphere like”.

As we have to do most of the transformation on the CPU, it should be clear that these effects have a heavy impact on the FPS and CPU load.

After a lot of preparations in the last weeks, that resulted also in the “curve” expo mode, I’ve finally finished my idea to implement a cylinder deformation for the cube plugin. The code is in the cubeaddon plugin, that is the cubereflex plugin with this new feature.

I’ve committed the first version of a generic Compiz plugin CMake macro into the universal Makefile repository. This macro makes it really easy to write CMakeLists.txt files to build a plugin with CMake. The macro implements the same functionality that is currently implemented in the universal Makefile and the code that is needed in the CMakeLists.txt file is as simple as the code of the plugin.info file.

With CMake we get various benefits compared to the universal Makefile:

• Out of tree build support to keep the checkout clean
• Combine the build of multiple plugins into one big build (much faster than using yags/Makefile)
• It doesn’t use libtool. This makes the build faster
• Multi core compiling (something that is pretty broken with yags/Makefile)
• …

We also consider to switch the build system of our merged plugin repositories to CMake. Guillaume (iXce) has already created a test CMake build system in the plugins-main repository. We will keep both build systems in the repository, until we are sure that CMake provides everything we need. Maybe we will also switch to use the generic CMake macro in the merged repositories, but this would definitely kill the autoconf/automake build system because of the needed change of the structures in the repository. Something like this won’t happen before 0.8.0 is released.

Why CMake?
Because it’s easy. You can learn to create a complex and individual build system in hours with CMake, instead of days (years) with autoconf/automake.

Compiz 0.7.4 is out and it contains improved shaders in the blur plugin. I’ve made changes to the gaussian blur shader, so that it should work on more cards. The blur plugin will work on a lot of radeon/intel cards once support for framebuffer objects and accelerated glCopySubTexImage is implemented in the drivers.

I will not commit (or publish) my patch that replaces the framebuffer object code with glCopySubTexImage, because it results in a very bad performance due to the slow copy operation (5 fps with an intel i915). The drivers will get accelerated glCopySubTexImage and frambuffer objects at the same time, because both need the same changes to the texture management.

Only fglrx users can currently benefit from the changes. They should see a nice performance boost if the new “Independent texture fetch” option is enabled.