← Back to team overview

multi-touch-dev team mailing list archive

Current grail architecture and future needs

 

As I've thought some more about the current grail architecture and the
future when we have XInput 2.1 with full multitouch support, I realized
there may be an issue with our current implementation.

Grail currently takes MT input and looks for a subscribed gesture. If
there wasn't any, the MT input is discarded (leaving aside single touch
emulation). Once XInput 2.1 is available, including when we move gesture
recognition to the client side, we'll need to be able to pass through MT
events. A wrinkle is that we need to be able to support MT grabbing as
well.

When I thought about MT grabbing, I realized that grabbing really needs
to be done on a per-finger basis, and the client needs to decide early
on whether to grab the touch through the entire touch, or whether it
should allow events through to non-grabbing clients.

Imagine you perform a two finger pinch gesture and then move directly
into a two finger drag. If a client subscribes only to the drag gesture,
it will receive gesture events for the drag once grail starts to
recognize it. However, this breaks down when we try to involve MT grabs.
We would need to wait through an entire touch sequence until a
subscribed gesture is found before we can decide whether to handle all
the events ourselves or replay them to other clients.

What I think we'll need to do is modify grail so that it recognizes a
subscribed gesture very soon after a touch begins. If no gesture was
recognized, the touch needs to be passed through as normal MT events for
the remaining duration of the touch. This allows a grabbing client to
make a decision on whether to replay events for the touch to
non-grabbing clients. This also means grail can't recognize gestures
based on touches that have already been disposed to pass-through status.

Any thoughts?

Thanks,

-- Chase




Follow ups