Notes on the Metacity compositor

[Soeren Sandmann <sandmann daimi au dk>]

The metacity GL compositor was intended to:

- move towards the "3D desktop"

- be a technology demo with a focus on cool effects

But given those two gaols, compiz is clearly better than the metacity
compositor.

So I think that if anybody wanted to pick up the metacity compositor,
the focus should probably not be on doing lots of cool effects, but
rather on something that would be nice to use.

Anyway, here are some technical notes on the metacity compositor, if
someone should feel like working on it:


How to make it build and work:
------------------------------

libcm and metacity --enable-compositor should both build and work out
of the box. I recently (today) updated libcm to work with the
latest texture-from-pixmap API. 

If you compile CVS head of libcm and metacity, you should get
something that works, ie., no blue screens etc. It will be a bit slow,
and some of the effects annoying, but it should basically work.


Performance Issues:
-------------------

Metacity as compositor is slower than compiz on the same
hardware. Some potential reasons:

        - libcm does not use multitexturing to draw windows, compiz
          does.

          R100 hardware (such as Radeon 7000) has three texturing
          units which is a lot for its time, so on that chip (which is
          the
          one in T42 ThinkPads), compiz will have a pretty big
          advantage.


        - When dragging windows around with metacity, applications are
          repainting themselves. That doesn't happen with compiz for
          some reason.

          For this particular operation this is the main source of
          slowdown. I don't know why it happens.


Architectural issues:
--------------------

- Argb decorations:

  With composite the X server gained a 32 bit visual intended to be
  used for ARGB windows. When such an argb window has an rgb child,
  the X server will do an automatic composite redirection on the
  child.

  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.

- 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

- Framework for effects

  Current metacity has hooks for some events, such as minimization and
  unminimization. More should be added, but it is not always trivial
  to get right when windows can be closed and disappear without
  warning.

- Dealing with screens, workspaces and windows

  I think the model has to be that each of these objects knows how to
  paint itself. This is different than what we have now, where the
  compositor is a separate entity that is listeing to what is going
  on, and then painting what it thinks the world looks like.

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.


Soren