multi-touch-dev team mailing list archive

[Denis Dzyubenko <shadone@xxxxxxxxx>]

Hi guys,

I've been thinking about the GEIS/GRAIL architecture, talking for a
few people here in the Qt office, and in general we are all pretty
happy about the api, would be interesting to try it out, to see if
there will be any performance issues and how convenient it is in
general.

There are a few concerns been raised about the approach - for example
Bradley Hughes made a good point that his main use case for gestures
is application gestures (mac that is) - scrolling with two fingers on
the touch pad, occasionally pinching, and only seldom making system
gestures.

With that in mind we've thought about the architecture and it seems to
be fine in general, even though we might have some latency because of
application gestures triggering on the window manager side and then
being delivered to the client (through dbus or any other rpc
mechanism).
Basically three processes will wake up for every single move of
fingers - the X.org which sends the touch events to client, the window
manager that receives touch events due to a passive grab on the device
and the client that receives the gesture event from the window
manager.
Is there anything we can optimize here? Is it necessary to wake up a
window manager after we realize that this is an application gesture?
Do we need the latency introduced by sending all application gestures
through extra component - through the window manager?

Drawing of the architecture from UDS
https://docs.google.com/drawings/edit?id=1X6Tk-Gw9FzNpiye8dotSPzMEcbWMQLaTnK6VKB5wfuo&hl=en
System gestures
https://docs.google.com/drawings/edit?id=1uCgZTJzJ5tFPgwLLEida4XC9TD89W8iJ2vExwDQ0UQY&hl=en&authkey=CKGx4fUE
Application gestures
https://docs.google.com/drawings/edit?id=1Rm3qHcaORHBaIapgLaJmM1kS1vOgpfQ0Uwjx-_QLyTc&hl=en&authkey=CJTEt9MB

-- 
Best regards,
Denis.