Re: Merging spif-2 branch

[Havoc Pennington <hp redhat com>]

On Thu, 2005-12-15 at 14:43 -0500, Soeren Sandmann wrote:
> >"Ws *ws" doesn't read very well (what's a Ws?)
> >
> It's a windowsystem, but shorter to type. I can change the name of it 
> though -
> any suggestions?

Maybe just "NamespaceWindowSystem *ws" - I assume you'd only type the
type one time, the rest of the time you're typing "compositor->ws"
right?

When hacking with GTK and metacity in C trying to save typing seems a
little futile anyway ;-)

Anyway, up to you, as I said I'd like someone else to own compositor.c

> Actually, the compositor calls XTestGrabControl (dpy, ignore), so it 
> will ignore grabs.
> This is necessary not only because of being in-process with metacity, 
> but also simply
> because we can't turn off screen updating just because someone grabbed 
> the server ...
> On the other hand this does mean that the compositor has to be careful 
> what it does
> to avoid confusing other clients.

It means the compositor just can't do certain things I would say - it
should probably never change an X property for example. Probably
reasonable, but will be really easy for some future programmer to
accidentally mess up, since a bug like this will only show up very
occasionally once introduced.

> The reason the server needs to be ungrabbed in this particular case is 
> that for
> some reason the libGL.so I am using opens a _third_ connection to the X 
> server

That sounds kinda busted but OK ;-)

> >Or maybe we should explicitly adopt a model where the compositor is
> >async with respect to the main WM, i.e. all core->compositor messages go
> >in a queue... ? does it end up basically working that way anyway due to
> >the two X connections?
> >
> Right, my long term plan is to actually have the CM be a separate 
> process that
> just manages a scene graph. Metacity and other interested desktop 
> applications
> would then modify this scene graph through some sort of IPC.

Hmm. It's not obvious to me that's a good idea, but not obvious it isn't
either.

I guess I'd need to step back and understand better what kind of
user-visible improvements we're trying to get here, and how they'll be
implemented in metacity/compositor combo... I don't have a good sense of
what the communication between WM/apps and the compositor will be.
You've obviously thought about it a lot more.

> Putting the CM in its own thread is something I have thought about doing 
> anyway.
> That would allow us to have the compositing manager only ignore grabs 
> when it was
> drawing and not other times.

We'd run into the "Xlib thread support is terrible" problem though
wouldn't we? I guess with a separate display connection we only depend
on Xlib to correctly lock any global variables it has, and presumably
they get that right.

If you put it in another thread I think talking to it through a queue
rather than trying to share metacity data structures between the threads
might be smart. I'm thinking of something simple, a C equivalent of
this:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html

Seems like glib could use one of those if it doesn't have one yet.

Anyway if you just implement the same requests/replies you imagine using
for an out-of-process CM over a queue like that, popping the CM out of
process later would be trivial. Of course, implementing the CM with a
thread is probably just as hard as doing it out of process ;-) I guess
the only thing that's easier about a thread is that you could just
allocate structs and toss them over the queue, instead of devising some
kind of protocol.

> Nothing has replaced it for now.

XOR tricks aren't any faster than normal drawing in CM mode are they?

If not we should definitely not try to do XOR nonsense in CM mode.

>  This layer will then maintain animation states and modify the scene 
> graph
> accordingly. Hopefully this API will survive the compositing manager moving
> out of process.

That make sense.

> It needs to be figured out how to make sure semantic/behaviorial things 
> like this
> don't get mixed up with transitional effects like genie type stuff. A 
> possibility might
> be to have the effects layer call back when the event should take 
> "semantic effect".

Right, just some kind of "animation completed" event or something.

Havoc