Re: Composite Manager Specs

I think we all agree that compositing is likely to end up
in the window manager under most circumstances.

But Keith and I think it is worthwhile pushing a bit longer on
enabling them to be separate, if only as a way to push on the design
harder to make sure we aren't missing anything.

For example, making it separate showed that the destroy case
was interesting, and that a simple change enabled separate compositors
to work correctly.

Also, in the LTSP case, since compositing requires intervention
at frame rates (e.g. up to 70 hz) while graphics is active, having
a local compositor is needed.  Window managers in general
can and do run remotely as it is.  And yes, in the LTSP case we
can run local processes, but it raises a flag that the separation
might be valuable.
                      - Jim


On Sun, 2003-11-23 at 12:54, Havoc Pennington wrote:
> On Sun, 2003-11-23 at 01:10, Keith Packard wrote:
> > 
> > I'm still not sure making them separate is the best plan in the long run. 
> > Performance of everything *except* window manipulation seems pretty good 
> > so far, and merging the compositing manager and window manager together 
> > should fix that.
> > 
> 
> I think the compositing manager will be *much* easier to do inside the
> WM. I've written a WM and also libwnck which does WM-like stuff outside
> the WM, so I have a fairly reasonable idea what's involved here.
> 
> > However, I can see value in semantic labeling of the window manager frames 
> > for all kinds of things like screen readers and magnifiers.  Perhaps we 
> > can start with some conventions for that and see where it leads us.  In 
> > particular, it would be nice to know which windows are menus, which are 
> > dialogs and which are just visual effects.  Might be nice to know which 
> > window is currently active.  These semantics seem independent of the 
> > separation of compositing from window management and yet could be useful 
> > for that as well.
> 
> EWMH already has a lot of this.
> 
> Havoc
> 
> 
> 
> _______________________________________________
> 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