4 ms·

TUIs are very pretty and very convenient. Unfortunately rendering to the Terminal is...slow. See https://github.com/browsh-org/browsh https://github.com/browsh-

TUIs are very pretty and very convenient. Unfortunately rendering to the Terminal is...slow. See https://github.com/browsh-org/browsh https://github.com/browsh-org/browsh. Honestly I wonder if there is a way to speed it up. Like a new terminal mode which lets you write or color a particular row/column directly, or utilizes the GPU to render to each pixel, or really anything better than literally printing text with fancy spacing, escapes, etc. on each refresh. Until then, anything which is render-intensive you're much better using a GUI, even if it's just a shell script which opens a window while it's running.

theamk 5y ago
As long as you don't send video/graphics, most of the terminals are limited by the link bandwidth, as opposed to rendering performance. And if you are sending video or animated graphics, then perhaps a special video-orented protocol is a much better choice. Like that browsh project - I am fairly sure the performance would be much better with special protocol.
qbasic_forever 5y ago
Perfectly emulating pixel graphics with a TUI isn't really the point. The point is to simplify an interface to the most essential text. Look at lynx or elinks for an example of a more realistic and usable TUI web browser. It doesn't try to play youtube videos, it just extracts the text and content from a site to display it. But to your question, yes there are 'text' console bitmap graphics protocols. Check out sixel for one example: https://saitoha.github.io/libsixel/ https://saitoha.github.io/libsixel/ Some terminal emulators support other bitmap graphics too.
- zozbot234 5y ago
  The point of things like sixel is to efficiently support interfaces where text is mixed with a little bit of graphics, like in many old-style apps of the 1980s and 1990s - they work very well for that. Replicating a full-featured GUI though is kinda outside their scope; you could make it work but it's not really the point.
  - GekkePrutser 5y ago
    By the way regarding sixels, in the original VT430 (IIRC) they were ridiculously slow :P. Anything today is lightning fast.
quesera 5y ago
> Unfortunately rendering to the Terminal is...slow. That is not accurate, and your example is absurd abomination of the text-based concept (but is nevertheless a fun demonstration of capabilities). I run TUIs that push hundreds (sometimes thousands) of changes per second to a 80x48 canvas. There is zero lag induced by the front end.
easygenes 5y ago
It’s buried in that list, but Notcurses is fast and challenges assumptions about what can be done in a terminal. https://youtu.be/dcjkezf1ARY https://youtu.be/dcjkezf1ARY
nofunsir 5y ago
It’s called vt-100 mode and it’s not new. You can easily write a TUI that only updates the View (at a particular location and color) when the View Model changes.
bhay 5y ago
Have you tried Alacritty? I've found it's very good at GPU rendering.
- Ancapistani 5y ago
  I love Alacritty, but when I got an M1 Mac I discovered that it was always running in x86 mode. After a couple of hours trying to figure out why… I just switched to Kitty and haven’t looked back.
  - unphased 5y ago
    Mine's installed from homebrew and is a native process. 0.10.0-dev (1df7dc51) it reports.
    - Ancapistani 5y ago
      I've not used it for a few months, but I installed from homebrew as well. Run `arch` in a terminal. Does it return `arm64`? Interestingly, I just opened Alacritty on my M1, and it's showing `arm64` now. I know it didn't before. The app has been upgraded because macOS's security tools blocked it when I tried to open it and I had to explicitly allow it. Maybe it was an issue that they've fixed since I last looked?

theamk 5y ago

As long as you don't send video/graphics, most of the terminals are limited by the link bandwidth, as opposed to rendering performance. And if you are sending video or animated graphics, then perhaps a special video-orented protocol is a much better choice. Like that browsh project - I am fairly sure the performance would be much better with special protocol.

qbasic_forever 5y ago

Perfectly emulating pixel graphics with a TUI isn't really the point. The point is to simplify an interface to the most essential text. Look at lynx or elinks for an example of a more realistic and usable TUI web browser. It doesn't try to play youtube videos, it just extracts the text and content from a site to display it. But to your question, yes there are 'text' console bitmap graphics protocols. Check out sixel for one example: https://saitoha.github.io/libsixel/ https://saitoha.github.io/libsixel/ Some terminal emulators support other bitmap graphics too.

zozbot234 5y ago
The point of things like sixel is to efficiently support interfaces where text is mixed with a little bit of graphics, like in many old-style apps of the 1980s and 1990s - they work very well for that. Replicating a full-featured GUI though is kinda outside their scope; you could make it work but it's not really the point.
- GekkePrutser 5y ago
  By the way regarding sixels, in the original VT430 (IIRC) they were ridiculously slow :P. Anything today is lightning fast.

quesera 5y ago

> Unfortunately rendering to the Terminal is...slow. That is not accurate, and your example is absurd abomination of the text-based concept (but is nevertheless a fun demonstration of capabilities). I run TUIs that push hundreds (sometimes thousands) of changes per second to a 80x48 canvas. There is zero lag induced by the front end.

easygenes 5y ago

It’s buried in that list, but Notcurses is fast and challenges assumptions about what can be done in a terminal. https://youtu.be/dcjkezf1ARY https://youtu.be/dcjkezf1ARY

nofunsir 5y ago

It’s called vt-100 mode and it’s not new. You can easily write a TUI that only updates the View (at a particular location and color) when the View Model changes.

bhay 5y ago

Have you tried Alacritty? I've found it's very good at GPU rendering.

Ancapistani 5y ago
I love Alacritty, but when I got an M1 Mac I discovered that it was always running in x86 mode. After a couple of hours trying to figure out why… I just switched to Kitty and haven’t looked back.
- unphased 5y ago
  Mine's installed from homebrew and is a native process. 0.10.0-dev (1df7dc51) it reports.
  - Ancapistani 5y ago
    I've not used it for a few months, but I installed from homebrew as well. Run `arch` in a terminal. Does it return `arm64`? Interestingly, I just opened Alacritty on my M1, and it's showing `arm64` now. I know it didn't before. The app has been upgraded because macOS's security tools blocked it when I tried to open it and I had to explicitly allow it. Maybe it was an issue that they've fixed since I last looked?