composite manager thoughts

[Keith Packard]

Around 2 o'clock on Dec 26, Jaymz Julian wrote:

>  * I would like to see the composite manager split up into a libcompmgr, and a
>  * main refrence application.

Seems like a good plan; I've discovered a lot of parallels between 
xcompmgr and uncover.  Perhaps the library should support both manual and 
automatic update clients.

> * Window managers will probably want to do compositing themselves in some
>   cases, for example, in order to implented the macosx style "genie" minimise
>   effect correctly.

Hmm.  One of the things I've discovered is that the basic event processing 
technique is very different in the compositing mananager -- I tried a lot 
of things and ended up using XSync (!) as the best performing solution.  
Window managers generally don't want to use that as they prefer to batch 
processing of long sequences of events and overlapping event delivery and 
request processing.

I don't know if we can get a window manager doing compositing as smoothly; 
so we may need to design with the possibility that separate compositing 
manager connections are a necessity.  That doesn't require separate 
compositing managers, but it may be nice to preserve this.  Some mechanism 
for cooperation between the window manager and compositing manager would 
be required to perform some effects; at a minimum, we could have the WM 
create an appropriate ARGB window and just paint into that.

> (side note: i added a '-noshadows' flag to my local tree, which i have no
> short terms plans to commit, since it falls under the definition of
> "nontrivial functionality change" rather than optimization ;), which makes
> things a *lot* faster under the current code base - as in, 3x faster, because
> compositing with a mask is hideously slow right now.  The above would be a
> much better way to handle both of my shadow issues.  I attached the patch in
> case anyone is interested to use it, tho, anyhow, but it's for curiosity at
> best).

I've also got the 'true' shadow code sitting on my disk; that doesn't 
create an explicit shadow mask, rather using the alpha value for the 
window itself, allowing shadows to follow the translucency of the window 
around shapes.  I was waiting to test server-side convolution before 
committing that; I expect performance there to be terrible though.

> I don't have a written down API spec or anything like that yet, obvisouly,
> because I wanted to test the waters before I put in much work in this
> direction.  So, I guess this is a "tell me what you think" thing more than a
> "here is something concrete that i am going to implent" thing.  Flame on!

I think it would be useful to have a library that could track the top-level
window geometry; I think that's the hardest part right now that will be 
shared by any compositing client.  I'm sure there are other bits we could 
stick in it as well.

-keith