iain – …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…

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 :)

By popular request

Some people have expressed concern about the panel drop shadows. At least three people didn’t like that they drew the shadows over the windows close to them. So in response I’ve just committed a change that makes the panel drop shadows only draw on the desktop. I think it looks quite neat and tidy actually. One person said “Oh cute”

Here’s a now obligatory screenshot

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?