Hacker News Reader

Comment by mlyle | Hacker News Reader

> The fact that the latency is almost 1/144th of a second means that it might become 1/60th of a second on standard 60Hz monitors.

My guess: the "true" numbers are close to 2.5 (half a frame of random phase of when the mouse is touched vs. refresh, plus 2 frames to move cursor) and 3.5. If you throw out the low outlier from each set you get pretty close to that.

(of course, the 125Hz mouse poll rate is another confound for many users, but this guy used a 1KHz mouse).

> This is hard to notice consciously without training, but most people can "feel" the difference even if they can't explain it.

Yah. 7ms difference is not bad vs 16.6ms is starting to be a lot.

IMO, we should be putting in effort on computers to reach 1.6 frames of latency -- half a frame of random phase, plus one frame, plus a little bit of processing time.

View on HN

To have a compositor not introduce a frame of latency more or less requires it to race the beam, which has definitely been suggested[1], but you can see how it’d be difficult, and so far no operating systems have tried as far as I know. And as for good frame pacing support in UI toolkits (and not just game engines), well, one can dream. Until both of these are in place, 2.5±0.5 seems to be the hard limit, the question here is more where the Mutter is losing another frame (which even the greats tell us[2] is not hard to do by accident).

[1] https://raphlinus.github.io/ui/graphics/2020/09/13/composito...

[2] http://number-none.com/blow/john_carmack_on_inlined_code.htm...

I’ve read these arguments quite a few times and always found them a bit questionable. Sure, if everything is driven by the vblank time (or any other clock that counts in frames), it makes sense. But that’s a silly approach! There is nothing whatsoever special about allocating one full frame interval to the compositor to composite a frame — if it takes 16ms to composite reliably, it will take 16ms to composite reliably at 30Hz or 60Hz or 144Hz. So shouldn’t the system clock itself on a time basis, not a frame basis?

Put another way, a system fast enough to composite at 144Hz should be able to composite at 60Hz while only allocating 1/144 seconds to the compositor, which would require offsetting the presentation times as seen by the compositor’s clients by some fraction of a frame time, which doesn’t actually seem that bad.

It gets even better if variable refresh rate / frame timing works well, because then frames don’t drop even if some fraction of compositing operations are a bit too slow.

I assume I’m missing some reason why this isn’t done.

We have multiple processes on a time-share system. This mouse is updating at 1kHz, it just doesn't make sense consistently rerendering everything when the screen aint updating.

We need to cut some deadline and doing it at vsync is the easiest way

Actually, this is sometimes done exactly as you describe. See "AMD Anti-Lag" or "Nvidia Ultra Low Latency"/"Nvidia Reflex Low Latency".

https://news.ycombinator.com/item?id=42835019

A strong argument that it's never more than one frame's worth of latency.

Reply on news.ycombinator.com