Re: Notes on the Metacity compositor


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]