8 ms·

Whenever I have to do something in a TTY I kinda wish my normal terminal experience was that crisp and snappy.

by zadler 3y ago

quesera 3y ago
It should be, unless you're running too much bash/zsh plugin stuff.
- petepete 3y ago
  And a terminal emulator with low latency definitely helps.
  - arcanemachiner 3y ago
    I can only hope you're referring to network latency...
    - Rufbdbskrufb473 3y ago
      Probably not. There are terminals with surprisingly high latency, even on modern hardware. See here for examples of ~100 ms of local latency: https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/
    - codetrotter 3y ago
      I remember that urxvt used to be much more comfortable to use than some other terminal emulators whenever a process was spewing out thousands and thousands of lines of text. Some other terminal emulators at the time were very slow because they printed each and every line. urxvt on the other hand would skip printing lines to keep up. This was much preferable. If I intended to look at thousands of lines of text I would do so through a pager. So printing out thousands of lines of text directly into the terminal was almost always by accident. I have since gotten better at not accidentally printing a bunch to my terminal, so I am no longer using urxvt these days. But for a period of time urxvt was my preferred terminal emulator for that reason.
      - petepete 3y ago
        I had this discussion with someone on here the other day who flat out believed I'd invented the problem. Kitty is so fast compared to anything else I've tried.
      - quesera 3y ago
        > urxvt on the other hand would skip printing lines to keep up Really? That's a fatal flaw. Skipping lines is never ever OK for a terminal emulator. Not keeping up can also be a fatal flaw of course!
        codetrotter 3y ago
        It’s not a flaw, it’s by design. https://man.archlinux.org/man/urxvt.1 https://man.archlinux.org/man/urxvt.1 > -ss|+ss > Turn on/off skip scrolling (allow multiple screens per refresh); resource skipScroll. > […] > skipScroll: boolean > True: (the default) specify that skip scrolling should be used. When receiving lots of lines, urxvt will only scroll once in a while (around 60 times per second), resulting in far fewer updates. This can result in urxvt not ever displaying some of the lines it receives; option -ss. > False: specify that everything is to be displayed, even if the refresh is too fast for the human eye to read anything (or the monitor to display anything); option +ss.
        quesera 3y ago
        Flawed design is still a flaw. I'll accept that it is a design feature to get around another failure mode, and that it might even be preferable sometimes. But it's a serious flaw. Terminal emulators should never drop output, that's what control flow signaling is for!
        codetrotter 3y ago
        It’s not a flaw. It’s a different kind of use-case than you have in mind. It’s fine. No one is telling you to use urxvt. You can continue to use whatever terminal emulator you prefer. That’s the power of choice we have. Different programs that do the same kind of things but in different ways. So there is no reason to insist that urxvt is flawed.
    - zamnos 3y ago
      Nope. Alacrity is probably the terminal emulator that revealed this, but terminal emulation itself is sometimes there bottleneck and GPU acceleration is required to get around the problem.
    - deleted 3y ago
      [deleted]
- zadler 3y ago
  Nah it’s probably gnome terminal and the rest of the UI stack, schedulers etc. See eg https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/
  - quesera 3y ago
    Yes that's important too, but the magnitude of difference is relevant. A local shell with a non-pathological shell config and a reasonable terminal emulator is snappy-ish. Most sluggishness can be fixed in shell config. If that isn't working, some terminal emulators are definitely faster than others, especially on Linux with its wide variety of modern and historical choices! And of course tty will always be faster still, but far less convenient. When all is said and done and properly optimized, it's all probably still slower than the ProDOS prompt on an Apple //e (1MHz 6502 CPU), which can't help but make you wonder what we've all been doing for the last 40 years!
    - 656565656565 3y ago
      What we’ve been doing for the last 40 years is producing layers of abstraction for developers to play with
- miniupuchaty 3y ago
  I have all the same config in TTY as in emulated terminal and emulated is nowhere near as snappy and smooth as TTY. Even with GPU accelerated terminals like alacritty, it's a lot better, but still far. If I wasn't working mostly on graphical applications I would just work from TTY.
AlecSchueler 3y ago
Try different terminals. rxvt is way faster than xterm for example.
- loeg 3y ago
  Enlightenment's terminology is pretty snappy if you don't want to give up too many of the fancier term features.
  - zadler 3y ago
    What kind of fancier term features ?
chlorion 3y ago
I definitely recommend trying a hardware accelerated terminal emulator! It might sound silly at first, but it actually makes a pretty big difference! Even something is simple as drawing text is not that fast on a CPU, a GPU can do it not only faster but much more efficiently too.
- zadler 3y ago
  Yea it’s about time I give it a proper go

Whenever I have to do something in a TTY I kinda wish my normal terminal experience was that crisp and snappy.

by zadler 3y ago

Whenever I have to do something in a TTY I kinda wish my normal terminal experience was that crisp and snappy.

quesera 3y ago

It should be, unless you're running too much bash/zsh plugin stuff.

petepete 3y ago
And a terminal emulator with low latency definitely helps.
- arcanemachiner 3y ago
  I can only hope you're referring to network latency...
  - Rufbdbskrufb473 3y ago
    Probably not. There are terminals with surprisingly high latency, even on modern hardware. See here for examples of ~100 ms of local latency: https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/
  - codetrotter 3y ago
    I remember that urxvt used to be much more comfortable to use than some other terminal emulators whenever a process was spewing out thousands and thousands of lines of text. Some other terminal emulators at the time were very slow because they printed each and every line. urxvt on the other hand would skip printing lines to keep up. This was much preferable. If I intended to look at thousands of lines of text I would do so through a pager. So printing out thousands of lines of text directly into the terminal was almost always by accident. I have since gotten better at not accidentally printing a bunch to my terminal, so I am no longer using urxvt these days. But for a period of time urxvt was my preferred terminal emulator for that reason.
    - petepete 3y ago
      I had this discussion with someone on here the other day who flat out believed I'd invented the problem. Kitty is so fast compared to anything else I've tried.
    - quesera 3y ago
      > urxvt on the other hand would skip printing lines to keep up Really? That's a fatal flaw. Skipping lines is never ever OK for a terminal emulator. Not keeping up can also be a fatal flaw of course!
      - codetrotter 3y ago
        It’s not a flaw, it’s by design. https://man.archlinux.org/man/urxvt.1 https://man.archlinux.org/man/urxvt.1 > -ss|+ss > Turn on/off skip scrolling (allow multiple screens per refresh); resource skipScroll. > […] > skipScroll: boolean > True: (the default) specify that skip scrolling should be used. When receiving lots of lines, urxvt will only scroll once in a while (around 60 times per second), resulting in far fewer updates. This can result in urxvt not ever displaying some of the lines it receives; option -ss. > False: specify that everything is to be displayed, even if the refresh is too fast for the human eye to read anything (or the monitor to display anything); option +ss.
        quesera 3y ago
        Flawed design is still a flaw. I'll accept that it is a design feature to get around another failure mode, and that it might even be preferable sometimes. But it's a serious flaw. Terminal emulators should never drop output, that's what control flow signaling is for!
        codetrotter 3y ago
        It’s not a flaw. It’s a different kind of use-case than you have in mind. It’s fine. No one is telling you to use urxvt. You can continue to use whatever terminal emulator you prefer. That’s the power of choice we have. Different programs that do the same kind of things but in different ways. So there is no reason to insist that urxvt is flawed.
  - zamnos 3y ago
    Nope. Alacrity is probably the terminal emulator that revealed this, but terminal emulation itself is sometimes there bottleneck and GPU acceleration is required to get around the problem.
  - deleted 3y ago
    [deleted]
zadler 3y ago
Nah it’s probably gnome terminal and the rest of the UI stack, schedulers etc. See eg https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/
- quesera 3y ago
  Yes that's important too, but the magnitude of difference is relevant. A local shell with a non-pathological shell config and a reasonable terminal emulator is snappy-ish. Most sluggishness can be fixed in shell config. If that isn't working, some terminal emulators are definitely faster than others, especially on Linux with its wide variety of modern and historical choices! And of course tty will always be faster still, but far less convenient. When all is said and done and properly optimized, it's all probably still slower than the ProDOS prompt on an Apple //e (1MHz 6502 CPU), which can't help but make you wonder what we've all been doing for the last 40 years!
  - 656565656565 3y ago
    What we’ve been doing for the last 40 years is producing layers of abstraction for developers to play with
miniupuchaty 3y ago
I have all the same config in TTY as in emulated terminal and emulated is nowhere near as snappy and smooth as TTY. Even with GPU accelerated terminals like alacritty, it's a lot better, but still far. If I wasn't working mostly on graphical applications I would just work from TTY.

AlecSchueler 3y ago

Try different terminals. rxvt is way faster than xterm for example.

loeg 3y ago
Enlightenment's terminology is pretty snappy if you don't want to give up too many of the fancier term features.
- zadler 3y ago
  What kind of fancier term features ?

chlorion 3y ago

I definitely recommend trying a hardware accelerated terminal emulator! It might sound silly at first, but it actually makes a pretty big difference! Even something is simple as drawing text is not that fast on a CPU, a GPU can do it not only faster but much more efficiently too.

zadler 3y ago
Yea it’s about time I give it a proper go