Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

wezfurlong.org

Post reply on HN
Print view View original

91–100 of 128 posts

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

#91

Post by vidarh »

samwillis wrote: post #7

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.

Very little unless you use shaders for effects. . Updating terminals fast enough was a solved problem on 30 year old hardware. Most of the slowness of some terminal apps is down to poor design not CPU rendering (see the speed differences between various CPU rendered terminals)

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

#92

Post by gregwebs »

theobeers wrote: post #35

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 chose WezTerm because Altacritty is optimized for dumping large amounts of text to the terminal which is something I don't care much about. There are a lot of other terminal emulators that have lower latency for just normal typing, etc. Wezterm, kitty, zutty, uxterm, xterm.

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

#93

Post by floatboth »

vidarh wrote: post #91
samwillis wrote: post #7

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.

Very little unless you use shaders for effects. . Updating terminals fast enough was a solved problem on 30 year old hardware. Most of the slowness of some terminal apps is down to poor design not CPU rendering (see the speed differences between various CPU rendered terminals)

30 year old hardware didn't have to render fancy antialiased fonts at 3840x2160 @ 144Hz.

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

#94

Post by gregwebs »

benfrain wrote: post #33

Any Kitty users tried this? I’ve found Kitty to be exemplary so would be curious if anyone finds this an improvement?

Wezterm has more features and for me being written entirely in Rust made it easy to send a bug fix patch. Kitty however seems to have a noticeably lower latency at least on mac.

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

#95

Post by vidarh »

ohgodplsno wrote: post #54
samwillis wrote: post #11

Earlier quoted context omitted.

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 effici…

This was a solved problem in the 1980's with Amiga consoles separating input processing, high level terminal handling and rendering into separate threads.

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

#96

Post by floatboth »

jcelerier wrote: post #26
mattbee wrote: 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)

> rerender only the parts of the screen which changed

e.g. Firefox is already good at doing that on the GPU. WezTerm isn't yet, but We're Working On It™ (i.e. someday it will be done), follow https://github.com/wez/wezterm/issues/1134

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

#97

Post by vidarh »

user-the-name wrote: post #12
samwillis wrote: post #7

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.

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

... if the terminal is poorly designed and renders every character update even when the buffer is filling, rather than batch updates.

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

#98

Post by theobeers »

foothall wrote: post #77
theobeers wrote: post #55

Earlier quoted context omitted.

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 Alacritt…

I see. Poor MacOS support isn't indicative of an unhealthy project, but I can see why MacOS users might want to avoid such projects.

Support for macOS is not poor—though it could go that way eventually. It would be more accurate to say that Alacritty qua macOS software is now almost unmaintained. If you encounter a problem, don't hold your breath; deal with it in your own fork. (I did this for many months.)

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

#99

Post by usrbinbash »

ziotom78 wrote: post #82
usrbinbash wrote: post #58

Earlier quoted context omitted.

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

Before you press Ctrl+C and type the correct command, your neighbour running Kitty has already got the last line of the output (which is often the only thing that one really needs). I switched to Kitty because I felt that the increased speed produced a perceived improvement in my workflow.

>which is often the only thing that one really needs)

    tail 1_gb_of.txt
...will get the last line of output long before the rendering engine finished initializing. And it will probably do so even on a 10year old laptop with no GPU, in virtual console, while the system is running under load ;-)

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

#100

Post by vidarh »

floatboth wrote: post #93
vidarh wrote: post #91

Earlier quoted context omitted.

Very little unless you use shaders for effects. . Updating terminals fast enough was a solved problem on 30 year old hardware. Most of the slowness of some terminal apps is down to poor design not CPU rendering (see the speed differences between various CPU rendered terminals)

30 year old hardware didn't have to render fancy antialiased fonts at 3840x2160 @ 144Hz.

My computer in the 80s ran at 7.16MHz and a single core. The CPU speedup has increased far more than the amount of data to be moved even at the kind of setup you're describing.
Post reply on HN