Alacritty gets scrollback, publishes benchmarks

Post by jwilm » Mon, Sep 17, 2018, 6:31 PM UTC

billiob wrote: post #11

jwilm wrote: post #7

Earlier quoted context omitted.

We tried to strike a balance between "commonly accepted as fast" terminal emulators and coverage of "commonly used" terminal emulators. Termite gets us libvte-based terminals (like gnome-terminal), urxvt is generally considered as one of the fastest, and Kitty is another well-regarded GPU-accelerated terminal emulator. On macOS, there's not nearly as many choices. Ultimately, it would be great if we could benchmark a…

You could try Terminology (I'm the main dev). It can be GPU-accelerated or not.

Post by singingboyo » Mon, Sep 17, 2018, 6:54 PM UTC

mindB wrote: post #19

jwilm wrote: post #17

Earlier quoted context omitted.

"miss the point" feels a bit strong. Rather, I get the impression Alacritty's values don't match your own values in a terminal emulator, and that's totally OK. Historically, input latency hasn't been considered a big pain point by most users. That said, we do have a plan[1] to address this issue and be both high throughput _and_ low-latency. [1]: https://github.com/jwilm/alacritty/issues/673

Fair enough. :) I guess my stronger wording is because I don't understand workflows where being able to dump vast quantities of text to the terminal quickly is important. In general, a terminal emulator is for use by a human, and humans can't really process info at the throughput rate of other terminal emulators, much less the faster alacritty. All that said, I'm glad to hear there's a plan on the latency front.

Post by O_H_E » Mon, Sep 17, 2018, 7:05 PM UTC

Post by jimpudar » Mon, Sep 17, 2018, 7:34 PM UTC

singingboyo wrote: post #23

mindB wrote: post #19

Earlier quoted context omitted.

Fair enough. :) I guess my stronger wording is because I don't understand workflows where being able to dump vast quantities of text to the terminal quickly is important. In general, a terminal emulator is for use by a human, and humans can't really process info at the throughput rate of other terminal emulators, much less the faster alacritty. All that said, I'm glad to hear there's a plan on the latency front.

It's not ideal, but one flow I end up using at some points is tmux-as-grep. Basically, something either gets dumped to terminal, and I use tmux's search. So then, for a combo of reasons (some good, some bad) I cat files to terminal on occasion, and I use tmux's search to find something in it. The idea isn't that the I'm processing at the throughput rate of the emulator - it's more that a low throughput rate delays wh…

Post by O_H_E » Tue, Sep 18, 2018, 2:09 AM UTC

L0stLink wrote: post #28

O_H_E wrote: post #25

What possible use cases where such high scrollback speeds could be useful?

Performance is never a bad thing, even if I don't always need my terminal emulator to be able to handle large amounts of text, there is nothing wrong with having a light weight high performance (eventually cross platform, hopefully) modern terminal emulator. I read a while back that implementing the same in iterm2 (a popular macOS only terminal emulator) is challenging due to past design decisions [0]. Certainly in a…