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. _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
