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

Alacritty gets scrollback, publishes benchmarks

jwilm.io

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Alacritty gets scrollback, publishes benchmarks

#11

Post by billiob »

jwilm wrote: post #7
Y_Y wrote: post #5

Earlier quoted context omitted.

How did you choose the terminals to benchmark against? What about xterm or gnome-terminal or powershell or whatever?

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.

Re: Alacritty gets scrollback, publishes benchmarks

#12

Post by jwilm »

pcwalton wrote: post #10

Regarding tabs, macOS has native tab support more or less built-in to the windowing system—you can see this in action if you create a document-based app in Xcode—but your app has to be structured in such as a way as to opt into it. Have you considered opting into this or would you consider it contrary to the project goals?

The hardest part about supporting things like this on macOS is that they often require a lot of additional code or a certain design whereas on Linux, a lot of these features are provided by the window manager.

I don't consider it contrary to the project's goals if it's something that can be done unobtrusively. Given your description, it sounds like this may be something we could support easily. I filed #1544 to track this. Thanks for the suggestion!

#1544: https://github.com/jwilm/alacritty/issues/1544

Re: Alacritty gets scrollback, publishes benchmarks

#13

Post by mindB »

These benchmarks miss the point in my opinion. When I'm choosing a terminal emulator, beyond features, the one "performance" metric that I'm interested in is latency; nothing else really affects my workflow (positively or negatively). In the benchmarks I've seen of alacritty wrt latency[1][2], it doesn't come out so well.

[1]: https://danluu.com/term-latency/

[2]: https://lwn.net/Articles/751763/

Re: Alacritty gets scrollback, publishes benchmarks

#14

Post by saagarjha »

jwilm wrote: post #12
pcwalton wrote: post #10

Regarding tabs, macOS has native tab support more or less built-in to the windowing system—you can see this in action if you create a document-based app in Xcode—but your app has to be structured in such as a way as to opt into it. Have you considered opting into this or would you consider it contrary to the project goals?

The hardest part about supporting things like this on macOS is that they often require a lot of additional code or a certain design whereas on Linux, a lot of these features are provided by the window manager. I don't consider it contrary to the project's goals if it's something that can be done unobtrusively. Given your description, it sounds like this may be something we could support easily. I filed #1544 to track…

This is actually enabled by default unless you disable it. No extra code needed, unless the macOS implementation conflicts with yours.

Re: Alacritty gets scrollback, publishes benchmarks

#16

Post by jwilm »

saagarjha wrote: post #14
jwilm wrote: post #12

Earlier quoted context omitted.

The hardest part about supporting things like this on macOS is that they often require a lot of additional code or a certain design whereas on Linux, a lot of these features are provided by the window manager. I don't consider it contrary to the project's goals if it's something that can be done unobtrusively. Given your description, it sounds like this may be something we could support easily. I filed #1544 to track…

This is actually enabled by default unless you disable it. No extra code needed, unless the macOS implementation conflicts with yours.

Thanks for this clarification. I don't see any reason we couldn't support this given that info.

We haven't intentionally opted out of this that I know of, we just didn't start Alacritty from an XCode project on macOS.

Re: Alacritty gets scrollback, publishes benchmarks

#17

Post by jwilm »

mindB wrote: post #13

These benchmarks miss the point in my opinion. When I'm choosing a terminal emulator, beyond features, the one "performance" metric that I'm interested in is latency; nothing else really affects my workflow (positively or negatively). In the benchmarks I've seen of alacritty wrt latency[1][2], it doesn't come out so well. [1]: https://danluu.com/term-latency/ [2]: https://lwn.net/Articles/751763/

"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

Re: Alacritty gets scrollback, publishes benchmarks

#18

Post by saagarjha »

jwilm wrote: post #16
saagarjha wrote: post #14

Earlier quoted context omitted.

This is actually enabled by default unless you disable it. No extra code needed, unless the macOS implementation conflicts with yours.

Thanks for this clarification. I don't see any reason we couldn't support this given that info. We haven't intentionally opted out of this that I know of, we just didn't start Alacritty from an XCode project on macOS.

I've noticed you don't have anything in the menu bar. The option normally appears under Window > Merge All Windows, which is inserted by default by the Xcode template.

Re: Alacritty gets scrollback, publishes benchmarks

#19

Post by mindB »

jwilm wrote: post #17
mindB wrote: post #13

These benchmarks miss the point in my opinion. When I'm choosing a terminal emulator, beyond features, the one "performance" metric that I'm interested in is latency; nothing else really affects my workflow (positively or negatively). In the benchmarks I've seen of alacritty wrt latency[1][2], it doesn't come out so well. [1]: https://danluu.com/term-latency/ [2]: https://lwn.net/Articles/751763/

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

Re: Alacritty gets scrollback, publishes benchmarks

#20

Post by jwilm »

saagarjha wrote: post #18
jwilm wrote: post #16

Earlier quoted context omitted.

Thanks for this clarification. I don't see any reason we couldn't support this given that info. We haven't intentionally opted out of this that I know of, we just didn't start Alacritty from an XCode project on macOS.

I've noticed you don't have anything in the menu bar. The option normally appears under Window > Merge All Windows, which is inserted by default by the Xcode template.

Thanks for this additional feedback. It sounds like we should create an XCode project from scratch to get many of the defaults and figure out how to bridge this with our current implementation.
Post reply on HN