Linux terminal emulators have the potential of being much faster
Looking at this, I’m reminded of early clang, which was often 5 or more times faster at compiling C++ than gcc, while handling maybe 95% of C++ code.
While clang is still in my experience faster than gcc, it turns out handling that last 5% correctly can knock a lot off your performance. Of course with terminals it might turn out you don’t need that last 5%, or you really can get all the way and keep the speed, but this isn’t the first project dedicated to making “the fastest terminal”.
This reminds me of the kerfuffle Casey Muratori caused last year when he dared suggest the windows terminal could be faster.
Although people wonder why anyone cares about performance in terminal emulators, it's more about caring about inefficiency in terminal emulators. There are some legit cases where performance actually does come into play, like with high-throughput. Sometimes it's not even necessary, such as when terminal emulators do more work than they should processing data that won't be displayed; those things have the potential to impact the experience even when there is plenty of CPU and GPU to spare, like on a desktop machine. However, it's not just performance. It's also energy usage, particularly on small things like the Pinephone.
Linux being an OS where the terminal is as powerful as it is, it's really good to see a high level of attention to detail going to terminal emulators finally. Terminal emulators should be extremely robust and extremely efficient; and finally, they're getting pretty close.
Happy to see more folks working on fast terminal emulators!
Earlier this year, I went through every single terminal emulator in Arch's repos and tested using them while compiling AOSP (Android). AOSP's Soong build system does not produce a lot of scrollback, but it does overwrite a line containing the progress ~150k times (once per source file). Alacritty was the only one that was both responsive and didn't eat up a CPU core (staying under 10%). Wezterm, Kitty, Foot, and Konsole stayed responsive, but used 100% CPU on a single core, causing a measurable impact to the build speed (though Konsole 23.08 seems to have regressed and now sometimes locks up). Most of the others became unresponsive or had multiple second delays trying to do anything (eg. ^C, opening new tab, etc.).
Why care about terminal emulators speed? I never cared about anything (let alone terminals) to go above 30 fps. I've heard extra FPS can help in professional gaming but I can't even imagine a case when speed of any existing terminal emulator would be not enough (for what?). Surely its nice to make any app as efficient and responsive as physically possible (as long as this doesn't harm anything) but I still feel curious about what, besides pure perfectionism and competition, actually motivates people in this case.
Meanwhile, all GNOME-based terminals are still capped at 40fps:
I once played a esoteric video game where you had to interact with a terminal inside a 3d world as part of the gameplay mechanic. It was implemented in unity, and it featured motion blur when a lot of output was generated. Since then I always wonder if text editors and terminals could actually greatly benefit from motion blur whenever text is moving.
The purpose of motion blur is first to make things seems smoother, but mostly to indicate how things are moving on the screen with lower framerates. I think with motion blur you could make text jump way further frame by frame while understanding how text was moving. If you have a word that is bold on screen, you could make it jump half a screen with within a single frame while immediately understanding where it went. Wouldn't that help navigating e.g. huge logs (esp. if they're colored) faster while still having a sense of how far you moved frame by frame?
If your terminal outputs so much that nothing of the screen is the same frame by frame, you could also still get a feeling of how much is actually outputted, by how blurry the screen is.
Never got around implementing it though, curious what you think!
Fast is good but given that any terminal is fast enough to type commands and scroll around, convenient is even better. Example: I went with tilix months ago and eventually switched back to Gnome terminal because tilix froze sometimes. Furthermore tilix doesn't have a way to bind commands to a profile to run them when opening a terminal with that profile. The freeze is of course 99% of my switching back.
I favor kitty[0] and zutty[1].
Gnome terminal / libvte is and has always been slow, and alacritty might have good throughput, but sadly is high latency.
Back in the day, terminal emulators were fast enough that they were up to date by the time each 50Hz/60Hz period came around - why on earth are they now so much slower?
A couple of days ago I spent a while trying to figure out why a piece of hardware appeared to be outputting serial data in bursts. After eliminating issues with the underlying hardware and buffering in the USB stack, it (too slowly) dawned on me that the issue was entirely due to how slow terminal emulators have become (this was on a fastish PC).
Updating a screenful of text at 60/120Hz, why/how is it so much slower these days? (and what benefits have we gained in return for the slowdown?).
> "Just going to put it out there because I don't intend to do anything with it, but I have created a terminal emulator that is twice as fast as the closest GPU-based renderer I've found (at least on Linux) which was Alacritty."
> "I don't care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one."
These sentences sounds conceited and arrogant.
It seems like he's not even sharing the code, which is unfortunate if Alacritty or others want to learn from this. I guess that's a personal choice, but is it in the spirit of fosstodon (the mastodon instance he's on.)?
here's a good read about terminal emulators, including speed benchmarks and discussing security aspects: https://lwn.net/Articles/749992/ https://lwn.net/Articles/751763/
I've tried every "accelerated" terminal app that I see, yet I find I never perceive any improvement in response, only the negative effect of losing the helper UI of menus and such compared to my (now ~10 year usage) usual term of Sakura.
Kitty came closest to being usable for me, but still it involved throwing away ease of access to various things to have a boost to performance that was only something I was told I was getting, not something I was experiencing.
alacritty is fast but kitty is faster. glad to see us racing to the top in this space.
I may write my own but wayland, pure CPU rendering, assembly (x86_64/risc-v)... but... I am still on other projects.
Honestly, all I ask from a terminal emulator is to have a slick and fast search UX (similar to item on macOS)
Just look at Windows Terminal - which is pretty damn fast.