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

261–270 of 491 posts

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

#261

Post by dualogy »

dvt wrote: post #249
jwilm wrote: post #115

Earlier quoted context omitted.

The amount of time spent doing GPU work is rather small. Battery life tends to be better on my Macbook with Alacritty than with other terminals. This seems to suggest that power consumption is actually less than with CPU based renderers (and that your GPU fans shouldn't be spinning).

I didn't realize there's no Windows version available yet, I was totally thinking about my Windows laptop. My Apple (work) laptop is much better about not turning on fans willy-nilly.

Not necessarily due to "your Windows laptop", sometimes it's due to hidden/forgotten vendor bloatware and Windows' very own background services. That is, due to shabby software, not your laptop. I disabled Windows Update (rather check it manually every other month) and went through the list of services that'll realistically never be used even indirectly to disable and voila, no more random fan spinning! Until I open a WebGL page or something that is.. that "3D JS" will heat up even a current mobile workstation with a 3GB-VRAM Quadro GPU!

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

#262

Post by jcelliott »

rogerbinns wrote: post #215
jwilm wrote: post #160

Earlier quoted context omitted.

Thank you for the thoughtful comment. There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider. I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to…

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.

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

#263

Post by buzzybee »

readittwice wrote: post #248

so this uses GPU-accelerated rendering with OpenGL. TBH I have never used OpenGL and when I read "GPU-accelerated XYZ" this still sounds like magic to me because I've know idea how this works. Could you point me to some resources where I can read up on this stuff? if this helps you: I am not a newbie, I already know C, C++ and Rust, but I haven't done any graphics programming at all yet. For example I only have a ver…

I learned this stuff a long while ago, but I found a promising textbook for you to review [0]

tldr; the "easy 80%" of the effort in GPU rendering, specifically, is reformatting graphics data in forms that the GPU prefers. (The "hard 20%" is dealing with confusing APIs, broken implementations, etc.) Graphics techniques themselves may apply various mathematics(geometry, trigonometry, a little bit of linear algebra, DSP), either on the CPU or GPU. To render things you make decisions about the processing and output format and write data and algorithms accordingly.

[0] http://math.hws.edu/graphicsbook/

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

#264

Post by kevin_thibedeau »

nopreserveroot wrote: post #207
dekhn wrote: post #202

Earlier quoted context omitted.

The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.

That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"

You can still make modifications so long as it isn't distributed outside the company.

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

#265

Post by stuckagain »

sigi45 wrote: post #40

Less repeating that it is fast and more benchmarks instead!

Seriously. ^^^

How fast is it? I haven't had a terminal that was as fast as xterm with a matrox millenium ii. That was 20 years ago which is pretty sad. Of course the terminals look better these days.

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

#266

Post by Anderkent »

nopreserveroot wrote: post #207
dekhn wrote: post #202

Earlier quoted context omitted.

The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.

That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"

It's a very common company policy, because it's 'never use GPL' is a much easier rule to follow than 'only use GPL when it doesnt expose the company to risk'. Programmers aren't lawyers.

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

#267

Post by dman »

sidlls wrote: post #187
Thaxll wrote: post #167

Earlier quoted context omitted.

To change what exactly? What is the current issue with c++ that prevent you from doing a terminal using OpenGL?

Reading his comment, his concern isn't with c++ as a language, it's with the tooling and development practices around it. He suggests that because of the generally project specific nature of the tooling and development idioms, generally a higher bar of experience is required to contribute. I can't argue with him there, and I'm about as much of a C and C++ fan as it's possible to be.

I fully agree with you here - neither C/C++ are a gateway to salvation. http://www.redox-os.org/news/rust-is-softwares-salvation-17/

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

#268

Post by jalopy »

jwilm wrote: post #2

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

For some reason I can't run Emacs in terminal/unwindowed mode in Alacritty. Every "regular" character I type (ie to enter text into a buffer), Emacs says it's "unrecognized".

Control sequences work - ie I can exit with C-x C-e.

Works fine in regular Mac OS X terminal.

Any suggestions appreciated. Looks like an awesome project!

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

#269

Post by chadcmulligan »

stuckagain wrote: post #265
sigi45 wrote: post #40

Less repeating that it is fast and more benchmarks instead!

Seriously. ^^^ How fast is it? I haven't had a terminal that was as fast as xterm with a matrox millenium ii. That was 20 years ago which is pretty sad. Of course the terminals look better these days.

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

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

#270

Post by stuckagain »

chadcmulligan wrote: post #269
stuckagain wrote: post #265

Earlier quoted context omitted.

Seriously. ^^^ How fast is it? I haven't had a terminal that was as fast as xterm with a matrox millenium ii. That was 20 years ago which is pretty sad. Of course the terminals look better these days.

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.
Post reply on HN