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.
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.
Scrolling through a large text with colours and higher unicode characters (tailing a log with colour coding, for instance) can be a bit slow with Gnome’s terminal in my experience. In Alacritty (and on a machine with a GPU) it’s not.
It’s not just about speed, but also (battery) efficiency.
Even if you don’t notice the speed, if you are working on anything but a modern expensive laptop, you will notice the difference in battery draw between:
VS Code > NeoVim in traditional terminal > Neovim in Alacritty or Ghostty
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.
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.
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.
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.
ok but such a sensational announcement like this suggests that before (and without) gpu acceleration the program was noticeably slow for some reason
Scrolling through a large text with colours and higher unicode characters (tailing a log with colour coding, for instance) can be a bit slow with Gnome’s terminal in my experience. In Alacritty (and on a machine with a GPU) it’s not.
Have you ever been in a terminal, or VSCode, and started tailing a super-fast log, and control-C takes forever to stop it while a CPU core goes crazy?
Text rendering isn’t efficient, and GPUs help.
It’s not just about speed, but also (battery) efficiency.
Even if you don’t notice the speed, if you are working on anything but a modern expensive laptop, you will notice the difference in battery draw between:
VS Code > NeoVim in traditional terminal > Neovim in Alacritty or Ghostty
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.
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.
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.