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

Yeah, it's not a rendering issue, it's an architectural issue. It's people writing terminals imperatively: Text comes in from the app, and they trigger a set of updates to state ending in rendering the text straight to screen.

The first fix is that if you want a maximally responsive terminal you'll want to decouple input process, output processing and rendering into separate threads - this was established already in the 1980's with the Amiga console handling. E.g. any modern terminal that struggles with handles Ctrl+C is an example of why you want this.

The second fix is to "render" into a text buffer and have the renderer look at how many lines it has to scroll and rerender each time it starts a rendering pass, blit whatever is still intact, and then render what is left, rather than process character by character. When the producer overwhelms the terminal in that scenario you end up scrolling multiple lines at once. This will be jerky if the rendering is very slow but it'd need to be very slow for it to be noticeable, and even then it's generally much preferable to the terminal lagging behind.

And when you then have a process barfing gigabytes of data to the terminal, most text will not be visible more than a frame on a terminal that insists on showing it all, and won't be visible at all on one that updates faster than the frame rate anyway, and the fix above will simply entirely skip rendering most of the text. As long as your terminal can render a page full of text at a high enough frame rate it will be seamless.

With respect to the actual rendering, glyph size tends to be small enough that there's not that much to be gained in terms of acceleration other than a rectangular copy to accelerate scrolling, which is mostly relevant when the terminal doesn't handle huge chunks of data being barfed. The main exception being if you use shaders. E.g. on my personal copy of kitty I experimented with a shader to add a "glow" to characters to make it more legible on semi-transparent windows. But I've applied similar hacks to purely CPU-rendered terminals (created "poor mans outlines" by simply rendering the text multiple times at slight offsets with different colours) and good CPU-rendered terminals can do even that more than fast enough.

I tested kitty (GPU accelerated) and rxvt on my laptop, and rxvt beat kitty on throughput. Now, kitty looks much nicer, and I prefer it over rxvt any day. My local copy applies a shader to add a subtle glow so the transparent background doesn't make the text unreadable, for example. That is where GPU rendered terminal shines - not speed. High terminal throughput you get from good architecture (do decouple IO and rendering in separate threads; don't trigger your rendering pipeline for every character output if the buffer is growing; very few terminals bother to do this because a more naive approach is generally fast enough on modern hardware), and even a brutally naive CPU rendered terminal can render fast enough if your architecture is decent.

Do you have any examples of command line apps that actually uses the double-wide/double-height characters? I'm aware of them, but I don't think I've ever seen it used. I'm always curious to see good uses of terminal capabilities that are under-used.

Smooth-scrolling I think is generally ignored because as you can see from this thread people are obsessed with throughput over all else, and assumes the raw rendering is the bottleneck, but in my experience with terminals it rarely is - few terminals are in any way optimised for speed.

Elsewhere in this thread I've advocated for a pretty old-school solution to the throughput and responsiveness issue: Decouple IO and rendering into separate threads. The Amiga did that in 1985, and I have no reason to think it was a particular revelation back then - just necessary to produce something that'd become unresponsive too easily. That split then makes it easy to have the renderer batch updates when there is much waiting. E.g. if so much text comes that it'd scroll two lines in a frame there's no reason to scroll one line twice.

If more terminals first did that, then the converse of doing what you propose with defaulting to smooth scrolling when there is little in the buffer, and falling back on faster scrolling would also be "trivial": Just peek at the buffer of how many lines of output are waiting, and adjust scroll speed accordingly. The only difficulty, I suspect, would be to find the optimal rate of change to prevent it from looking jerky.

Fair enough, that's good to know.