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

111–120 of 128 posts

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

#111

Post by goldenkey »

jstimpfle wrote: post #107
goldenkey wrote: post #69

Earlier quoted context omitted.

Caching glyphs, into a texture. Then they don't need to be re-rendered and can just be copied.

Let's say 512 glyphs should be a pretty conservative upper bound for normal usage. Just pulling this number out of thin air, but I assume it's reasonable. normal glyphs should be about 100-400 pixels (20x20), for 8-bit grayscale that means 2MB of texture cache should be plenty for normal use. Multiply by 3 if you want to support subpixel rendered glyphs, that still leaves us with a very comfortable upper bound of 6MB…

> 512 glyphs

You're forgetting about colored glyphs. Although a fragment shader should be able to deal with that, shouldn't it?

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

#112

Post by CyberRabbi »

the_gipsy wrote: post #5
CyberRabbi wrote: post #4

> WezTerm is a GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust This is great. I’ve been looking for a GPU-accelerated terminal written in Rust and haven’t been able to find one. Glad to see someone finally wrote one.

Alacritty?

Oh nice, thanks! This wasn’t humor, I really was looking for a modern performant terminal written in Rust. I wasn’t aware of Alacritty, I’ll definitely check it out :)

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

#113

Post by jstimpfle »

goldenkey wrote: post #111
jstimpfle wrote: post #107

Earlier quoted context omitted.

Let's say 512 glyphs should be a pretty conservative upper bound for normal usage. Just pulling this number out of thin air, but I assume it's reasonable. normal glyphs should be about 100-400 pixels (20x20), for 8-bit grayscale that means 2MB of texture cache should be plenty for normal use. Multiply by 3 if you want to support subpixel rendered glyphs, that still leaves us with a very comfortable upper bound of 6MB…

> 512 glyphs You're forgetting about colored glyphs. Although a fragment shader should be able to deal with that, shouldn't it?

One typical approach is that glyphs are rastered (e.g. by Freetype) as 8-bit grayvalues. Basically Alpha channel if you will. You can add RGB color channels from there and blit RGBA with Alpha blending enabled. Not sure if there are finer points to consider here, it's what I've always done and it works for me.

Perhaps less used, and becoming less and less relevant as higher DPI screens are becoming common: With subpixel-rasterized glyphs, you get RGB channel output from the font rasterizer instead of the Alpha channel. These are properly balanced values that are arranged to appear as "white" pixels to most viewers - the idea is that this increases the perceived horizontal resolution by a factor of up to 3. Not sure how to add color to these, maybe just multiplying each component with the respective component of a text color RGB value would work.

In any case, if you have a 4K screen full of flickering glyphs that need to be of varying colors and backgrounds, that might indeed indicate a GPU approach. On the other hand, nobody is getting value of flickering glyphs, so CPU rasterization with some rate limiting would be just as good in these situations, practically speaking.

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

#114

Post by CyberRabbi »

geokon wrote: post #39
CyberRabbi wrote: post #10

Earlier quoted context omitted.

Well since GPU acceleration minimizes latency (because of zero-copy, all character textures are resident in video memory), that is a boon to perceived responsiveness. IMO that is the single most important feature in a terminal, next to correctness. It’s like typing on an old serial terminal.

Latency and throughput benchmarks don't confirm this. Eshell has one of the best latencies (that's why it feels so responsive compared to VS Code) but low throughput Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. GPU term…

> And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated.

No textures need to be updated. The texture stays in VRAM across each frame, just need to change which texture the character cell points to. That is zero-copy.

If you were to do this with a software rendered terminal, at minimum the software would tell the windowing system which region of the window changed and then copy that region to VRAM. That’s only if the window system supports region updates, if not you’d need to copy the entire window to VRAM each frame. Much slower than just twiddling a pointer to a texture.

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

#115

Post by Emigre_ »

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?

I agree… I’m using Kitty and am very satisfied with it. I haven’t tried this one yet, though.

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

#117

Post by floatboth »

vidarh wrote: post #100
floatboth wrote: post #93

Earlier quoted context omitted.

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.

Data rates for display have increased very much too. Don't underestimate the, uhh, "how rectangles work" factor – doubling the resolution means doubling both width and height, so quadrupling the pixel count.

80s computers also used lots of special hardware for graphics output, they didn't software render everything ;)

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

#118

Post by jasonjayr »

conaclos wrote: post #85
jasonjayr wrote: post #48

Earlier quoted context omitted.

I actually went alacratty => wezterm => kitty. I tried and liked wezterm for a while after alacratty, but after some version, it did something that caused all heavy GPU-using programs(like firefox) to slow down severely, or seize up or something , on multiple computers, after running for more than 24-48 hrs. I had been using the default config, except for my preferred font (the VGA font from https://int10h.org/oldsch…

I'm currently using termite. However Termite is no longe rmaintened. I plan to switch to alacratty or kitty. I'm wondering: Why did you choose kitty / wezterm over alacratty?

I started my journey with urxvt, and was seeking better rendering. Alacratty+tmux (with urxvt keybindings) was working well, and I learned to deal with the "auto resize" when moving windows between screens with different DPIs. I tried wezterm from a thread here, and the emoji rendering (a feature I've never relied on before, but nice to have) was better than on alacritty, and stuck with it. Learned to work with it's tabs + extra features, and stuck around for a bit. Liked that I could run the same terminal on Linux + Windows.

I liked wezterm, and it's flexibility, but like I mentioned that GPU bug was killer. I'd have love to help diagnose it, but I'm not sure where to begin. Kitty did most of what wezterm did, and I just stuck with it since. The timestamp on my kitty.conf is 2021-09-11, so it looks like that was the last time I had to tweak it after starting to use it, and I'm happy thus far.

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

#119

Post by geokon »

CyberRabbi wrote: post #114
geokon wrote: post #39

Earlier quoted context omitted.

Latency and throughput benchmarks don't confirm this. Eshell has one of the best latencies (that's why it feels so responsive compared to VS Code) but low throughput Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. GPU term…

> And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. No textures need to be updated. The texture stays in VRAM across each frame, just need to change which texture the character cell points to. That is zero-copy. If you were to do this with a software rendered terminal, at minimum the software would tell the windowing system which region of the wind…

Show me the numbers..

https://danluu.com/term-latency/

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

#120

Post by vidarh »

floatboth wrote: post #117
vidarh wrote: post #100

Earlier quoted context omitted.

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.

Data rates for display have increased very much too. Don't underestimate the, uhh, "how rectangles work" factor – doubling the resolution means doubling both width and height, so quadrupling the pixel count. 80s computers also used lots of special hardware for graphics output, they didn't software render everything ;)

Yes, but as I said the increase in data rates has not been anywhere near as fast as the increase in CPU speed, even with the unusal example you gave.

As for special hardware for graphics output, that's not really true. Some, sure. My Amiga had a basic blitter. But all that allowed for that helped a terminal was scrolling at a few times higher speed than the CPU - it was limited by the memory bus speed. That was revolutionary at the time. Most other 80's hardware had much less, except for having character modes, but I was specifically talking about ones using bitmap screens like the Amiga for example.

But a blitter does not help you with the worst case scenario of filling the terminal with text from scratch as the setup cost is typically higher than the cost of having the CPU render individual characters (it certainly was on the Amiga - the blitter helped when moving larger chunks of data, but not for character sized areas).

I have written terminals for 1980s hardware and for modern hardware. I know where the bottlenecks are and there is no issue whatsoever keeping up with the graphical display. When a terminal is slow it's a design issue.

Post reply on HN