Kitty – a fast, featureful, GPU based terminal emulator
sw.kovidgoyal.net
sw.kovidgoyal.net
I prefer it to iTerm because it's so. Damn. Fast. It's the only software (besides Sublime) I run on my laptop that actually feels like it's using the 40 years of transistor improvements I'm paying for.
I know iTerm recently added a Metal renderer but I need ligature support, which iTerm Metal doesn't have.
Maintainer has also been responsive on GitHub.
I wish more software fell into this category. It's still a little odd to me that something as conceptually simple as a terminal emulator should require a full blown GPU in order to perform smoothly.
If you want to see just how fast it can be, grab a linux instance, press ctrl+f1 to drop to a GUI free terminal and see just how responsive and how fast it can run.
It's kind of nuts that we have to rely on something as powerful as hardware acceleration via GPU to make plain text rendering on a screen in a GUI approach the same speed as CPU rendered text in a straight terminal console.
Yup, I was also pretty surprised by this. I switched to Kitty recently, after terminology broke for me after an update. It's surprisingly hard to find terminal emulators that run on Xorg and on Wayland without making a fuzz.
Kitty does this beautifully and I had a real a-ha moment because of its speed the first time I tried it.
One thing is, I don't get its layout, is it possible to create a vertical/horizontal split like what (shift+)cmd+d does in iTerm 2?
Ctrl-Shift-L goes through all enabled layouts. A layout specifies how the "windows" are arranged. Simple splits are available among others. I like the stacked layout: window 1 fills the full height on the left half of the screen, all other windows are stacked on the right half.
There does not seem to be a way to control the borders within the layout with the mouse; e.g. temporarily resize window 1 in the example above to be 80% of the width. That's something I sometimes miss. It's configurable, of course, but not ad hoc.
I'm using macOS and unfortunately not familiar with how I'd do that, but I'm sure it would be easy with something like i3wm on linux (which I still miss after moving away from linux 3 years ago :/), but I don't know what I could use in macOS.
Maybe I could find some third-party solution just to show/hide a particular application. I think if I had that + if I could figure out tabbing/tiling behaviour of Kitty, I would switch to it. Those two things are the main things that I need from iterm.
How are you attributing speed to Kitty over iTerm? Wouldn't most of the sluggishness of anything be more attributed to the programs you're running in the terminal?
I mean, I love how user friendly (meaning configuration and all) kitty is out of the box. That's how tools made by programmers for programmers should look like.
That said, kitty behaves a little weird when scrolling back and forth in vim — at least on my laptop with my vim colorscheme. It leaves out background of a line black until I jump on that specific line or simple refresh the screen. I wonder what might be the issue here.
Just look at how often a new product - like this one - is compared to existing products on HN, and how many comments are about what features other products have that are dealbreakers.
It's not new. Just one example from the 1980s is NeXTStep, which did away with the cryptic Unix directory names (/opt/sfw, /usr/ccs, /usr/mbin, /usr/rbin, /usr/5bin, and so on) in favour of /Library , /LocalLibrary , /Apps , /NextApps , and so forth.
Although it has a lot less features than kitty and really is only usable with tmux (or GNU screen, whatever), it is more or less perfect for people who want their terminal to do just one thing and that one thing pretty fast.
Disclaimer: Haven't tried kitty yet and using alacritty for a nearly a year now.
This seems to be a general issue on macOS with any terminal emulator, according to [0].
Use a full screen terminal with a 12pt font on a 4K display. Split the tmux window into quarters and pull up some logs in each pane. Now use the mouse to click and drag on the center vertical border; quickly resize it from left to right. The border takes about half a second to catch up with the mouse cursor as tmux repeatedly reflows all the text on the screen.
It's actually very, very slow.
It even looks like he has his own pre-jquery compliance library written about 18 years ago: https://kovidgoyal.net/scripts/VisualDocumentAPI.js
> W A R N I N G! Your browser is not supported by this site.I cannot guarantee that things will work as they should. Consider downloading either Mozilla >=1.4 or Internet Explorer >= 6
takes me back!
It would seem prudent for this kitty to consider changing it's name to help alleviate confusion.
For instance, iTerm supports italic, which Terminal.app doesn't. Gnome's terminal (vte, actually) does support overline (I volunteered adding it to iTerm, but I'm nowhere near close), which is handy for status lines, as well. I think there is one that takes ANSI codes seriously enough to support double-height and width.
To see what's missing, you can look into https://en.wikipedia.org/wiki/ANSI_escape_code
It does (just checked).
If you're a light user, probably not much.
I spend probably 2/3rds of my day at a command line, and iTerm has a ton of handy usability features that make life a little nicer. With kitchen-sink apps like this, everyone uses them differently, but things that make my life easier include:
- command-up arrow to scroll up by command - programmable appearance changing (using the server-side shell integration) to visually prompt me when I'm not my usual UID and to show machine names in the background of the window - Deeply customizable minor usability details, like the ability to copy-on-select, which I use all the time but some people hate
Nothing that is going to empower you do do things you can't now; rather just nice features that make address the quirky needs of heavy shell users.
Text rendering is basically just blitting cached glyph bitmaps into a buffer, and CPUs have been more than overly fast doing that for eons. And CPU rendering has none of the compatibility problems/quirks that GPUs have. I can fire up a Gnome Terminal onto an unaccelerated Vesa X11 display if my graphics card doesn't work or I haven't configured it yet.
For better responsivity I suppose a terminal that behaves like mosh would be a good approach. It would maintain the tty state in memory and only render the latest view, dropping the rendering of any intermediate diffs in the buffer. I would guess most terminal emulators do work like that these days but I haven't checked.
I'm not sure if Kitty is using GPU specifically to minimize latency, but it would be a good reason.
That being said I think it is valuable to have a reasonably fast terminal because it's not uncommon to have applications slow down dramatically if they output a lot of information on stdout/stderr while the terminal struggles to render everything.
Input was just so .... immediate? It’s really hard to describe, but it was surprisingly obviou.
I can definitely tell you that while I can't see the actual letter appearing on the screen - the letter on the calculator would feel as if it appeared right at the bottom position of the button, while on my PC the key would have travelled some distance off the ground before I see the letter.
It's not uncomfortable, but I could easily tell the two apart in a blind test would something like that come up.
It's depressing that he's only ever tried for throughput, when that's irrelevant next to latency. And it does have abysmal latency as per your link.
I've been using iterm for years; when they introduced their metal rendering backend the impact was very subtle but noticable. Anyway, given the amount of time I spend using cli stuff, it kind of matters.
Smooth scrolling is inherently bounded by the vsync rate of the display. As long as you can render the terminal's pixel buffer with new characters and send it to front for the next flip, all within some portion of the time you have between frames, it's as smooth as it can get. Missing a frame will cause stutter, and make it non-smooth. Given the fact that terminal doesn't necessarily need to render if there are no changes, using GPU seems like an overkill for regular use.
A pity, maybe some day either the author changes his mind or Alacritty will be less buggy to make it a straight upgrade to Kitty. In the meantime, Termite it is.
https://github.com/kovidgoyal/kitty/issues/106
Obviously using the truetype version (which isn't pixel perfect but a mess) is not an option.
Too bad. I'll stick to libvte (sakura).
time find ~
alacritty takes 8.5 seconds and uses 75% CPU
kitty takes 15 seconds and uses 100% CPU
konsole takes 16 seconds and uses 100% CPU
time for i in {1..2000000}; do echo $i; done
alacritty takes 16 seconds and uses 75% CPU
kitty takes 17 seconds and uses 100% CPU
konsole takes 16 seconds and uses 98% CPU
It does vaguely measure two things:
1) How big the buffer is on the terminal when it reads in lots of output. If the buffer is as big as the output then your test reports a figure close to the `/dev/null` test. Not useful.
2) How well the terminal is in SKIPPING the rendering of lots of output. No normal terminal tries to render all of the text on screen.
I would much prefer a terminal that still provided interactivity when text was scrolling in other parts than raw speed. Open up two panes in tmux or your favorite split screen with text scrolling in one and measure latency in the other pane with typometer and I will use whatever comes up to the top.
START=`date +%S.%N` && find ~ && echo $START && date +%S.%NHow long between key press and character render? That's all I care about. 24 cores and still have lag when I type. My 7mhz Amiga 500 had a more fluid GUI than modern PCs. It's disgusting.
Still, I wonder if the terminal emulators could use less CPU and be faster if they refreshed only with the frequency of the monitor.
An interesting insight from the tests is that the execution speed of a program can depend on the speed of the terminal emulator.
However I do agree with your point that this "shouldn't" happen in practice (ie any decent hardware you'd expect to have buffers to prevent that kind of write errors).
EDIT: alacritty took 4.15 and 54% cpu.
I should note these results are all from second runs.
Locking how? He can keep his tmux configuration and use it when he needs to in the future.
I wish this were all unified into a single window/tab/keybinding model. That was easy to code against and write your own interactions for.
I keep hoping I'll see a boundary-pushing project like Kitty do something new in this space.
> I'm widely known for my extreme stupidity.
Loving the zero <expletives> given approach from the maintainer. Installing now.
> To elaborate, the GL driver is incorrectly treating const variables in the shaders as uniforms.
That's a pretty serious bug in the driver. I might also simply refuse to work around something that colossally flawed.
And to which someone declares "not a smart move", and he said, roughly, "okay, I'm stupid then ┐_(ツ)_┌". Yeah. Okay. This isn't exactly flaming someone out.
(The calibre/setuid things are a little less impressive. Though on the other hand, again, I can almost see the sense; I also have some serious beefs with the core design of the linux mount API right down to the syscall level.)
On the other hand he actually fixes things.
Even if you actually were paying money for his services, which most of us are not, which would you prefer an obsequious kind person who didn't fix your problem or a dick that did.
I would take the dick every day of the week.
When I'm asked a question whether it's better to hire a dickhead that is an expert in some field, or a normal person that isn't an expert of this field but showing promises, I'm probably always going with the non-dickhead person.
Dickheads are hard to communicate with, they are lowering team morale, make teamwork harder so in the end expert dickheads are less valuable than non-dickheads.
The beauty of open source is you can look at the code and even the issue tracker. I dare you to look at even `setup.py`, a file that's usually quite straight forward in Python, and tell me what it's doing. But if you're happy using kitty as your daily driver, great.
I guess you can dismiss all this as "haters gonna hate" and "what have you made?". Which is why in the comment, I refrained from stating my opinion and linked to other people's experiences/opinions instead. Just don't say you didn't know. And good luck getting the things you want fixed.
That came out wrong...
> Not a smart move, imho.
a library that I can feed data directly into (without a pty)
LGPL, MIT, or BSD
able to quickly serialize its internal state (make me a blob)
able to restore state if I feed it a blob of saved state, even across different software builds
portable to recent versions of Linux and Windows
Moreover, the session state saving is not possible either since you need to save the internal state of running programs as well as their cached output (saving the output is really very easy but it's the least of your worries given the specifications you've described).
You might also find this problem is better solved with a $SHELL replacement rather than a terminal emulator.
So the emulator gets bytes from the emulated virtual machine, and then what? This needs to get fed into a terminal. While it is possible to invoke xterm with the very buggy -S option, there is no way for the emulator to suck the state back out of xterm for coherent snapshots. Simics uses xterm with the -S option. It sucks.
A library interface is required. The whole point of a library interface is to allow session state saving. Using a $SHELL replacement is way off. That has nothing to do with the problem.
So, if you were hacking on an emulator (qemu, MAME, Simics, VirtualBox, etc.) and you were trying to emulate a device with a serial port or even a modem, how would you get snapshots to contain the terminal state? To make this work, you need that state within the emulator. Passing stuff over a PTY is not going to work.
The state of an entire OS, with all running programs, gets saved. It's more complete than when a laptop/notebook does suspend-to-disk. The emulator saves the CPU registers, the RAM, the disks, the parallel port mode, etc.
The trouble is that a connected terminal is not included in that list.
You can then also forward any output to a file/terminal emulator/whatever is convenient, but relying on the terminal emulator to save part of your emulator's state seems weird to me, unless you are going to ship the two bundled together.
The point of a library is that the two are more than just bundled together. They are linked together, making one executable. The terminal window is a part of the emulator.
The only thing that wouldn't be inlined via control characters nor escape sequences would be the PTY operating mode (which are defined via kernal syscalls). Im talking about stuff like local echo, flow control, how CR/LF characters are handled, etc. However that's solved with a multiplexer (screen or tmux type thing) or a custom shell, thus you could save that running state and reset it when needed (shells actually already need to do this to some extent so they can pass control of the TTY to forked processes. But we'd obviously need to take things a step further and store any state changes made by forked processes as well). However now we are back to my original solution you dismissed.
It is useful for virtual machine snapshots. You can restore the virtual machine with the terminal state intact.
It isn't true if the VM is communicating over an emulated serial port. In that case, the VM software must provide a terminal as hardware. Typically the VM software only provides a serial port to the VM, which the user will then associate with something else via the VM configuration. This fails when loading a snapshot because the terminal isn't part of the snapshot.
For example, suppose that the VM is a PC-AT running DR-DOS and a BBS. (from the pre-internet days, with a modem for users to dial in on) At minimum, the VM software must provide a serial port for the VM. You could configure this to connect with a real physical modem and then connect to that with another modem and some dial-up software, but then you'd have a problem with snapshots. Loading a snapshot would place the BBS in a state that is inconsistent with the dial-up software. What you really need is for the terminal emulator to be part of the hardware that the VM is emulating. It would then be properly snapshotted.
Linux desktop in 2018 is incredible though. On my desktop, I'm running an RX 580 on AMD's open source drivers and I can play modern Windows games at >= 60fps using WINE + dxvk. Steam is even officially supporting it now. Just wait 2-3 years and GNU / Linux will be the way to go.
Btw I'm big fan of your games, like Link to the Past! 16-bit era was best era.
Which is odd, cause Kitty does, IIUC.
But it does have a comprehensive documentation page: https://sw.kovidgoyal.net/kitty/index.html#scrolling
There's a huge configuration doc[1], and the homepage already does a very good job of introducing you to its features. You have to read that, yeah, but maybe you can get a screen reader to read it for you. Dunno.
More importantly, making a video probably takes more time that having a nice write-up about anything.
I am 26, BTW.
However, there are several behaviors that are atypical for OSX applications such as missing conventional system shortcuts and some things I consider confusing such as the fact that there are OS windows and then there are "windows" which are similar to panes in iTerm, but are not actually windows. Perhaps for other terminals or systems this is normal, but it isn't exactly par for the course for the tools I've worked with prior.
One of the best things about OSX is that every item that is available in the menu bar has a clear shortcut associated with it and a very helpful search box available via the cmd+? key combo which works as a shortcut for anything you don't happen to know the shortcut to offhand. Menus happen to be one of the fastest ways to navigate OSX with a keyboard for me. This app does not have any menus to speak of, which is fine, but it just makes it that much harder to figure things out on your own.
As for the video suggestion: some things just don't translate as well as text for me (I am legally blind: not afraid to RTFM, but sometimes reading is asking a bit more for me than others). Sometimes it's nice to see how someone else does it because it helps when you don't know how to do something on your own. Even an asciinema style demo is quite helpful for certain tools here and there.
(compared to Apple's Terminal.app, which I found to be the fastest and least problematic on a Mac)
From the performance page: https://sw.kovidgoyal.net/kitty/performance.html
EDIT/Whinging: Welp, scratch that, kitty requires an OS X one version higher than what apple will allow me to install. And while it is an older MBP from 2010, at least it's fast and reliable. AND it has the multitude of ports that I like. And the magsafe.
I'm sure I'm venting into an echo changer, but, here goes. Why won't Apple simply provide me (an option to buy) a modern solid mid-level 15" rMBP for under $2000. I bought mine for $1700 and it came with a $200 ipod as a gift (sold on eBay).
Give me that. A rMBP, with all the ports, plus the new USB-C. They could leave out some of the stuff that's pricy.
Ya, give me a new version of what I have, and will last at least another 8 years (fully supported by MacOS releases), and price it under $2000. That I would buy. When I replace this one, I'm just going to have to buy something to linux or Windows (probably both, realistically), since I've been priced out the product I would have normally purchased and recommended.
Most of what terminals have to do is blitting of prerendered text bitmaps, which is relatively slow on CPU and does benefit from the much faster memory bandwidth of the GPU. Core Graphics generally does not use the GPU for text blitting in most Mac apps, so having a custom renderer can help here. Font rasterization on the Mac does not use the GPU either, but the glyph cache hit rate for a terminal emulator is so high that it ends up pretty much irrelevant.
On Windows, Microsoft ships multiple rendering stacks for legacy compatibility. Most terminals are old Win32 programs that use classic GDI, which as far as I know is partially accelerated but mostly CPU (and implemented in the kernel!) Direct2D, the newer API, does use the GPU for blitting text. Like macOS, Windows still does all font rasterization on CPU. In GDI, font rasterization is done on CPU in the kernel (!) (except on Windows 10, in which the kernel calls out to a userspace fontdrvhost.exe). In Direct2D, font rasterization is done on CPU in userspace.
This also makes me weary of statements that criticize how e.g. windows does it wrong, “except in the current three years old version”.
WSL desperately needs a good terminal.
I've switched to kitty and am much happier.
I use i3 (a tiling WM) though, so tmux is redundant for me unless I work on remote machines.
And I really don't want tmux running on top just for scrolling. It hurts performance quite a bit.
Also kitty definitely feels snappier to me in terms of latency.
If this is progress... I'm not sure I want it
And the GPUs were character-based, with only 256 different characters, usually 16 colors/each. That's the main reason for the hardware requirements. Essentially, these shaders emulate a character-based fixed function GPU from 30 years ago, adding features like more colors, Unicode, and custom fonts.
Modern displays at 1920x1080 in millions of colors.
30 years ago a terminal was the whole display and nothing more. Now its a single window amid dozens of other windows including content ranging from high definition video to real-time rasterized 3D graphics.
Yes, that's progress.
VGA was introduced 31 years ago, in 1987. The text mode was 80x25 characters, 9x16 pixels/each, so the effective output resolution was 720x400 pixels. I currently develop a device with similar one, 800x480, only now I have GPU and GLES 3.2.
Back to the old times, because RAM was so expensive, that high resolution only worked in text mode, where the frame buffer only had 2 bytes per character, one for character itself, another for attributes i.e. background and foreground colors.
Graphic modes had way lower resolution, indeed.
I wish Alacritty had better scrollback, I'd give that a go as well. But for now, I am sticking to Kitty.
Data analysis and data science comes to mind.
Edit: I did some basic tests using slow motion recording on my phone, and this is how long I found it took a few terminal emulators to start: (Recorded in 240FPS)
- rxvt-unicode 33 frames
- kitty 298 frames
- lilyterm 20 frames
- sakura 55 frames
Alacritty apparently accepts input before it is able to display anything. It took 53 frames before it would take input, and 180 frames (total from startup) before it displayed anything.
:(
but fast? on an intel haswell graphics card Im seeing input latency. Sure, its technically beautiful, but the st terminal from suckless.org is lightning fast compared to this.
update: this is on a 2015 macbook with retina running funtoo, so this may be a performance consideration specific to the hardware.
Clone it/download the .zip and replace the kitty.exe with a recent one
makes this hardly usable
https://sw.kovidgoyal.net/kitty
2. There is a resize option for text. Hell, in my experience, Kitty seems to have the most powerful font management of any terminal. See:
https://sw.kovidgoyal.net/kitty/conf.html#conf-kitty-fonts
3. That's because the machine you're SSHing into doesn't have Kitty's terminfo files. That's easily fixed by running "kitty +kitten ssh myserver" where "myserver" is the IP/domain of your server. See:
https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-...
I quite like Kitty compared to urxvt, which I was using before. Just looking at cmatrix, you can tell the difference. Smooth characters dropping down in kitty, sketchy 10fps on urxvt.
The only thing that bothers me is the theme being set in the config file. For urxvt, I put the theme separately in xresources and have a shell alias to change it (which then requires opening a new terminal, but that's what I use tmux for).
Maybe I can do something similar for Kitty, haven't really read the docs.
Increase background opacity ctrl+shift+a>m
There are a few pointers for Linux solutions in the issue.
I do wish creators of these tools would search for existing names to see if they are already in use. I would not mind if they were tools with sufficiently different purpose. But this just confuses users (and potential users) of either one.
I likewise thought this was KiTTY. Had to look up the actual homepage for it to confirm that I was looking at a different tool.
https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41...