Iain’s compositor – …for the adult in you

Squib of the day: speed up alt-tab under compositing

GNOME bug 504729 suggests that switching with alt-tab, while using compositing, is too slow. This is because all the images of the windows are scaled on the client side before the window is displayed.

There are two possible answers to this problem.

Firstly, we can check for key release while scaling is happening, and if one is received, abort scaling and simply switch to the next application.

Secondly, scaling can be faster if it’s done server-side. This is possible but apparently there’s a common bug that it hits. Fixing this would also mean that we got to have animated previews easily.

I think the first solution should be added in any case, and the second should be added when it’s possible. I can add the first solution; I’m not sure I know enough to fix the second.

Photo © L. Marie, cc-by.

Squib of the day: Exposé

In GNOME bug 502491 someone is asking for an effect like Exposé on OS X. Iain, who wrote the compositor and ought to know, believes it would be better done as a separate program. There was an attempt to do this a while back, called Expocity, but nothing much came of it. Does this mean the bug is INVALID? Should the external program exist? Anyone fancy doing it?

Includes the memorable exchange:
“Every time I propose an enhancement, you say ‘go for it’. What are you doing?”
“I’m cooking my dinner. What are you doing?”

If it was a separate program, it could be activated by a mouse button or a keybinding in the same way that, say, Print Screen is currently activated. The program could move windows about using the EWMH, but I don’t see how an external utility could tell the compositor to scale the contents of windows down and back again. Iain, can you throw me a clue? Update: Thanks.

Someone said yesterday in the discussion on animated previews in the alt-tab switcher that an Exposé-like effect would be good for everything that animated previews would, and more.

Photo © Underpuppy, cc-by-nd-sa.

Squib of the day: Live previews in alt-tab

True to my promise, here’s the first bug/squib of the day.

In GNOME bug 567757 someone is asking for live previews in the alt-tab window. I can’t think why this would actually be useful, as opposed to pretty, and it sounds like a lot of work and a source of new bugs. I am therefore minded to say no. Can anyone think of why it might be worth the trouble?

Compositor command-line switches

It seems, from reading blogs and forums, that many people like the idea of using Metacity’s compositor but are scared of changing the deep magic of gconf. In addition, there is nothing in the “–help” text to show that we have a compositor at all. Therefore, I propose a new switch to override the current gconf setting for the compositor, which will display in “–help”, and for symmetry another switch to turn it off again.

I am not sure whether –compositor and –no-compositor, or –composite and –no-composite, would be better names.

What do you think? Tell us at GNOME bug 545323.

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