November 2007 – …for the adult in you

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.

2007-11-28: All our journal entries are busy; please hold

This still isn’t a complete roundup of yesterday, but:

GNOME bug 500279: theme inefficiency: Iain continued to rock on by finding and fixing quite a major inefficiency in the theme code: values which could have been cached weren’t. Thomas began to review the patch last night, but it was a little too much to take in in one go. It’s all rather wonderful: thanks, Iain!

Compositor rewrite: Still on the verge of being able to start making the call about putting it into trunk. If anyone wants to come around and make real life less complicated so there’s more time for patch review during the week…

GNOME bug 150897 has had some dupes recently. The Windows key or whatever you want to call it is a thornier issue than you might suppose. We generally make it a modifier key, perhaps the one which X calls Super— a hangover from the Space Cadet Keyboard— so that you can use it in combination with other keystrokes in the same way you can Ctrl and Shift and Alt. (There’s Super-R for run, and so on.) Some people think that this is a bad idea and that the Windows keys shouldn’t be modifiers (these people never want to do Super-R). Some people want to keep Windows=Super, but also have the key pressed on its own being able to cause an effect (namely to put up the main menu, as it does in Windows). But there is no current case, as far as I know, in which you can make a modifier perform an action without actually modifying something else. (I don’t think, for example, that you can configure Metacity to minimise the window when you press and release Ctrl.) Apparently IceWM does this to some people’s satisfaction, so I expect we should look at how they manage.

GNOME bug 114384 has also had a few dupes. As mentioned yesterday, we need to support startup-notification. Elijah points out that we already link to the relevant library, so this may not be very hard.

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

2007-11-27’s not-quite-a-journal

Life is still hectic for the maintainers this week, so this will be a short post.

On that theme, GNOME bug 468075, about a problem with vertical maximisation (which has been said to be a simple, reproducible bug, although it’s about a feature that most users don’t know exists) is not yet fixed. Someone complained that it raises the question of whether Metacity is still maintained. We are here, though; we’re just doing the best we can with the resources we have. Help is always welcome.

GNOME bug 500047 was a request to add the “busy cursor” when Metacity starts an application in response to a keystroke. This requires using startup-notification, which makes it a dupe of GNOME bug 114384 (that one’s been around a while; we should bump up the urgency).

Apparently we reached GNOME bug 500000 the other night, though it was actually a dupe of GNOME bug 500002.

Continued absence of dolphins

Sorry for the lack of daily “journal” posts over the past few days: I’ve been rather busy with real life, and it takes rather a while to gather up the crumbs to make a post. I’ve been writing a script off and on which will do the donkey work and let me or anyone else simply write the human part, but it’s not quite finished yet.

To be going on with, here’s the fascinating saga of negative numbers in theme files (well, more of a bug, really: Njáll Þorgeirsson does not have a starring role.) Someone complained that they couldn’t put negative numbers into theme files; Thomas closed the bug because the source comments (but not the documentation) say explicitly that negatives aren’t allowed. Besides, what good would they be? The reporter said that there was actually no reason to need negative literals because expressions which yield negative numbers can always be written instead. Certainly this does need documenting explicitly.

Havoc then pointed out that it makes little sense to prohibit “-1” but allow “0-1”. A long discussion of the semantics of the original comment followed. Nobody could remember ever writing it or quite what its subtleties were. Did it mean that unary negation wasn’t implemented because negatives weren’t allowed for some unstated reason, or did it mean that negative literals weren’t allowed because unary negation would over-complicate the parser? Perhaps it does make sense to prohibit “-1” if it means the code will be more maintainable? Maybe code could be shared with some existing expression parser? The issue has not been resolved.

In other news: congratulations to contributor Alex Turner (plexq on irc, aturner in svn) who got svn access yesterday after two very useful patches.

Thomas is aware that patch review is a little behind again (see above under “rather busy with real life”) and will try to get it back on track by the end of the week.

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

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.

raise_on_click: not what you think

There is a GConf key called /apps/metacity/general/raise_on_click. It does not, as is widely assumed, cause windows to be raised when they’re clicked. You should never turn it off. Doing so will make your user experience confusing in subtle ways.

The short description of the key in the current schema says that it controls whether raising should be a side-effect of other user interactions. In other words, this key would have been better named “raise on click and also on a shedload of other random things like resizing”. The longer explanation runs:

Setting this option to false can lead to buggy behavior, so users are strongly discouraged from changing it from the default of true.

Many actions (e.g. clicking in the client area, moving or resizing the window) normally raise the window as a side-effect. Set this option to false to decouple raising from other user actions. Even when this option is false, windows can still be raised by an alt-left-click anywhere on the window, a normal click on the window decorations, or by special messages from pagers, such as activation requests from tasklist applets.

This option is currently disabled in click-to-focus mode.

Note that the list of ways to raise windows when raise_on_click is false does not include programmatic requests from applications to raise windows; such requests will be ignored regardless of the reason for the request. If you are an application developer and have a user complaining that your application does not work with this setting disabled, tell them it is their fault for breaking their window manager and that they need to change this option back to true or live with the bug they requested. See also bug 445447, comment 6.

(See also GNOME bug 326156.)

We still regularly receive bugs complaining that turning off raise_on_click breaks things. This is expected behaviour:

We told you not to turn it off.
raise_on_click doesn’t do what the name implies anyway.

We have to keep the key for backwards compatibility, but please, everyone, just leave this key the heck alone and turned on. Thanks. :)

2007-11-18: quiet day

Quiet day. Lucas Rocha submitted a patch to make Metacity play nicely with the new gnome-session startup, which will be in the next development release. Also, mateju updated the Slovenian translation again.

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