Compiz

Compiz Release Announcement – 0.8.10

40 Comments

It took a bit of setup and cook time but compiz 0.8.10 tarballs are ready now including addons-experimental plugin package. Anyone who has installed compiz before knows it can be confusing so here, I will focus on installing 0.8.10 using the tarballs.

Step 1)  –  Install Xubuntu 14.10 or your variant of *buntu based Linux distribution with sudo installed.

Step 2)  –  Open a terminal

Step 3)  –  Install git

$ sudo apt-get install git

Step 4)  –  Download the build scripts with

$ git clone git://northfield.ws/compiz/scripts -b release-0.8.10

Step 5)  –  Run the INSTALL script

$ ./scripts/INSTALL

terminal

Step 6)  –  Start ccsm by typing ccsm in the terminal and verify it runs

$ ccsm

Step 7)  –  Enable basic plugins such as Window Decoration, Move Window, Place Window, Resize Window and maybe Wobbly so you know it’s working

Step 8)  –  Start compiz with

$ compiz –replace ccp

Step 9)  –  Open another terminal

Step 10)  –  Start a compiz window decorator

$ emerald –replace

If everything is working, then congratulations! You can add ’emerald’ (without quotes) to ccsm>Effects>Window Decoration>Command field so emerald starts when compiz does.  If not, you can ask in #compiz or #northfield on irc.freenode.net using your IRC client or visit wiki.compiz.org. Enjoy!

AUDIENCE: This information is targeted toward those familiar with Linux distributions and GNU open source software.

INFORMATION: The compiled runtime executable files and libraries will be installed to /usr/ and icons for ccsm can be found in /usr/share/ccsm/icons/hicolor/scalable/. Emerald includes emerald-theme-manager which can be run from a terminal. To remove, run ‘make uninstall’ in each of the source directories in ~/src/compiz/.

WARNING: This software and other 0.8.x versions may conflict with any 0.9.x compiz, ccsm, emerald or other compiz 0.9.x components.

DISCLAIMER: Not responsible for soggy corn flakes, mistreated kittens or spontaneously combusting laptops.

Compiz

Compiz Maintenance

8 Comments

Hello again. It’s been awhile and now it’s time for another blog post. Included are the details of a compiz maintenance routine outline and release schedule preview.

For those that do not keep track, here is a general overview. My name is Scott Moreau and I’ve been working on compiz for about 8 years by wearing the hats of support, script writer, code contributer and now, maintainer. Over time, many left the project entirely. In the past 4 years, I have been maintaining the official upstream compiz with the assistance of long time server maintainer, Guillaume Seguin. Fortunately, it hasn’t been too much work and graphics drivers have improved greatly thanks to companies like Intel, AMD, RedHat, Novell, Canonical, Collabora, Mozilla, Google, Valve and the many interesting people they’ve employed. Without further ado, here is the general road map outline as it stands currently:

1) Take a snapshot of the preserved original C implementation  of all compiz components (currently 0.8.9) including patches we’ve tossed in to keep things going, and make a release dubbed 0.8.10.

2) Test thoroughly

2b) Bump version to 0.8.11

3) Work out obvious, easily fixable problems and consider small improvements, with a strong focus on defaults.

4) Make an eventual 0.8.12 release, when it’s ready.

5) …

 

I am working on plugins-experimental, a collection of plugins that never really saw the light of day. Not only are these great plugins, but I would like to present this as a celebration of their works and contributions to compiz development throughout the years.

Finally, I would like to thank all of the contributers, developers and testers alike, especially those that have worked hard to improve open source software we cherish today and will continue to use for many years to come. Here is a list of talented individuals, sorry if I’m forgetting anyone.

Sam Lantinga

Ryan Gordon

Richard Goedeken

David Reveman

Pierre Bourdon

Dennis Kasprzyk

Danny Baumann

Guillaume Seguin

Sam Spilsbury

David Richards

Kristian Hoegsberg

Pekka Paalanen

Kristian Lyngstøl

Dave Airlie

All the testers and users worldwide…

Wayland

Wayland Wobbly Whistles

1 Comment

I found some time and inspiration to resume working toward wobbly wayland surfaces. After making decent progress, it’s time for another blog entry.

Effects such as wobbly windows are argued by some to be a blatant waste of time for both developers and users. However, many still enjoy wobbling their windows despite the controversy. Some power users claim that the mindless wobbling is a welcome brain rest during other tasks. Critics aside, the effect continues to live on in different forms and implementations.

In this iteration, I decided to port the original compiz plugin to wayland surfaces. First, I isolated the code to identify the algorithm inputs and bound the output to a more easily portable format. Then I worked on massaging it into the compositor code, creating a rudimentary plugin API. In the process, the zoom code was also isolated in it’s own plugin. For the moment, plugins aren’t loaded automatically and must be specified in the config file.

Surprisingly, the model positioning code is the most complicated issue because the plugin must render such that the surface position is synced with the compositor when the wobbling cycles are complete. One annoying positioning problem was related to a combination of rotating and resizing but I managed to track down the core issue and fix this case.

The way opaque and blend regions are handled requires duplicate rendering; one with the opaque rbgx shader and another pass for blended rgba. Since wobbly requires additional arbitrary vertices, it’s not really feasible to draw two different regions. For now, it uses the usual rgba shader if the blend region is not empty and the rgbx shader otherwise.

Further plans include writing an interface to talk to the compositor from a GUI and more compiz-like plugins. Check back later for more updates.

Random

Wobbly Standalone GLES2

Leave a comment

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.

wobbly-shot-2

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.

wobbly-shot-1

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.

 

wobbly-shot-3