A conversation

Over the next few days, weeks, months and years there will be a conversation covering one very important question. Depending on the answer that people come to accept, the belief formed will have far reaching implications.

That question is: “is liberalism no longer a viable political ideology in a democracy?”

Many people will tell you that Brexit and Trump became a reality because liberals ignored the interests and views of the “white working class”. This explanation is attractive because it is simple. But simple explanations are dangerous, especially when we consider what some of those interests and views are.

The reality is that in some sense, the “silent majority” who voted to put Trump in the White House and the Republicans in the Congress and Senate must have, at some level, believed that you could do anything you wanted to a woman if you had power and money. They must have at some level believed that the country you were born in determined whether you were a rapist, a criminal or ‘perhaps a good person’. They must have at some level believed that your faith and the community that you grew up in is a reason to prevent you from interacting with some subset of 300 million people in the world, despite the fact that such a subset might want to include you.

We can say that Trump voters had these beliefs because it would take an astounding level of self deception to not hold those beliefs and still vote the way they did. Perhaps how they reached those beliefs involves a degree of moral blameworthiness. Perhaps it involves a degree of socialisation.

Regardless of the source, the question for liberals now is whether those beliefs, views and interests should be catered to for the sake of electability. Be very weary of this.

In a representative democracy elected representatives are not just a mouthpiece for the majority states, or the majority of electorates or the majority of people. They are also there to act on moral principle. We elect representatives because we trust them to make the hard decisions for all of us on our behalf.

One only needs to look to Australia to find out what happens when this principled outlook is lost. Our own politicians figured out that they could make themselves more electable by accommodating racist and xenophobic beliefs. But they quickly found out that racism and xenophobia begets more racism and xenophobia. Australia now runs one the most, if not the most, cruel and inhumane offshore detention schemes with a large degree of bipartisan and public support. And it was only last week that we heard it was to become more cruel. Real people are suffering and even killing themselves as a result.

If you find that liberals are unelectable because because of a racist, xenophobic and sexist silent majority, change the silent majority. We could all (myself included) do a much better job to call out intolerance when we see it.

Silently accepting it is so much worse.



There’s a meme going around social media at the moment which I think is particularly worthwhile, called #itsokaytotalk. If you haven’t seen it yet, its primary purpose is to send a message that as individuals, we can and should, seek support from our friends, colleagues and family when we are experiencing problems, feelings or negative thought patterns (often collectively referred to as “mental illness”). The message also points out that, statistically speaking, the leading cause of death for people aged 15-44 is suicide. It has gained a substantial amount of traction recently, so you’re likely to see it if you haven’t already.

I’m usually hesitant about adding my voice to the chorus with these things, primarily because I don’t think I have anything important to add and I don’t want to minimise the stories of others whom I think should be listened to. I had some debate with myself about whether to add my thoughts to the mix, but I think I can contribute to the common good by adding those thoughts.

I should add a disclaimer here that the stories I will tell here are in no way intended to minimise the experiences and stories shared by other people. We should all take the time to listen to their stories and, if appropriate and called for, provide our words of support. I’m also not purporting to act in any capacity as a mental health professional. Most of the stories I will share with you in this post are either anecdotal or personal experience. As we all know, the plural of anecdote is not evidence.

Now some unpacking of this message and the answering of questions which may actually provide some support and insight to people.

Why should I burden others with my feelings, thoughts, fears or problems which just seem so irrational, uninteresting or commonplace?

The analogy I like to draw here is that depression and anxiety are not like a car crash. At least in my own experience and in the experience of others I know, they are experienced not as a reaction to a highly traumatic adverse event but usually start as a small reaction to something that might otherwise seem commonplace(1). Depression and anxiety are more like cancer. For some reason that we don’t understand yet, sometimes people get unlucky and that otherwise commonplace disappointment starts to infect their identity and sense of self-worth. The person starts to believe that they are defective, unworthy, useless or unloveable because of what may have happened to them.

Unfortunately, the human brain is wired to be very good at confirmation bias. The small “network” about our identity grows and as it grows, more thoughts become linked to it. The person afflicted starts to explain everything that happened around them by reference to the  belief about themselves. Then they begin to act out the belief, which reinforces it even more. Soon almost everything begins to remind the afflicted person of how terrible they are and it becomes overwhelming.

Common examples of these small seeds that grow are relationship breakdowns, fights with friends, lack of employment or lack of success at work or education.

As an example to dissect, I’m going to pick unamicable breakdowns of a romantic relationship, because they’re common, they hurt like hell and we’re very embarrassed to talk about them. Usually when a romantic relationship breaks down, the person who wanted to stay in the relationship will search for answers and explanations as part of the grief cycle. It is quite likely that one of those explanations will start with “If only I …” followed by some sort of statement about a person’s internal characteristics, appearance, behaviour or the like. That explanation feeds back into the person’s sense of self-worth, perhaps because they feel the particular characteristic which they thought was the cause of the relationship breakdown makes them inherently defective or unloveable. And so the cycle begins and continues. This isn’t the fault of anyone in particular – it is just a thing that happens.

Because such unamicable breakdowns are a fact of life and happen frequently, we’re generally hesitant to talk about them, viewing them as “drama”. There’s a rather unhelpful adage of “block, gym, lawyer, move on” which reinforces this notion. The thing is that while the breakdown of the relationship might, objectively, seem insignificant to talk about, the consequential impact on identity and self-worth is very significant and could well be a life-or-death conversation. A good way to combat confirmation bias is to have an external source provide undeniable evidence that the internal belief is false. And it is far easier to combat a dogma in its early stages of formation than the point where it becomes well-formed and attached to lots of other things. If you had cancer, would you prefer to nip it in the bud or go through years of excruciating treatment later on down the track? I’m sure you’d probably pick the former.

(1) This is not to say that depression and anxiety can be experienced as a response to a highly traumatic or extreme events nor are the needs of a person in that situation any less important than they would be at present.

If I just exercise and take some antidepressants, the problem will just go away and I won’t have to talk to anyone right?

Actually, no, because depression and anxiety which are sourced from beliefs about yourself don’t work like that.

Both natural (in the sense of endorphins released during exercise and dopamine released during pleasurable activities) and artificial antidepressants have the function of lifting your mood and your energy levels. They reduce the effect of the the negative-self-worth network so that you can function without everything slamming that network and making you feel miserable all the time. But they don’t fix the problem, which is that the network exists in the first place.

Medication and exercise absolutely have an important place and if you are struggling with recurring negative thought patterns or generalised malaise, it never hurts to ask a doctor who can refer you on to the right person and to determine if they’d be right for you.

However, you still need to talk to your friends, family and colleagues if something is troubling you and you’re stuck in a thought loop. See above for why.

What if my friends, family and colleagues don’t care?

Put yourself in their shoes – if someone came to you and wanted to talk about something that was making them feel miserable, would you tell them to “get over it” because you didn’t care?

Of course not.

In fact, they’re more than likely to be humbled by the that you opened up to them and will likely encourage you to talk to them more.

I don’t discount the possibility that someone may well tell you to go away or minimise your feelings. To that extent, I would say that if you are the person being asked to give support, try to look past the particular problem to the internalised belief that the person has. To the person seeking the support, it may be easier for people to give you that support if you talk about the belief as opposed to the event. We can all relate to beliefs about ourselves, whereas it might be harder to relate to particular events.

What if I’m so far down the track that it feels impossible to talk about this stuff?

The more depression and anxiety grow, the more complex the emotions and circumstances behind them become. Often times things become cyclic and entangled and you just don’t even know where to start.

Start somewhere. Even if its just the bad day you happened to have at work. Your discussions with others may prove to be enlightening and help you to find the core belief that’s causing the entangled feeling of misery.

Of course, you can also ask  doctor to refer you to a qualified counsellor who specialises in things like clinical psychology and Cognitive Behavioural Therapy. Those professionals are there to help you unpack what’s going on and change the thoughts, beliefs and behaviours you have might may be reinforcing the negative self-worth. In Australia, you can get ten free private consultations and ten free group sessions per year with a doctor’s referral. That almost gives you one private and one group consultation per month.

I’m not a man and I feel like I can’t talk to anyone either

It would be folly for me to end this post without some discussion of how depression and anxiety affect people who aren’t men. I’ve deliberately tried to adopt a non-gendered approach in this post for reasons I’ll discuss below but I should probably note that it seems to be in vogue right now to talk about mental health as it relates to men and we seem to be forgetting women and other gender minorities in the mix too.

First of all, there’s a gendered assumption that women are better at leveraging their networks for emotional support and further that women are better at talking about emotions generally. Anecdotally at least, I’ve found that to be totally untrue. Now, I have no real way of verifying this, because I have no experience of being female. But out of the people who have come to me for support, men and women included, everyone told me that they felt that there was nobody else they could talk to about the challenges they were facing. Didn’t matter how large or small their networks were. So in that sense, one should not abstain from talking because a gendered assumption tells them that they should have networks which will automatically provide support and advice.

Second of all, there’s another (perhaps implicit) assumption that women face less stigma than men for being afflicted by problems in their emotional wellbeing. This is also totally false. The stigma just has different labels and consequences. Many women are just as concerned as men that talking about their own mental wellbeing and related problems for fear that it could have adverse affects on their career, social standing or future relationship prospects. All I can do in this post is acknowledge and validate the fact that, for both genders, the fear is there and it feels very real, and state further that talking to people you trust about what’s bothering you will still be beneficial.

Closing Thoughts

The #itsokaytotalk meme is important and we should all take heed of its message. I only wrote this post because I think my own experiences with having been there and in supporting others who have been there could contribute some insight that others might find useful.

I don’t want this to become a post about me, so I’d challenge you to do this. Don’t click the “like” button on this post. Don’t reshare it verbatim either. If you think I said something that’s worthwhile to spread, then write about it in your own words and add your own thoughts. If I missed something, talk about that. Criticise me if you think I’m wrong. You don’t even have to tell me that you saw this post as inspiration to do so.

Mental wellbeing is a really complex and hard topic. It is complicated by all sorts of personal, cultural and social factors.  The more people understand about it, the more they’ll able to help themselves, so lets make this an exercise in not just awareness, but understanding.

Improvements to polysquare-travis-container

After some time out, I sat down to make some changes to polysquare-travis-container based on some things I had recently learned about package managers.

My job at Endless requires that I occasionally work with Debian packages. One tool I have been working with quite a lot lately has been chdist from the devscripts

Whilst also being a wonderful tool to compare Debian-based distributions, the fact that a tool like chdist exists quite handily proved that it should be possible to use apt and dpkg in a separate subdirectory, without needing root access. This was the initial raison d’être for polysquare-travis-container.

One of my thoughts recently has been that while proot was a great tool to start out with, it is probably too heavyweight for what I am really trying to do with this project. What I really want is a way to quickly install things that only exist in Debian packages, install them without root access and ensure that the installation, compile and test process for a project requiring those packages is reproducible at least on the same platform. The overall goal is to enable users to run their CI setup locally, as painlessly as possible.

With this new knowledge, I took some time this weekend to look into how chdist works.

In essence, chdist is a perl wrapper around apt which specifies configuration options such that apt is able to run locally. It does that by specifying the Dir, Dir::State and Dir::Cache options. That mirrors closely what you might find on a Debian installation in /var/cache and /var/lib/dpkg.

Assuming that the directory structure both dpkg and apt expect exist at those paths, you can run apt-get update without root on a custom lists file and even start downloading packages along with their dependencies.

My goal was to get polysquare-travis-container to a point where it wasn’t necessary to download an Ubuntu filesystem image or use proot. After hacking around for a little while, I’m more or less settled on the idea that doing so isn’t particularly trivial unless you have access to something like debootstrap because of all the initial circular dependencies. Ideally you want to be running apt from within the nested filesystem as well, since the “jailing” of apt by using the aforementioned variables isn’t perfect.

Most software from the new filesystem can be run without root access somewhat comfortably. Hardcoded paths, particular in shebangs, may cause trouble however. You will need to set the following environment variables:

  • PATH: Where the system should look for executables. Obviously you want this so that typing an executable name into a shell will find the executable in your filesystem tree.
  • LD_LIBRARY_PATH: Where ld.so should look for dynamic libraries. It is effectively mandatory to set this to /usr/lib and /usr/lib/${arch-triple}, otherwise running binaries from the filesystem root will attempt to bring in libraries from your system filesystem (which likely won’t work).
  • PKG_CONFIG_PATH: Needed for building software.
  • LIBRARY_PATH: Needed for some static linking cases.
  • INCLUDE_PATH: Needed if you installed a compiler in your filesystem root, since this is the first place gcc and clang will look for headers.
  • CPATH: See above.
  • CPPPATH: See above.

I have now released polysquare-travis-container 0.0.38 which takes into account these considerations. It now ships with a –local option for Ubuntu, which downloads an Ubuntu core image, minifies it to about 20MB using dpkg and proot and from that point onward uses only environment variables and a specially-configured apt to install packages and run software. It is about as lightweight as you can get for this kind of thing. Please feel free to try it and give feedback.

Safety is not our first priority

I was on a flight back to Australia when something in the routine safety
demonstration video struck me with more significance than it had in the past.

“Safety is our first priority”

I began to realise just how often I had seen this value being espoused and how
often I’ve come to take it for granted. The infrastructure and services I rely
on every day put my safety as their top priority. Above making money. Above
being innovative. Above customer service. If that organisation did not keep me
safe whilst my livelihood was in their hands, the organisation would consider
itself to have failed at its primary objective.

If you look around, you’ll find that this is an incredibly common organisational
value. You will find it in any organisation that operates heavy machinery, any
organisation that is responsible for taking care of a dangerous place and any
organisation that is responsible for building infrastructure upon which the
public relies. It is therefore no surprise that this value has been reflected in
the customary law of negligence for centuries. When someone is vulnerable to
your actions making them unsafe, you are under a duty of care to ensure that
above all else, they are safe.

It is customary for all engineers in the United States and Canada to receive an
iron ring upon their qualification and admission into the profession. It is
folklore that the iron is sourced
from the remains of the Quebec Bridge, which collapsed during construction in
1907, killing seventy five construction workers. The reason the bridge
collapsed was that the engineers responsible for its design and construction cut
corners to get the project to completion more quickly. Those workers were
relying on the engineers to keep them safe and the engineers put profit ahead
of the safety of those people. The ring is intended to be a permanent reminder
to all of those in the profession that such errors should never be repeated.

The priority of safety in software

You will very rarely find this value in organisations that develop software.
Most organisations are even allergic to it, including verbose disclaimers in
software licences purporting to waive any implied warranty that the code you run
is fit for purpose and won’t cause you trouble. Most licenses will require users
to agree to numerous waivers and consent to all sorts of things which may be
harmful to them. There is no way other professions would get away with that
without raising an eyebrow. But for software, we don’t seem to care.


This is puzzling, because at the same time, professional bodies representing the
computer software industry purport to put the public interest as their number
one priority. For instance, the Australian Computer Society’s (Australian Computer Society code of ethics) says that "You
will place the interests of the public above those of personal, business or
sectional interests." This disconnect is disturbing when we think about the
consequences that flow from such ignorance. A failure to have a safety oriented
culture means that as so-called "engineers" our profession becomes complacent
about the impact of our strategic and engineering choices upon users. It results
in culture that puts the need to stay ahead and continue making a profit above
the need to protect the legitimate safety interests of users. It leads to a
discourse which implicitly accepts that failure is inevitable and can only be
mitigated as opposed to prevented by making trade-offs which may reduce
competitiveness but protect the public.

A resort to realism

Many computer software professionals would retort at this point delivering
perfect quality software is just not realistic. The project may be on a tight
budget or operating under a tight timeframe. It would not be possible to remain
competitive and maintain such a high standard. And nevertheless, software
professionals say, users have come to understand this reality as well. The
software industry has remained unregulated since its inception and the benefits
for society have been explosive growth of technology and innovation at a pace
never before seen.

Such explosive growth and innovation has had real winners and losers. Over the
last forty years technology has moved beyond the realm of academia and military
research and become democratised. Computing is readily accessible in the age of
the smartphone. It is also no surprise then that the wealth generated by
computer software has become concentrated in the hands of the few who were best
able to execute and facilitate this explosive growth.

But there are losers. It is becoming increasingly difficult, and now almost
impossible for people to opt out of relying on software in their daily lives,
just like it is now almost impossible to opt out of roads, electricity and
plumbing. Software controls an increasingly higher degree of the infrastructure
that we rely on every day and increasingly controls the way that we interact
with each other, do business and access essential services. In an age where
software grows explosively and operates the world, people have become
increasingly vulnerable to the choices software development organisations make.
Every day we hear of a new data leak. Confidential information is stolen and
sold to the highest bidder. Lives are meddled with and lives are ruined. User
facing software upon which people rely to make a livelihood breaks and those
users shoulder the burden of the lost time or inconvenience. In extreme cases
people die. Virtual bridges are collapsing around us and the best we can say as
a profession is that such collapses are a cost society is willing to accept in
the name of exponential progress.

Safety, is not our first priority.

What if safety were our first priority?

Engineering failures threatening the safety of others can be avoided so long as
we are willing, as a profession, to make certain trade-offs. If you ever wonder
why the pace of change for aviation, rail transportation and civil architecture
seems to be glacial in comparison, it is because safety is the first priority.

If we want to make safety the first priority, there are some uncomfortable
counter-realities that we may need to accept. It is plausible that in such an
alternate timeline, the smartphone may have never been brought to the mass
market, It is possible that social networking and the writeable web would have
been considered and then quietly abandoned, due to the inherent risk associated
with storing confidential information about millions of people in a central
repository. Your operating system and applications may be considerably more
stable, but the redundancy required to avoid takings risks would mean that its
performance and scope of functionality would be heavily reduced.

These costs, are, I suspect, too much for our cutting-edge society and cut-
throat business culture to bear. One thing I do believe though is that we can
still put the safety of users as our number one priority by focusing on the 20%
which will avoid 80% of the risk. We can, as a profession, still ask the hard
questions which might affect the bottom line. We can still ask whether a
particular feature, though innovative, might bring with it risks to the people
who depend on us that those people would find unacceptable, even if it meant
sacrificing the feature. We can still look at the systems we are designing and
ask "do I understand the impact upon a person if this fails?" We can still sit
down and make sure the math checks out before proceeding on a course of conduct
which may have irreversible consequences.

If we just sat down and accepted that certain trade-offs will have to be made,
we can be a profession that can be proud to say that safety is our first

Thanks to Wayne Spilsbury for providing feedback on and editing this essay

Naming things

Naming things is apparently one of the hardest problems in software engineering.

I have a bunch of side projects with rather generic and uninspiring names. I’d like to see them gain some wider usage and I think the names are putting people off. Unfortunately, I can’t think of any decent names. So I’d like to throw it out to the community to see if we can find a better name for them! Here’s a list of projects and what they do. If you can think of a better name, just post it in the comments.


Elevator Pitch: Getting software to run on CI environments like Travis-CI requires installing a bunch of dependencies, activating environments and doing other setup. This creates a lot of duplicate code in configuration files. These extensible scripts, written in Python, can be directly fetched with CURL and executed. They set up any required language environments, install dependencies and do deployment-specific steps.


Elevator Pitch: System package managers are great, but they make life painful when trying to reproduce builds between systems. They often require system level access – something you don’t always have or want. Docker and Vagrant partially solve this problem, but one only works for linux guests and the other is quite heavy-weight. This project creates a local version of your operating system’s package manager so you can install just what you need and nothing else. You run binaries through it and it will automatically set up any required PATHs or LD_LIBRARY_PATHS to make it work.


Elevator Pitch: Parse CMake files and create an abstract syntax tree, usable from Python.


Elevator Pitch: Catches bad practice in CMake files. Like cmake-lint, but it checks for other things, especially variable quoting.


I can’t think of a worse name!

Elevator Pitch: Ensures that each source code file’s header is consistently styled and checks for spelling mistakes in comments and user facing strings. For instance, it checks to make sure that every file contains a copyright notice, or that if the name of the file appears at the top of its copyright notice, that the name is actually correct. It also makes sure that anything referred to in a code comment can actually be found in the code if it is not an english word.


Elevator Pitch: Integrates every decent python linting tool into a setuptools command. Collects all the output into a single format and de-duplicates any warnings. Runs prospector, flake8, pyroma and polysquare-generic-file-linter. Caches results and parallelises the linter processes where possible to speed up builds.


Elevator Pitch: Bumps your project’s version number, tags a new release and pushes tags to git on request. Uses bumpversion under the good. Designed to be used in conjunction with Travis-CI.


Elevator Pitch: A library for CMake that makes it easy to integrate new static analysis tools into your build. Just run psq_run_tool_for_each_source on a target with your tool’s binary and arguments and that tool will run every time that target is updated during your build.


Elevator Pitch: Add it to your project, add executables and libraries through it, and you get amazing tooling like CPPCheck, clang-tidy, include-what-you-use, vera++ and others for free. Adds an option to build code with AddressSanitizer, UndefinedBehaviourSanitizer, MemorySanitizer and ThreadSanitizer. Adds an option which turns on pre-compiled headers and unity builds without having to make any underlying changes to the build system.


Elevator Pitch: Examine a header file to determine all of its dependencies and whether it is C only or involves C++. Many tools require that the language be specified manually for such headers.


If you can think of a better name for any of these, please let me know. I’ll take any suggestion!

Bringing back the old animations

One of the other casualties when we switched to using Modern OpenGL in Compiz was the loss of the older animation plugins, such as animationaddon, simple-animations, animationjc and animationsplus.

I took some time last weekend to make the necessary changes to bring them back to life and get them merged back into mainline.

One of the more interesting parts of all this was the polygon-based animations. You might remember this as the “glass shatter” or “explode” animations. Unlike most of the other code in Compiz plugins that did transformations on windows, the “polygon animation” mode actually completely took over window drawing. This meant that there was a lot more work to do in terms of getting them to work again.


Compiz has had (for a few years now) a class called GLVertexBuffer which encapsulates the entire process of setting up geometry and drawing it. If you want to draw something, the process is usually one of getting a handle for something called the “streaming buffer”, resetting its state, adding whatever vertices, texture co-ordinates, attribute and uniform values you needed then calling its render method.

Under the hood, that would populate vertex buffer objects with all the data just before rendering and then call glDrawArrays to render it on screen using the defined vertex and pixel processing pipeline.

glDrawArrays can be cumbersome to work with though, especially with primitive types where you might end up having a lot of repeated vertex data. You have to repeat the components of each vertex for every single triangle that you want to specify.

glDrawElements on the other hand allows you to set up an array of vertices once, adding that array to the vertex buffer, then specifying a little bit later the order in which those vertices will be drawn. That means that if you were drawing some object in which triangles always had a point of (0, 0, 0), then you could just refer to that vertex as “1”, so long as it was the second vertex in the vertex buffer. This is very handy when you have complex 3D geometry.

Quite understandably, animationaddon’s polygon animation mode didn’t use glDrawArrays but glDrawElements.

In order to support both OpenGL and GLES it was necessary add some sort of support for this in GLVertexBuffer, since the old code was using client side vertex and attribute arrays. The quickest way to do this was to just add some overloads to GLVertexBuffer’s render method, so now as a user you can specify an array of indices to render. Its a little more OpenGL traffic, but it makes things a lot easier as a user.


All the geometry for those 3D animations was rendered using the GL_POLYGON primitive type. Polygons are essentially untesselated concave shapes. GLES only supports triangles, triangle fans and triangle strips which threw a spanner in the words.

The polygon animation mode supported splitting windows into rectangles, hexagons and glass shards.

At first I was wondering how to convert between the two geometries, but it turns out that for concave shapes there’s an easy way to split it up into triangles. Just take a reference point, then make a line from that reference point to each of its neighbours, bar its neighbours.


That can be represented with this simple function:

    enum class Winding : int
    Clockwise = 0,
    Counterclockwise = 1

    /* This function assumes that indices is large enough to
     * hold a polygon of nSides sides */
    unsigned int determineIndicesForPolygon (GLushort *indices,
                         GLushort nSides,
                         Winding direction)
    unsigned int index = 0;
    bool front = direction == Winding::Counterclockwise;

    for (GLushort i = 2; i < nSides; ++i)
        indices[index] = 0;
        indices[index + 1] = (front ? (i - 1) : i);
        indices[index + 2] = (front ? i : (i - 1));

        index += 3;

    return index;

Depth Buffer

We never really used the depth (or stencil buffers) particularly extensively in Compiz, even though the depth buffer is a common feature in most OpenGL applications.

The depth buffer is a straightforward solution to a hard problem – given a bunch of geometry, how do you draw it so that geometry which is closer to the camera is drawn on top of geometry that is further away?

For simple geometry, the answer is usually just to sort it by Z order and draw it back to front. For the vast majority of cases, compiz does just that. But this solution tends to break down once you have a lot of intersecting geometry. And those animations have a lot of intersecting geometry.

Incorrect Depth Buffer.png

Note in this image how the white borders around each piece are drawn on top of everything else?

The better alternative is to use the depth buffer. It isn’t perfect and doesn’t allow for transparency as between objects whilst the depth buffer is enabled, but it does handle the intersecting geometry case very well.

The way it works is to create an entirely separate framebuffer where each “pixel” is a single 24 bit floating point number. Compiz uses an implementation where the other 8 bits are masked out and used for the stencil buffer. Every time OpenGL is about to write a pixel to the framebuffer, it keeps track of how far away that pixel is in the scene. It does that during something called the “rasterisation stage”. This is where a determination is made as to where to draw pixels. That’s done by interpolating between each vertex to reach a position and its relatively trivial to keep track of depth too by similar methods. Then, OpenGL compares the depth to the existing value at that position in the depth buffer. The usual depth test is GL_LESS – so the value in the depth buffer is updated and the framebuffer write is allowed.

The result is that parts of geometry which were already occluded are simply not drawn, where as geometry which occludes other previously-drawn geometry overwrites that geometry.

Correct Depth Buffer.png

I this image, you’ll notice that each piece correctly overlaps each other piece, even if they are intersecting.

Trying it out

The newly returned plugins should be back in the next Compiz release to hit Yakkety. They won’t be installed or enabled by default, but you can install the  compiz-plugins package and compizconfig-settings-manager to get access to them.

If you’re ever curious about how some of those effects work, taking the time to re-write them to work with the Modern OpenGL API is a great way to learn. In some cases it can take a lot of head-scratching and debugging, but the end result is always very pleasant and rewarding. There’s still a few more to do, like group, stackswitch and bicubic.


Revenge of the blur plugin for compiz

A couple of years ago I blogged about the blur plugin for compiz – how it worked and some of the changes necessary to make it work with the modernised codebase. I wanted it to be available for the rest of the Ubuntu users, but I was a little overzealous about how much I chose to re-write and I took a rather long hiatus from development before I was able to get it through review.

Revenge of the blur plugin.png

I’ve decided to revive that branch and minimise the change-set so that there might be one last chance of it making it into 16.10 before Unity 7 is dropped. I have to admit that these days there isn’t really all that much use for it, unless you like transparent terminals. Transparent panels and window decorations have more or less gone away now and most WM-integrated shells handle blurs on their own just fine.

It can be found at lp:~smspillaz/compiz/compiz.revenge-of-the-blur-plugin. What can I say, reviving it has even been a little fun!