Compositing – Page 2 – …for the adult in you

Some compositor issues

So, now that the compositor is in trunk and everyone is excited, this might be a good time to mention some “issues”.

Firstly, it seems that there are some weird shadow redrawing problems…these just appeared recently, so it shouldn’t be hard to find the offending commit. I think I know what it is, I just need to work out why its not working.

Next: Now that some windows have argb visuals some buggy themes may have translucent parts where there weren’t translucent parts before. Gilouche was one of these themes and Jimmac fixed it up recently. So if you start seeing through the window title bars, tell your theme author.

Also, I’ve been getting reports of terrible performance and rendering issues with xgl. It seems xgl doesn’t like any of the non-GL compositors, so I don’t know what to do about that.

Finally, on a happier note – a big thank you to whoever bought me stuff from my wishlist. Its much appreciated, even if it did take me two days before I noticed my parents had piled up my mail in a weird place while I was away…

2.21.5 is out, with the compositor

Thanks to Iain Holmes and Thomas Thurman for improvements in this version. This is the first unstable release to contain the new compositor; please try it out and let us know how it goes for you. Downstream maintainers should note that its GConf key is initially turned off in src/metacity.schemas.in and consider whether to turn it on by default in their packages.

merge compositor branch! (Iain) (GNOME bug 499081)
print “Subversion” and not “CVS” when building (Thomas)

Translations:
Jorge González (es), Kjartan Maraas (nb), Daniel Nylander (sv)

Source:

3d3ac7dc8e52981af032e35171789e60 metacity-2.21.5.tar.bz2
eef55d7ce921b23d0749155876d53873 metacity-2.21.5.tar.gz

Photo: Footbridge over the River Ver, Hertfordshire, England. Photographer: Gary Houston. Public domain.

Compositor on trunk

Iain’s compositor is now on trunk since it now meets every requirement I wrote about here. It looks gorgeous. It will be in the next unstable release, which will happen before the weekend. Do not use bucket-o-bling any more; it is a dead branch. Work will continue on trunk. This closes GNOME bug 499081. All kudos goes to Iain.

When Iain’s compositor will be merged

Someone asked about this and I was going to tell them, but then I thought I’d say it here. I will merge Iain’s compositor branch when:

there are no known
- large memory leaks
- security holes
- crashes
it can be turned off entirely from ./configure and GConf
when it is turned off in GConf or ./configure, the code paths are substantially the same as before the merge
I actually compile it myself and see it working on a computer in front of me
there are no smaller nitpicks like coding style and so on

So far most of these have been met, but not all at once. Note that “it all works perfectly” is not a criterion: it is important that it’s easily testable in standard unstable releases. On the other hand, “Metacity is as stable as before if you turn compositing off” is a very important criterion.

Trip the light fantastic

Useful uses for a compositor #1

Some videos this time, they’re not particularly good quality but that doesn’t matter. First – http://folks.o-hand.com/iain/watch-updates.ogg

Its like acid, but cheaper!

So what exactly are we seeing?

Well, everytime a section of the screen needs to be redrawn, the compositor draws it correctly, and then picks a random colour and overlays that colour on the region that was redrawn. So you can watch screen updates as they happen. Just by watching the colours change.

Besides being a cheap night in, what use is it?

Well, here is video #2 – http://folks.o-hand.com/iain/totem-button.ogg

Again, crap quality, but down in the bottom left corner of the screen, we can see that something is constantly redrawing itself. That something is the totem-mozilla play button. It seems to be constantly redrawing itself for no apparent reason. Bastien got a bug for you.

Shoot speed kill light

Some recent changes to the compositor made it feel kinda slow and laggy. Not in a noticable way but more in a subconscious something feels wrong way. I tested xfwm and it seemed fine running as a compositor, and given that Metacity’s compositor has the same heritage as xfwm’s and I’ve been checking the xfwm code to see how they do things, I thought that was suggesting that there was something wrong with the Metacity one. I couldn’t see anything abnormal or strange looking at/comparing the codebase, so I turned to valgrind and oprofile. Running callgrind didn’t really show anything about the compositor code though, but as always with callgrind stuff gets lost in amongst the small functions like g_type_check_instance_is_a and the wonderfully mysterious <cycle 8>

My expectations were that some of the compositor functions would be topping the profile, given that the redrawing functions need to run anytime something changes on the desktop (modulo that they’re called from an idle handler so some redraw events are merged together) but what Oprofile said was

samples % symbol name

13908 21.8501 pos_eval_helper 10471 16.4504 pos_tokenize 7621 11.9729 meta_color_spec_render 5408 8.4962 compositor_idle_cb 3785 5.9464 fix_region 1559 2.4493 meta_draw_op_draw_with_env 1511 2.3738 free_tokens 1480 2.3251 meta_parse_position_expression

Eh? What are pos_eval_helper, pos_tokenize and meta_color_spec_render and why are they so high up the profile? Well, it turns out they’re part of the theme parsing code (Metacity has a very powerful, but complex theme format dontcha know?), but some more debugging showed that the theme expressions were being reparsed and re-evaluated every time Metacity had to draw a window frame. The impressive screenshot for this is:

Just look how many times pos_tokenize and pos_eval_helper are called when a draw op is drawn. That is one complicated function call chart.

Looking through the code I saw that draw operations were stored as their string format, like “2 * width + Bmin / height % 7”. These expressions were first tokenised (in pos_tokenize) into constituent parts (‘2’ ‘*’ ‘width’ etc) and they were then evaluated. Thing is that these strings cannot be changed at all so they can be tokenised when loading the theme rather than every time they are evaluated.

meta_color_spec_render is a similar problem. Colours can be defined as a basic colour, a GTK theme colour, a shade of a colour, or from two colours blended together. With shaded and blended colours they were generated every time Metacity had to use that colour, which is an obvious waste of time as the colour specs cannot be changed after they are created and so the colours should just be generated whenever the spec is created and then it becomes a simple function to get the correct colours.

All this is filed as bug #500279 and the patch attached to the bug fixes these two issues.

pos_eval_helper is the function that calculates the theme expressions from their tokenised state and it still gets called every time the theme needs redrawn, which sort of makes sense, as the variables may have changed since the last time, but it looks to me like the variables are all related to the width/height of the window, so it may be that we can make it so that the expressions are only re-evaluated when the width/height changes. I’ll have to look into it.

Anyway, with the patch from bug #500279 applied this is what the profile looks like now…
9355 32.4815 compositor_idle_cb 7129 24.7526 pos_eval_helper 1070 3.7151 meta_parse_size_expression 1020 3.5415 event_callback 604 2.0971 meta_compositor_process_event 597 2.0728 .plt 542 1.8819 win_extents 531 1.8437 pos_eval 519 1.8020 meta_frame_style_draw 495 1.7187 meta_draw_op_draw_with_env

The compositor functions are up where they should be…getting rid of that pos_eval_helper would be nice though, as evinced by this screenshot of the same function as above, but with the patch applied. The function is a lot less busy, which is a good thing, but the three sets of calls to pos_eval_helper could possibly be reduced somehow.

Anyway, the compositor seems faster, and I didn’t even touch that code this time :)

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

We get letters: two projects

Nigel Tao writes:

Hello. I’ve been reading http://blogs.gnome.org/metacity/ with great interest, and was wondering if you had any thoughts on my superswitcher program? People occasionally ask me if I’d push some of it upstream, which presumably means into metacity.

I asked which parts people wanted pushed upstream, and he said “the replacement of the existing alt-Tab behaviour”. I think this sort of behaviour replacement largely belongs in add-in programs like superswitcher and Devil’s Pie, for example, where they just use the EWMH to take over part of Metacity’s functionality, Metacity stays out of the way, and it makes Metacity a little bit simpler.

I think we should probably have some central place, maybe on live.gnome.org, where we list add-in programs such as these. Your thoughts, gentle readers?

(Nigel also raises the question of whether ctrl-alt-left from workspace 1 should switch to workplace n, which I think has been raised before, but I can’t find a record of. Update: GNOME bug 89315 and about a million dupes.)

Meanwhile, gandalfn writes:

Hello,

I see recently that Iain work to integrate compositing in metacity. I’ll also work on composite manager (outside metacity) which use cairo for rendering. I have implemented it outside metacity to preserve his
functionalities. My principal goal was to provide compositing in GNOME and on all platform. For that, CCM used cairo and his backends to render (Xrender/Glitz).

What about joining our efforts to provide compositing on GNOME ?

CCM is using GObject for object model design and provides a plugin system which can be used to add various effects. In the future, I’m planning to add a clutter backend, some means for other applications to interact with cairo-compmgr (especially accessibility applications), some cool plugins, etc.

Iain, and everyone else, what do you think? For myself, I think gandalfn’s compositor looks to be both more complicated (with a plugin system) and less finished than Iain’s, but as it grows we’ll see how it looks; even if/when Iain’s compositor is a standard shipping part of Metacity, it’ll be possible to turn it off and use another one, in the same way that Nigel’s been doing with superswitcher. Then if other compositors come along in the spirit of Metacity with good ideas, it’ll be possible to switch parts around and so on.

All email quoted by permission. Image: Stamp FR 387, Postverk Føroya; released to public domain.

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?