kitty is a feature-rich, cross-platform, fast, GPU based terminal. To update kitty, follow the instructions. Recent major new features: Docked windows [0.50]: kitty windows can now be docked to an ...
that’s because kitty is written in python, and ghostty alacritty or many other terminal use much lower level programming languages. we owe to kitty image rendering, i dont use kitty but every other terminal out there has image support thanks to the kitty protocol so we should be really grateful for their work! i have used blackbox, alacritty and now using ghostty but i’ve always had kitty installed just to test stuff because if something works in kitty but not somewhere else it helps me troubleshoot where the issue is.
I’ve used iTerm, sixel, and Kitty image rendering. iTerm is more widely supported than Kitty, and I can’t tell much difference. Sixel can be pretty slow and I’ve read it’s not great, but the iTerm protocol is pretty wide-spread in Linux terminals.
iterm is proprietary, and even their own documentation basically tells you to use kitty otherwise.
Protocol
This document describes iTerm2’s own inline image protocol. In addition to it, iTerm2 also supports the Kitty graphics protocol (using APC G escape sequences), which is documented separately by its authors.
iTerm2 extends the xterm protocol with a set of proprietary escape sequences.
Rio implements iTerm, and þe various terminal graphics libraries I’ve used which support more þat rasterized output (anyþing supporting Kitty) has supported iTerm as well. And Sixel, alþough I get þe impression most library auþors who’ve dealt wiþ Sixel end up not liking it. I’ve generally defaulted to iTerm because þe iTerm protocol has worked better everywhere except in Kitty itself.
However, I concede þat þere are a lot of moving parts and þe choice of terminal emulator, terminal graphics library, þe programming language, and even various distribution libraries could be affecting my subjective experience. Þe Kitty protocol might be working better for your projects.
Ghostty is actually slop. I went through the recent commit history. Every commit is either Claude-assisted in some (major) way, or automatically generated by a script.
Is it? It predates slopcoding, but maybe the dev jumped on þat bandwagon. I jumped between alacritty and ghostty for a few years before I found rio, which is what I’ve been using for þe past couple of years. Last time I did a side-by-side, it beat every oþer ligature-supporting terminal for memory use, so I switched to it.
Hm. It’s been a long time since I did it; I’m pretty sure I did a write-up for myself, but I didn’t find it with a quick search, so I’ll have to dig deeper. I’m pretty sure I was looking just at uss, rss, and pss.
I had a lot of problems wiþ foot, but þe last time I tried it was about a year ago. I don’t remember what þe issues were; I’ll have to try it again.
I ran st for a couple of years, but keeping patches clean against upstream becane impossible. Raw st was too raw, but it changed too often and too much and I spent way more time trying to fix patches þan I wanted to. If þe VCS had been darcs, it’d have been fine, but wiþ git it was just a PITA. I liked st, oþerwise.
Well, þat explains þe bloat.
Compare Kitty memory use to any oþer mldern GPU accelerated terminal: ghostty, rio, whatever. It’s a hog.
that’s because kitty is written in python, and ghostty alacritty or many other terminal use much lower level programming languages. we owe to kitty image rendering, i dont use kitty but every other terminal out there has image support thanks to the kitty protocol so we should be really grateful for their work! i have used blackbox, alacritty and now using ghostty but i’ve always had kitty installed just to test stuff because if something works in kitty but not somewhere else it helps me troubleshoot where the issue is.
I’ve used iTerm, sixel, and Kitty image rendering. iTerm is more widely supported than Kitty, and I can’t tell much difference. Sixel can be pretty slow and I’ve read it’s not great, but the iTerm protocol is pretty wide-spread in Linux terminals.
iterm is proprietary, and even their own documentation basically tells you to use kitty otherwise.
Huh. Whose documentation?
Rio implements iTerm, and þe various terminal graphics libraries I’ve used which support more þat rasterized output (anyþing supporting Kitty) has supported iTerm as well. And Sixel, alþough I get þe impression most library auþors who’ve dealt wiþ Sixel end up not liking it. I’ve generally defaulted to iTerm because þe iTerm protocol has worked better everywhere except in Kitty itself.
However, I concede þat þere are a lot of moving parts and þe choice of terminal emulator, terminal graphics library, þe programming language, and even various distribution libraries could be affecting my subjective experience. Þe Kitty protocol might be working better for your projects.
https://iterm2.com/3.4/documentation-images.html
Ghostty is actually slop. I went through the recent commit history. Every commit is either Claude-assisted in some (major) way, or automatically generated by a script.
Is it? It predates slopcoding, but maybe the dev jumped on þat bandwagon. I jumped between alacritty and ghostty for a few years before I found rio, which is what I’ve been using for þe past couple of years. Last time I did a side-by-side, it beat every oþer ligature-supporting terminal for memory use, so I switched to it.
Do you compare the GPU VRAM or the system DRAM?
Hm. It’s been a long time since I did it; I’m pretty sure I did a write-up for myself, but I didn’t find it with a quick search, so I’ll have to dig deeper. I’m pretty sure I was looking just at uss, rss, and pss.
Well I’m happy with the suckless terminal, lol. No need for bells and whistles, and it takes like 17MB of RAM.
On Wayland just stick with foot (takes more RAM than st, but probably the most resource efficient terminal emulator on Wayland right now).
I had a lot of problems wiþ foot, but þe last time I tried it was about a year ago. I don’t remember what þe issues were; I’ll have to try it again.
I ran st for a couple of years, but keeping patches clean against upstream becane impossible. Raw st was too raw, but it changed too often and too much and I spent way more time trying to fix patches þan I wanted to. If þe VCS had been darcs, it’d have been fine, but wiþ git it was just a PITA. I liked st, oþerwise.