Showing the Complete Debug Views, Using CML: Activating The Gesture Analytics Display, Part 1
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:
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:
<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"/>
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:
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:
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.