Tag Archives: opengl

Compiz port to GLES2 : Putting everything together.

Hi, here’s the last article of the “Compiz port to GLES2” series.

This project was really tons of fun. It led me to :

  • Learn compiz and metacity internals
  • Rewrite parrt of the opengl plugin
  • Port many cool compiz plugins (Water, Wobbly, Cube, Scale, etc…)
  • Rewrite compiz opengl plugin’s partial damage rendering
  • Harmonize Nux/Compiz framebuffer usage

And all of this working on the really cool PandaBoard plateform !

So today, I just wanted to show you the results. Check the following two videos :

1) This video showcases Unity3D with Wobbly, Water and other plugins.

2) At the end of this video, we see the rest of the demo I devised : The cube plugin !

Tagged , , , , , ,

Compiz port to GLES2 : Porting the water plugin

Yet another fun task I tackled along the way to porting Compiz to OpenGL|ES was to completely rewrite the “Water plugin”. But before I talk too much (like always), let’s take a look at the Water plugin on desktop:

So clearly, for those of you who didn’t already know the water plugin, clearly, you’ll understand that its practical applications are… well… limited! I mean, having water drops pop up all over one’s desktop is nice and fun… but only for the first 10 minutes I’d say ! 😛  After this already-long time frame, the excitment is over… and you’ll understand that our interest in the water plugin was for demoing purposes, of course.  In fact, the water plugin is a really cool thing to have for a demo. It showcases per-fragment shading capabilities like no other compiz plugin can, and the way the plugin was devised originally is rather interesting : it makes a very clever usage of Framebuffers. In fact, it uses a series of three square FBOs of limited resolution (let’s say 256×256) which content aren’t colors, but bump normals (in the x,y,z components) and heights (in the w component). By binding 2 FBOs in the series (current and last ones), the water-calculating shader may then proceed all the framebuffer fragments (it calculates a per-fragment “acceleration” factor by comparing current/last heights for each fragments) and output newly computed normals and heights in the next FBO in the series!

Only problem was… the original shaders were written in ARB language !  Rewritting this shader in GLSL really was a liberating action !!

Here’s the ported Water plugin in action! This was run on a Pandaboard ES running ubuntu 11.04 Natty Narwhal :

You can find the final version of the Compiz water plugin port to GLES here. Have fun !

Tagged , , , , ,

Compiz port to GLES2 : Supporting the Unity Desktop

The second part of my “Compiz port to OpenGL ES” task was to make the whole thing work seemlessly with Canonical’s brand new Unity desktop. Take a look at the Unity Desktop that appeared originally in Ubuntu 11.04 Natty Narwhal :

This change, of course, promised to bring its share of problems, mainly for 2 reasons:

  • Unity displays its GUI components/Widgets using the “Nux” toolkit, which is OpenGL-based. I knew Nux made extensive use of framebuffers, which compiz-gles depended on as well, so ouch.. possible interference ahead!
  • The Unity/Compiz running scheme is very peculiar : Unity runs as a Compiz plugin (the “Unityshell” plugin).

Let’s take a look at the main challenges those elements posed to this task:

1) Unity depending on NUX

This, at first, wouldn’t have to be such a big deal because after all, stacking openGL calls at different software layers is a common thing. The problem here though, is that Nux made unsafe uses of framebuffer Objects (FBO). By “unsafe”, I mean that the code was not carefully unbinding FBOs back to their previous owners after use… so any caller (like compiz !) trying to nest Unity/Nux drawings in its own FBO just couldn’t do it ! This “unsafe” FBO usage comes from a “standalone” point of view and is somewhat not compatible with the compiz plugin scheme.

So what I and Jay Taoko came up with is a new nux API :

This new API lets us manage a new so-called “reference frame buffer” that allows for FBO nesting 🙂  Here it is :

=== modified file 'Nux/WindowCompositor.h'
--- Nux/WindowCompositor.h    2011-12-29 18:06:53 +0000
+++ Nux/WindowCompositor.h    2012-01-05 04:00:19 +0000
@@ -175,6 +175,23 @@
+    /*!
+        Set and external fbo to draw Nux BaseWindow into. This external fbo will be
+        restored after Nux completes it rendering. The external fbo is used only in embedded mode. \n
+        If the fbo_object parameter 0, then the reference fbo is invalid and will not be used.
+        @param fbo_object The opengl index of the fbo.
+        @param fbo_geometry The geometry of the fbo.
+    */
+    void SetReferenceFramebuffer(unsigned int fbo_object, Geometry fbo_geometry);
+    /*!
+        Bind the reference opengl framebuffer object.
+        @return True if no error was detected.
+    */
+    bool RestoreReferenceFramebuffer();
     ObjectPtr<IOpenGLFrameBufferObject>& GetWindowFrameBufferObject()
       return m_FrameBufferObject;
@@ -561,6 +578,10 @@
     int m_TooltipX;
     int m_TooltipY;

+    //! The fbo to restore after Nux rendering in embedded mode.
+    unsigned int reference_fbo_;
+    Geometry reference_fbo_geometry_;

All this landed in Nux 2.0 series as a big “Linaro” merge on 2012-01-06.  Take a look !  It’s still upstream in more recent versions!

2) Unity running as a Compiz plugin

It may be weird at first to think of Unity as a compiz plugin, but let’s think about it for a minute. When running compiz as our Window Manager, which makes intensive use of OpenGL ES calls, it’s not so foolish to make Unity a plugin because Unity is also making intensive usage of openGL primitives and we’ve got to find a way to coordinate the two components in a graceful manner. One manner is to run Unity as a compiz plugin (the “unityShell” plugin, that is). That way, Unity declares a series of callbacks knowed to Compiz (like glPaint, glDrawTexture, preparePaint, etc…) and compiz calls them at the right time. Every drawing operations are done, every framebuffers are filled at the right time, in the right order, in a graceful manner with the other plugins. On second thought, this decision from Canonical to write Unityshell is not so foolish after all 😛

Tagged , , , ,

Compiz port to GLES2 : Another Cool Project !

Hi ! It’s been a while since I last wrote about my professional highlights in the Open-Source World.

From oct2011 till mar2012, I worked on porting COMPIZ –  the open-source eye-candy window manager – to OpenGLES1/2. This was a very fun and interesting task to tackle! Now, compiz runs under Linux and many of you might never have used it. So here’s two videos, showing what’s it’s basically capable of on a desktop ubuntu:

Those videos actually show compiz running on fast desktop boxes, but my task was to port compiz to the Texas Instruments’ OMAP4 platform (using the power of its amazing SGX GPU). Now, we don’t find any OpenGL implementation on theses SoCs, rather, OpenGLES1/2 implementations delivered by Imagination Technologies (remember, it’s embedded !). So since Compiz was originally written using legacy OGL calls, conventional glVertex and almost no shaders, the fun work could start!!  I ported a lot of ‘compiz core’ code to GLES2, using vertexBuffer objects instead of glVertices. I also had to completely get rid of the fixed-functionality and write cool brand new shaders in GLSL for eye-candy plugins that we wanted to include in our demo (e.g. the Wobbly plugin  – to be showcased in another blog post).

During those months, I had the pleasure of working with Travis Watkins from Linaro (a.k.a. Amaranth) who did first rounds of GLES porting and with whom I worked closely. I also have to mention the work of Pekka Paalanen (from Collabora),  who briefly worked on this project but made important contributions to the paint and damage system, for example. For those interested in pulling our CompizGLES work from the community git, clone the ‘gles’ branch from here :


Tagged , , , , ,