"fast"? What, terminal emulation is slow now? Needs hardware acceleration? Be serious.
A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.
"fast"? What, terminal emulation is slow now? Needs hardware acceleration? Be serious.
A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.
https://danluu.com/term-latency/
> A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.
I've mostly done OpenGL recently, and I think xterm (which is fast) is an exception in that it uses just X11 primitives, but I also know that some font frawing APIs are very slow. GDI is what I have in mind mostly. So using Hardware more directly (i.e. OpenGL) might be not the worst idea.
But it sounds like what should really be written is a fast, hardware-backed, low-latency but limited-feature graphics library.
Then have your terminal use that. I still say that direct awareness of the hardware is _way_ too much coupling.
I've also heard about performance issues with high res, large terminals. It's a lot of pixels to throw at the screen and I'm sure most terminal emulators were written with much smaller screens in mind.