5 ms·

With due respect - this sounds like the terminal emulator equivalent of a ricer car: https://en.wikipedia.org/wiki/Rice_burner https://en.wikipedia.org/wiki/Ric

With due respect - this sounds like the terminal emulator equivalent of a ricer car: https://en.wikipedia.org/wiki/Rice_burner https://en.wikipedia.org/wiki/Rice_burner "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.

jstimpfle 7y ago
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/ 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.
- einpoklum 7y ago
  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 7y ago
    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 7y ago
      Yeah, plus hardware accelerated font rendering isn't trivial.
- mgaffney 7y ago
  > https://danluu.com/term-latency/ 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.
pfranz 7y ago
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.

jstimpfle 7y ago

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

einpoklum 7y ago
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 7y ago
  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 7y ago
    Yeah, plus hardware accelerated font rendering isn't trivial.
mgaffney 7y ago
> https://danluu.com/term-latency/ 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.

pfranz 7y ago

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.