[jacobmischka]

The UI seems interesting, and I'm a sucker for RIIR, but why do terminal emulators keep trying to use "blazingly fast" as a feature? They're all fast (except the hideous electron ones), they're white text on black rectangles.

[GordonS]

I don't get it either - I use Windows (the default cmd, Powershell and Cmder), Linux and MacOS and don't recall a terminal emulator being slow... ever.

Yet when the subject of terminal emulators comes up, there are often comments from other HN users insisting that Windows terminal emulators are molasses compared to MacOS, or that this emulator is much faster than that. I don't get it.

[jstimpfle]

> I don't get it either - I use Windows (the default cmd, Powershell and Cmder), Linux and MacOS and don't recall a terminal emulator being slow... ever.

You might be a particular type of person... I don't remember Windows Cmd being not slow, ever. It feels extremely sluggish. It supposedly has something to do with Windows ConHost, but I don't know about the details.

In fact, even most terminals on Linux are unbearable to me. Not only do the antialised vector fonts tire the eyes on sub-4K screens - most of the terminals I've tried feel slow as well, though not as slow as Windows Cmd.

http://danluu.com/term-latency/

https://github.com/cmuratori/refterm

Personally I use xterm with bitmap fonts whenever I can, it feels sooo good. It has both crisp font rendering as well as being reasonably fast/responsive. (It's probably not the fastest ever in throughput if you want to display /dev/urandom, but that's not my benchmark).

[vidarh]

The funny thing is fast terminal rendering was a solved issue as far back as the mid 80's even on machines like the Amiga.

Yet people seem intent on inventing slow ways of doing it that then gets people to reinvent all kinds of complex ways of making it faster.

The performance differences between different terminals are indeed absolutely astounding (but rarely matters much, because the things that are much faster/slower are things you rarely do on purpose, like dumping thousands of lines to the terminal at once)

[jstimpfle]

It's all about latency and ergonomics for me.

I suppose that terminals like Gnome's [0] are slow or feel "jittery" (i.e. inconsistent latency) for example because everything needs to go through a separate terminal server process. Then, there is Desktop compositing in the way. There might even be latency added by GPU acceleration (handling double buffering badly vs naively sending pixel updates to the Display Server?). Then, vector fonts are just terrible for programming on normal [1] displays - either anti-aliased (mushy, eye-straining) or not (jagged-y).

Another issue is historically bad / incompatible VT-100 emulation. I don't know what it is and I'm not a fetishist for organically grown terminal cruft, but in any case I've always had the most trouble with Gnome and KDE (missing characters, wrong colors, wrong drawing positions) while xterm works just fine, only the occasional "tput reset" needed after dumping binary data.

[0] just talking experiences, I'm probably referring to something based on VTE? Don't use Gnome regularly.

[1] "normal" meaning sub-4k / ~100dpi, soon will have to be referred to as "older"

[vsviridov]

https://www.youtube.com/watch?v=hxM8QmyZXtg

This, I think, sufficiently explains the slowness of terminals on Windows.

[GordonS]

It's an hour long, but I watched a few snippets - is the "problem" only if you try to print megabytes of text on the terminal?

I started with computers more than 30 years ago, and have been a "power user" and coder for essentially all of that. In all that time and experience, I've never found any terminal to be slow, or found one to be noticeably "faster" than another.

[vidarh]

> It's an hour long, but I watched a few snippets - is the "problem" only if you try to print megabytes of text on the terminal?

That's pretty much where most of the terminal performance difference is on most platforms. Latency can be an issue on some, but really this was a mostly solved problem as far back as the Amiga.

I have a toy terminal written in Ruby + a tiny C extension to interface to raw xlib that currently draws individual characters and redraws the entire screen on scrolling, and even that is fast enough for most normal usage (but indeed slow at printing megabytes of text)

But getting a terminal fast enough, including on the "print megabytes of text" test boils down to a few simple principles (and you'll be "fast enough" without doing all of them even on pretty slow hardware):

* Render your text to a buffer, and only render to screen at intervals.

* Use non-blocking IO and read as much as you can into suitably sized buffers (aka: reduce pointless context switches)

* Scroll the bitmaps using whatever OS/toolkit provided functionality, rather than re-rendering the text like my stupid Ruby term.

* If you have multiple lines in your buffer, scroll once and render all of the new lines at once.

* If vector fonts, prefer to pre-render glyphs to a buffer rather than re-rendering every time.

That's about what I remember from rewriting parts of the AROS (AmigaOS replacement) terminal handling code a decade ago (does not do all of the above, but is still more than fast enough).

[samatman]

Not true!

If a terminal doesn't paint on a per-frame basis, then dumping reams of text to that terminal will slow the program to the speed of printing, this can easily be a 100x slowdown versus only updating the view when the monitor wants more pixels.

Most of them don't do this, so the ones that do are within their rights to advertise it as a feature.

[seumars]

Fast enough, sure, but nobody’s pushing the envelope. Casey Muratori recently did a proof of concept on this problem: https://mobile.twitter.com/cmuratori/status/1411437902802808...

[jacobmischka]

Interesting. I'm looking forward to watching the video, thanks for the link.

[rhacker]

"Blazingly fast" is just a buzz word. I guess at some point someone should put a requirement on that buzz word that means it has at least some response rate of X ms after key press (or mouse move).