Drag thresholds must scale with input precision and display density, not fixed pixels
Aliases: display density · input precision · threshold scaling
What it is
A drag-start threshold should vary with input precision and display density, rather than remain a fixed CSS or physical pixel count. The same pixels represent different hand motion and visual distance on a high-DPI mouse, low-resolution trackpad, large scaled display, and small screen, altering the balance of false and missed drags.
Why it happens
Device sampling, pointer gain, display scale, and app zoom jointly turn physical movement into screen displacement. Fixed pixels ignore that chain: a value that filters noise in one context is oversensitive or sluggish in another. There is an easily overlooked coupling here: if the threshold is defined in raw device sample counts (sometimes called mickeys) rather than logical screen pixels, it must scale together with exactly the same gain curve applied to cursor displacement — otherwise the same amount of physical hand movement produces far more raw counts on a mouse with a higher-resolution sensor than on one with a lower-resolution sensor, and even though the system has already used gain to equalize their on-screen displacement, if the threshold does not apply that same gain curve, the physical hand travel needed to trigger a drag will differ between the two mice — a difference that should not exist, since the cursor movement the user perceives is identical either way.
Studying it
Repeat click and short-drag tasks across DPI, scale, mice, and trackpads, comparing error rate and actual movement distance. Record system settings, not only pixels, and verify consistency at the perceived level of slight movement. A more direct test measures the actual physical hand displacement needed to trigger a drag (in millimetres, not screen pixels) and compares that quantity across devices — if it stays roughly constant, the threshold is properly tied to the gain curve; if it comes out noticeably smaller on a high-DPI device, the threshold was defined purely in screen pixels without scaling to raw sampling precision.
Where it stops holding
Scaling does not remove individual difference, tremor, or task need; system defaults may not suit specialist canvases or accessibility contexts. Avoiding fixed pixels does not require a continuously changing number — clear device-level bands can be more predictable.
Applying it
- Prefer platform drag thresholds, or a value computed jointly from logical density and the gain currently in effect, rather than hard-coding a screen-pixel count.
- Regression-test across displays, scale changes, and pointer devices, specifically covering mouse pairs with a large DPI gap.
- How to check: have the same participants trigger a drag on devices with different DPI and measure the physical hand travel each requires, comparing that physical quantity rather than the pixel count, to confirm the experience is actually consistent.
Related
- Same group: C1.22.1 A threshold that is too small misclassifies natural hand tremor as drag intent · C1.22.2 A threshold that is too large discards real short drags as clicks · C1.22.4 While held below threshold, the cursor should show no drag feedback · C1.22.5 A directional threshold can distinguish horizontal dragging from vertical scrolling at gesture start
- Nearby: C1.01 Types and properties of pointing devices · A1 Human capabilities and human-factors foundations
- Search terms:
DPI·drag threshold·input precision
Cards in the same group
- C1.22.1A threshold that is too small misclassifies natural hand tremor as drag intent
- C1.22.2A threshold that is too large discards real short drags as clicks
- C1.22.4While held below threshold, the cursor should show no drag feedback
- C1.22.5A directional threshold can distinguish horizontal dragging from vertical scrolling at gesture start