Comments on: XComposite required for semi-transparency http://blogs.gnome.org/cneumair/2005/12/17/xcomposite-required-for-semi-transparency/ Just another GNOME Blogs weblog Tue, 15 Jun 2010 18:43:49 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Anonymous http://blogs.gnome.org/cneumair/2005/12/17/xcomposite-required-for-semi-transparency/comment-page-1/#comment-23 Anonymous Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/cneumair/2005/12/17/xcomposite-required-for-semi-transparency/#comment-23 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.<p/>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.<p/>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.<br/> 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.

]]> By: ajax http://blogs.gnome.org/cneumair/2005/12/17/xcomposite-required-for-semi-transparency/comment-page-1/#comment-24 ajax Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/cneumair/2005/12/17/xcomposite-required-for-semi-transparency/#comment-24 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.<p/>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. 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.

]]>