Re: composite manager thoughts

On Thu, 2003-12-25 at 15:54, Keith Packard wrote:
> 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.

I'm unconvinced, though I do see there are tradeoffs either way.
I don't think we'll know the answer until we've gotten a good bit
further prototyping the things we want to do. Someone might try hacking
on the metacity compositing manager and see where the problems/virtues
arise ;-) perhaps adding a nice minimize animation.

One concern I have is just overall complexity of the system with yet
another separate process and all the IPC flying around. But this is one
of those gut-feeling concerns that's hard to defend concretely.

Here's a more concrete discussion: define for me the line between the
graphical effects done by the compositing manager and those done by the
window manager, and convince me that the spec for CM<->WM communication
is finite, clean, and well-defined. Can we get a concrete idea what the
CM<->WM protocol looks like?

It seems to me that the whole point of the compositing manager design
was to avoid the question: "what is the API for doing graphical
effects?" - instead leaving that totally up to the desktop environment.
If you keep the CM separate, you've reopened that can of worms; suddenly
you have to standardize an API to ask the CM to do effects on other
clients' behalf. At that point I don't know why we have a CM instead of
just an X extension?

I guess I remain unclear on the entire rendering process though, we
don't yet have a working prototype that eliminates all flicker and
tearing and has smooth animation. The flow of events including who
double buffers, who syncs with what, etc. doesn't seem fully sorted out.

Havoc