multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Fri, 2010-10-08 at 13:37 +0200, Henrik Rydberg wrote:
> On 10/05/2010 10:22 PM, Chase Douglas wrote:
> [...]
> 
> > The reason this is useful is to lower the latency when there's
> > system-wide and application specific gesture recognition to be
> > performed. It requires a trust of the client applications to not handle
> > the events as though they owned them, but X trusts client applications
> > with lots of similar things today without issue.
> 
> 
> It seems to me that the idea of tentative events is not so much about latency as
> it is about implementing user feedback which helps resolve ambiguities.

It's the latency to the user feedback that's important. In my mind,
these two concepts are one in the same.

> There are at least three stages in gesture recognition in this respect. In the
> first stage, the engine builds up a reaction based on user input, from nothing
> to something. I see no reason to send this buildup anywhere at all. In the
> second stage, something is happening, and the user may need feedback from the
> system to tell that something has been registered. This is equivalent to our
> notion of gesture primitives, and could well be represented by tentative events,
> although I see no compelling reason to change views. The third stage is to
> perform a user-approved gesture, which is on a higher level than what we have
> implemented so far, and could be a good target for geis.

The sticky point comes when we need to handle the possibility for both
gestures and low-latency multitouch input. For example, think of the
three finger hold to unlock many finger MT and gestures occurring over a
paint application. With the proposed XI 2.1 passive grabbing paradigm,
gimp will receive tentative events and may start painting, knowing that
it will need to undo those paints if the events should be discarded.
This should occur as immediately as possible after touches hit the
screen.

-- Chase