XComposite required for semi-transparency

thos: IIRC, a compositing manager together with the XComposite extension is in fact required for having a semi-transparent (thus arbitrarily-shaped) window.

There is another X extension available allowing arbitrarily shaped windows without any semi-transparency (each pixel is either displayed or omitted). It uses a bitmap, i.e. you explicitly set which pixels to display and which to “carve out”. It probably takes care of that by sending expose events to the underlying windows, and overlaying the results afterwards. This would still mean on-screen drawing, though, compared to off-screen XComposite drawing.

On a sidenote: I think the problem with XComposite is that even if the library is loaded, there is no guarantee that the underlying graphics hardware supports it, and that the user gets semi-transparent output.

For instance, some people demanded semi-transparent drag icons for Nautilus, but it turned out that finding out whether compositing is actually done is nontrivial. I made a proposal on the xdg freedesktop.org mailing list for finding out whether a compositing manager is actually running, but nobody has proposed a freedesktop spec yet.

2 thoughts on “XComposite required for semi-transparency”

  1. There’s no extra exposes with the shape extension, like those transparent-terminal hacks. Shape is just clipping of drawing to a different set of rectangles, and exposes on different areas when you move/resize/etc.

    As far as composite, it doesn’t matter in any way what your hardware supports. It’s always supported except for Xnest and a couple of cfb-using drivers you’ve never heard of, because Render has a software implementation (you know, what all your text is drawn with if you’re not using a Radeon). For example, it’s supported if you’re using Xvfb. Hell, iirc it’s supported if you’re using Xprt, if you’re insane.

    The “problem” with the composite extension is that there’s no new rendering policy built into the x server. Many of us consider that a feature (don’t you force your fadey menus on me). It’s up to a compositing manager to push windows offscreen and deal with updating the main screen in a way the user actually wants. I really want to see gnome take this on and provide a decent compmgr by default.

  2. Composite is not a hardware feature. compositing is implemented by the compgmr which can use any X requests it likes to draw the screen. so _all_ hardware supports Composite; it’s just that not all hardware accelerates it.

    as for the lack of a spec: why haven’t you written one? freedesktop.org has no “specs working group”, and any useful spec from any contributor is welcome and encouraged.

Comments are closed.