4 ms·

Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice

Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my computer, more confident to try things out if I can see my typing updating instantly than 10s or 100s of milliseconds later.

samwillis 5y ago
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.
- 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.
jcelerier 5y ago
Lower CPU usage but higher GPU usage. On my laptop I get muuuch more battery out of it (going from 6 hours to ~2 hours) if I disable everything that may wake up the GPU and force software rendering everywhere (since, unlike GPUs, it's much more often able to rerender only the parts of the screen which changed)
- unbanned 5y ago
  Wall socket
- heftig 5y ago
  That isn't an inherent limitation of GPUs, though. More likely just a missing feature in whatever GPU rendering path.
- floatboth 5y ago
  > rerender only the parts of the screen which changed e.g. Firefox is already good at doing that on the GPU. WezTerm isn't yet, but We're Working On It™ (i.e. someday it will be done), follow https://github.com/wez/wezterm/issues/1134 https://github.com/wez/wezterm/issues/1134
usrbinbash 5y ago
> until you accidentally unleash a lot of output at once The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`. If that happens, I usually terminate the process anyway.
- nyadesu 5y ago
  This is also pretty common when running test runners a lot
  - usrbinbash 5y ago
    So I pipe their output into a file, or into a logger engine. Problem solved.
- cyberge99 5y ago
  You can also run ‘reset’ which will clear escape codes and reset your session.

samwillis 5y ago

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

jcelerier 5y ago

Lower CPU usage but higher GPU usage. On my laptop I get muuuch more battery out of it (going from 6 hours to ~2 hours) if I disable everything that may wake up the GPU and force software rendering everywhere (since, unlike GPUs, it's much more often able to rerender only the parts of the screen which changed)

unbanned 5y ago
Wall socket
heftig 5y ago
That isn't an inherent limitation of GPUs, though. More likely just a missing feature in whatever GPU rendering path.
floatboth 5y ago
> rerender only the parts of the screen which changed e.g. Firefox is already good at doing that on the GPU. WezTerm isn't yet, but We're Working On It™ (i.e. someday it will be done), follow https://github.com/wez/wezterm/issues/1134 https://github.com/wez/wezterm/issues/1134

usrbinbash 5y ago

> until you accidentally unleash a lot of output at once The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`. If that happens, I usually terminate the process anyway.

nyadesu 5y ago
This is also pretty common when running test runners a lot
- usrbinbash 5y ago
  So I pipe their output into a file, or into a logger engine. Problem solved.
cyberge99 5y ago
You can also run ‘reset’ which will clear escape codes and reset your session.