5 ms·

For anyone who uses ffmpeg for this type of per frame analysis, `ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png` will get the "presentation

by sxp 2y ago

For anyone who uses ffmpeg for this type of per frame analysis, `ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png` will get the "presentation time" of each frame in the video. That's more precise than just dumping frames and calculating timestamps. You can also do something similar in a web browser by playing a <video> and using `requestVideoFrameCallback()`. Though, you might need to set `.playbackRate` to a low value if the computer can't decode all the frames fast enough. > With my 144Hz screen,....Wayland, on average, has roughly 6.5ms more cursor latency than X11 on my system...Interestingly, the difference is very close to 1 full screen refresh. I don't know whether or not that's a coincidence. 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. This is hard to notice consciously without training, but most people can "feel" the difference even if they can't explain it.

goalieca 2y ago
I found low latency terminals make a big improvement to even simple tasks like typing.
- daef 2y ago
  what would you count as low latency terminal?
  - layer8 2y ago
    See https://beuke.org/terminal-latency/ https://beuke.org/terminal-latency/. Single-digit milliseconds I’d say. These numbers are minus the keyboard and display latency.
    - rustc 2y ago
      Has anyone run this test on Ghostty?
      - _emacsomancer_ 2y ago
        I get a "Cannot detect the reference pattern" error when I try with Ghostty with Typometer.
    - chupasaurus 2y ago
      Some of those include display latency (e.g. Konsole) because you can't throw lazy rendering out of some terminals.
    - daef 2y ago
      thanks!
- XorNot 2y ago
  I was pretty shocked by the eyestrain difference I felt going from 30hz to 60hz with a 4K monitor while only doing coding tasks (i.e. text and mouse, no real graphics or animations).
  - askonomm 2y ago
    I recently went from 60 to 144, also on a 4k (27") monitor, and to me too it has been a very noticeable upgrade. No tearing of any kind when dragging windows around, and scrolling feels buttery smooth.
rcxdude 2y ago
It's almost certainly because of one extra frame of buffering between the mouse move and the screen. Vsync can cause this, but it should be possible to get vsync with just double buffering.
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.

by sxp 2y ago

goalieca 2y ago

I found low latency terminals make a big improvement to even simple tasks like typing.

daef 2y ago
what would you count as low latency terminal?
- layer8 2y ago
  See https://beuke.org/terminal-latency/ https://beuke.org/terminal-latency/. Single-digit milliseconds I’d say. These numbers are minus the keyboard and display latency.
  - rustc 2y ago
    Has anyone run this test on Ghostty?
    - _emacsomancer_ 2y ago
      I get a "Cannot detect the reference pattern" error when I try with Ghostty with Typometer.
  - chupasaurus 2y ago
    Some of those include display latency (e.g. Konsole) because you can't throw lazy rendering out of some terminals.
  - daef 2y ago
    thanks!
XorNot 2y ago
I was pretty shocked by the eyestrain difference I felt going from 30hz to 60hz with a 4K monitor while only doing coding tasks (i.e. text and mouse, no real graphics or animations).
- askonomm 2y ago
  I recently went from 60 to 144, also on a 4k (27") monitor, and to me too it has been a very noticeable upgrade. No tearing of any kind when dragging windows around, and scrolling feels buttery smooth.

rcxdude 2y ago

It's almost certainly because of one extra frame of buffering between the mouse move and the screen. Vsync can cause this, but it should be possible to get vsync with just double buffering.

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.