Underground Cave Dwellers Society

A quick update on the compositor.  I updated the branch to match the trunk, so all the bug fixes have been up into the branch.

Some more compositing bugs have been squashed:

  • Changing screen resolution should work
  • The transparency property on windows is now respected (meaning that gdk_window_set_opacity works, as does transset)
  • Jonathan Matthew fixed a signed bug that was causing the shadows of 50-99% opaque windows to be corrupted

Because the transparency property is listened to, it means that screens that fade to black now work (like at log out and entering admin password).

And I also made some more work on the alt-tab dialog: scaling is better and the program icons are overlaid. Some people said it was slow to appear. I think I know the problem, it’ll be fixed soon.


Finally, I’ve been doing silly experiments with what we can do with a compositor. I had alt-tabbing dimming the screen so that the selected window was highlighted, but it started getting too hacky too quickly, so I want to think of a better, cleaner approach to things like this before I commit them. (And I’ve been working on some other little hacks, but they’re not related to Metacity, so I probably shouldn’t mention them here)

People have been reporting that the compositor is stable for them, so if you were too scared to try it out, please don’t be. I’d especially like to know if there’s any problems on people with weird screen setups, multiple monitors, xinerama that sort of thing, cos I only have one monitor and can’t test that stuff. Oh, and SuSE users too, I’ve had a weird report of shadow corruption on SuSE and I’d like to know if its a common problem to SuSE or just this person’s setup.

Thanks iainxoxox

Ok commandos, you’ve been asking for it all week

Everyone seemed concerned about window previews in the alt-tab dialog…

20 minutes coding, 30 lines of code added, this composite lark is easy (yeah, right…). Not committed yet, a few bugs remain (note the glitches in the Gossip window corners and the terminal window doesn’t get previewed yet, and obviously the scaling), but I’m confident I’ll be committing it soon.

Changes since the last blog entry: Fix weird crashes at startup, correctly mark screens as having a composite manager, and do drawings on an idle function so that we can compact redraw operations.

To answer some questions that came up in the comments last time round:

* No, you don’t need 3D acceleration for this compositor, so cards with sucky GL will be able to use it. You will however need a good  and fast XRender implementation. I’m using the both the binary NVidia driver and the opensource Intel driver. The NVidia driver works well, the Intel one (as shipped by Gutsy) works ok, but CPU usage can get high. I’ve been told the Fiesty Intel driver is quite slow.

* Yes, we can have window previews :)

* When I talked about people wanting translucent windows, I meant more that people wanted some parts of windows to be able to be translucent, which is used for things like AWN and cairo-clock stuff. I don’t really see the point of windows which are all transparent (although I did see a friend using some photo editor on the Mac tonight that had translucent dialogs, seemed a bit weird though. . . )

Adventures in Compositation Land

As Thomas said, I’ve been working on hacking about with a compositor in Metacity recently. All I’ve really done is to take xcompmgr.c by Keith Packard and worked it into Metacity, so I’m not claiming that I really wrote the compositor, more massaged an already existing one into shape. The code is at http://svn.gnome.org/viewvc/metacity/branches/iains-blingtastic-bucket-o-bling/ and it seems to work reasonably well on my desktop (Nvidia), but not so well on the laptop (Intel), so you might be lucky. Its not perfectly stable, but I’ll track down the problems soon I’m sure. Everyone loves a screenshot:

With that out of the way, I thought I’d explain a little about compositing and what my plans are.

What is compositing anyway?

When people talk about compositing they seem to think about vibbly vindows, desktops laid out hendecagonally which spin around, fish swimming behind windows and eating windows and other stupid effects who’s only purpose is for you to play with in conferences so the people sitting behind you have something to watch instead of listen to the boring talk. These are all things made possible due to compositing, but they are byproducts if you will. You can only have the effects if you have compositing, but you don’t have to have the effects to have compositing. And it is this barebones compositor I’ve put into Metacity.

Compositing at its simplest is a program telling the Xserver not to draw the windows anymore because the program wants to do it instead. So now X doesn’t draw the window to the screen, but to a backing store pixmap which the compositor program then draws on the screen. It makes sense for this compositing program to be the window manager, because it already knows all about screens and displays and what window goes where when. . . etc, but it does not need to be (e.g. xcompmgr).

The trick is that when the compositor comes to draw the window’s backing pixmap to the screen it can really do whatever it wants with it. It can paint it backwards, or with a red tint, or just simply paint it normally to the screen. Compositors like Compiz draw the window onto GL textures and then are able to do 3D transforms on them. The compositor in Metacity just draws it to the screen using the XRender extension.

What can we do with a plain compositor?

Well, just because the windows aren’t rendered into a 3D scene doesn’t mean it isn’t useful. Metacity was a designed as a simple window manager that concentrated on managing windows well. Its design ethos doesn’t stretch to being configured in every minute detail. And in my opinion, a simple compositor based on XRender fits in well. Most people I have spoken to want two things from a compositor. They want translucent windows[1] and drop shadows.

What does the future hold?

All metacity’s compositor needs to do is draw windows to the screen and draw a drop shadow around them, and I think its doing that pretty well at the moment. There are some rendering glitches (mostly in dealing withTrans windows) and some crashes, but it is getting there. There are a few other things that the compositor could do but most of the usefulness of a compositor comes from when the programs running on the desktop start to become aware of the compositor’s presence. In the above screenshot the volume control OSD changes design when there is a compositor and draws itself in a translucent design and can fade in and out. The gnome-terminal switches to real transluceny when running on a composited desktop. I have a patch for Metacity that turns the alt-tab dialog translucent with a compositor

Metacity could use the presence of a compositor to do other tricks as well…the icons in the alt-tab dialog could be replaced with window previews (because we can get the backing store pixmap to use anywhere we want), Nautilus’ desktop could be completely transparent meaning we could stop having to draw a huge image on both the desktop window and on the root window and the task switcher could show a popup of the real window. The list is endless. Maybe when I’m feeling up to it I’ll write a “So you want your application to look cool when a compositor is running” tutorial type affair. Maybe. I might be busy.

[1] There are two types of translucent windows: windows which have some area painted with an alpha value (an example of this would be a translucent gnome-terminal, only the text area has an alpha value), and windows that are normally completely opaque but have had their opacity lowered somehow. The former is controlled by the program for artistic measure, the latter is controlled outside of the program and more for an effect (e.g. lower the opacity of all dialog windows to 75%) as it affects all the elements of the window (as well as the frame).

Internally the first type are called ARGB windows, and the second type are Trans windows. Currently the Metacity compositor supports both, but there is no way to set the opacity of the Trans windows. There maybe at some point, who knows?

2007-11-14: a quieter day than usual

The VintrySome helpful Ubunteros came and fixed Thomas’s laptop, which meant that Benjamin’s patch got reviewed (good work there), and also that the question was raised about what api.[ch] are good for.

Most of the checkin activity today was from Iain Holmes with his new compositor rewrite (or, as he has called the branch, the Bling-Tastic Bucket o’Bling). I am hugely excited about this; I hope Iain will write about his experiences here later.

On Launchpad, a discussion has been going on about whether it should be possible to set the width of window borders in general rather than its being down to the theme. Having too-narrow window borders makes resizing windows difficult, but some people don’t like the way it looks. This briefly spilled over into GNOME Bugzilla. It would seem to be a good plan to ask people to make default themes have large borders.

Alex Turner identified a place where the code could be made clearer and more easily optimised by the compiler, which seems promising.

A few months back, Matt Harley wrote a post about why he’s running Metacity rather than Compiz, which should be interesting reading for the future if we want to know why people choose Metacity rather than any other way of managing their desktop. Gentle reader, if you do, why do you use Metacity?

Photo: The Vintry, St Albans. Photo by Gary Houston, public domain.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.