Re: composite manager thoughts

I'm wondering if an X synchronization extension based 
implementation, even without vertical retrace, is a useful
alternative to use of XSync.

Have you tried that alternative?

It may be possible to do a single WM and compositor using
two connections, as well....
                     - Jim

On Thu, 2003-12-25 at 15:54, Keith Packard wrote:
> 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
> 
> 
> 
> _______________________________________________
> Xserver mailing list
> Xserver-u7BhqnqprCWvj1b/[email protected]
> http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/xserver
-- 
Jim Gettys <[email protected]>
HP Labs, Cambridge Research Laboratory