Re: composite manager thoughts

Around 22 o'clock on Dec 27, Havoc Pennington wrote:

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

I think the range of effects possibly drawn by any application aside from
the compositing manager is fairly limited without quite a bit of
conventional mechanism applied atop the existing system, and I have to
agree that we're far from capable of codifying a long-term specification at
this point.

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

Really, the design was to eliminate any kind of fixed mechanism within the 
X server; thoughts beyond that about fixing an API at the user level were 
not in mind.

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

And a separate compositing manager doesn't simplify this kind of 
prototyping at all.  Perhaps we should sit down and sketch out the whole 
system, from toolkit through window and compositing management to see how 
this part of the system should work.  Ideas about fancy window management 
effects should be subordinate to the idea of a clean and unconfusing 
screen presentation.

I've also been thinking about how Damage can help manage this problem; 
pending events until applications have finished their presentation.  One
simple idea is to have Damage pend events to newly mapped windows until 
all of their contents have been given values by the application to avoid 
ugly results from background None windows as seen today.  I've been hoping 
to prototype this particular fix to see whether it works.

-keith