Hacker News Reader

Comment by gumby | Hacker News Reader

> ...it turns out xterm has incredibly low input latency compared to modern terminals.

This boggles my mind. What on earth does a windowed terminal need to do that should result in any latency on a modern machine?

We had full ANSI-addressible displays that ran faster than the eye could read over serial lines in the 1980s. What on earth additional does a terminal program do and why would I want that?

View on HN

Well, it first needs to take the your input and pass it through the HID subsystem into userspace to the appliction, which then responds to it and sends it to the terminal, wjocj collects the output and then emulates whatever control codes there are, then updates its internal model of whatever PTY thing it is emulating, then sends that to the screen and wait for the window server to pick up on those changes and then double buffer it onto the screen…it's complicated, to say the least.

But my point is that an Ann Arbor Ambassador terminal (with logic, not even an 8-bit processor) talking to a VAX 750 (about 1/2 MIPS, also passing data from kernel into user space) was lightning fast.

The internal processor that does nothing but scan my laptop's keyboard to send events to the "computer" is more powerful than the setup we used to have. Yet the entire thing is slower.

My Mac doesn't draw any faster than the Alto I used in the 70s.

> My Mac doesn't draw any faster than the Alto I used in the 70s.

Yes it absolutely does, you just don't notice because of the increase in fidelity. What was then 640x480 pixels is now a 4K display. The total number of pixels is several orders of magnitude more, the number of colors is now 16.7 million rather than 256, and the complexity of the scene has increased where we now have anti-aliased text and alpha blending.

Also, in the 70s, you have a bitmap font of max 256 characters of equal size. Nowadays displaying text requires font selection, text shaping (incl. kerning), glyph selection, text layouting (incl. line wrapping), glyph pre-rendering, and a final assembly step to get the composite image of all glyphs.

Want to skip font selection? No emojis for you.

Want to skip glyph selection? No ligatures or Arabic or Devanagari text for you.

Want to skip text layouting? No Right-to-Left support for you.

There is a whole crapton of legitimate complexity in the font rendering stack because we don't want to have the constraints of the 70s anymore (only 256 glyphs, fixed font size, monospace font only).

(Sidenote: For those of you who think "I'm fine with monospace fonts in my terminal", I am using a monospace font as well. But "monospace font" only means that all ASCII glyphs are equal-sized, which is a tiny minority of all glyphs a Unicode font supports. I have grown a very strong opinion regarding this topic since I started to learn Japanese and hence want to be able to deal with CJK characters.)

Most terminal usage will be restricted to the English-language software and source code, for expediency reasons or because English is the lingua franca of tech. You can usually get away without RtL and ligature/wide glyph support.

What I would like to see is a terminal that has a default high-performance monospace-only rendering engine, but gracefully and dynamically switches to a different rendering engine that supports the full-blown text layout capability once the terminal detects some input that makes use of these features.

You might be surprised how often you trigger that second code path. For just one example, an increasing number of CLI programs use emoji in their output, whether you like it or not.

I'm actually a great fan of using emoji to spice up terminal output. Most of these would be fixed width too, isn't it? I know there are wide emoji, but most times I see them around one char wide.

Emoji are square, which makes them overwide under most (all?) monospace fonts.

Nit, but 640×480 -> 4k is single order of magnitude difference (307,200 -> 8,294,400).

Well the Alto was 6060 x 808 B&W bitmap display, but the machine was maybe .25 MIPS. The UI was pretty snappy -- faster than an IBM PC display.

Yours is the first comment to actually address my question.

Yet nearly every serial terminal from that era tends to struggle to handle text at >9600bps without some form of flow control at some point.

I'd love to see text spew into my Terminal emulator at 960 cps these days!

Reply on news.ycombinator.com