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

Kitty 0.17 – GPU-accelerated terminal emulator

sw.kovidgoyal.net

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#61

Post by pfranz »

einpoklum wrote: post #33

With due respect - this sounds like the terminal emulator equivalent of a ricer car: https://en.wikipedia.org/wiki/Rice_burner "fast"? What, terminal emulation is slow now? Needs hardware acceleration? Be serious. A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.

I've noticed terminal rendering performance issues when dumping a lot of text. If that's part of your job, it's important to you. For me it seems to come up once every few years and I've poked around at alternatives.

I've also heard about performance issues with high res, large terminals. It's a lot of pixels to throw at the screen and I'm sure most terminal emulators were written with much smaller screens in mind.

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#62

Post by JdeBP »

blinkingled wrote: post #14

Kitty is good but the only issue I have is the use of custom terminfo xterm-kitty. This means things break when ssh’ing to older Linux until you copy the terminfo manually. On BSDs it doesn’t work as there is no terminfo support.

It really should not be "xterm-" anything. This is another misnomer.

* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-...

* https://invisible-island.net/xterm/xterm.faq.html#other_vers...

The correct terminal type, per Dickey terminfo, is "kitty". (The PuTTY variant KiTTY is apparently also "putty".) And the terminfo database lends itself both to copying individual records and to having extra records in one's home directory.

* https://invisible-island.net/ncurses/terminfo.ti.html#tic-ki...

* https://invisible-island.net/ncurses/terminfo.ti.html#tic-pu...

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#63

Post by JdeBP »

blinkingled wrote: post #53
Strum355 wrote: post #49

Earlier quoted context omitted.

Doing `export TERM=xterm` has worked consistently for me

Yep it works for the most part - I remember having weird issues once in a while - not sure if it was build from git kitty that I was using or some TERM compatibility thing.

It's pretty much always the case in such situations that the terminal emulator is not XTerm and the "xterm" entry in termcap/terminfo simply does not describe it.

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#64

Post by JdeBP »

timw4mail wrote: post #45
diggan wrote: post #41

Earlier quoted context omitted.

As someone who is currently using Alacritty, and been since it first appeared on HN (years ago?), what specific features are you missing in Alacritty that Kitty has?

Tabs are probably the biggest thing.

One thing about tabs, which ironically has come up now for Microsoft Windows Terminal, is that they do not fit at all well with the idea of application-resizable terminals, which has been the widely case for terminal I/O since the days of 80/132 column application-switchable terminals back in the 1970s. If (just to pick a mild example) one tab is a 24-line terminal and another is a 25-line terminal, they aren't the same size in the GUI.

Line up a row of real terminals, and of course they do not constrain one another, size-wise. Indeed, back in the 1990s the DTTerm terminal emulator pioneered the terminal emulators' abilities for applications to set any arbitrary size (within reason) for a terminal emulator.

I did a quick review of terminal emulators in light of this, and varyingly tabbed terminal emulators do not support application resizing (DECSLPP/DECSNLS/DECSCPP) at all or support it in limited, or at least odd (compared to real terminals), ways. Konsole, possibly the best of the bunch, implements resizing properly, leaving large margins when the requested terminal screen size does not match the GUI window size, but triggers a GUI resize whenever a tab receives the input focus back, so application-requested size changes do not last if one switches amongst tabs. One tabbed terminal emulator author is actively opposing the idea that terminals should be resizable by applications emitting these control sequences, completely reversing course from DTTerm's innovation.

The problem for Windows Terminal is compounded by the fact that it isn't just supporting terminal I/O applications, it is supporting console I/O applications. In console I/O not only can applications set the screen buffer size at whim, they can also set the window rectangle. Not supporting either is a huge and very noticable step backwards, by over three decades, for Windows TUI applications that Windows Terminal is aimed to be compatible with.

A tabbed UI is not a universally unproblematic thing when it comes to terminal emulators. (-:

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#65

Post by JdeBP »

quotemstr wrote: post #23

I really like how kitty addresses the weird compatibility issues of bce [1] by providing a facility to just do character cell property modifications in an efficient and correct way [2]. I wish ncurses were more eager to adopt descriptions of innovations in terminal emulator design. [1] https://github.com/kovidgoyal/kitty/issues/160#issuecomment-... [2] https://sw.kovidgoyal.net/kitty/protocol-extensions.html#ext...

The problem with BCE is largely that it does not fit with the paradigms of ncurses and terminfo, not that it is problematic in itself. This is alas true of a large number of terminal things, from function keys through "cursor addressing mode" to erasure, whose ncurses/terminfo abstractions do not fit the actual ways that these work.

On both real (DEC) terminals and terminal emulators, background colour erase is settable off and on, with DECECM; so a full-screen application can set the behaviour and know what the colour is going to be, leading to more efficient screen redraws. The ncurses/terminfo model, in contrast, is that the behaviour is fixed on or off, and a boolean (named bce) in the database tells softwares which it is for any given terminal type.

In reality, it is the paradigms of ncurses and terminfo that are the problems here.

* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MEAN...

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#66

Post by mgaffney »

jstimpfle wrote: post #37
einpoklum wrote: post #33

With due respect - this sounds like the terminal emulator equivalent of a ricer car: https://en.wikipedia.org/wiki/Rice_burner "fast"? What, terminal emulation is slow now? Needs hardware acceleration? Be serious. A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.

Not just terminals. So much software is unbearably slow today. Definitely terminals. The only terminal I can really stand is xterm with bitmap fonts. https://danluu.com/term-latency/ > A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering. I've mostly done OpenGL recently, and I think xterm (which is fast) is an exception in that it us…

> https://danluu.com/term-latency/ This was written in 2017. It's got great information but I'm guessing most, if not all, of the terminals tested have newer versions. Just think of what 3 years of feature bloat could have done to their performance.

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#67

Post by blinkingled »

JdeBP wrote: post #62
blinkingled wrote: post #14

Kitty is good but the only issue I have is the use of custom terminfo xterm-kitty. This means things break when ssh’ing to older Linux until you copy the terminfo manually. On BSDs it doesn’t work as there is no terminfo support.

It really should not be "xterm-" anything . This is another misnomer. * http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-... * https://invisible-island.net/xterm/xterm.faq.html#other_vers... The correct terminal type, per Dickey terminfo, is "kitty". (The PuTTY variant KiTTY is apparently also "putty".) And the terminfo database lends itself both to copying individual records and to having extra records in…

Thanks for the insight :) I have always had a bit of 'why do I gotta know that' thing going on with terminfo, console and friends - this is making me want to dig a bit deeper!

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#68

Post by bspammer »

fnord123 wrote: post #13
unixhero wrote: post #2

Not to be confused with Kitty[0], a Putty fork. Also a terminal emulator! [0] http://www.9bis.net/kitty/#!index.md

Holy cow I really thought this was about the putty fork.

There are only so many words in the english language ending in tty I suppose.

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#69

Post by voxl »

pwdisswordfish2 wrote: post #31
KarlKemp wrote: post #26

Earlier quoted context omitted.

The relevant Github issue is also quite memorable: https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41... I wonder if the author might be willing to reconsider. He should have newfound appreciation for how annoying name collisions can be.

Ah, so he kept his attitude from back when he refused to fix security vulnerabilities in Calibre. Good to know. I'll keep avoiding his software.

I can't think of anything more petty or pathetic then taking the side of a mob that demands an open source developer change the name of the software he makes in his free time.

People talk about entitlement in games but here you are not even paying or even having a pretense of sponsoring.

Just gross.

Re: Kitty 0.17 – GPU-accelerated terminal emulator

#70

Post by tonyedgecombe »

bspammer wrote: post #68
fnord123 wrote: post #13

Earlier quoted context omitted.

Holy cow I really thought this was about the putty fork.

There are only so many words in the english language ending in tty I suppose.

It hadn't even occurred to me Putty was named that based on the word containing tty.
Post reply on HN