|Search Microsoft.com for:|
Pointer Ballistics for Windows XP
Updated: October 31, 2002
On This Page
Summary of Ballistic Performance
This paper describes the algorithms for the pointer ballistics for Microsoft Windows XP and is intended for hardware engineers, driver developers, test managers, and independent hardware vendors. The new algorithms overcome some of the limitations and fallbacks of the ballistic algorithms in the previous operating systems. The main feature results in smoother pointer movements regardless of the pointer speed setting.
Pointer Ballistics Objectives for Windows XP
The objectives of the pointer ballistics for Windows XP are to fix earlier problems and to:
Ballistics Problems Before Windows XP
Problems with pointer ballistics before Windows XP included the following:
Basic Theory of Pointer Ballistics for Windows XP
For Windows XP, we designed a transfer function that relates the actual velocity of the mouse to the actual velocity of the pointer on the screen. Then an algorithm was applied to that transfer function to calculate the transferred pointer data. To improve design by giving physical meaning to the transfer function, the arbitrary units of the system were first converted to physical units.
Relating to Physical Units
Arbitrary units of the mouse were transformed to physical units by taking the X or Y value of the mouse called mickey and scaling it using the update rate of the mouse bus and the resolution of the pointing device:
The typical bus update rate for a USB mouse is 125 Hz, and the typical pointer resolution is 400 mickey/inch. The typical range of a mickey size per packet that coming from a mouse is between 0 and +50, though +127 is allowed in the packet structure. For example, if a standard USB mouse has a constant output of 3 mickey per packet, the physical velocity of that device is 0.9375 or about 1 inch/second.
To transfer the screen from arbitrary units to physical units the following relationship was used:
For example, a typical 17-inch monitor running at 1024 X 769 will have a resolution of about 80 dpi and a refresh rate of about 75 Hz. Thus, if the data is not transformed (default setting with no ballistics) from the previous example, then at 3 mickey per packet, the pointer physically moves at 2.8 inches/second on the screen. Thus, with a USB mouse and a 17-inch screen with the above specifications, there is a physical to virtual gain of 3 (2.8/9.375). In other words, the physical velocity of the pointer on the screen is three times faster than the physical velocity of the mouse.
The Parent Transfer Function
When the physical units were established, the parent transfer function was constructed based on a usability study. The parent transfer function is illustrated in the following graph:
The transfer function consists of five points. Four of the five points reside in the lower end of the mouse velocity spectrum. The velocities that go beyond the 4-inch limit are linearly extrapolated.
The Family of Curves
A family of curves is extrapolated from the parent curve to yield a transfer function with varying speed and acceleration properties, as shown in the graph below. The user selects one of these curves using the pointer speed slider in the MouseProperties dialog box (Pointer Options tab).
The following figure shows a more detailed view of the critical inflection points of the transfer function graph.
The slope of the first line segment yields a physical-to-screen gain of less than one gain, providing the precision movement and ability to target every pixel on the screen, or subpixilation. Subpixilation is when the user has to move the mouse physically farther than the pointer moves on the screen, giving a high degree of precision and stability at low velocities. To achieve subpixilation, the divided remainder mouse counts have to be preserved and added into the next counts.
The following figure shows the same close-up with the family of curves. The most important feature to note is that regardless of whether a fast or slow curve is selected, the first set of points tends towards subpixilation, which means that the user is always able to target every pixel on the screen regardless of the mouse speed setting.
The transfer function is stored as a lookup table, and the points between the stored values are interpolated. The number used to look up the mouse X and Y translated values is the vector magnitude of incoming X and Y magnitudes. The ballistic algorithm used before Windows XP independently calculated the acceleration multiplier from X and Y. Therefore, the movement of the pointer was biased towards the greater axis, which resulted in rounded squares instead of perfect circles. To solve this problem, the vector magnitude of X and Y is now used to calculate the acceleration multiplier and is then applied to translate the X and Y data.
Fixed Point Math and Number Bounds
The ballistic Windows XP pointer algorithm resides between ring0 and ring3. Therefore, floating point math is not readily available, and because the Windows XP ballistics required the use of division with a remainder, fixed-point (16.16) integer math was used. This is important for the subpixilation and the increased smoothness of the pointer movement. Therefore, the maximum resultant number from two products is 2^16 (65536). While an overflow is possible, it is very unlikely. If an overflow ever becomes a problem in the future, the fixed point constants in the ballistics code are easily changed to support a 20.12 fixed-point format.
Changing the Transfer Function
The values of the parent curve are stored in a registry setting, its possible to modify and customized the curves and could be achieved easily with a GUI. These characteristics should allow programmers and users custom control of the pointer ballistics to meet a wide variety of needs. Five X and Y pairs are stored in 16.16 fixed point format.
Summary of the Ballistic Algorithm for Windows XP
The following list summarizes the ballistic algorithm used in Windows XP, in sequence: