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.
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.
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.
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.
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.
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.
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).
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.
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.
- Terminal search and focus (you can list kitty tabs and windows and get the window content from the socket, implementing a BM25 based search is quite easy)
- Giving the current terminal content for AI, so I can do things like run `ls` and then write "Rename the files (in some way)", and push the whole thing to LLM that replaces the command line without me having to write the full context
I even have a Codex session finder that uses codex session files to list and select the session I want, and then uses the kitty socket to find and focus the window which matches the session content
I have thought of things to do with kitty remote but have always been lazy to actually write the code. Do you have it open source by any chance for me to steal?
The ones that I use the most are designed to reduce context switching, like:
Mutt, personal wiki (fzf searching and neovim editing) and todo (a long never ending markdown file), they all have dedicated shortcut (cmd+m/cmd+z/cmd+d) to open(switch to) their window. These applications, always reside in the first tab with stack layout. For example, I can press cmd+m to switch to mutt (or open it), and press cmd+m again to switch back to the previously focused window.
Depending on which repl is running, I can usually open up vim to edit the line with the same cmd+e shortcut, which sends C-X C-E in bash/zsh, ESC O in iex, C-O in aichat ... Also vertical split in tmux and kitty tab share the same shortcut, cmd+|.
Kitty does not have a command palette, and I use fzf to search some of my frequently used operations and make this my command palette.
There are genuinely moments where something in the hell-stack of terminal-bash-ssh-tmux is slow enough that rendering speed is affected and its annoying.
Is this fixable by using a gpu? Probably not, but I'm willing to give it a try!
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.
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.
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.
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.
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
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.
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.
Those two are already balanced by Zutty and Rio. So let's have a look around at some of the emulators that make using the GPU a marketing point.
DarkTile (https://github.com/liamg/darktile) accepts TTF and OTF, so presumably if you can get your bitmap font of choice converted into those formats you are alright.
GhosTTY (https://github.com/ghostty-org/ghostty) gained proper bitmap font support just last month, the issues list says, but is reliant upon what FreeType and CoreText can handle. It has an open issue discussing those vis-a-vis bitmap fonts.
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?
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?
In short - it depends on your CPU and your display configuration.
On a 640x480 screen, a terminal will probably render fine with low CPU overhead. On a HiDPI screen, CPU may have millions of pixels to render for a single terminal window.
It's not that different from other application programs IMO. DAWs and VSTs often offload rendering to GPUs to save as many CPU cycles as possible to get the latency down. I love having low latency in my terminals, so I prefer GPU accelerated emulators.
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]
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.
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.
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.
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.
iTerm2 switches GPU to CPU rendering when running on battery. GPU rendering is more power hungry than CPU.
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 )
https://beuke.org/terminal-latency/
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.
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.
Not OP but
- Terminal search and focus (you can list kitty tabs and windows and get the window content from the socket, implementing a BM25 based search is quite easy)
- Giving the current terminal content for AI, so I can do things like run `ls` and then write "Rename the files (in some way)", and push the whole thing to LLM that replaces the command line without me having to write the full context
I even have a Codex session finder that uses codex session files to list and select the session I want, and then uses the kitty socket to find and focus the window which matches the session content
I have thought of things to do with kitty remote but have always been lazy to actually write the code. Do you have it open source by any chance for me to steal?
The ones that I use the most are designed to reduce context switching, like:
Mutt, personal wiki (fzf searching and neovim editing) and todo (a long never ending markdown file), they all have dedicated shortcut (cmd+m/cmd+z/cmd+d) to open(switch to) their window. These applications, always reside in the first tab with stack layout. For example, I can press cmd+m to switch to mutt (or open it), and press cmd+m again to switch back to the previously focused window.
Depending on which repl is running, I can usually open up vim to edit the line with the same cmd+e shortcut, which sends C-X C-E in bash/zsh, ESC O in iex, C-O in aichat ... Also vertical split in tmux and kitty tab share the same shortcut, cmd+|.
Kitty does not have a command palette, and I use fzf to search some of my frequently used operations and make this my command palette.
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.
There are genuinely moments where something in the hell-stack of terminal-bash-ssh-tmux is slow enough that rendering speed is affected and its annoying.
Is this fixable by using a gpu? Probably not, but I'm willing to give it a try!
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.
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.
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.
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.
https://plan9.io/wiki/plan9/using_rio/index.html
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?
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.
Those two are already balanced by Zutty and Rio. So let's have a look around at some of the emulators that make using the GPU a marketing point.
DarkTile (https://github.com/liamg/darktile) accepts TTF and OTF, so presumably if you can get your bitmap font of choice converted into those formats you are alright.
GhosTTY (https://github.com/ghostty-org/ghostty) gained proper bitmap font support just last month, the issues list says, but is reliant upon what FreeType and CoreText can handle. It has an open issue discussing those vis-a-vis bitmap fonts.
Trap2 (https://github.com/tale/trap2) likewise relies upon FreeType.
Contour (https://github.com/contour-terminal/contour) at least appears to have bitmap font support. Alacritty, WezTerm, and Kitty get a lot of mentions in the issues list.
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?
In short - it depends on your CPU and your display configuration.
On a 640x480 screen, a terminal will probably render fine with low CPU overhead. On a HiDPI screen, CPU may have millions of pixels to render for a single terminal window.
It's not that different from other application programs IMO. DAWs and VSTs often offload rendering to GPUs to save as many CPU cycles as possible to get the latency down. I love having low latency in my terminals, so I prefer GPU accelerated emulators.
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