Not just terminals. So much software is unbearably slow today. Definitely terminals. The only terminal I can really stand is xterm with bitmap fonts.

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.

> https://danluu.com/term-latency/ This was written in 2017. It's got great information but I'm guessing most, if not all, of the terminals tested have newer versions. Just think of what 3 years of feature bloat could have done to their performance.

Wow, those graphs are mind-blowing!

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.

OpenGL is actually pretty high-level. I don't know how much detail of the hardware it lets you get - probably mostly through hardware-specific extensions. The most basic usage is really hardware oblivious. There are many even more high-level toolkits on top of that, such as Qt. But if you need some flexibility and performance, using OpenGL is probably your best bet.

Yeah, plus hardware accelerated font rendering isn't trivial.

I've noticed terminal rendering performance issues when dumping a lot of text. If that's part of your job, it's important to you. For me it seems to come up once every few years and I've poked around at alternatives.

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.