4

I am trying to understand how compositors work on X (well basically because neither xcompmgr nor cairo-compmgr can draw shadow properly for my awesome wm~~~)

I have read part of the source code both xcompmgr and cairo-compmgr but I still don't really understand how they do that.

I want to know how they know where the shadow should be (well, arround the window for sure, but the shadow might be under other window and don't need to be drawn.), as well as where (on which layer/window) do they draw the shadow. Probably also how all those X extension are used (and what's for) and how cairo-compmgr use cairo to deal with low level X stuff.

It's a little hard for me to learn these from the source code because a lot of stuff (especially X extensions) is poor documented. It will also be helpful just to point out where I should look at.

Peter O.
  • 32,158
  • 14
  • 82
  • 96
yuyichao
  • 768
  • 6
  • 28
  • For those who are also interested in how compositor use the overlay window to draw shadow and other stuff, `src/compositor/compositor-clutter.c` in mutter 2.27.1 is a neat example. – yuyichao Feb 11 '12 at 14:02

1 Answers1

4

The simpler you code it, the best it will work.

  • Get a list of the visible windows
  • Sort them by inverse z-order (from the bottom-most to the top-most)
  • Draw the shadow and then the window itself for each window

You need no black magic.

If you are wondering how it works, it's straightforward: you have to use the 'composite' X extension. It enables the overlay window, which is the only visible window on the screen once it is enabled, then you have to draw all the windows on it as you will be provided with a Pixmap for each window.

EDIT: If you are seeking for documentation, you can use the linux manual (the man command), and the header files, they're the main (also best and perhaps the only real) source of documentation, as all the other sources/websites rely on them afaik.

moongoal
  • 2,847
  • 22
  • 23
  • Yes, this is a straight forward way~~, but won't there some problem with handling focus (or other events)? And I don't think either {x,cairo-}compmgr use this way afaik. Hmm, I do read manpages and headers, but some of them don't have manpage or comment in header file (e.g. pixman) and I think additional doc will be helpful. – yuyichao Dec 10 '11 at 16:44
  • @yuyichao Why there should be problems such as focus? The overlay window is a regular window but doesn't appear while calling functions like `XQueryTree` or such. It will not disturb your environment nor get input focus, you will use its handle only to draw things, nothing more. It's hard to begin with this kind of stuff since there really is not plenty of documentation and it's kinda sparse too. Just don't give up, it's the only way I know, and it works. – moongoal Dec 11 '11 at 10:32
  • Hmm, I c what you means. But I do need to pass the event to the really window (or no)? and this will probably break xprop/xwininfo etc? I still don't think that is the only way (altough maybe it IS the simplest way) since I didn't find a single XCompositeGetOverlayWindow in xcompmgr source code. – yuyichao Dec 11 '11 at 19:24
  • @yuyichao Think of the overlay window as an object that has a window handle associated to it, but is not a window. When you send/receive events, you have to do as you normally would, without taking it into account. That's why it doesn't break anything. The only thing that changes is that you have to manually paint the windows onto the overlay object that will be then presented on the screen. And unless you know of any other composite-like extension, I think this is the only way available atm. – moongoal Dec 11 '11 at 20:02
  • At least this seems to be how some of the compositor work. (afaik, mutter 2.27.1 (clutter part) is one of them). – yuyichao Feb 11 '12 at 13:46