Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kitty – a fast, featureful, GPU based terminal emulator

sw.kovidgoyal.net

Post reply on HN
Print view View original

241–250 of 323 posts

Re: Kitty – a fast, featureful, GPU based terminal emulator

#241

Post by C4K3 »

I tried kitty very briefly, but its startup speed feels very slow. As someone who prefers using my WM to manage multiple windows, a slow startup speed is absolutely killer for me.

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.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#242

Post by irq-1 »

Avamander wrote: post #178
sime2009 wrote: post #158

Earlier quoted context omitted.

Can we not start throwing around these bullshit `time blah` tests. They don't measure what people thing they measure. It doesn't measure rendering speed at all. 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 SKIPP…

Please suggest better methods then.

I think this works:

    START=`date +%S.%N` && find ~ && echo $START && date +%S.%N

Re: Kitty – a fast, featureful, GPU based terminal emulator

#243

Post by heavenlyhash »

guitarbill wrote: post #65
Rantenki wrote: post #48

Earlier quoted context omitted.

Closed and locked with: > I'm widely known for my extreme stupidity. Loving the zero given approach from the maintainer. Installing now.

Kovid Goyal is infamous/known to be a bit toxic, see Calibre: https://news.ycombinator.com/item?id=8213946 (and the setuid "issue": https://lwn.net/Articles/465311/ )

I'm... pretty dang okay with that response on issue 456.

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

Re: Kitty – a fast, featureful, GPU based terminal emulator

#244

Post by b3n »

C4K3 wrote: post #241

I tried kitty very briefly, but its startup speed feels very slow. As someone who prefers using my WM to manage multiple windows, a slow startup speed is absolutely killer for me. 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…

You might like alacritty[1].

[1] https://github.com/jwilm/alacritty

Re: Kitty – a fast, featureful, GPU based terminal emulator

#245

Post by Const-me »

syn0byte wrote: post #226
jbb67 wrote: post #211

I don't even know where to start with this. We had terminals that were way faster than you could type or see 30 years ago. They didn't need a GPU and ran on a CPU 1000 times slower than what we have now. If this is progress... I'm not sure I want it

They were also char based display at something like 320x240 resolution and maybe 16-256 colors. 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.

The resolution wasn’t that bad.

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.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#246

Post by strunz »

ikornaselur wrote: post #102
ryenus wrote: post #71

Earlier quoted context omitted.

Have you managed to configure it to behave similar to iTerm 2 in terms of keyboard shortcuts? Would you please share your config? 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?

That's something I really need as well - I like how fast kitty is compared to iterm2, but I'm just so used to using the splits in iterm2 + using a global keyboard shortcut to show and hide the terminal. I couldn't find anything similar in a quick glance over the config :/

Global shortcut to bring up iterm2 is the main reason I use it!

Re: Kitty – a fast, featureful, GPU based terminal emulator

#247

Post by lytedev »

syn0byte wrote: post #226
jbb67 wrote: post #211

I don't even know where to start with this. We had terminals that were way faster than you could type or see 30 years ago. They didn't need a GPU and ran on a CPU 1000 times slower than what we have now. If this is progress... I'm not sure I want it

They were also char based display at something like 320x240 resolution and maybe 16-256 colors. 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.

Also, as others have noted, with many new layers of abstraction between user and system including the compositor, window manager, display manager, display server, and probably a host of others within the operating system and places I'm unfamiliar with.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#248

Post by snvzz »

dancek wrote: post #116
yason wrote: post #95

Why render with the GPU? I don't think I've seen a visually slow terminal emulator since 2000 and barely even in the 1990's. 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…

Input latency makes for a bad user experience. People just usually don't notice it when typing as it's so common. See https://danluu.com/term-latency/ for measurements of some terminal software and discussion of why latency is bad. I'm not sure if Kitty is using GPU specifically to minimize latency, but it would be a good reason.

>There are no benchmarks in which I've found Alacritty to be slower.

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.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#249

Post by snvzz »

christoph-heiss wrote: post #118

Another GPU-accelerated terminal emulator is alacritty[0]. 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. [0] https://github.com/jwilm/alacritty

>There are no benchmarks in which I've found Alacritty to be slower.

It's actually very, very slow.

https://danluu.com/term-latency/

Re: Kitty – a fast, featureful, GPU based terminal emulator

#250

Post by burfog »

laumars wrote: post #123
burfog wrote: post #23

What I could really use would be a terminal emulator that is: 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

Theres no way you can build a terminal emulator without a PTY and still expect terminal UIs (eg stuff that uses ncursors) to work. 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…

Yes you can. I want to hook this up to an emulator (like qemu or MAME) with an emulated serial port. That is the PTY equivalent. I'm writing this 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.

Post reply on HN