If this is progress... I'm not sure I want it
Kitty – a fast, featureful, GPU based terminal emulator
211–220 of 323 posts
Re: Kitty – a fast, featureful, GPU based terminal emulator
#212Re: Kitty – a fast, featureful, GPU based terminal emulator
#213Earlier 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 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.
Re: Kitty – a fast, featureful, GPU based terminal emulator
#214Re: Kitty – a fast, featureful, GPU based terminal emulator
#215Earlier quoted context omitted.
And most of it still works perfectly fine on an iPad Pro, in a completely new browser from the future. Good times!
On safari desktop and mobile, I get: > 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
Re: Kitty – a fast, featureful, GPU based terminal emulator
#216Earlier 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 :/
Re: Kitty – a fast, featureful, GPU based terminal emulator
#217I've been using Kitty for a month now. I really like it. It's slightly less usable out of the box than iTerm 2. The default shortcuts are very counterintuitive (no CMD T for new tab or CMD W to close tab). But editing the preferences is straightforward. 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 tran…
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.
Re: Kitty – a fast, featureful, GPU based terminal emulator
#218Terminal emulators have tabs/windows, tmux has tabs/windows, vim has tabs/windows. All with different keyboard shortcuts and semantics. 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.
Re: Kitty – a fast, featureful, GPU based terminal emulator
#219I 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
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.
Re: Kitty – a fast, featureful, GPU based terminal emulator
#220Earlier quoted context omitted.
The big idea of Alacritty is that it uses the GPU for superfast rendering and updates. But relying on tmux for scrolling seems to be a case of "penny wise and pound foolish". Having to round trip key presses and updates through a separate and possibly remote process (tmux) just to do scrolling, introduces a bunch of latency. "Normal" emulators with built in scrolling don't have this problem. Scrolling is purely local…
It's not for scrolling , it is for scrollback .