Hi, On Fri, Sep 24, 2010 at 08:55:50AM +0200, Peter Hutterer wrote: > On Tue, Sep 21, 2010 at 11:30:07AM +0200, Benjamin Tissoires wrote: > > In case of a passive grab (from what I understood, same think of a > > button press - move - release), Peter suggested to send the events > > to all the clients in the stack. However, only the top most one will > > have the flag that the event is for it. The others will receive the > > events, but with a bit flag that mainly consists in saying: "hey, > > this event stream is currently occurring, but is still not yours". > > The point here is that we should rely on the client not to handle it > > even if the event is still not for it. > > The idea was brought up by Keith at XDS: in a normal sync passive grab event > delivery with ReplayPointer, we may send the same event to multiple clients > - first all those that passively grab on a window or its ancestors and then > finally to the window. This is a serial delivery with the server queuing up > events until the AllowEvents request comes through. > Keith's suggestion was to deliver the event stream to all clients that may > possibly get this stream, but with a "Do not use" flag set on all but the > topmost passively grabbing client. Then, when the first client calls > AllowEvents with ReplayTouch (or whatever), instead of sending the whole > queue, the server just sends a "you are free to use event stream X" event to > the next client down. Likewise, if the grabbing client does not replay the > stream, a "discard" event can be sent. > This allows for parallel processing of e.g. gestures, removes the need to > queue potentially vast numbers of events in the server but relies on clients > behaving correctly - if they provide UI feedback for an event stream that is > not yet theirs, it gets tricky. UI problem though. > I haven't scoped out all the corner cases yet, so while I like the idea for > the above advantages in the server, I can't say if it's viable.
That does seem fine to me; I'm sure people will find ways to screw it up, but that's true of anything. The only corner case I can see here is if someone grabs/selects for events after a touchpoint has begun, they'll see a different event stream to clients which selected first. But I'm not sure that's actually a problem, just something to consider. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
