4 ms·

Are these better than XTerm wrt latency? I find XTerm (in Linux) and Terminal.app (in macOS) much snappier. These measurements seem to agree with my subjectiv

by nextos 4y ago

Are these better than XTerm wrt latency? I find XTerm (in Linux) and Terminal.app (in macOS) much snappier. These measurements seem to agree with my subjective perception: https://danluu.com/term-latency https://danluu.com/term-latency

aumerle2 4y ago
kitty is much better than the rest on latency, see hardware based measurements https://thume.ca/2020/05/20/making-a-latency-tester/ https://thume.ca/2020/05/20/making-a-latency-tester/ showing kitty has the same latency as terminal.app on macos.
p-e-w 4y ago
Those measurements are several years old and thus say essentially nothing about the current generation of these terminals, which are all under very active development. XTerm is X11 only. Considering that Wayland is much more lightweight than X11, it's hard to imagine XTerm beating e.g. Foot, which is purpose-built for modern Wayland desktops, with almost no abstraction in between. Not to mention that these terminals have much better overall engineering than XTerm, whose README famously states "This is undoubtedly the most ugly program in the distribution." That line alone is enough for me to avoid XTerm like the plague.
- AceJohnny2 4y ago
  > Considering that Wayland is much more lightweight than X11 That's irrelevant. More relevant is that Wayland is adamant about presenting "perfect frames" (ie no frame tearing), which requires a sync/checkpoint for everything that's displaying, which inherently puts a lower bound on latency that non-sync-respecting X11 isn't subject to.
  - arghwhat 4y ago
    What's more relevant is that Wayland is adamant on ensuring that scanout is an option as often as possible, making it extremely efficient and fast to put stuff on screen. Also, every pixel has a "checkpoint" sampled at the display refresh rate. With tearing, the checkpoint of a pixel differs from its neighbors, with each subsequent pixel (leading to rolling shutter artifacts), whereas without, all pixels show the same sample. At the cost of glitches, tearing and higher render load let's you put slightly newer data in the bottom third or quarter of your screen. Not really something to write home about, especially considering that X11-users commonly run external compositors exactly to get that tear-free behavior.

by nextos 4y ago

aumerle2 4y ago

kitty is much better than the rest on latency, see hardware based measurements https://thume.ca/2020/05/20/making-a-latency-tester/ https://thume.ca/2020/05/20/making-a-latency-tester/ showing kitty has the same latency as terminal.app on macos.

p-e-w 4y ago

Those measurements are several years old and thus say essentially nothing about the current generation of these terminals, which are all under very active development. XTerm is X11 only. Considering that Wayland is much more lightweight than X11, it's hard to imagine XTerm beating e.g. Foot, which is purpose-built for modern Wayland desktops, with almost no abstraction in between. Not to mention that these terminals have much better overall engineering than XTerm, whose README famously states "This is undoubtedly the most ugly program in the distribution." That line alone is enough for me to avoid XTerm like the plague.

AceJohnny2 4y ago
> Considering that Wayland is much more lightweight than X11 That's irrelevant. More relevant is that Wayland is adamant about presenting "perfect frames" (ie no frame tearing), which requires a sync/checkpoint for everything that's displaying, which inherently puts a lower bound on latency that non-sync-respecting X11 isn't subject to.
- arghwhat 4y ago
  What's more relevant is that Wayland is adamant on ensuring that scanout is an option as often as possible, making it extremely efficient and fast to put stuff on screen. Also, every pixel has a "checkpoint" sampled at the display refresh rate. With tearing, the checkpoint of a pixel differs from its neighbors, with each subsequent pixel (leading to rolling shutter artifacts), whereas without, all pixels show the same sample. At the cost of glitches, tearing and higher render load let's you put slightly newer data in the bottom third or quarter of your screen. Not really something to write home about, especially considering that X11-users commonly run external compositors exactly to get that tear-free behavior.