3 ms·

> If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt. This doesn't sound like a rendering issue

> If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt. This doesn't sound like a rendering issue, though. Many text editors can't cope with extremely long lines either, terminal-based or not. That happens when they store lines as flat buffers without any algorithmic optimization. GPU has the potential to speed up terminal rendering a little bit, but in the absence of antialiasing (cache glyphs with the right background color) you can probably achieve 60fps on a 4K screen full of glyphs. It's just memcpy(), a 4K screen is about 32MB of data. 32MB * 60 = 1.8GB, today's memory is much faster.

vidarh 5y ago
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.

vidarh 5y ago

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.