Live data from Hacker News

WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

wezfurlong.org

51–60 of 128 posts

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#51

I switched from Alacritty to WezTerm a few months ago. I cannot overemphasize what a healthier project/community this is. The developer is surprisingly responsive and seems to be a good guy. Join the Matrix room (linked from the GitHub repo readme) if you have any questions.

I don't know anything about Alacritty. What is unhealthy about the project?

There was a thread about this roughly two weeks ago:

https://news.ycombinator.com/item?id=29349240

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#52

Earlier quoted context omitted.

"cat 1_gb_of.txt" will push your terminal far beyond what just a CPU can comfortably handle.

And when do I want to `cat` 1GiB of text? I cannot process it with my human eyes, so what does it matter if the CPU rendering can keep up or not? cat 1_gb_of.txt | less Is what I want to do, and this is easily rendered even on older hardware.

When you don't actually realise it is 1 GB before you cat it.

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#53

This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.

Note that consoles back in the day (e.g. classic 80x25) were essentially hardware accelerated.

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#54
post #8

Earlier quoted context omitted.

Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my com…

I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?

For a basic example of why you would want GPU acceleration, have a look at refterm: https://github.com/cmuratori/refterm

Even processes that you wouldn't think would be impacted by a terminal can be hurt relaly bad by your terminal's performance: your compiler's logs, etc. The GPU rendering part merely guarantees that your terminal sticks at 60FPS (or, whatever your refresh rate is) if the processing behind is efficient.

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#55

I switched from Alacritty to WezTerm a few months ago. I cannot overemphasize what a healthier project/community this is. The developer is surprisingly responsive and seems to be a good guy. Join the Matrix room (linked from the GitHub repo readme) if you have any questions.

I don't know anything about Alacritty. What is unhealthy about the project?

I don't want to speak uncharitably of Alacritty, which was my daily driver for a couple years. It's FOSS, the developers don't owe me/us anything, etc. And I never contributed (though I tried once or twice and was summarily rejected).

It's better to focus on the positives of other projects. I will say, on a more specific note, that if you use macOS and have been frustrated with certain longstanding issues in Alacritty, you're in for a pleasant surprise with WezTerm.

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#56
post #18

Earlier quoted context omitted.

A really basic test is just type "base64 (ofc the differences might not be something you ever notice or care about)

But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?

What about when you don't know that it ends up being megabytes ? Say you're running Gradle on a large project that does a full recompilation. You don't really particularly care, you know that module X has warnings, etc. But it still prints it all out by default. With carriage returns to update the current percentage, ANSI codes and more. Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. This is compounded by other factors, but ultimately, writing to the terminal is not an asynchronous thing, so your process _will_ be impacted by it being slow.

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#57

This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.

> What is the advantage of GPU acceleration for a terminal emulator?

I haven't found any. Seems like it's just a fashion accessory for $THIS_YEAR.

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#58

Earlier quoted context omitted.

And when do I want to `cat` 1GiB of text? I cannot process it with my human eyes, so what does it matter if the CPU rendering can keep up or not? cat 1_gb_of.txt | less Is what I want to do, and this is easily rendered even on older hardware.

When you don't actually realise it is 1 GB before you cat it.

So then I hit Ctrl-C and issue the correct command. How does a GPU based renderer improve on that use-case?

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#59
post #8

Earlier quoted context omitted.

Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my com…

Lower CPU usage but higher GPU usage. On my laptop I get muuuch more battery out of it (going from 6 hours to ~2 hours) if I disable everything that may wake up the GPU and force software rendering everywhere (since, unlike GPUs, it's much more often able to rerender only the parts of the screen which changed)

Wall socket

Re: WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

#60
post #18

Earlier quoted context omitted.

A really basic test is just type "base64 (ofc the differences might not be something you ever notice or care about)

But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?

Android logs.
Post reply on HN