3 ms·

> Terminal text editors are also lighter due to the fact that the terminal is providing all of the windowing fuss for them and that terminals are light applicat

by zokier 2y ago

> Terminal text editors are also lighter due to the fact that the terminal is providing all of the windowing fuss for them and that terminals are light applications in and of themselves due to not having to do much that is extremely novel or intensive on a CPU I think this is a common fallacy. Fundamentally adding an tty layer in the middle does not make lighter solution, so in almost all cases terminal application+terminal emulator is inherently heavier than equivalent application talking directly to display server.

flutetornado 2y ago
I think the performance in terminal apps could come from the fact that terminals can use pre rendered, pre cached in GPU, text glyphs covering a fixed size small grid (of glyph sized blocks instead of pixels.) At least that’s what I have wondered - because the terminal UI experience has been always a lot more slick compared to heavy GUI based programs. Feel free to correct me if someone has done actual performance analysis.
bitwize 2y ago
Generally you're going to need some sort of layer in order to display something meaningful; even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit. And it can appear on more devices.
- zokier 2y ago
  > even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit But using tty/ncurses does not avoid the costs of GUI, your terminal emulator will still need to have that. So using terminal can only add additional cost, not reduce it.
  - bitwize 2y ago
    The costs of, say, xterm (or even konsole) + tty layer are still far less than the costs of the UI layer for a halfway decent IDE. It's a bit penny-wise and pound-foolish to worry about the added cost of the tty layer when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be). Remember, Unix systems implemented tty support in perhaps tens of kilobytes of memory, on CPUs running at single-digit megahertz speeds. Graphical IDEs these days are often frickin' Electron apps.
    - zokier 2y ago
      > when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be). Talking directly to display server simply can not incur more cost than having terminal application and then terminal emulator talking to display server; the talking to display server is something you need anyways, and anything else (like having a tty layer) is just additional cost on top of that.
timewizard 2y ago
The terminal has implicit state. The GUI does not. The TTY layer is doing far less per call than your GUI stack is.
- zokier 2y ago
  How does that implicit state help with anything if you look at the system as whole? Sure, with terminal applications the costs are spread around in more components, but ultimately the total can not really be smaller. You still have the GUI stack in the end, with terminal apps there is just terminal emulator and tty layer in between.
  - timewizard 2y ago
    The terminal layer can exist outside of the GUI. That GUI programs provide emulation for this, yea, adds the whole GUI layer back in so systemically you are worse off. The application doesn't notice any of this though. So they're easier to develop and the program itself runs faster (is lighter). Which is the specific point the article was making.
    - immibis 2y ago
      VGA cards haven't provided actual 80x25 text mode since forever, so you're still converting to pixels at some layer. Which means you might as well take full advantage of having full control over those pixels, rather than constraining yourself to the patterns that happen to be in your font. With full control over pixels, you can use any combination of "text" and "graphics" that you want. For example, you could make Vim or EDIT.COM but with a normal mouse cursor and a scrollbar with pixel granularity.
      - timewizard 2y ago
        > VGA cards haven't provided actual 80x25 text mode since forever, Are you sure about that? The memory range still exists and still operates the same as it ever has. The _card_ just does the translation for you. > so you're still converting to pixels at some layer. This has /never/ not been true. > With full control over pixels Yea, again, you are intentionally not understanding the point the article or myself made. The application in text mode does NOT need to do this work. The application IS lighter as a result. > but with a normal mouse cursor and a scrollbar with pixel granularity. And how do you receive mouse inputs? With more code. How do you manage pixels? With more code. Are you understanding that this is PRECISELY the point here?

by zokier 2y ago

flutetornado 2y ago

I think the performance in terminal apps could come from the fact that terminals can use pre rendered, pre cached in GPU, text glyphs covering a fixed size small grid (of glyph sized blocks instead of pixels.) At least that’s what I have wondered - because the terminal UI experience has been always a lot more slick compared to heavy GUI based programs. Feel free to correct me if someone has done actual performance analysis.

bitwize 2y ago

Generally you're going to need some sort of layer in order to display something meaningful; even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit. And it can appear on more devices.

zokier 2y ago
> even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit But using tty/ncurses does not avoid the costs of GUI, your terminal emulator will still need to have that. So using terminal can only add additional cost, not reduce it.
- bitwize 2y ago
  The costs of, say, xterm (or even konsole) + tty layer are still far less than the costs of the UI layer for a halfway decent IDE. It's a bit penny-wise and pound-foolish to worry about the added cost of the tty layer when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be). Remember, Unix systems implemented tty support in perhaps tens of kilobytes of memory, on CPUs running at single-digit megahertz speeds. Graphical IDEs these days are often frickin' Electron apps.
  - zokier 2y ago
    > when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be). Talking directly to display server simply can not incur more cost than having terminal application and then terminal emulator talking to display server; the talking to display server is something you need anyways, and anything else (like having a tty layer) is just additional cost on top of that.

timewizard 2y ago

The terminal has implicit state. The GUI does not. The TTY layer is doing far less per call than your GUI stack is.

zokier 2y ago
How does that implicit state help with anything if you look at the system as whole? Sure, with terminal applications the costs are spread around in more components, but ultimately the total can not really be smaller. You still have the GUI stack in the end, with terminal apps there is just terminal emulator and tty layer in between.
- timewizard 2y ago
  The terminal layer can exist outside of the GUI. That GUI programs provide emulation for this, yea, adds the whole GUI layer back in so systemically you are worse off. The application doesn't notice any of this though. So they're easier to develop and the program itself runs faster (is lighter). Which is the specific point the article was making.
  - immibis 2y ago
    VGA cards haven't provided actual 80x25 text mode since forever, so you're still converting to pixels at some layer. Which means you might as well take full advantage of having full control over those pixels, rather than constraining yourself to the patterns that happen to be in your font. With full control over pixels, you can use any combination of "text" and "graphics" that you want. For example, you could make Vim or EDIT.COM but with a normal mouse cursor and a scrollbar with pixel granularity.
    - timewizard 2y ago
      > VGA cards haven't provided actual 80x25 text mode since forever, Are you sure about that? The memory range still exists and still operates the same as it ever has. The _card_ just does the translation for you. > so you're still converting to pixels at some layer. This has /never/ not been true. > With full control over pixels Yea, again, you are intentionally not understanding the point the article or myself made. The application in text mode does NOT need to do this work. The application IS lighter as a result. > but with a normal mouse cursor and a scrollbar with pixel granularity. And how do you receive mouse inputs? With more code. How do you manage pixels? With more code. Are you understanding that this is PRECISELY the point here?