xfwm4 + compositor

[Olivier Fourdan]

On Fri, 2005-10-07 at 01:24 -0700, Brian J. Tarricone wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hey Olivier,
> 
> I finally upgraded my 6-year-old video card to something a bit more
> recent (nvidia GeForce FX5700LE, if you're looking for data points), and
> the compositor is great!  Things do overall feel a bit less 'snappy',
> but I suppose that's to be expected.  They eye-candy is fun, and I love
> being able to have translucent panels.  move_opacity is really cool,
> though resize_opacity is a bit too slow for my taste.
> 
> So... just wanted to say it rocks ^_^.

Hey thanks :)

> Also, I was thinking about something.  When you're using a compositor,
> the entire desktop is drawn to an offscreen pixmap, essentially a type
> of double-buffering (yeah?).  In addition, GTK does double-buffering of
> most widgets by default, essentially giving you "triple-buffering",
> which is probably a bit of a waste.  Obviously we can't turn off D-B in
> all GTK apps, but would it make sense to bug the GTK guys about a way to
> do this?  If I'm thinking this through properly (and I may not be), I
> imagine this might be a way to make the compositor's performance hit a
> bit less severe.

I don't think so. When using the compositing, the windows contents are
stored off screen. It's up to the compositor to "compose" the final
image, using alpha blending where suitable (such its name, compositor)

To make sure the screen displayed is in line with the actual window
contents, XFixes comes to help by informing the compositor what region
(s) of the screen have changed and need to be refreshed in the displayed
image. If you disable double-buffering in GTK, you'll end up with
multiple small fixes notifications instead of a single larger one (at
least it's how I see thing) and I'm not sure that would be an
improvement. In all case, double buffering is using basic bitblt ops, so
it's hw accelerated on any video card (except when using the vesa
driver).

HTH
Olivier.