Re: Notes on the Metacity compositor

[Havoc Pennington <hp redhat com>]

Hi,

Thanks for the helpful writeup.

Soeren Sandmann wrote:
>   In a reparenting window manager, the natural way to do decorations
>   with an alpha channel (for antialiased rounded corners maybe) is to
>   just make the decoration window ARGB. Unfortunately, if the
>   application has an RGB window (which is almost always the case), an
>   extra redirection will happen, causing slowdowns and extra memory
>   use. One fix for this would be to make metacity not reparent when it
>   is compositing, another would be to shape the decoration window so
>   that it becomes invisible.

Not reparenting should be pretty plausible, since metacity already 
handles undecorated windows without reparenting (most older WMs still 
reparent in that case but just have the parent the same size as the client).

> - Metacity really needs a wrapper around libX11. There is one in libcm
>   called (Ws) that could be extended as necessary.
>
>   Things that can be done cleanly that way:
>         - async properties
>         - roundtrip-free error handling
>         - having signals on windows when events arrive

I'm skeptical this is more than a code cleanup or truly 
compositor-related, but it might be nice.

(There's already async property support of course, though not all parts 
of the code use it.)

I don't think making everything a GObject and using signals and stuff 
like that would really improve the codebase much. I would consider it 
higher-value to make some of the key objects (window, display) opaque 
instead of exposing their fields; this would help clarify how all the 
code interrelates.

> More generally, I think anybody picking up the metacity compositor
> should be prepared to change all parts of metacity to become
> "compositor-aware", rather than grafting it on as I did.

Owen was showing me FC6 this morning, and it does seem to work out 
nicely having metacity handle the old video hardware and compiz handle 
the new, with a simple toggle between them. The only real glitch in it 
was that compiz uses EWMH-viewports to implement workspaces, which I 
think is probably a bad choice; the exact same user-visible behavior 
could be done with the EWMH-workspace implementation, and then 
apps/libwnck/etc. would not have to deal with the extra complexity of 
implementing the same thing differently, and toggling metacity/compiz 
would be a lot smoother (apps wouldn't lose their workspace).

If this FC6 approach is the setup we expect, I'd discourage large 
metacity changes; what I'd do is treat metacity as "done" as much as 
possible (for at least a couple years now, I'd say metacity has been in 
that steady state where maintenance introduces about as many issues as 
it fixes - software can only get up to a certain level of stability 
before this happens, though all of us programmers find it hard to admit).

The worst possible path would be to put a lot of churn in the metacity 
codebase, and then switch to Compiz. The good paths are to either 
overhaul metacity and then stick to it, or leave metacity stable and 
switch to Compiz. If you overhaul metacity then dump it, you piss off 
users twice, aside from spending a lot more developer effort.

Conceivably relatively simple/uninvasive compositing changes (maybe drop 
shadows and just killing some flicker, maybe a hardcoded animation or 
two) would make sense even in a non-overhauled metacity for some interim 
period or something, I don't know.

Havoc