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.
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
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.
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
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
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.
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.