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

21–30 of 491 posts

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

#21

Post by mrec »

frozenport wrote: post #10
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?

On Windows "std::cout" can take upwards of 3ms. I noticed this when writing high speed camera software that was supposed to hit my callback every 2ms. Instead it was limited by my print statement! Does this emulator solve my problem?

3ms sounds pretty dire, if you weren't writing very much. Out of curiosity, was this with or without `std::ios::sync_with_stdio(false);` ?

I've found syncing makes a huge difference to IO perf in Windows, e.g. `_getc_nolock` is much faster than `getc`. (Assuming of course that you can get away with it.)

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

#24

Post by dom0 »

snuxoll wrote: post #12
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?

Have you even had Control-C take forever to kill that `cat` you accidentally ran against a 1GB log file? I have. Most terminal emulators are 'dumb' and try to render the whole backbuffer sequentially even if what you are seeing is no longer the tail of the output stream. It's not so much that this is 'fast' (because even gnome-terminal which is not what I'd call crazy fast is 'fast enough' most days), but that it's m…

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.

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

#26

Post by jwilm »

vvanders wrote: post #19
jwilm wrote: post #2

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

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.

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

#27

Post by tetraodonpuffer »

Florin_Andrei wrote: post #25
jwilm wrote: 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?

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.

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

#28

Post by valarauca1 »

ahoka wrote: post #13
jwilm wrote: post #2

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

Not really a question, but a request. Given you have a Travis CI setup, could you make binary snapshots available?

from the readme [1]

    This initial release should be considered to be pre-alpha 
    software--it will have issues. Once Alacritty reaches an 
    alpha level of readiness, precompiled binaries will be 
    provided for supported operating systems.
[1] https://github.com/jwilm/alacritty
Post reply on HN