Clean velocity data
Windows is focusing on making the touch experience cleaner and smoother. To help, partners can ensure that they provide realistic velocity modeling in their touch reports; that is, the digitizer must report the realistic velocity of the user between any two consecutive reports for any given contact.
Finger contacts screen (down)
As the finger makes contact with the screen, it is important to quickly determine whether the contact is real, as this latency will manifest itself in delayed input to the screen, which will be exacerbated if the user quickly begins to move. <Digitizer.Touch.Latency> defines the allowable amount of latency for a Windows system, but we always encourage the lowest possible value whilst maintaining noise resistance.
Finger begins to move (disambiguation)
As the contact begins to move, we must make a trade-off between holding steady in the presence of noise or involuntary movement and reacting quickly to an intended movement.
We assume the existence of a disambiguation zone, within which movement is discarded and the contact is reported as stationary. If this area is too large, the user will perceive a lag, or jump, in following the motion across the screen, and any program that attempts to smooth velocity will be disadvantaged by the sudden change in position of the reported contact.
The disambiguation zone should be as large as necessary to meet the <Digitizer.Touch.Jitter> requirement, and no larger.
Finger continues to move (pan or swipe)
After the contact is deemed to be in motion, it is very important to maintain a realistic representation of its progress across the screen. If the contact is moving at a constant speed of 200 mm/s, then the digitizer should report a change in position of approximately 200 mm/(seconds/report interval). For example, given constant report interval of 10 ms, we would expect the digitizer to represent a change in position of 2.0 mm per report.
In the case of a swipe, motion is often accelerating in one direction, and in this situation we expect that the digitizer will represent this as a uniformly increasing (or decreasing) change in position between consecutive each reports. When this is not the case, the user will see a misrepresentation of the intended speed in an application, as the program must overcome what appears to be stoppage or backtracking.
Finger leaves screen (up)
It is very important to report the removal of a contact as quickly as possible and optimally within 15 ms, as this latency will manifest itself to the user in the form of improper speed representation in touch applications. An ideal stream of reports for a moving contact would appear as a sequence of TIP-down reports with position data reflecting the true rate of motion, followed by a single report with the TIP flag removed, and the same position as the final TIP-down report. See Windows pointer device data delivery protocol for state transition details.