Touch delay


Processing of a touch is expected to be instantaneous but there are situations where this may not be the case, either due to valid operational processes or due to known issues, both of which should be resolved by appropriate setting changes.

UI Element issues

UPDD Commander will seek a list of UI elements used by application dialogs and this request to the OS should be instantaneous but in some cases the response is slow which can delay gesture processing. Where applications do not satisfy this request immediately it is necessary to disable these UI element requests as discussed below.

This was especially observed in Unity apps and games created with Cocos2D-X. Because they're constantly rendering graphics, usually at 60 frames per second, they'll only respond to requests from the Accessibility API once every frame. So lots of Accessibility requests will take a long time to complete. And since they often don't report any UI elements to the system anyway, its unnecessary to make these requests.

Click nearest UI Element

A useful setting, that is enabled by default, is 'Click nearest UI element'.

With this enabled, when you click in an application, Commander will seek a list of clickable UI elements from the application and click it if it is very near to the touch.

However, some applications are either slow or fail to respond to this request, causing the following issues:

Slow response  In this case, Commander will time out this request after 250ms and generate the click at the point of touch. Unfortunately, it will delay the touch by 250ms!  If this occurs, Commander will output the message "Warning: search for nearest clickable UI element took too long" in the output log.
Fail to respond In this case, Commander was unable to search for a clickable element. It couldn't determine which UI element was touched, and therefore doesn't know which set of gesture actions to apply. Hence, there's an error and no action is taken. The output log will show two error messages:  Error: UI element task timed out
Error: applicable gesture search timed out

If either of these issues occur, you can globally disable the Click nearest UI element setting, disable it in the 'Default Gestures' definition, or you can add the application to the Application list, add a One Finger Tab gesture with the Click nearest UI element disabled for that application only. This is described in greater detail here.

UI element processing

Similar to the above issue, when performing a gesture over a specific application, Commander will seek a list of UI Element to determine if any elements have their own set of dedicated gestures and will experience the same issues described above if the application does not respond as expected to UI element requests. See here for more information and how to disable UI element processing for a specific application.

Latency issues

Latency issues, whereby the cursor movement is delayed or lags behind touch, were initially raised by users using Avid Pro Tools and Proppelerhead Reason when using small audio faders or adjusting some controls to adjust their values.

There are a number of reasons latency can occur.

Certain gesture settings are such that there could be touch latency, whereby the touch movement is delayed or lags behind point of touch, as described below.

Adjust the settings as suits your usage.

Tap

Gestures cannot be certain a single touch is actually a tap until the finger has been released and therefore has to wait a short while to see if the finger is being released within the 'tap threshold setting'. This tap delay threshold can be adjusted in the Setting dialog, Touch Gestures tab and the individual gesture definition.

Drag

By default, a single touch needs to move a minimum of 10 screen pixels in order for Gestures to detect it as a "drag" gesture so applications won't receive a mouse event until the 10 pixels have been traversed, creating the slight lag. The pixel threshold is configurable in the Setting dialog, Touch Gesture tab and the individual gesture definition. A smaller value reduces the lag or can eliminate it altogether.

Double tap

In normal usage, you will quickly tap the screen twice to produce a double click.  However, you can enable the double tap function to be associated with a different action. If this is enabled then there will be a delay on single taps (as specified in the dialog) as gestures waits to see if this is a start of a double tab gesture before generating a single click on the first tap.

The double tap setting does not need to be set for standard double click generation, only to associate a different action with the double click gesture.

Gesture sensitivity

There is also a setting for gesture detection sensitivity to adjust how accurate or responsive of the gesture detection process in the Setting dialog, Touch Behaviour tab.  This can also affect latency.

Browser usage latency

Web browsers will behave differently from other applications when using the gesture software as the gesture settings are automatically adjusted to emulate iOS usage and also to offer smart zoom on double click. With smart zoom enabled there will be a delay on each touch as gestures waits to see if a 2nd touch is following within the tap delay threshold.

Single touch usage only

If running an application that requires single touch only, no gesture support, you can either quit commander in which case the driver will generate a single touch as a mouse event or, if you prefer to still have commander running you can add the application and set for single touch mouse events whilst the the application is foremost.

This option removes all latency issues as it will immediately process the first touch and ignore subsequent touches.

Search