What is the deal with getting gpu acceleration into a terminal emulator of all things? Of all the innovations that we could use, faster drawing of text doesn’t feel like it should be a priority.
My experience might be a bit outdated, but I remember finding the default Mac OS X Terminal extremely slow. A few years back I ran an output-heavy command, and the speed difference between displaying the output in terminal vs outputting it to a file was orders of magnitude. The same thing on my Linux system was much, much faster. I’m not sure how much of that was due specifically to rendering, vs memory management or something else, though.
I might see if I can still reproduce this in Sequoia and if Ghostty is faster on Mac.
GPU rendered text interfaces are pretty ubiquitous already. You can find that in IDEs, browsers, apps and GUIs of OSs. Drawing pixels is still a job the GPU excels at. No matter whether it’s just text. So I don’t see a point why we shouldn’t apply that to terminal emulators as well.
But thats different, the issue there isn’t the text drawing, its that it isn’t meaningfully asynchronous and console drawing is typically blocking (at least on windows)
that’s true, but the impact would still be lessened by faster rendering. and as someone who spends all day in the terminal anyway, i do see the benefits often.
That’s what I would have said till I tried using a TUI epub reader. The jankiness of line-level scrolling (rather than pixel-level like in a GUI app) is all but a deal breaker.
I was then most surprised to discover that terminal emulators with this amazing cutting-edge technology (smooth scrolling) do not even exist.
What is the deal with getting gpu acceleration into a terminal emulator of all things? Of all the innovations that we could use, faster drawing of text doesn’t feel like it should be a priority.
My experience might be a bit outdated, but I remember finding the default Mac OS X Terminal extremely slow. A few years back I ran an output-heavy command, and the speed difference between displaying the output in terminal vs outputting it to a file was orders of magnitude. The same thing on my Linux system was much, much faster. I’m not sure how much of that was due specifically to rendering, vs memory management or something else, though.
I might see if I can still reproduce this in Sequoia and if Ghostty is faster on Mac.
GPU rendered text interfaces are pretty ubiquitous already. You can find that in IDEs, browsers, apps and GUIs of OSs. Drawing pixels is still a job the GPU excels at. No matter whether it’s just text. So I don’t see a point why we shouldn’t apply that to terminal emulators as well.
text is like the slowest thing to draw :P when debugging games, a running log can make the 3D rendering stutter significantly.
See the minecraft f3 menu for a notorious example
no, that’s just minecraft being badly made. I’m talking logs running in a separate window.
But thats different, the issue there isn’t the text drawing, its that it isn’t meaningfully asynchronous and console drawing is typically blocking (at least on windows)
that’s true, but the impact would still be lessened by faster rendering. and as someone who spends all day in the terminal anyway, i do see the benefits often.
That’s what I would have said till I tried using a TUI epub reader. The jankiness of line-level scrolling (rather than pixel-level like in a GUI app) is all but a deal breaker.
I was then most surprised to discover that terminal emulators with this amazing cutting-edge technology (smooth scrolling) do not even exist.