4 ms·

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 c

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.

roylez 1y ago
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.
- casparvitch 1y ago
  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.
  - wredcoll 1y ago
    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!
- zeppelin101 1y ago
  How do you use the remote control of Kitty? I have barely explored it.
  - bayesianbot 1y ago
    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
    - porridgeraisin 1y ago
      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?
    - zeppelin101 1y ago
      Very impressive! I'll look into some of these.
  - roylez 1y ago
    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.
zeppelin101 1y ago
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).
- somat 1y ago
  You would love Xterm then, still has the least latency of any terminal. (/s only half joking ) https://beuke.org/terminal-latency/ https://beuke.org/terminal-latency/
  - steve-atx-7600 1y ago
    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.
sedawkgrep 1y ago
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.
cma 1y ago
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.
electroglyph 1y ago
there are some cool geeky things u can do like the stuff here: https://chrisbuilds.github.io/terminaltexteffects/ 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
- danudey 1y ago
  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.
JdeBP 1y ago
For some insight on bitmap font support on the "We use the GPU!" terminal emulators, see https://news.ycombinator.com/item?id=45354014 https://news.ycombinator.com/item?id=45354014 . As I noted in https://news.ycombinator.com/item?id=45433715 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.
pjmlp 1y ago
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.
vbezhenar 1y ago
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?
- nerdponx 1y ago
  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.
  - ku1ik 1y ago
    Did you find Ghostty’s input latency subpar?
    - nerdponx 1y ago
      Not subpar but Terminal.app seemed a little faster, enough to notice a difference side by side.
- Permik 1y ago
  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.
  - mireq2 1y ago
    iTerm2 switches GPU to CPU rendering when running on battery. GPU rendering is more power hungry than CPU.
hnlmorg 1y ago
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.
- landl0rd 1y ago
  Text rendering can be GPU accelerated if you're cracked enough: https://sluglibrary.com/ https://sluglibrary.com/
- Gormo 1y ago
  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.
unscaled 1y ago
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.

roylez 1y ago

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.

casparvitch 1y ago
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.
- wredcoll 1y ago
  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!
zeppelin101 1y ago
How do you use the remote control of Kitty? I have barely explored it.
- bayesianbot 1y ago
  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
  - porridgeraisin 1y ago
    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?
  - zeppelin101 1y ago
    Very impressive! I'll look into some of these.
- roylez 1y ago
  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.

zeppelin101 1y ago

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).

somat 1y ago
You would love Xterm then, still has the least latency of any terminal. (/s only half joking ) https://beuke.org/terminal-latency/ https://beuke.org/terminal-latency/
- steve-atx-7600 1y ago
  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.

sedawkgrep 1y ago

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.

cma 1y ago

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.

electroglyph 1y ago

there are some cool geeky things u can do like the stuff here: https://chrisbuilds.github.io/terminaltexteffects/ 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

danudey 1y ago
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.

JdeBP 1y ago

For some insight on bitmap font support on the "We use the GPU!" terminal emulators, see https://news.ycombinator.com/item?id=45354014 https://news.ycombinator.com/item?id=45354014 . As I noted in https://news.ycombinator.com/item?id=45433715 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.

pjmlp 1y ago

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.

vbezhenar 1y ago

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?

nerdponx 1y ago
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.
- ku1ik 1y ago
  Did you find Ghostty’s input latency subpar?
  - nerdponx 1y ago
    Not subpar but Terminal.app seemed a little faster, enough to notice a difference side by side.
Permik 1y ago
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.
- mireq2 1y ago
  iTerm2 switches GPU to CPU rendering when running on battery. GPU rendering is more power hungry than CPU.

hnlmorg 1y ago

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.

landl0rd 1y ago
Text rendering can be GPU accelerated if you're cracked enough: https://sluglibrary.com/ https://sluglibrary.com/
Gormo 1y ago
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.

unscaled 1y ago

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.