Hacker News Reader

Comment by armchairhacker | Hacker News Reader

TUIs are very pretty and very convenient. Unfortunately rendering to the Terminal is...slow. See 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.

View on HN

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/ Some terminal emulators support other bitmap graphics too.

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.

By the way regarding sixels, in the original VT430 (IIRC) they were ridiculously slow :P. Anything today is lightning fast.

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

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

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.

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

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.

Mine's installed from homebrew and is a native process. 0.10.0-dev (1df7dc51) it reports.

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?

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.

Reply on news.ycombinator.com