I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-:
There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly, and some do, almost everyone tries to support this colour system now.
See the screenshot of the old syscons FreeBSD kernel built-in terminal emulator at https://tty0.social/@JdeBP/110424206935120790 for what I mean by really badly. It still does understand the control sequences, though.
I switched to Terminal.app from iterm2 almost 10 years ago because of horrific scroll and input latency for iterm2 after one of the osx upgrades (maybe Mavericks or Yosemite?). For the last few years I've been using kitty, which works well and for my setup allows me to eschew tmux. But Terminal.app still mostly just gets the job done so if it's working for you, I'd say stick with it.
Also, Terminal.app is really bad at rendering Unicode block characters correctly. It doesn't space them correctly vertically, so if you have a lot of block chars it looks like total garbage. iTerm/kitty/etc. all render it correctly.
I’m sticking to Terminal.app for the reasons stated by you in this thread. It works, it’s fast and text renders beautifully with whatever theme you fancy.
However, it could use some love from Apple. Better keyboard-only text selection, horizontal and vertical splitting, True Color (not Cyndi Lauper style)…
I love that Terminal.app, out of the box, changes the colorcheme depending on your desktop dark or light configuration. iTerm does this on new versions, but only on 10.14 and later, which my company doesn't support yet :-p
I actually have the opposite problem. I’d like to limit terminal apps to just the 16 colours I have defined in my terminal settings (which is actually 3 colours in my case), but some apps (like the rust compiler e.g.) emit escape sequences which slightly change the shade in some places, in 256 colour space. I’d like to disable those 256 colours and limit everything to 16. I don’t think I can though.
Sometimes "now with added GPU" is not the issue at all.
There's a demo program that comes with libcaca, called cacademo. It can either output text to standard output with ECMA-48 control sequences, or crank up a built-in X client that displays a very simple text window.
I SSHed into a remote machine with it from a local machine that had an X server. Tunnelled over the SSH connection, the X version of the demo was a little slower than running directly on the remote machine's own display, but mostly didn't drop frames. The mode where it sent ECMA-48 control sequences over the SSH connection to a local terminal emulator was woefully slower, to the point that it was displaying less than 1 frame a second sometimes, and visibly tearing the display. I tried it with both Microsoft Terminal and MobaXTerm to see whether it was the terminal emulator. It wasn't.
Sending colour information as ITU-T T.416 RGB control sequences, or even as AIXTerm 16-colour control sequences, to be interpreted by a control sequence state machine in the terminal emulator and turned into a display buffer and graphics drawing commands, turns out not to be as efficient over SSH as the X protocol over SSH. Yes, X11.
The X path was going through an X client library to the X server. It was probably using the old X11 primitives for text, rather than doing client-end rendering. The terminal emulator path was going through ncurses, then probably wasn't being batched up very much over the SSH connection, and then was going through a decoder that had to (amongst other things) parse numbers from human-readable to machine-readable thousands of times per frame because ECMA-48 uses decimal-character-encoded values in control sequences, and the cacademo program outputs lots of colour changes, frequently a colour change for each successive cell.
No. But it was like for like. It was the one single SSH connection in both cases, simply running cacademo with and without a DISPLAY environment variable.
I think that part of the problem lies with SSH: the lack of batching as I mentioned, which might also be at ncurses' door too. Of course one wants terminal output to go over the wire as soon as possible, and not wait "until we have a buffer-ful". But not in this case.
Rather, batching up the control sequences to change colour, cursor position, and then output the relevant character into a single exchange over the wire would be better. That would be equivalent to a an X primitive to write character X at position Y with attributes Z, which presumably goes as a single message over the wire.
But a combination of whatever output buffering ncurses and libcaca are doing, what happens in the pseudo-terminal and sshd at the remote end, and then what happens at the local end when ssh is outputting to its pseudo-terminal, are all almost certainly strongly militating against that.
... In addition to converting lots of numbers from machine-readable to human-readable, then back to machine-readable again. (-:
I should mention that at one point I was transcoding from AIXTerm to ITU T.416 colour control sequences. The latter are about 4 times as long as the former, and that noticeably slowed things down even further. Yes, I'm in favour of 24-bit colour like the other terminal emulator authors, but it does come at a measurable price.
Cool! Porting to the web is an interesting idea. I can’t help but imagine going back to the 70s and trying to show someone that yes, everyone has this full colour, mouse-supporting, GUI app platform accessible on any device and interlinked between billions of similar interactive documents from around the world… but it was really important that we set up a TTY. The smug (or horrified) look on their face would be priceless.
Yeah I'd love to know what this is aiming for over WezTerm, which already supports both WebGPU and OpenGL rendering. Maybe just that it is closer to being able to run in a browser?
I have to take a moment to just evangelize WezTerm a bit. I switched over from iTerm in the last few months and IMO WezTerm's absolute killer feature is its Lua-based configuration. You can do so much with it, down to running scripts on key binds, and the API is powerful enough to do virtually anything you want. For example I have some key binds that act differently when the active pane is running emacs vs. a shell.
Meanwhile I have to wonder what's the selling point of these over good old urxvt? It has an ecosystem of perl plugins, which has all the batteries I need and more. In its daemon/client mode I can have 20+ terminal windows open and they consume sum total of like 30MB memory, with embedded perl interpreter and everything. I feel like one or two instances of these modern incarnations is enough to completely dwarf that number.
GPU rendering is really cool, but I don't really understand what might people be doing where CPU rendering in terminal is anywhere close to being a bottleneck. People lose ability to comprehend way before that, why would I want gibberish to be printed even faster? Redirecting output to a file (or /dev/null) is almost always what I would want?
Well, if you search for these projects yourself and read the first few paragraphs on their websites, you might learn the selling points. Warp has a lot of features that are just not possible in urxvt.
Kitty also has the benefit of supporting much better keyboard handling through key codes. This includes things like button press/release/repeat, other keyboard modifiers and better escape handling. More details: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
It's really a shame that more terminals don't support this protocol, because we could have a lot more sophisticated terminal applications.
Thanks for the recommendations! Since switching from Kubuntu to Ubuntu, I have been looking for a replacement for Konsole and had finally settled on Terminator, but one major gripe I have with it is searching the scrollback, which is a bit buggy (results aren't highlighted, search is case sensitive even though it's not supposed to be). I just tried Wezterm and it seems to tick all the boxes. Now I just have to figure out how to configure it, seems a bit more complicated than most other terminal emulators...
This is anyway a niche market on Linux - you can go really far with gnome/kde default terminals, and even slimmer ones like xterm/urxvt/st are more than enough to perform all the necessary tasks.
Perhaps, on Mac, you badly need an alternate terminal app , because the default one is unbearably slow.
As someone who still just uses whatever terminal emulator my desktop environment provides, what are the advantages of choosing another terminal emulator application? Also, what's the point of providing GPU rendering on the terminal? I've never experienced latency or any problems otherwise related to rendering, so I wonder why some terminals nowadays pride themselves in using GPU rendering. Am I missing something?
Also, which terminal emulator would you recommend?
Some older terminals are slow enough to rate limit text output from things like streaming logs. I don't think that's specifically a GPU versus CPU, though.
I use Terminology, from the Enlightenment WM team. It's fast, supports unicode, is easily configurable, and behaves how I, personally, prefer. But if you don't really have a preference, I don't think fancy different terminals are going to be that important.
It may have something to do with this mind blowing exchange between Casey Muratori (a highly experienced game engine developer) and the Microsoft Terminal team.
It really highlighted how crappy software gets written in large corporations. They told him rendering monospaced fonts on the GPU would involve a multi year PHD research project.
Apparently they then went on to infiltrate his discord server so they could ask questions. Then write up a blog post calling the change "trivial".
As it turns out, the thing Muratori suggested absolutely _didn't_ work for a large variety of edge cases. That was experimented with for a couple releases before being even _more_ substantially rewritten: https://github.com/microsoft/terminal/pull/14959
I hate that what was definitely intended as a joke originally turned into this massive miscommunication and flame war. Admittedly tone is hard to convey on the internet, and italics is no replacement for a good old fashioned ":P". But this could have been a good place for everyone to work together, rather than flame one another.
It's certainly an experience that everyone can learn from.
I think it is a little like when people trick out their honda civic with led lights, and new speakers, etc. It is fun, but you can get to all the same places just as well with a stock honda civic. IOW it seems there are a subset of hackers that are sort of terminal hobbyists.
You never seen a case where a slow terminal would throttle the app running because it couldn't render output fast enough ?
I use JetBrains IDEs and honestly their built in terminal emulators are embarrassingly slow. VSCode is buttery smooth in comparison. Sad state of things.
I use Terminator. I like all of the configuration that's possible with the layouts that can be done, plus it has right-click to paste, which I got used to with PuTTy. The default Terminal in Debian is very bare-bones by comparison.
Probably portability, it's a pretty good low (but not too low) abstraction layer over the systems preferred graphics API. I'm not a graphics programmer but my understanding is it's closer to vulkan or metal in terms of control over the hardware compared to OpenGL, which has rocky support on Mac now anyways.
WebGL is not really related to WebGPU in any way. WebGL is almost a strict subset of Gles3, WebGPU is a completely different API, sharing on a few concepts. They're about as related as Java and JavaScript
How does one get full CJK Input Method Editing working for a project like this?
I've sort of been looking into it and it doesn't seem there are cross platform libraries for handling IMEs and not many people talk about even the platform-specific APIs.
Readit News
There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly, and some do, almost everyone tries to support this colour system now.
See the screenshot of the old syscons FreeBSD kernel built-in terminal emulator at https://tty0.social/@JdeBP/110424206935120790 for what I mean by really badly. It still does understand the control sequences, though.
I still stubbornly use it as my daily driver for some probably terrible reason.
However, it could use some love from Apple. Better keyboard-only text selection, horizontal and vertical splitting, True Color (not Cyndi Lauper style)…
It's a 96 GiB of RAM machine, for chrissake! That ought to be enough for everybody!
(That's the big push that I mentioned. Going since January 2014.)
Deleted Comment
Dead Comment
There's a demo program that comes with libcaca, called cacademo. It can either output text to standard output with ECMA-48 control sequences, or crank up a built-in X client that displays a very simple text window.
I SSHed into a remote machine with it from a local machine that had an X server. Tunnelled over the SSH connection, the X version of the demo was a little slower than running directly on the remote machine's own display, but mostly didn't drop frames. The mode where it sent ECMA-48 control sequences over the SSH connection to a local terminal emulator was woefully slower, to the point that it was displaying less than 1 frame a second sometimes, and visibly tearing the display. I tried it with both Microsoft Terminal and MobaXTerm to see whether it was the terminal emulator. It wasn't.
Sending colour information as ITU-T T.416 RGB control sequences, or even as AIXTerm 16-colour control sequences, to be interpreted by a control sequence state machine in the terminal emulator and turned into a display buffer and graphics drawing commands, turns out not to be as efficient over SSH as the X protocol over SSH. Yes, X11.
The X path was going through an X client library to the X server. It was probably using the old X11 primitives for text, rather than doing client-end rendering. The terminal emulator path was going through ncurses, then probably wasn't being batched up very much over the SSH connection, and then was going through a decoder that had to (amongst other things) parse numbers from human-readable to machine-readable thousands of times per frame because ECMA-48 uses decimal-character-encoded values in control sequences, and the cacademo program outputs lots of colour changes, frequently a colour change for each successive cell.
I think that part of the problem lies with SSH: the lack of batching as I mentioned, which might also be at ncurses' door too. Of course one wants terminal output to go over the wire as soon as possible, and not wait "until we have a buffer-ful". But not in this case.
Rather, batching up the control sequences to change colour, cursor position, and then output the relevant character into a single exchange over the wire would be better. That would be equivalent to a an X primitive to write character X at position Y with attributes Z, which presumably goes as a single message over the wire.
But a combination of whatever output buffering ncurses and libcaca are doing, what happens in the pseudo-terminal and sshd at the remote end, and then what happens at the local end when ssh is outputting to its pseudo-terminal, are all almost certainly strongly militating against that.
... In addition to converting lots of numbers from machine-readable to human-readable, then back to machine-readable again. (-:
I should mention that at one point I was transcoding from AIXTerm to ITU T.416 colour control sequences. The latter are about 4 times as long as the former, and that noticeably slowed things down even further. Yes, I'm in favour of 24-bit colour like the other terminal emulator authors, but it does come at a measurable price.
Deleted Comment
- Alacritty minimal and blazingly fast
- Wezterm with batteries included
- Warp even batteries included
I have to take a moment to just evangelize WezTerm a bit. I switched over from iTerm in the last few months and IMO WezTerm's absolute killer feature is its Lua-based configuration. You can do so much with it, down to running scripts on key binds, and the API is powerful enough to do virtually anything you want. For example I have some key binds that act differently when the active pane is running emacs vs. a shell.
GPU rendering is really cool, but I don't really understand what might people be doing where CPU rendering in terminal is anywhere close to being a bottleneck. People lose ability to comprehend way before that, why would I want gibberish to be printed even faster? Redirecting output to a file (or /dev/null) is almost always what I would want?
It's really a shame that more terminals don't support this protocol, because we could have a lot more sophisticated terminal applications.
Perhaps, on Mac, you badly need an alternate terminal app , because the default one is unbearably slow.
https://danluu.com/images/term-latency/loaded-terminal-laten...
Also, which terminal emulator would you recommend?
I use Terminology, from the Enlightenment WM team. It's fast, supports unicode, is easily configurable, and behaves how I, personally, prefer. But if you don't really have a preference, I don't think fancy different terminals are going to be that important.
https://github.com/microsoft/terminal/issues/10362
It really highlighted how crappy software gets written in large corporations. They told him rendering monospaced fonts on the GPU would involve a multi year PHD research project.
Apparently they then went on to infiltrate his discord server so they could ask questions. Then write up a blog post calling the change "trivial".
https://twitter.com/cmuratori/status/1522471966929653761
I hate that what was definitely intended as a joke originally turned into this massive miscommunication and flame war. Admittedly tone is hard to convey on the internet, and italics is no replacement for a good old fashioned ":P". But this could have been a good place for everyone to work together, rather than flame one another.
It's certainly an experience that everyone can learn from.
I use JetBrains IDEs and honestly their built in terminal emulators are embarrassingly slow. VSCode is buttery smooth in comparison. Sad state of things.
[1] https://wezfurlong.org/wezterm/
[2] https://www.warp.dev
edit: found the reference at https://twitter.com/nathansobo/status/1619398212712022017
I've sort of been looking into it and it doesn't seem there are cross platform libraries for handling IMEs and not many people talk about even the platform-specific APIs.