4 ms·
These days it's easier to write hardware accelerated terminals than CPU bound ones simple because of the system libraries available for drawing to a blank canva
by hnlmorg 1y ago
These days it's easier to write hardware accelerated terminals than CPU bound ones simple because of the system libraries available for drawing to a blank canvas. That is, unless you're using a web wrapper (eg Electron), but then you'd bet Electron is using GPU acceleration under-the-hood too.
I say this as someone who's written my own terminal emulator too. SDL was a natural choice, not because of GPU acceleration, but because it gave me the APIs I needed for rendering a terminal.
The other ironic thing about all these terminal emulators that advertise themselves as being "GPU accelerated" is that text rendering cannot be GPU accelerated. Or at least the only way I know of to render text to the GPU is to first render it using the CPU, then push that bitmap to the GPU memory. This leads to developers having to create a "font atlas", which is basically a bitmap with all your characters already cached in GPU memory. And thus you either need to cache the entirety of Unicode, including alternative glyphs due to variation selections, different font characteristics (bold, italic, etc), and even different font colours (if you want nice anti-aliased fonts ;) ). Which means you then need to software render a bunch of stuff on demand anyway, because otherwise you're basically caching every imaginable character and combination on start up.
So yeah, I don't think "GPU accelerated" is the same flex it used it be.
- landl0rd 1y agoText rendering can be GPU accelerated if you're cracked enough: https://sluglibrary.com/ https://sluglibrary.com/
- Gormo 1y agoIt's kind of funny, because hardware text modes essentially are GPU-accelerated text rendering -- storing the character set in hardware and offloading the output rendering from the CPU is one of the oldest and most fundamental use cases for dedicated video hardware.