Live data from Hacker News

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

blog.jwilm.io

81–90 of 491 posts

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

#82
post #26

Earlier quoted context omitted.

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.

[deleted]

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

#83
> Both the utf8parse and vte crates that were written for Alacritty use table-driven parsers. The cool thing about these is that they have very little branching; utf8parse only has one branch in the entire library!

From a simplicity point of view table-driven parsing is pretty neat. However, it does mean you'll be getting a lot of branch misprediction in your single branch, since it's harder for the CPU to predict where it will branch to. You could probably go faster with some handcoding in the parser.

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

#84
post #59

I'd like to host this terminal in a 3D environment. Any plans to enable this? Perhaps with a signed distance field texture. I'm building a 3D game in Rust and would like to be able to drop this in.

Oh, just as interesting, plugging this into VR system! Make it way easier to multitask and work on lots of systems (at the risk of looking incredibly goofy).

Sadly VR is useless for reading :( I wish it wasn't so. You're much better off with a high resolution screen with the ability to zoom in and out between landmarks. Maybe a head tracker to make navigation more intuitive.

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

#85
post #50

Earlier quoted context omitted.

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 a…

I just disable tmux's mouse usage by putting "bind m set -g mouse off" into my tmux.conf: tmux is useful enough just with key shortcuts, and I generally dislike terminal programs that use the mouse anyways.

Also, some terminal emulators (iTerm2 on Mac) let you disable mouse grabbing by holding a special key while clicking, maybe Alacritty could implement something like this?

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

#86
post #24

Earlier quoted context omitted.

I've done that (we all did), but "can't reproduce". So this seems to depend a lot on the emulator, eg. I'm using Konsole, which is superb, and don't see that problem there.

Konsole is the only emulator I've used (other than actual tty) that doesn't have this problem. It's actually been frustrating, becasue there is plenty about it that I don't like. I'll be giving Alacritty a try shortly - if it does what it says on the tin, it's exactly what I've been looking for.

Curious: What don't you like about Konsole?

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

#87

> Both the utf8parse and vte crates that were written for Alacritty use table-driven parsers. The cool thing about these is that they have very little branching; utf8parse only has one branch in the entire library! From a simplicity point of view table-driven parsing is pretty neat. However, it does mean you'll be getting a lot of branch misprediction in your single branch, since it's harder for the CPU to predict wh…

Rust has macros so any sort of tables can be rolled out into more efficient code, like if you wrote switch-case in C. It should be possible to rewrite vt_state_table! once later, when it becomes a problem.

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

#88
post #50

Earlier quoted context omitted.

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 a…

`mode-mouse off` helps tmux forget about mice.

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

#89

Earlier quoted context omitted.

Looking at the code, it looks like this basically only relies on two things: inclusive ranges, and clippy. But you don't have to use clippy this way; it's just one way of doing it. So it's really one feature. EDIT: Oh oops, and custom derive, which is stable in a month. > I really hope they're able to stabilize it In general, "nightly" is never going to be stabilized. Remember, it's how Rust development works. Some p…

My feeling is that having a lot of people running on different rust versions is likely to raise the bar to contribute to the project; for example if I go to hack on a python project the odds that I have to change my interpreter setup are basically zero. In this specific example, I saw that building the project required mucking with my rust version/setup and decided that the cost of that was too high for me to proceed…

Rustup makes it painless, though. I have a ton of versions of Rust installed. I use different versions for different projects. Some versions I just tested to find where the performance regression was, so I could just remove them, but they don't bother me.

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

#90
post #2

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

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

It's also a deal breaker for me. I use a tiling WM instead of tmux.

That said, I really wanted to build this exact same project at some point, so maybe seems like a feature that could be added in a fork :)

Post reply on HN