Measuring Motion Latency Without a Robot Arm

Two approaches to measuring mouse latency meet at the price of the equipment. One is to buy or borrow a motorised slide and a high-speed camera, which is accurate and out of reach for almost everyone. The other is to conclude that the number is unknowable without a laboratory and rely on impressions instead. Neither is necessary.

There is a middle path. With a camera that most phones already have, a printed target, and a bit of care about what you are actually timing, you can produce a figure that is good enough to compare two mice on your own desk. It will not match a laboratory, and it does not need to.

What exactly is motion latency?

It is the gap between the mouse physically moving and the cursor visibly moving. That spans the sensor integration, the filtering, the report, the host processing, the render and the panel, which is why the number is larger than most people expect. Quoting it without saying so invites confusion with device-only figures.

Separating the device part from the display part is the first useful thing a home rig can do. If you capture both the mouse and the screen in one frame, you get the full chain. If you capture only the report, you get something much smaller and much less relevant to what you feel.

Why is a camera the simplest tool?

Because it sees both ends of the chain at once. Point a camera at a rig where the mouse and the screen are both visible, move the mouse sharply, and count frames between the physical movement and the pixel change. The frame rate sets your resolution, and modern phones record fast enough to be useful.

The method has an honest limitation: you are quantised to the frame interval. At a typical phone frame rate the resolution is coarse compared with the differences between good mice. That makes the method sound for large comparisons and useless for fine ones, and knowing which is which matters.

What does a simple rig look like?

A printed scale on the desk, the mouse on a pad next to it, and a straightedge to guide the movement. The camera looks down at an angle that includes the mouse, the scale and the monitor. A bright marker on the mouse makes the start of movement easy to identify frame by frame.

The screen needs something that changes immediately when the mouse moves: a cursor over a sharp boundary, or a simple test page that draws the pointer position as a moving bar. Anything with animation or an unknown frame budget will ruin the measurement.

How do you avoid the most common mistake?

The most common mistake is measuring the display rather than the mouse. If the test page renders at the display refresh rate, the frame quantisation of the screen dominates and every mouse looks the same. Choose a page that updates immediately on input, and say so in your notes.

The second mistake is moving the mouse by hand and calling it repeatable. Hand movements vary in speed and in where they start, which adds scatter larger than the effect you are looking for. A guided movement along a straightedge fixes half of that.

Can you get a repeatable start point?

Yes, with a simple release mechanism. A rubber band against a stop, or a small weight on a string, produces a start that is fast and consistent enough for comparison. The goal is not precision, it is repeatability, and a crude mechanism repeated many times beats a careful hand movement done twice.

Repeat each measurement many times and use the distribution. A single run tells you almost nothing; twenty runs give you a median you can trust and a spread that tells you how much to trust it.

What about timing the report instead of the pixel?

That is a different and much shorter interval, and it is where device-level figures come from. Capturing USB traffic while triggering a light sensor at the moment of movement gives you the device half of the chain cleanly, without the display in the way.

Both are worth having. The device figure tells you about the mouse; the full-chain figure tells you about your experience. Comparing them shows how much of your latency is the mouse and how much is everything else, which is usually a surprise.

How much does the host contribute?

Often more than the mouse. Running the same test on an idle machine and then with a defined background load separates the two, and in our logs the host contribution was frequently the larger part. That reframes the whole exercise from choosing a mouse to cleaning up a system.

It also explains why laboratory numbers do not transfer. A figure measured on a quiet, well-maintained machine describes that machine as much as the mouse, and your machine is probably busier.

Is there a place for software timers here?

Yes, for the device side. A small program that timestamps input events and compares them with a known physical trigger gives you repeatable numbers without a camera, as long as the trigger is genuinely external. Without an external trigger, you are timing software against itself.

The trap is measuring the event loop rather than the hardware. A timer that starts when the program notices movement is measuring the program’s own latency, and it will show differences that have nothing to do with the mouse.

How should you report a home result?

State the frame rate, the number of runs, the display refresh rate, and what the start and end of the interval were. Those four items let someone else judge whether your figure is comparable with theirs, and they take one sentence to write.

Publish the spread, not just the middle. A home rig’s value lies in comparing conditions on the same day with the same method, and the spread tells you whether a difference you saw is real or inside the noise.

What is the honest limit of this approach?

It resolves large differences and misses small ones. If two mice differ by a few milliseconds, a phone camera will not separate them reliably, and claiming that it did would be dishonest. If they differ by more, the method is entirely adequate.

That limit is fine for the questions most people actually have. Whether a hub is adding stutter, whether a firmware update changed something, or whether one mouse is clearly slower than another are all questions a home rig can settle.

Where does a home measurement lead?

How do you keep the movement repeatable?

Use a guide and a start stop, and make the movement end at the same place every time. A rail, a straightedge, or even a book spine works, and the point is that the physical path is the same rather than approximately similar. Repeatability comes from the fixture, not from care.

Release the mouse the same way each run. A rubber band against a stop or a small weight gives a consistent start, and hand-started movements add variation that swamps the differences you are trying to measure.

What is the honest resolution of a phone camera?

One frame interval, which at common rates is tens of milliseconds. That is coarse compared with the differences between good devices and fine compared with the difference between a fast display and a slow one. Know which comparison you are making before trusting the result.

You can improve it by recording at the highest frame rate available and by using many runs. Averaging reduces the quantisation error, and with enough samples the median becomes usable for comparisons that a single frame could not resolve.

How should you present a home result honestly?

As a comparison measured on one rig, with the conditions stated and the spread included. Avoid quoting an absolute figure as though it were a laboratory result, because it is not, and presenting it as one is what makes home measurements untrustworthy.

The value is entirely in the comparison. Two devices measured the same way on the same day is a result that holds up, and that is usually the question being asked.

What is the most common source of false results?

The display endpoint. If the test page renders at the display refresh rate, the screen dominates the measurement and every device looks the same. Choosing content that updates immediately on input, and stating that choice, is the difference between a real result and a meaningless one.

Check it by comparing two displays with the same mouse. If the result changes, the display was the variable all along, and the mouse comparison needs a different endpoint.

Is a single measurement ever enough?

Only for very large differences. If one device is clearly slower by a margin much larger than your spread, a few runs will show it, and more data adds nothing. For anything close, the spread decides, and the spread needs samples.

Knowing which case you are in saves time. Run a few, look at the spread, and then decide whether more data would change the conclusion.

Once the method is repeatable, the same rig answers questions about the display, the host and the cable, all of which usually contribute more than the mouse. Extending the capture to include those is the natural next step, and it changes what you spend money on next.