Processing Input with DirectManipulation
This section provides an overview of the Direct Manipulation threading model, how window messages are processed by Direct Manipulation, and how the state of a viewport changes as input is mapped to output motions.
Direct Manipulation uses two threads to coordinate asynchronous operations:
UI thread - the thread that owns the HWND associated with input. This thread owns initialization of Direct Manipulation. Mouse and keyboard input processing also happens on the UI thread.
Delegate thread - the thread created and owned by Direct Manipulation. Touch input processing happens on the delegate thread.
In a typical configuration where hit testing is done on the UI thread, window messages are processed by Direct Manipulation in the following order:
For a viewport at rest:
- 1) A series of window messages reach the delegate thread.
- 2) Direct Manipulation sends a WM_POINTERDOWN message to the client.
- 3) The client calls SetContact to associate a contact with the viewport.
- 4) If a manipulation is detected, Direct Manipulation sends a WM_POINTERCAPTURECHANGED (abbreviated to WM_PCC in the diagram) message to notify the client that the input is being handled by Direct Manipulation. The viewport status is set to RUNNING and the output transform will be updated.
For a viewport in motion (with a status of RUNNING or INERTIA), the window message reaches the delegate thread first, where Direct Manipulation hit tests against all running viewports. Direct Manipulation automatically assigns the contact to the appropriate viewports identified by hit testing. The viewport status is RUNNING and the output transform will be updated.
In some cases, an application UI thread may be too slow to respond to hit testing. A hit test thread may be used (RegisterHitTestTarget) to allow the client to move WM_POINTERDOWN and DM_POINTERHITTEST messages to a specific thread to allow for hit testing.