On windows, if you have a logitech gaming mouse, you can set the polling rate. The default USB is 125Hz IIRC, on my mouse you can up it up to 1000Hz. For gaming it helps reduce input lag as much as possible since 125Hz is 8ms of input lag. For desktop usage, about 125Hz works fine.
For what it's worth, on my 120Hz screen, I can tell a difference between 125Hz and 250Hz polling rates, from 500Hz upwards I think I can tell but it might be placebo.
Yes there is. Humans are normally not very responsive to the time between when an action is started and when it is carried out on the screen, but this changes for actions like drawing and dragging. This is the reason for the new Pro Motion behavior on the recently released iPad Pro models. For more information, this video [1] is a good place to start.
"not very responsive"? I'm responsive. I mutter things like, "Shit, why does it seem that the amount of lag in my computer's response to my inputs get worse and worse as its physical components get faster and faster."
I think you misunderstood what I meant by non-responsive. 10ms latency from click to action is nowhere near as noticeable as 10ms latency when dragging, because the mouse visibly lags behind.
I think there might be. If your polling is not frequent enough, then if you observed a finger touch disappear from one spot and appear at another spot, you have no way to know whether the finger moved there in the span of one polling period or if the finger was lifted and a second finger placed at the new location during that polling period. So a high polling rate might be essential to disambiguate cases like this, especially for many-finger multi-touch situations.
Can you clarify which part you think could be handled by the touchpad's microcontroller? In order to implement modern gestures and interactions you need full access to all input events, otherwise you'd lose the ability to customize or adequately handle changes to context.
A finger touching and leaving would be a high-priority event for the controller to output, and it should probably internally monitor events at a high resolution.
For position, as reported to the OS: what use would actually need a report every 2 milliseconds? Intuitively, I'd think that motions that matter wouldn't need that many datapoints to reliably differentiate.
Remember that 500 interrupts per second isn't the same as a report every 2 milliseconds - reading status from a device may involve more than one interrupt.
It's often used to compensate for the fact that you want an up-to-date reading at arbitrary points within a frame. If you only update once per frame, and some code reads the position just before that every frame, that's going to give a full extra frame of lag, rather than just an extra 2ms.
Indeed; in fact, that microcontroller could conceivably do the same thing programs like Synergy do with the input events: namely, converting them into a stream of bezier-curve-based gesture-motion events and reporting those to the OS. I can't imagine you'd need to report those at more than 5Hz or so (Synergy manages to have smooth multitouch movement across a LAN just fine with an even-lower update rate.)
You can lift one finger and place another finger quickly enough to fool some older touchpads. I was able to do it fairly consistently with my old Dell laptop.
That's not necessarily because you could do it in a single frame; a lot of the old touch controllers would maintain high levels of hysteresis as a really crude technique to mitigate low SNR. Couple that with a fairly dumb implementation of pointer tracking and you end up easily fooling touchpad into thinking the two pointers are the same. Note also that this is a much rarer and more user-friendly failure scenario than choosing to have the software err in the other direction (erroneously splitting a moving finger into two separate pointers, one of which may look like a tap gesture).
Source: I occasionally work with touchscreens, many of which experienced the same issue in early devices.
It's a cheap/easy way to minimise the input lag. It's otherwise complicated to know exactly when updates should arrive, as different programs might fetch it at different times in each frame, giving you up to a full frame of extra lag if you're only doing it once per frame.
Yes. Suppose you poll at 120Hz. That is a maximum of 8ms between you moving your mouse and the input being registered. Suppose now you poll at 1000Hz. Input lag is now 1ms.
On windows, if you have a logitech gaming mouse, you can set the polling rate. The default USB is 125Hz IIRC, on my mouse you can up it up to 1000Hz. For gaming it helps reduce input lag as much as possible since 125Hz is 8ms of input lag. For desktop usage, about 125Hz works fine.
For what it's worth, on my 120Hz screen, I can tell a difference between 125Hz and 250Hz polling rates, from 500Hz upwards I think I can tell but it might be placebo.