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.
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.
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].
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
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.
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.
How 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.
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.
> 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.
It is useful for virtual machine snapshots. You can restore the virtual machine with the terminal state intact.
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.
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
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.
WSL desperately needs a good terminal.
I've switched to kitty and am much happier.
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.