▲ 73 points
back
57 comments
Does anyone get anything out of these GPU accelerated terminals?
I am at a bit of a loss for a use-case where my CPU isn't fast enough to keep up.
What I do care about is my bitmap font, which all these new terms don't seem to like supporting.
These days it's easier to write hardware accelerated terminals than CPU bound ones simple because of the system libraries available for drawing to a blank canvas. That is, unless you're using a web wrapper (eg Electron), but then you'd bet Electron is using GPU acceleration under-the-hood too.
I say this as someone who's written my own terminal emulator too. SDL was a natural choice, not because of GPU acceleration, but because it gave me the APIs I needed for rendering a terminal.
The other ironic thing about all these terminal emulators that advertise themselves as being "GPU accelerated" is that text rendering cannot be GPU accelerated. Or at least the only way I know of to render text to the GPU is to first render it using the CPU, then push that bitmap to the GPU memory. This leads to developers having to create a "font atlas", which is basically a bitmap with all your characters already cached in GPU memory. And thus you either need to cache the entirety of Unicode, including alternative glyphs due to variation selections, different font characteristics (bold, italic, etc), and even different font colours (if you want nice anti-aliased fonts ;) ). Which means you then need to software render a bunch of stuff on demand anyway, because otherwise you're basically caching every imaginable character and combination on start up.
So yeah, I don't think "GPU accelerated" is the same flex it used it be.
It's kind of funny, because hardware text modes essentially are GPU-accelerated text rendering -- storing the character set in hardware and offloading the output rendering from the CPU is one of the oldest and most fundamental use cases for dedicated video hardware.
Text rendering can be GPU accelerated if you're cracked enough: https://sluglibrary.com/
For some insight on bitmap font support on the "We use the GPU!" terminal emulators, see https://news.ycombinator.com/item?id=45354014 .
As I noted in https://news.ycombinator.com/item?id=45433715 , this is likely down to following Kitty's lead and agreeing with Kovid Goyal's rationale.
The world of terminal emulators is diverging and has been for some time. There are the terminal emulators that are designed to emulate prior real terminals, with one codepoint per cell, support for original bitmap fonts, support for conventional TUI effects with MouseText/block/line drawing characters, and so forth. And there are are conversely the terminal emulators that are heading towards having an entire WWW browser/wordprocessor-like Document Object Model, with embedded images, reflowed proportionally-spaced document lines instead of a strict cell matrix, arbitrary font scaling, hyperlinks, and so forth.
there are some cool geeky things u can do like the stuff here: https://chrisbuilds.github.io/terminaltexteffects/
without GPU acceleration you just don't have enough FPS. i haven't tested Rio Terminal, but i have tested plenty of other terminals on Windows and xterm.js was the winner by far due to GPU acceleration
With respect, none of what's on that page is anything you'd actually want your terminal to do if you were using it to do anything other than show off what your terminal can do.
GPU accelaration has become so common for new terminals nowadays, that I can't see the point in making that a headline feature. To be fair, the homepage has a more generic tagline ("A modern terminal for the 21st century") and a list of items. My problem is that these bullet items also don't say very much:
24-bit color is even more ubiquitous than GPU acceleration. Apparently even the builtin macOS Terminal will support 24-bit color in Tahoe, and I think Windows Terminal has been supporting that since it was released (which is more than 5 years ago). Even image support is kinda old news: many terminals support at the very least Sixel or the iTerm image protocol. Ligatures and splits are also quite common.
It would be more interesting if we started comparing terminals by the details of these features, since the devil really is in the details. For instance, not all image protocols are made equal. Sixels are very slow, while the iTerm protocol is quite limited - you have very little control on where the image is placed. The Kitty Graphics protocol is the most advanced protocol, but there are two different image placement methods: positioning, unicode placeholder and relative to other images. Besides that there are a couple of other features such as animation and communicating back with the terminal to get image IDs. I've seen several terminals claiming to have Kitty Image Protocol support, but I've never seen any of them put out a matrix of which features they support (other than Kitty that obviously supports everything).
The Kitty Keyboard Protocol is also another thing that is quite complex and I've ran into issues in the past with both iTerm and WezTerm behaving differently than Kitty and running into trouble with some programs which expected the kitty behavior.
I don't see the point of that, but I switched to Kitty from Terminal.app and it feel much snappier all around. Even faster than iTerm2 (which I liked, but not enough to ditch Terminal.app).
You would love Xterm then, still has the least latency of any terminal. (/s only half joking )
Kitty supports full 24-bit color and ligatures while being fast as hell and not weighing down your CPU like iterm will. Plus it supports plugins and is wonderfully customize able (visually, fonts, key binds for everything). I switched after couple years ago after realizing the Mac terminal looked like shit and iterm2 was a dog and never looked back. Have not noticed any bugs during daily use. It is my only Mac and Linux terminal.
I don't understand this too. Terminal need to buffer tty output (so it's not the slow part of pipeline) and display latest visible lines. GPU is not needed for that. Even 10 FPS is enough for smooth CLI work. I don't type that fast or read that fast anyway.
That said, all pixels are rendered via GPU anyway. So using GPU API seems like the most appropriate API and if it means that terminal could work with 100500 FPS, why not?
Also I don't need high FPS when I accidentally cat a giant file or whatever. What I really want is minimal input latency. I switched from iTerm2 to Ghostty and then eventually back to Terminal.app because terminal input latency really bothers me.
Did you find Ghostty’s input latency subpar?
This also brings tons of efficiency gains on portable hardware. You can choose go full throttle or just reap the efficiency gains with minimal power usage on the rendering.
My kitty configuration has grown too much and I could hardly memorise all the customisations. I use its remote control heavily for my workflow. Before kitty, I usually use xterm or urxvt, which are still cool and fast but I cannot go back to the days without those terminal customisations.
How do you use the remote control of Kitty? I have barely explored it.
Yeah I understand all the flashy bits in kitty, but do you need GPU levels of speed? `foot` is much faster than my typing/brain in all cases.
Not at all, for what I use the CLI for, meaning as less as possible, even xterm does the job, while on Windows, I keep using vanilla Windows Terminal, hardly doing any customisation beyond what is the default shell.
After they added hardware acceleration to Windows Terminal, when updating nvidia drivers there is a chance it crashes and loses you work. I switched it over to software rendered after that.
It should be possible that it saves some battery on mobile at high resolutions, but for a while windows terminal was also doing something like issuing a separate draw call for every character so it didn't really help with that, but I think that was addressed.
I think the benefit is that you can do more than just display text in the window. I believe ghostty can display images for example, as well as overlay.
It probably does not matter too much, but the name collision with plan9's rio is a bit unsettling. There is enough domain overlap I was half expecting that someone had dug up the protocol and given it a new coat of paint for our modern systems.
I think drawterm fits that role? But yes, I had the same thought.
riow doesn't have OpenGL but it sets down your RSI a little.
was using it for a month, cool concept, it borrows stuff from alacritty for the base, added iterm2 inline images protocol, kitty image protocol soon
but there are quite a lot of issues, mainly just really weird ones
1. splits dont feel like splits. unlike in something like wezterm or ghostty, rio uses a literal black line for splits, which cannot be controlled. it doesnt properly resize splits, which you can notice if you have like 4 splits active
2. tabs inherit from the previous tab's zoomed in height and width https://github.com/raphamorim/rio/issues/1196
3. blur doesnt work on window (not that big of an issue anyways) https://github.com/raphamorim/rio/issues/1174
4. some characters are broken (no clue how this happens) https://github.com/raphamorim/rio/issues/1192
5. has issues with iterm2 while using yazi
its a cool concept like i previously said, but it needs a lot of tweaking
i think it has a lot of potential
yes, it does have a lot of potential, but the potential is locked behind fixing issues like these
A few months ago I've moved to ghostty and I have been very happy (minus a few bugs)
Is this new terminal bringing anything I'd be missing on? Or is it a case of "made in Rust" vs. "made in Zig"?
Ghostty has far more attention to the little things, whereas the Rust terminal cohort gets to around 80% then usually languishes.
It’s not so much the language as it is the people behind it. Hashimoto is just a machine and appears to know how to recruit well and when to delegate well. Potent combo.
It definitely seems to be that way.
...how do you search (history) effectively in ghostty? or are you not dependent on that feature?
Command+shift+J gives you a file link, you can then use your favourite editor to find or manipulate it to your heart's content.
Coming from iTerm2 I was a bit disappointed at first. Now, I hope this feature stays because it means I can save logs easily, version them, compare them, etc. It's actually fantastic.
Whenever I see a new interesting terminal emulator my main prerequisite to see if it's worth playing with is if it supports bitmap fonts, and unfortunately this one fails the test. I can't live without bitmap monospace fonts. I don't have a fancy 4k monitor so TTF fonts are blurry in comparison to a crisp bitmap font.
Your thread at https://news.ycombinator.com/item?id=45354014 can probably be extended from that particular one to all terminal emulators that have "We use the GPU!" on the marketing features list, because they are all influenced by alacritty and Goyal's Kitty.
My main and side terminal (Alacritty, and Wezterm) are both GPU accelerated and support Bitmap fonts.
oof good ppoint, would be good open an issue about it. I use the term and the maintainer is fairly active in responses
Can someone explain to me why I should want my terminal to be hardware-accelerated? I use my terminal to get stuff done by running commands and viewing the output. Sometimes I might run a TUI but I've certainly never found one that required a GPU to run. If I want to run a full-blown GUI I run it from my WM / DE. Am I missing something here?
> why I should want my terminal to be hardware-accelerated
So your CPU can focus on doing useful computation instead of software-rendering the terminal.
Does the CPU really spend a lot of time rendering text output if I don't use a GPU to do it? My guess is that it would take away a vanishingly small fraction of the time available for useful computation - but maybe I'm wrong?
hey there i am the author of rio terminal, please any issue found feel free to report in the repo. would help a lot, thank you all
Sooooo terminals are the new JS frameworks? :)
Often built using the newest JS frameworks too!
Please don't rub salt in the wound :D
this terminal have a lot of potential ngl
Ghostty 2
i would say it is more like alacritty 2
Quick question: can I JUST simply C-f (or smth else) to SEARCH the terminal for text without any extra complications? Like in macos default terminal and other sane ones?
...or is this another Ghostty geeksfest that wants me to C-S-whatever to dump history into a file then pipe it into a pager etc etc etc?
[+EDIT: ...apparently not liking ghostty gets you downvoted too? weird amounts fanboysm and hype for an underfeatured and poorly documented terminal]
might wanna check out https://rioterm.com/docs/key-bindings#search-actions