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

Alacritty – A fast, cross-platform, OpenGL terminal emulator

github.com

Post reply on HN
Print view View original

91–100 of 174 posts

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#91

Post by viraptor »

lupusreal wrote: post #76
skywal_l wrote: post #67

Earlier quoted context omitted.

Funny, I always use the binaries distributed by the developers whenever I can thinking that the less intermediaries the better. Maybe I need to revise that position.

Malicious distro packagers are virtually unheard of, and another set of eyes on the software is generally better. For instance, if the developer sells out the packager can save your bacon. This is especially true on Android where selling out is more common (see: the Simple Apps situation and F-Droid) but also a valid consideration on desktop Linux.

I wouldn't assume anything about distro packages really. It's a higher bar in some systems (like Debian), lower in some (like nixpkgs), but the time investment to be in a position to sabotage something is quite low overall and requires little skill. Then there are not-distro packages that they easily abused over time. For example sourceforge was a respected distributor of software for a long time and they moved to adware installers.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#93

Post by saurik »

jhchabran wrote: post #62
squigz wrote: post #42

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

The delay in between typing and seeing it rendered, drawing large portions of text (which matters if you spend a lot of time in term based editors) etc ... It's very subjective: some folks (me included) will notice the difference and feel frustrated if it's not fast enough, while others are scratching their head about how it actually makes a difference. It could also be said, that it's of logical to expect certain th…

The issue is that usually these terminals mean "higher throughput" when they say "faster", not "lower latency". The lowest-latency terminal in every test is Xterm, often by a LOT. Alacritty for a long time was actually quite bad at latency--and notably had a high variance on its latency, which is particularly miserable--but I think it improved recently? From what I remember of these benchmarks, someone using urxvt isn't going to be impressed by the supposed speed of Alacritty, if we are talking latency (and I agree: we should be, and everyone should use Xterm, which is actually an insanely good terminal).

As for throughput, I have lived in the terminal for decades, and as long as the various layers don't have massive buffers I honestly don't care how slow the terminal is: if I am dumping megabytes into my terminal backscroll I probably am going "oh shit" and am frantically hitting Ctrl-C... a slow terminal with a small buffer handles that almost immediately. I get the impression that there are maybe some use cases involving high-rate screen updates for apps that happen to run in consoles but are really GUIs... I don't use many of those and in fact try to avoid them, but I could maybe see an advantage for a high-throughput terminal to improve their simulated frame rate?

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#94

Post by reyqn »

padthai wrote: post #47
zokier wrote: post #14

Alacritty, foot, wezterm, kitty form this block of "nextgen" terminal emulators. I do find them difficult to differentiate. I personally use foot as my daily driver, but that is just because alacritty happened to have some issues with nvidia drivers (bleh). But I chalk that up to nvidia, not alacritty.

Foot is Linux only and lightweight, take it as a Wayland version of Xterm with good defaults and almost no emulation options. The rest works in all major OS. Alacrity is all about GPU rendering speed at the cost of everything else (at some point it did not have scrollbars/history). Kitty and Wezterm are packed with features and more difficult to differentiate. They are all good though.

Not sure if you don't consider Windows a major OS, but Kitty doesn't work there.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#95

Post by saurik »

5e92cb50239222b wrote: post #50
squigz wrote: post #42

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

I only really notice it when accidentally catting a really large file. Although I prefer kitty, any of these modern terminal emulators just rip through megabytes of text in less than a second, while in older ones you have to wait for half a minute or just sigkill them.

Your buffer is too big: your terminal shouldn't be sitting there for half a minute, as it should be processing Ctrl-C immediately and unrelatedly to its screen updates and sending it, and the remote process should be blocked on a write to its output (which in turn should prevent it from creating more garbage due to the back pressure) because all the buffers between it and you are full. Having ginormous buffers and then wanting the local terminal to be super fast to clear them quickly is kind of pointless as the use case for streaming megabytes of garbage to the terminal and NOT cancelling the operation are effectively 0.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#96

Post by fathyb »

keyle wrote: post #15

If you're on a mac, wouldn't be best to adopt iTerm2 with its metal rendering? Isn't OpenGL deprecated on macOS?

Alacritty uses OpenGL ES 2.0 which is not deprecated. It's shipped OOB in macOS through the ANGLE project by Google, mainly because Safari depends on it to provide WebGL support (it's kind of OpenGL ES for JavaScript). ANGLE translates OpenGL ES so that it runs on top of Metal, D3D, or desktop OpenGL.

OpenGL ES 2.0 is probably the most portable GPU rendering API there is, it pretty much runs anywhere. That said, using Metal or D3D should definitely bring noticeable improvements, especially when it comes to memory bandwidth (eg. on Metal no need to send pixels to the GPU memory for atlas-based text rendering).

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#98

Post by SushiHippie »

platzhirsch wrote: post #13

Since it's the year of Wayland desktop I prefer foot https://codeberg.org/dnkl/foot Renders faster than Alacritty or kitty.

Same and it also opens faster, which is important for me, as I use a tiling window manager and open/close terminals fairly often instead of using something like tmux.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#99

Post by Delk »

berkes wrote: post #80
datadeft wrote: post #73

Earlier quoted context omitted.

You can ask these questions about pretty much every single performance improvement project. At the end there is always a win: - cost (this is more relevant to large scale infra perf opt) - UX (this is what a fast terminal might be achieving) - energy efficiency (because energy is super cheap these are often overlooked, however battery life might be still relevant)

> energy efficiency I highly doubt that offloading the rendering to a GPU is more energy efficient. I'm quite sure it's the exact opposite: GPUs are power hungry energy-eaters; commonly.

GPUs (namely discrete ones) often have high maximum power draw, but that's because they're generally used for tasks that require computational heavy lifting. That doesn't mean they're particularly power-hungry in terms of watts vs. amount of work done. If you offload e.g. video decoding to a GPU, that's usually more energy-efficient than decoding on the CPU.

(The heavy lifting is probably more energy-efficient on the GPU, too, but that's not directly relevant here.)

Post reply on HN