[jstimpfle]

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.

[mgaffney]

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

[einpoklum]

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.

[jstimpfle]

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.

[camgunz]

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