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