I contemplated porting compiz wobbly plugin to a wayland compositor for some time now. I decided to break the problem down and familiarize myself with the code better by implementing the wobbly model outside of compiz.

For those that don’t know, wobbly is a piece of code that allows windows on your desktop to wobble, namely when they’re dragged or moved. In a GL compositor, windows are surfaces that consist of a series of points. Each point is called a vertex. The image of the surface is stretched across these points in a process called texture mapping. The vertex computation algorithms are responsible for the final on-screen position of the vertices and the result of rendered objects. This part of the code is where the wobbly magic happens.

I had several ideas on how to go about attempting to port more compiz functionality to a wayland compositor. There are two main functional parts of a compositing system:

– The underlying windowing system

– The renderer that composites the data

In the case of compiz, this is X and GL respectively. The X component is what we need to remove. In order to port the interesting compiz functionality to a wayland compositor, it is reasonable to write it from scratch without reference to the compiz code at all. This was the case with zoom in weston, where I implemented a stripped down version after doing the required matrix math.

There are some plugins that are more dependent on X than others, namely (and not surprisingly), the Window Management plugins.
The plugins that provide more bling than functionality are sometimes easier to port because it’s more GL and less X.

One idea I came up with was to create a program that demos some of the effects by implementing a fake desktop with fake windows, excluding any platform-specific code. I decided to dissect the wobbly window plugin and learned many interesting things. I grabbed a copy of es2tri.c from mesa demos and begin hacking it together.

The first thing I noticed is that wobbly renders using GL_QUADS. This means that the index assignment must be changed since we’re using GL_TRIANGLES. I managed to compare the values of the vertices from my wobbly code to the real thing and debug the position calculations before writing the code to actually draw them. Indeed, the vertices were correct but the indices were not. After fixing everything up, we have a wobbly surface using mouse click-n-drag events as input.

Ok, so the demo is rendering to an X window which means it’s still hooked to X but only for input and output. It should be relatively simple to port it to other platforms with EGL support. You can find the code here.