Showing The Complete Debug Views, Using CML:
Activating The Gesture Analytics Display, Part 1
Creative Markup Language (CML) has been designed to simplify the
development of multitouch applications by providing advanced methods in
Flash for developers to create interactive objects and containers. This
has been done to actively encourage developers to experiment with new
gestures interactions and descriptions with the goal of furthering
multi-user multitouch UX. Part of this process is having the ability to
accurately visualize the entire pipeline of activities that lead from
simple touch to complex gesture interactions. This can achieved using
the Gesture Analytics Display (GAD) tool or "gesture debugger display".
Each touch object created GestureWorks 3 (TouchSprite or
TouchMovieClip) has the ability to have gestures directly associated
with it. These gestures can be managed automatically using CML and GML
or manually using actionscript methods. Whichever method you choose to
create and manage touch objects and touch object interactions you must
use the root CML document "my_application.cml" to control debug display modes of touch objects.
Every touch object rendered on stage has the "built-in" ability to
independently display the touch point clusters it posses as well as
detailed informatics on cluster geometry and motion. To turn on the GAD
display, in the "my_application.cml" document set the attribute "displayOn" equal to true. For example:
<DebugKit displayOn="true">
This will globally activate the debug display of all touch objects
rendered on stage. When the GAD is activated it is always rendered on
the topmost layer of the application display hierarchy. This is done to
ensure that, when in debug mode, touch points and touch/gesture data is
always visible and not obscured by media or menus.
The GAD can be globally configured for all touch objects in an
application to selectively display the different "DebugLayers" of the
GAD. This was done so that developers can choose the focus of the
interaction data relevant to their project. When all "DebugLayers" in
the GAD are activated, it can show a visualization of the full gesture
pipeline from touch point tracking, cluster analysis (geometry and
motion), gesture processing (noise filtering, inertia) to property
mapping and display object transformations. For example:
<DebugKit displayOn="true" displayAlwaysOn="true" displayRadius="300">
<DebugLayer type="point_shapes" displayOn="true"/>
<DebugLayer type="cluster_circle" displayOn="true"/>
<DebugLayer type="cluster_box" displayOn="true"/>
<DebugLayer type="cluster_center" displayOn="true"/>
<DebugLayer type="cluster_web" displayOn="true"/>
<DebugLayer type="cluster_rotation" displayOn="true"/>
<DebugLayer type="cluster_orientation" displayOn="true"/>
<DebugLayer type="touchobject_pivot" displayOn="true"/>
<DebugLayer type="touchobject_transform" displayOn="true"/>
<DebugLayer type="cluster_data_view" displayOn="true"/>
<DebugLayer type="gesture_data_view" displayOn="true"/>
<DebugLayer type="touchobject_data_view" displayOn="true"/>
</DebugKit>
The GAD can be configured to always "draw" for a touch object even
when no touch events are detected. This can be useful when analyzing
dynamic chart displays as it effectively takes a display snapshot and
maintains the image.
To do this set the "displayAlwaysOn" attribute equal to true. For example:
<DebugKit displayOn="true" displayAlwaysOn="true" displayRadius="300">
Additionally the peripheral views associated with the touch sprite
can be "moved" further away from the center of the touch point cluster,
which may be useful when working with both hands or large touch
surfaces.
To do this set the "displayRadius" attribute to 500. For example:
<DebugKit displayOn="true" displayAlwaysOn="false" displayRadius="500">
The debug view available in the GAD is a powerful tool for developers
to create new gestures or refine multitouch interactions in
applications. In some cases showing the full range of display data
available can be unnecessary. However the GAD has been designed to allow
developers to selectively activate required display layers and
customize the display to suit their needs.
Note:
Currently the display of all debug data () in a multitouch application
can be CPU intensive. The "complete" debug view has not been designed to
be always on in deployed applications but rather to be used to assist
developers in creating new gestures and interactions or debugging
multitouch applications. For displays that need to show simple touch
point positions it is recommended that the debugger is used to show only
the "point_shapes" debug layer.