composite manager thoughts

[Jaymz Julian]

On Thu, Dec 25, 2003 at 12:54:26PM -0800, Keith Packard wrote:
> 
> > * 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.

Actually, they may not be as far removed as you'd think, based on that 
paragraph - when I was at computerbank fixing a bunch of software to
work on very low end (we had kword and kwin running fast on a p100.  a shame
it fell into politics before we got to attack kdesktop/kpanel), one of the 
major usability improvments was adding the Xsync() calls that people had
left out, because they thought it would give them better performance.  It's
the old rule, better *interactive* performance is often completly unreleated
To better *bulk* performance - on a high end machine, of course, you get the
event right now, but on a heavily loaded machine (such as one doing a lot of
compositing ;)), the mouse/key event you just did gets deffered as "not 
important", and sure your system is fast, but it *feels* like shit.

This is also probably why, on my laptop, there is a very noticable delay
between me clicking on the window title bar, and the window starting to drag -
because it is bulking up the events.  This is a *bad thing*.

Anyhow, I agree with you that the window manager isn't the place to do this - 
I just don't think that will stop window manager authors from doing it 
anyhow.  But maybe I'm just being cynical

> 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.

looking forward to seeing it.  performance can be fixed :). (note the smiley,
btw - this was not a serious statement)

> 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.

hrm, you could be riGht there

	-- jj

--
Jaymz Julian aka A Life in Hell / Warriors of the Wasteland / Unreal
Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people. 
 Very few people have `I want to be killed and eaten' on their cards, 
 so Hannibal is out of a job." - http://cards.sf.net