3 ms·

I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement

I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?

mattbee 5y ago
A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)
- mattbee 5y ago
  e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
  - dogma1138 5y ago
    The new terminal in windows 11 has GPU acceleration. Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.
- usrbinbash 5y ago
  But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
  - nix23 5y ago
    > But what's the use case for this? telnet towel.blinkenlights.nl
  - joseluis 5y ago
    well... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
    - usrbinbash 5y ago
      And what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
      - filmor 5y ago
        Please be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
        usrbinbash 5y ago
        > In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
      - southerntofu 5y ago
        > And what exactly is the use case for this? Terminal User Interfaces. There's technically no reason i can't check out an image in a folder when i'm browsing on an SSH session (yes i know i can rsync/scp && xdg-open but it's not exactly as fast to type as viu [0]. > powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side If you have tested and reliable desktop environments to recommend, i'm all ears. All the ones i've tried over the years have their own quirks and memory leaks (yes, that includes GNOME and KDE). But as you said, both approaches are complementary. I'm glad notcurses exists and works via graceful degradation, so people with a modern terminal can get the best while others can still get a featureful ncurses-like experience. [0] https://github.com/atanunq/viu https://github.com/atanunq/viu
vidarh 5y ago
I tested kitty (GPU accelerated) and rxvt on my laptop, and rxvt beat kitty on throughput. Now, kitty looks much nicer, and I prefer it over rxvt any day. My local copy applies a shader to add a subtle glow so the transparent background doesn't make the text unreadable, for example. That is where GPU rendered terminal shines - not speed. High terminal throughput you get from good architecture (do decouple IO and rendering in separate threads; don't trigger your rendering pipeline for every character output if the buffer is growing; very few terminals bother to do this because a more naive approach is generally fast enough on modern hardware), and even a brutally naive CPU rendered terminal can render fast enough if your architecture is decent.
ohgodplsno 5y ago
For a basic example of why you would want GPU acceleration, have a look at refterm: https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm Even processes that you wouldn't think would be impacted by a terminal can be hurt relaly bad by your terminal's performance: your compiler's logs, etc. The GPU rendering part merely guarantees that your terminal sticks at 60FPS (or, whatever your refresh rate is) if the processing behind is efficient.
- vidarh 5y ago
  This was a solved problem in the 1980's with Amiga consoles separating input processing, high level terminal handling and rendering into separate threads.

mattbee 5y ago

A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)

mattbee 5y ago
e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
- dogma1138 5y ago
  The new terminal in windows 11 has GPU acceleration. Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.
usrbinbash 5y ago
But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
- nix23 5y ago
  > But what's the use case for this? telnet towel.blinkenlights.nl
- joseluis 5y ago
  well... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
  - usrbinbash 5y ago
    And what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
    - filmor 5y ago
      Please be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
      - usrbinbash 5y ago
        > In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
    - southerntofu 5y ago
      > And what exactly is the use case for this? Terminal User Interfaces. There's technically no reason i can't check out an image in a folder when i'm browsing on an SSH session (yes i know i can rsync/scp && xdg-open but it's not exactly as fast to type as viu [0]. > powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side If you have tested and reliable desktop environments to recommend, i'm all ears. All the ones i've tried over the years have their own quirks and memory leaks (yes, that includes GNOME and KDE). But as you said, both approaches are complementary. I'm glad notcurses exists and works via graceful degradation, so people with a modern terminal can get the best while others can still get a featureful ncurses-like experience. [0] https://github.com/atanunq/viu https://github.com/atanunq/viu

vidarh 5y ago

I tested kitty (GPU accelerated) and rxvt on my laptop, and rxvt beat kitty on throughput. Now, kitty looks much nicer, and I prefer it over rxvt any day. My local copy applies a shader to add a subtle glow so the transparent background doesn't make the text unreadable, for example. That is where GPU rendered terminal shines - not speed. High terminal throughput you get from good architecture (do decouple IO and rendering in separate threads; don't trigger your rendering pipeline for every character output if the buffer is growing; very few terminals bother to do this because a more naive approach is generally fast enough on modern hardware), and even a brutally naive CPU rendered terminal can render fast enough if your architecture is decent.

ohgodplsno 5y ago

For a basic example of why you would want GPU acceleration, have a look at refterm: https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm Even processes that you wouldn't think would be impacted by a terminal can be hurt relaly bad by your terminal's performance: your compiler's logs, etc. The GPU rendering part merely guarantees that your terminal sticks at 60FPS (or, whatever your refresh rate is) if the processing behind is efficient.

vidarh 5y ago
This was a solved problem in the 1980's with Amiga consoles separating input processing, high level terminal handling and rendering into separate threads.