
A look at terminal emulators, part 2 - vquemener
https://lwn.net/Articles/751763/
======
secure
Shameless plug: the article pins the minimum latency of your keyboard to 3ms.
I recently published the kinX, a keyboard controller for the Kinesis Advantage
with merely 0.2ms of input latency:
[https://michael.stapelberg.de/posts/2018-04-17-kinx/](https://michael.stapelberg.de/posts/2018-04-17-kinx/)

~~~
Sidnicious
That article led me to the page on Cherry’s site about their “analog keyboard
controller”, which promises no scanning latency. “Analog” suggests to me that
each key has its own power-of-two-ish resistor value, and the controller can
just look at the total resistance to see which keys are pressed. Does this
seem plausible? If so, it could be a fun way to build a DIY keyboard.

~~~
kevin_thibedeau
More likely they are just using a package with enough pins to discretely input
every key without a scan matrix. There are no real cost constraints on doing
this nowadays with modern IC packaging. The added hardware inside to track all
those inputs is inconsequential with modern process technologies. Then their
marketing dept. got a hold of it and came up with some BS to sell it.

~~~
adrianratnapala
Yes sounds a lot easier than the resistor thing (though even that sounds
doable).

------
deng
All these latencies are well below 50ms worst-case. For me, those are
perfectly fine for typing. While it is obvious that high latencies have an
adverse affect on typing, there certainly is a "good enough" threshold. I find
it very hard to believe that you'd be able to see any difference in typing
with 2ms and 20ms latency. The article even implies that terminals with higher
latency might cause RSI, which is damn close to fearmongering. The article
also claims that the GNOME Human Interface Guidelines require 10ms latency,
while clicking that link shows "0.1s", which is much more reasonable. And just
to be clear: I'm strictly talking about typing. I do not question that in
other areas latencies have to be much lower than 50ms (like mouse movement,
music making, etc.).

~~~
ddingus
While I agree with most of what you put here, the idea that higher latencies
may contribute to RSI is plausible.

A while back, I was showing symptoms. It turns out, that I was tensing during
periods of waiting to see feedback. Now, being aware of it, it's no big deal,
and I don't do it anymore. Symptoms gone.

~~~
antjanus
As a gamer, I wonder how noticeable this latency truly is (2ms - 50ms). The
browser runs at "60fps" so any input, by default has a 16ms delay (unless I'm
understanding the browser incorrectly). This kind of delay does not phase me
one bit. However, if it was 3 frames (ie. ~50ms), how much would that bother
me?

~~~
ddingus
Lands right in the "sees last char input hit the screen as next one is being,
or about to be typed" range, depending on typing speed.

~~~
matt4077
50ms = 0.05s = 1/20s

Are you sure you're typing 20 letters per second?

~~~
ddingus
No, not often. For some common words yes. Depends on keyboard at that point.
Some will take it, some won't.

In game terms, input can approach that speed, which is really what I was
writing to. Should have said, by analogy.

For me, a whole lot depends. If I am transcribing, I look at the screen, and
it can matter. Same for a quick type of a common phrase. I'll blast that out.

For most things, it's a few CPS and slower.

And this is all modal. Interactive, like cursor navigation is different from
general character input, which is different from common, short words.

------
craftyguy
It's surprising how (relatively) poorly Alacritty did. The first question in
their FAQ still says:

> Is it really the fastest terminal emulator?

> In the terminals I've benchmarked against, alacritty is either faster, WAY
> faster, or at least neutral. There are no benchmarks in which I've found
> Alacritty to be slower.

Despite them already acknowledging that they have problems with latency[1]

1\.
[https://github.com/jwilm/alacritty/issues/673](https://github.com/jwilm/alacritty/issues/673)

~~~
ohazi
For a long time, the response to "but what about scrolling?" has been "eh,
just use tmux"

I think the author may have walked back on that a bit, but this is definitely
the thing that turned away most of the people I know who tried it.

~~~
craftyguy
I actually just started using alacritty full-time recently, after walking away
from it a few months ago because of the lack of scrollback. The only reason
I'm back is because I am now super comfortable with using tmux in my workflow
(and tmux's scrollback), so I don't _need_ scrollback in a term. emulator any
more.

------
llimllib
iterm2's new metal renderer[1] has greatly increased my terminal happiness on
mac. Highly recommended.

[1]: [https://gitlab.com/gnachman/iterm2/wikis/Metal-
Renderer](https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer)

~~~
kahlonel
I just tried it, ran `time cat bigassfile.txt` test. How come it is slower
after I enabled this? I have a mid-2013 MBA.

~~~
gnachman
When the metal renderer is enabled the screen updates at 60fps. When it is not
enabled, the refresh rate is governed by the current bandwidth. There are
cases where the new renderer has lower throughput because it does not use
adaptive framerate. I’ll look into this.

~~~
pvg
As another datapoint: for a 100k line log file, iterm2 had up to 2.5x
variability between runs and the fastest was about twice slower than
Terminal.app.

------
makecheck
I wonder how much “deep” profiling we can do to improve things, e.g. to know
how much is just graphics, how much is time spent processing byte-sequence
spam, or heck even time spent processing scrollback buffers and stuff. I
suspect it would turn out to be a mix. And I strongly suspect we could
identify just a handful of efficient terminal sequences and push for broader
support of the most efficient ones (i.e. things that directly tell the
emulator to do X instead of receiving three dozen other sequences that produce
the same result).

Graphics are a likely culprit but even then there can be multiple layers to
the problem, sometimes literally. Putting bits in a window can be surprisingly
expensive and it’s hard to have nice bells and whistles and speed at the same
time.

It’s hard when given many bytes at a time. I once observed that simply by
splitting a “vim” buffer vertically, my terminal received a significantly
greater number of bytes (such as extra spaces for layout and several more
special terminal sequences). The split also seemed to trigger more “full
screen” or “most of screen” refreshes, versus smaller and cheaper updates that
were typical of single editors. Scrolling, as it turns out, is a lot more
complex in a split buffer.

------
s_gourichon
Wow, is a terminal emulator expected to write content to your /tmp? Security!

> It turns out the VTE library actually writes the scrollback buffer to disk,
> a "feature" that was noticed back in 2010 and that is still present in
> modern implementations. At least the file contents are now encrypted with
> AES256 GCM since 0.39.2, but this raises the question of what's so special
> about the VTE library that it requires such an exotic approach.

[https://bugzilla.gnome.org/show_bug.cgi?id=664611#c48](https://bugzilla.gnome.org/show_bug.cgi?id=664611#c48)
seems to clarify. This affects all vte-based terminal emulators, but only when
setup to unlimited scrollback.

See [https://lwn.net/Articles/752924/](https://lwn.net/Articles/752924/) for a
quick test I made which seems to confirm that in the limited scrollback case,
nothing is written to disk.

------
ninjakeyboard
I started using Cathode a lot. It has terrible input latency, destroys my
battery, is very hard to read, but coupled with some cherry blue switches it
really brings me back to a better time.

If I ever need to blow off some steam, I just start smacking the "degauss"
button.

Puts the meta key in the wrong place but I'm usually using vim for remote
editing anyway.

------
majewsky
The difference between Vim (GTK2) and Vim (GTK3) is rather jarring. I have two
hypotheses:

1\. GTK3 is just slow.

2\. The GTK2 code path in Vim is older and thus more optimized than the GTK3
code path.

Which one is it?

~~~
gue5t
I would put good money on the first one, based on experience with GTK
development and my guesses about the way Vim uses GTK (presumably, they don't
do anything different across GTK2/GTK3 that they don't have to).

------
jwilk
First part:

[https://news.ycombinator.com/item?id=16894706](https://news.ycombinator.com/item?id=16894706)

------
zokier
While I understand that testing all terminals like this would be unreasonable
to ask, I would have liked to see at least couple of real end-to-end tests,
i.e. captures with high-speed camera looking at keyboard-to-display latencies.
Considering how complex the whole pipeline is, that would have helped to
validate the methodology used and might have also revealed some additional
differences due the way the applications render themselves.

------
microcolonel
Keep in mind that most monitors are at least 10ms late, on top of the inherent
latency introduced by the refresh rate, and most input devices are very late
as well.

------
andreypopp
Really surprised the didn't include Kitty terminal. It is the fastest I found
on macOS (even compared to Alacritty) when using PragmataPro font (which made
me switch away from Terminal.app due to slow rendering).

~~~
qyron
Can't agree more! With all respect to Alacritty, I find Kitty easier to
install/update, having more features and at least comparable performance (as
it also uses OpenGL for rendering). Overall it seems a pretty mature product
and the author is very responsive to Github issues.

I'd like to see it more in these terminal-related articales and discussions...

------
pasabagi
Just set up uxterm - and I don't know if this is placebo, but it feels
noticably snappier than urxvt.

~~~
arca_vorago
I prefer urxvt, but it does take customization and work to get it up to par
feature wise, but that's a good think as that's the power of urxvt in the
first place. I also have a strange affinity for the xfceterminal, I use it
sometimes even though awesome is my wm.

------
archi42
Hm, gedit is in there, but kate is missing ;) But interesting article: I use
Terminator (I like the tiling functionality) and vim as my editor, and it did
not feel that "slow" to me (compared to konsole or gnome-terminal; but that's
of course terribly subjective).

~~~
zlynx
gnome-terminal never felt slow to me. I tried out a few of these other
terminals and honestly, alacritty and terminology and gnome-terminal all feel
exactly the same.

------
JdeBP
There's a whole class of terminal emulators that this ignores, including (but
not limited to) bogl-bterm, zhcon, kmscon, fbpad, fbterm, the one in Linux
itself, and console-terminal-emulator+console-fb-realizer.

------
danmg
mlterm also supports sixel, regis and tektronix modes.

------
partycoder
Never tried mlterm before... it's insanely fast.

------
apatheticonion
Okay, so this is a thing.

