3 ms·

> 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

by mlyle 2y ago

> 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.

mananaysiempre 2y ago
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/compositor-is-evil.html https://raphlinus.github.io/ui/graphics/2020/09/13/composito... [2] http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm...
- amluto 2y ago
  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.
  - j16sdiz 2y ago
    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
  - GrantMoyer 2y ago
    Actually, this is sometimes done exactly as you describe. See "AMD Anti-Lag" or "Nvidia Ultra Low Latency"/"Nvidia Reflex Low Latency".
cryptonector 2y ago
https://news.ycombinator.com/item?id=42835019 https://news.ycombinator.com/item?id=42835019 A strong argument that it's never more than one frame's worth of latency.

by mlyle 2y ago

mananaysiempre 2y ago

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/compositor-is-evil.html https://raphlinus.github.io/ui/graphics/2020/09/13/composito... [2] http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm...

amluto 2y ago
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.
- j16sdiz 2y ago
  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
- GrantMoyer 2y ago
  Actually, this is sometimes done exactly as you describe. See "AMD Anti-Lag" or "Nvidia Ultra Low Latency"/"Nvidia Reflex Low Latency".

cryptonector 2y ago

https://news.ycombinator.com/item?id=42835019 https://news.ycombinator.com/item?id=42835019 A strong argument that it's never more than one frame's worth of latency.