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

Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

blog.jwilm.io

Post reply on HN
Print view View original

41–50 of 491 posts

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#41

Post by 1_2__3 »

jwilm wrote: post #6
h4nkoslo wrote: post #3

Earlier quoted context omitted.

Cool project, but I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. What applications benefit from a terminal that's even an order of magnitude faster than the alternative?

Terminal performance is fine at smaller sizes and with less going on. In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty. Alacritty is about having tools that do…

That's a lot more to do with Vim that your terminal emulator. It chokes on some files pretty reliably.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#42

Post by sanderjd »

swsieber wrote: post #32
Florin_Andrei wrote: post #25

Earlier quoted context omitted.

> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?

They suggest passing that duty off to tmux. Kinda makes sense I guess... though I'd love to have it.

Does tmux interpret mouse scroll events, or is it only keyboard-based?

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#43

Post by vvanders »

jwilm wrote: post #26
vvanders wrote: post #19

Earlier quoted context omitted.

Very cool, how are you handling glyphs? Do you have an LRU font cache or something simpler?

Glyphs are rasterized once and stored in a texture atlas. When rendering a glyph, the fragment shader pulls from that texture. Once loaded, the glyph stays loaded for the duration of the program.

Got it, just a heads-ups that texture atlas tends to hammer your GPU texture upload if you want to support UTF or non-latin(esp glyph-based) character sets.

Not trying to be discouraging just something to keep in mind if that's a direction you want to go. Pretty excited to see a GPU + Rust based stuff making it out into the wild.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#45

Post by kickscondor »

jwilm wrote: post #26
vvanders wrote: post #19

Earlier quoted context omitted.

Very cool, how are you handling glyphs? Do you have an LRU font cache or something simpler?

Glyphs are rasterized once and stored in a texture atlas. When rendering a glyph, the fragment shader pulls from that texture. Once loaded, the glyph stays loaded for the duration of the program.

Any idea how much memory it takes to store the full atlas for a font with full Unicode/emoji support? Also does it work for colored emoji?

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#46

Post by ekidd »

jwilm wrote: post #2

I'm the author of Alacritty, and I'm here to answer any questions!

I just wanted to say that this looks like a fantastic and very cool project! Congratulations on the speed.

Personally, the lack of scrollback and tabs is a dealbreaker for me. I know that I'm supposed to use tmux for that, but I can never remember how tmux scrollback and tab switching work without thinking about them. Plus I rely heavily on mouse selection of multi-screen text in the scrollback buffer. So I'm unlikely to be part of your target audience. (However, I could live without GUI config and menus, because I configure my terminals once every few years at most.)

Also, a silly question: Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#47

Post by woodrowbarlow »

sanderjd wrote: post #42
swsieber wrote: post #32

Earlier quoted context omitted.

They suggest passing that duty off to tmux. Kinda makes sense I guess... though I'd love to have it.

Does tmux interpret mouse scroll events, or is it only keyboard-based?

I know that screen can be configured to do that. I would be surprised if tmux cannot.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#48

Post by kbenson »

llimllib wrote: post #35

> Make sure you have the right Rust compiler installed. Alacritty is currently pinned to a certain Rust nightly Ok, I'll... um not do that. Hope you publish a build soon though! edit: more seriously, the nightly compiler situation on rust is going to become a problem as it gets more developer use. I really hope they're able to stabilize it. edit 2: I'm really sorry if I derailed the conversation in a not useful way,…

Using nightly for a single build and going back to stable for regular work is not hard. It's a command or two to build and switch, and a command to switch back.

Using nightly rust to build a project in development to check it out is like using a beta release of a library to build a project to check it out. In both cases, you expect that it will likely be using stable dependencies in the future, and you can still take a look now.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#50

Post by eridius »

tetraodonpuffer wrote: post #27
Florin_Andrei wrote: post #25

Earlier quoted context omitted.

> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?

the use case seems to be using tmux inside the terminal emulator, with tmux you'd use its own scrollback buffer (edit) from the project's github page in fact The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as tmux.

The problem with this is using tmux screws with using mouse for selection (since tmux takes over the mouse and does its own selection thing, which usually doesn't do what I want).

This approach also means you can't do anything interesting like what Terminal.app does with detecting prompts, marking them, and letting you jump back to them (or clear history back to them).

This approach could be excused if the terminal actually natively integrated with tmux, thus providing its own gui splits/tabs that represent tmux's panes/windows, but it doesn't sound like it does that.

Post reply on HN