Hacker News Reader

Comment by yason | Hacker News Reader

Why render with the GPU? I don't think I've seen a visually slow terminal emulator since 2000 and barely even in the 1990's.

Text rendering is basically just blitting cached glyph bitmaps into a buffer, and CPUs have been more than overly fast doing that for eons. And CPU rendering has none of the compatibility problems/quirks that GPUs have. I can fire up a Gnome Terminal onto an unaccelerated Vesa X11 display if my graphics card doesn't work or I haven't configured it yet.

For better responsivity I suppose a terminal that behaves like mosh would be a good approach. It would maintain the tty state in memory and only render the latest view, dropping the rendering of any intermediate diffs in the buffer. I would guess most terminal emulators do work like that these days but I haven't checked.

View on HN

Input latency makes for a bad user experience. People just usually don't notice it when typing as it's so common. See https://danluu.com/term-latency/ for measurements of some terminal software and discussion of why latency is bad.

I'm not sure if Kitty is using GPU specifically to minimize latency, but it would be a good reason.

I work in video and as a consequence I tend to be very sensitive to latency (I've spent more hours than I can count trying to figure out subtle synchronization issues) yet I've just spent one minute trying to detect input latency on my st terminal (which fares pretty badly in the benchmark you linked) without success. And that's running inside tmux on top of that.

That being said I think it is valuable to have a reasonably fast terminal because it's not uncommon to have applications slow down dramatically if they output a lot of information on stdout/stderr while the terminal struggles to render everything.

I would have said the same, until I recently had to boot into an UEFI shell.

Input was just so .... immediate? It’s really hard to describe, but it was surprisingly obviou.

Yeah, the feeling is pretty much "the letter appears while I'm pushing the key down" vs. "the letter appears when the key returns to the top position". Both feel immediate in their own way.

I don't know. Try using a simple, $2 (physical) calculator against the screen of your computer.

I can definitely tell you that while I can't see the actual letter appearing on the screen - the letter on the calculator would feel as if it appeared right at the bottom position of the button, while on my PC the key would have travelled some distance off the ground before I see the letter.

It's not uncomfortable, but I could easily tell the two apart in a blind test would something like that come up.

From what I can gather from the results, st is among the faster ones when tested on linux.

I would have thought using a GPU would make latency worse. GPUs are really good at throughput, not latency.

Usually, offloading to the GPU will get you higher throughout but also higher latency. Although of course this assumes a sane software renderer, X11 API calls will take forever.

Really? It's counterintuitive considering the GPU draws the screen anyway. Is it because the shader pipeline has some inherent latency that a software renderer doesn't?

>There are no benchmarks in which I've found Alacritty to be slower.

It's depressing that he's only ever tried for throughput, when that's irrelevant next to latency. And it does have abysmal latency as per your link.

Because on moder hdpi screens, text rendering involves pushing around a lot of pixels. Especially if you do stuff like having translucent windows, aliasing, complex font rendering, smooth scrolling, etc. So, it kind of makes sense to use the GPU for this. Of course on OSX, much of the desktop is already hardware accelerated so it is easy to overstate the impact here. Apple fixed this when they launched OSX in 2000 or so.

I've been using iterm for years; when they introduced their metal rendering backend the impact was very subtle but noticable. Anyway, given the amount of time I spend using cli stuff, it kind of matters.

Text rendering is very complex. GPU text rendering is however unlikely to be faster then "native" text rendering. But it could likely make scrolling more smooth.

Rendering the vector fonts into cached bitmaps is complex. Rendering the final buffer by blitting those bitmaps isn't very.

Smooth scrolling is inherently bounded by the vsync rate of the display. As long as you can render the terminal's pixel buffer with new characters and send it to front for the next flip, all within some portion of the time you have between frames, it's as smooth as it can get. Missing a frame will cause stutter, and make it non-smooth. Given the fact that terminal doesn't necessarily need to render if there are no changes, using GPU seems like an overkill for regular use.

You could use it to watch youtube in ascii mode if that somehow tickles your fancy

Nearly all text rendering libraries I've checked uses the GPU.

freetype definitely doesn't use the GPU and it's the most used font rendering library on Linux. What libraries did you check?

Reply on news.ycombinator.com