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

331–340 of 491 posts

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

#331

Post by Ericson2314 »

WhatIsDukkha wrote: post #95

I really disagree with the authors definition of minimal. Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have. I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know…

I avoid tmux and screen to. Instead I use SSH multiplexing (great for rsync tab complete too), and let the window manager so its job.

All I need is an orthogonal solution for persistent shells (how about I persist arbitrary login process trees, graphical or textual, OK?) And I'll truly have no need for tmux.

Then again I don't ssh too often for too long, so the last part is endlessly low priority.

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

#332

Post by rogerbinns »

jcelliott wrote: post #262
rogerbinns wrote: post #215

Earlier quoted context omitted.

I'd be very happy if you more closely integrated with tmux and used the features from tmux instead transparently. I don't care how the terminal does scrollback, as long as it does. If you forwarded the scrolling commands to tmux then great. Same thing with tabs, panes etc. As much as I like tmux (although I exclusively use it via byobu), the single most annoying thing is that it won't let different viewers see differ…

You probably want to do something like this: tmux new-session -t main -s main2 In practice it looks the same as attaching to the same session twice, except you can look at different windows at the same time.

Ok, now make byobu do that since it is how I actually use tmux. Also make sure it happens on every system I use. This gets tedious and annoying very fast. Heck mouse support not being on by default, requiring a single line in a config file on every system is already annoying enough.

The problem isn't that it is possible in theory. It is annoying in practise, unless you only have one machine and only need to do all this once in one system.

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

#333

Post by jstimpfle »

skybrian wrote: post #274

It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue? On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering fast…

I'm still using xterm (with bitmap fonts) for this reason -- the alternatives I know are both slower and antialiased fonts look blurry.

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

#334

Post by jstimpfle »

mrob wrote: post #307
skybrian wrote: post #274

It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue? On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering fast…

Not all people are equally sensitive to graphical performance issues. The default Ubuntu terminal is capped at approximately 40fps[1]. This is deliberate and hard-coded. It's not an integer multiple of any common screen refresh rate and it looks very bad. There is no way to configure keyboard autorepeat so new input is shown with consistent timing. I consider this bad design and I'm happy that Alacritty is limited on…

keyboard autorepeat doesn't have anything to do with the terminal emulator (or I would be surprised). There's an X11 setting, try "xset r rate ", e.g. "xset r rate 170 30".

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

#335

Post by chriswarbo »

atombender wrote: post #322
chriswarbo wrote: post #310

Earlier quoted context omitted.

I use st as my terminal application. Inside, I run dtach to provide detaching/reattaching functionality. Inside that I run dvtm to provide multiplexing and scrollback. Inside that I run bash. Inside that I run ad hoc commands. Everything's highly composable, e.g. I can switch out bash for zsh, fish, etc. I can switch out dtach for abduco. I can switch out dvtm for tmux or screen. I can switch out st for xterm or urxv…

Each to his own. Your setup sounds like a parody of the most outlandishly neckbeardy things devs can do in a shell. Most users don't want to deal with that sort of "layering".

> Your setup sounds like a parody of the most outlandishly neckbeardy things devs can do in a shell.

I shaved off my neckbeard, I'll have you know! ;)

My setup's no more outlandish than using tmux or screen, except instead of typing `tmux` or `screen` I type `shell`, which aliases a `dtach dvtm` one-liner (with a few options sprinkled around, so I don't have to bother with config files).

The point is that none of these applications care if/how they're composed; if I want to add in or swap out something, it's just a change that one-liner.

Not so if, say, my terminal application were hard-coded to rely on tmux, as some sibling comments have suggested.

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

#336

Post by jwilm »

brandur wrote: post #80

I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the boun…

> do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally?

I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really looking forward to see where it goes!

[0]: https://github.com/withoutboats/notty [1]: https://github.com/jwilm/alacritty/issues/51

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

#337

Post by chadcmulligan »

stuckagain wrote: post #270
chadcmulligan wrote: post #269

Earlier quoted context omitted.

yah, 9600 baud is as fast as I need my terminal to go. 19.2K is just crazy.

That's not what I said. What I said was that terminal was unbelievably fast. Especially for backwards scrolling which is an important use case to me.

I was just having a little joke, apologies if it came off as a criticism. It seems very strange to me that people are still talking about speeds of terminals, but not my field (any more) fortunately.

One of the first things I wrote was a terminal emulator using telnet to run on PC-DOS using a port of curses to connect to our Sun 3's. To think in 2017 people are still concerned about terminals is very surprising to me.

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

#338

Post by madgar »

mcguire wrote: post #325
madgar wrote: post #315

Earlier quoted context omitted.

I would characterize about 1/3 of HN posts as infantile delusion. You just learn to tune it out and get to the adult posts more quickly. There are browser extensions to help with this, too.

Ok, now you have got me. What extensions are those?

I personally use Hacker News Enhancement Suite for Chrome and tag users whenever I find myself mentally rolling my eyes. Then when I'm reading a page with lots of comments and see the "SKIP" tag I collapse the thread.

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

#339

Post by mrob »

jstimpfle wrote: post #334
mrob wrote: post #307

Earlier quoted context omitted.

Not all people are equally sensitive to graphical performance issues. The default Ubuntu terminal is capped at approximately 40fps[1]. This is deliberate and hard-coded. It's not an integer multiple of any common screen refresh rate and it looks very bad. There is no way to configure keyboard autorepeat so new input is shown with consistent timing. I consider this bad design and I'm happy that Alacritty is limited on…

keyboard autorepeat doesn't have anything to do with the terminal emulator (or I would be surprised). There's an X11 setting, try "xset r rate ", e.g. "xset r rate 170 30".

The timing of the input itself doesn't vary, but the timing of the visual feedback does. I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting). If the terminal is displaying at 40fps then some separate inputs will be merged and displayed at the same time. And if you like 30Hz autorepeat, instead of consistent 2 frames per input, you get a mixture of 1 to 3 frames per input depending on how the cycles line up. It makes it much harder to hit the exact character you want if you're using autorepeat for navigation.

Ideally the terminal should have MPV-style motion interpolation for supporting keyboard repeat rates that aren't an integer multiple of the display's refresh rate.

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

#340

Post by ac29 »

jwilm wrote: post #301
stuckagain wrote: post #282

Earlier quoted context omitted.

I put this comment elsewhere in the thread, but maybe if I put it in this subthread you'll get to see it. I tested on my laptop (a ThinkPad X250) and alacritty is slower than xterm. xterm can display find / at 80x24 in 11 seconds, but alacritty takes 17 seconds or more, depending on how large the window is (smaller seems to be slower) and whether it's on-screen or not (off-screen seems to be slower).

There's a small subset of systems experiencing this. Do you happen to have a Radeon video card? In the profile I looked at, glClear was calling down into (through libxcb) __poll_nocancel which was eating 99% of the CPU time. I'm not sure if there's an issue open for this yet, but it's something we're looking into. One of my testers during development ran into this so we're aware of the problem.

Another data point with find /:

terminator: 0m58s

alacritty: 2m46s

Up to date Arch Linux.

OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile

OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.3

edit2: there is a bug report tracking this issue here: https://github.com/jwilm/alacritty/issues/125

Post reply on HN