4 ms·

Serious question: why does a terminal editor need GPU acceleration? It's usually showing 80x25 of text, yeah? I guess text can get scrolling quickly sometimes o

Serious question: why does a terminal editor need GPU acceleration? It's usually showing 80x25 of text, yeah? I guess text can get scrolling quickly sometimes or it needs maybe... 1,000,000 lines of lookback

s9w 4y ago
[dead]
yjftsjthsd-h 4y ago
> It's usually showing 80x25 of text, yeah? That would be pretty small in modern times. Certainly some people are working with terminals that size, often then spilling out into multiple terminals side by side on the screen, but modern resolutions are good enough to support a lot more text per terminal than that. As a single data point, my half-screen terminal right now is 140x75.
- SauciestGNU 4y ago
  Another data point, I keep a 1920x1200 monitor in portrait mode and have kitty fullscreen on that monitor. My workflow is [emacs, browser] + kitty, I keep emacs and my browsers fullscreen on another monitor.
linsomniac 4y ago
A couple of points: - WezTerm has windows/tabs/panes in it, and one use case would be ~10 panes on a 4K display in various columns/rows. - Within those you might have applications that themselves have columns/rows of panes, like vim. - Why not use the GPU to draw the graphics so you can offload the CPU? When there's a lot of text to go through (something scrolling stdout hard, jumping through a big file), the extra performance can be nice.
NikkiA 4y ago
Why do you think pixels constituting text are any different to pixels constituting images? A terminal editor needs GPU acceleration for the same reasons any other displayed item needs GPU acceleration.
dmytrish 4y ago
Text rendering is a quite CPU-intensive thing to do nowadays. It can burn your CPU with unnecessary work to move bitmaps around, while the GPU, which is specifically created and tuned for this kind of tasks, stays idle. This is basic mechanical sympathy.
- Narishma 4y ago
  Text rendering in a terminal emulator is not a CPU-intensive thing.
vidarh 4y ago
It doesn't. At least not explicit (e.g. using the render extension with X11 might well end up using a GPU behind the scenes, but no need to write GPU-specific code; a fast terminal requires pretty much too primitives: an ability to copy a rectangle, and an ability to draw a list of textures, if you need to deal with the GPU it's a failure of abstraction). Fast enough bitmap terminals have existed since the 1980's, and it takes really naive rendering for the rendering to be a bottleneck ever since then. Resolutions have increased, sure, but overall the increase in resolution and colour depth has been slower than the increase in CPU speed. If you test various terminals, you'll find the difference in throughput is massive and the most popular ones are not necessarily the highest throughput ones, because people rarely run into the use cases where it makes a difference. (the one step up from naive rendering that makes the most difference: the renderer should run in a separate thread, at most once per frame, and scroll the required number of lines with a single copy - that copy might well be optimised to a blit using the GPU by the X server or whatever, but that's besides the point; do just that and output does not bottleneck on the rendering as long as the renderer can render individual frames fast enough)
fulafel 4y ago
GPUs are tricky to program so it's a nice sized programming puzzle. In general if GPU style processors had better dev experience, less fragmentation and other chilling effects, we might be running a lot of our software on them for general efficiency.

s9w 4y ago

[dead]

yjftsjthsd-h 4y ago

> It's usually showing 80x25 of text, yeah? That would be pretty small in modern times. Certainly some people are working with terminals that size, often then spilling out into multiple terminals side by side on the screen, but modern resolutions are good enough to support a lot more text per terminal than that. As a single data point, my half-screen terminal right now is 140x75.

SauciestGNU 4y ago
Another data point, I keep a 1920x1200 monitor in portrait mode and have kitty fullscreen on that monitor. My workflow is [emacs, browser] + kitty, I keep emacs and my browsers fullscreen on another monitor.

linsomniac 4y ago

A couple of points: - WezTerm has windows/tabs/panes in it, and one use case would be ~10 panes on a 4K display in various columns/rows. - Within those you might have applications that themselves have columns/rows of panes, like vim. - Why not use the GPU to draw the graphics so you can offload the CPU? When there's a lot of text to go through (something scrolling stdout hard, jumping through a big file), the extra performance can be nice.

NikkiA 4y ago

Why do you think pixels constituting text are any different to pixels constituting images? A terminal editor needs GPU acceleration for the same reasons any other displayed item needs GPU acceleration.

dmytrish 4y ago

Text rendering is a quite CPU-intensive thing to do nowadays. It can burn your CPU with unnecessary work to move bitmaps around, while the GPU, which is specifically created and tuned for this kind of tasks, stays idle. This is basic mechanical sympathy.

Narishma 4y ago
Text rendering in a terminal emulator is not a CPU-intensive thing.

vidarh 4y ago

It doesn't. At least not explicit (e.g. using the render extension with X11 might well end up using a GPU behind the scenes, but no need to write GPU-specific code; a fast terminal requires pretty much too primitives: an ability to copy a rectangle, and an ability to draw a list of textures, if you need to deal with the GPU it's a failure of abstraction). Fast enough bitmap terminals have existed since the 1980's, and it takes really naive rendering for the rendering to be a bottleneck ever since then. Resolutions have increased, sure, but overall the increase in resolution and colour depth has been slower than the increase in CPU speed. If you test various terminals, you'll find the difference in throughput is massive and the most popular ones are not necessarily the highest throughput ones, because people rarely run into the use cases where it makes a difference. (the one step up from naive rendering that makes the most difference: the renderer should run in a separate thread, at most once per frame, and scroll the required number of lines with a single copy - that copy might well be optimised to a blit using the GPU by the X server or whatever, but that's besides the point; do just that and output does not bottleneck on the rendering as long as the renderer can render individual frames fast enough)

fulafel 4y ago

GPUs are tricky to program so it's a nice sized programming puzzle. In general if GPU style processors had better dev experience, less fragmentation and other chilling effects, we might be running a lot of our software on them for general efficiency.