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

301–310 of 491 posts

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

#301

Post by jwilm »

stuckagain wrote: post #282
jwilm wrote: post #2

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

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.

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

#302

Post by jwilm »

gbuk2013 wrote: post #255
jwilm wrote: post #2

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

Just another vote for scroll back - would not use without. I do use tmux occasionally but it is just too awkward beyond keeping stuff running in SSH. I also have a tiling window manager and since I use mouse a lot in browser and other GUI apps it's too much of a pain to switch to keyboard only navigation for the terminal.

The tiling WM argument has basically sold me at this point. I'm expecting to open an issue about adding this feature behind a compile-time flag.

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

#303

Post by jwilm »

digler999 wrote: post #108
jwilm wrote: post #2

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

since it's GL-rendered at 60+fps, will I see a much more smooth scrolling effect ? Does scrolling introduce lines discretely or continuously ?

Generally continuously, but it depends on how you scroll. If you're in `less` for example and holding the down key, you will probably see one line at a time, and it should be very smooth. It's possible with high key repeat rates that you might get multiple lines on some frames.

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

#304

Post by coldtea »

y7 wrote: post #277
coldtea wrote: post #250

Earlier quoted context omitted.

> Completely understandable. This decision was expected to be polarizing. The project being OK with polarizing decisions (instead of listening to the community and discussing it) is the dealbreaker for me. It's OK to build opinionated software, but not at such basic level.

Doesn't being opinionated necessarily preclude listening to a community and following consensus?

No. Rails is opinionated but also had great community driven improvements.

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

#305

Post by chriswarbo »

m45t3r wrote: post #231
arandomcoder wrote: post #180

Earlier quoted context omitted.

I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p

> I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p This is the problem of Unix philosophy, becau…

> Adding tmux just to get scrollback goes against Unix philosophy.

I agree. Rather than adding scrollback support to allacritty, maybe someone could write an independent program for scrollback support (a la dtach/abduco for detaching/reattaching)?

Such a program would be useful for all terminals which lack scrollback (alacritty, st, possibly others).

For the record I use st with dtach and dvtm; scrollback is supplied by dvtm, but it would be nice to decouple it some more.

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

#306

Post by cyberpunk »

Jwilm: This is great, and I'm really looking forward to following this project; beers on me and thanks for the effort!

A few findings from my side if you want some feedback, I generally work mosh'd into some beefy servers with a long running tmux I resume -- so I'm probably the use case this is aimed at (client: xps13, archlinux).

1) If I create a vertical split view (tmux_key+v) while I already have some output in the left side of the split, and have nothing but my prompt in the right side; then resizing the split is instant/snappy.. However, if I then do a find / in the 'new' (right) split, ctrl+c it after a moment and then resize it lags/judders hugely -- I'm not sure what's going on there but let me know if you'd like me to try and explain that more if you can't reproduce from that.. This doesn't happen in termite..

2) I had to set offsets and use a giant font to make it look reasonable on my (highdpi) lappy:

font:

  normal:
    family: SourceCodePro # should be "Menlo" or something on macOS.
    style: Regular

  bold:
    family: SourceCodePro # should be "Menlo" or something on macOS.

  italic:
    family: SourceCodePro # should be "Menlo" or something on macOS.

  size: 26.0

  offset:
    x: 4.0
    y: -30.0
Otherwise:

+100 :}

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

#307

Post by mrob »

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 only by the monitor. But some people might never notice the timing problems in other terminals.

[1] https://github.com/GNOME/vte/blob/b517d20379c7a665e897f925ca... line 10685

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

#308

Post by seeekr »

atombender wrote: post #235
twic wrote: post #222

Earlier quoted context omitted.

That particular example of find not needing to sort persistently annoys me. sort doesn't know anything about the structure of its input, so it has to read and buffer all of it before it can sort it. find knows that its input is a tree of strings, which it could exploit to produce sorted output at the cost of buffering one directory's worth of filenames at each level of the tree. It's rarely a significant problem in p…

To avoid cluttering "find" with a sorting interface, we could use the modern technique processing push-down: If you do "blah | sort", then "sort" could ask its upstream processing node whether it supported sorting on the requisite fields, and "push down" the necessary sort-order descriptor into the "blah" step. That requires two things: That the pipe API sets up a communications channel between the two programs in a…

... or the downstream program could ask the upstream one (or get automatically along with the stream) about meta-data/type information for the stream it is being passed, and then it could benefit fully from already-known information. Though that does not solve the need to potentially read the full stream and buffer it before doing the processing.

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

#309

Post by stuckagain »

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.

It seems to be a OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)

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

#310

Post by chriswarbo »

lobster_johnson wrote: post #200
arandomcoder wrote: post #180

Earlier quoted context omitted.

I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p

> Alacritty follows the Unix philosophy of doing one thing, and doing it well. That principle is often misapplied, and I think that's true here, too. The "do one thing" about Unix is really about composability (e.g. "find" doesn't need to sort because you do "find | sort"), but you don't compose a terminal app with anything. A terminal app that has terminal features doesn't violate any principles of simplicity.

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 urxvt. And so on.

Adding an extra layer for scrollback, separate from a multiplexer, wouldn't disrupt anything, and would provide more flexibility for composition.

Post reply on HN