3 ms·

You should not dismiss "crude" methods so easily: the same output can be rendered inside GNU screen or tmux, which would be complicated otherwise. And low band

by csdvrx 8y ago

You should not dismiss "crude" methods so easily: the same output can be rendered inside GNU screen or tmux, which would be complicated otherwise. And low bandwidth is useful when doing SSH: I posted this quick example of what I use everyday as a reply "ROSshow: ASCII art visualizations for robot sensor data" (https://news.ycombinator.com/item?id=19519165 https://news.ycombinator.com/item?id=19519165) by ssh'ing to my remote host (which does not have a GPU) from my laptop (which doesn't have a GPU either). I wanted to share something that you can use right now, and that works reliably even in non optimal conditions. Notice how my loadavg is above 10, and how I'm using a mlterm binary downloaded straight from mlterm.sf.net/bin.html The same will work with a vanilla msys2 installation, or with the in-kernel console of "old powerless machines" as noted on https://saitoha.github.io/libsixel/#sayaka-chan https://saitoha.github.io/libsixel/#sayaka-chan

sprash 8y ago
With a serialized GPU commands the remote host does not need a GPU since everything is rendered locally. Only the machine running the terminal emulator needs one. And this would also work within screen or tmux if they don't meddle with unknown escape codes.
- csdvrx 8y ago
  With the history of ^O bracketed paste handling exploits and the more recent spectre/meltdown exploits, I'm not sure serialized GPU rendering is such a bright idea. If the concern is the speed of the scrollback on device rendering the content, wouldn't adding GPU support to say mlterm be enough? Anyway, if someone has a desperate need of graphical output inside a terminal, this is an actual solution working with little risks and default tools: I only recompiled gnuplot with the proper compile-time flag, exported the GNUTERM variable, and voila!!
- chubot 8y ago
  Even if they don't mess with unknown escape codes, wouldn't they have to know how wide what is being drawn is? I ran into this issue while writing a shell. All shells use wcwidth() to determine the width of a unicode character. I think all terminals need that information too, and they would also need the analogous information for unknown escapes.
  - sprash 8y ago
    It will certainly mess up multi window screen/termux arrangements. The dimensions of the current terminal can be obtained easily. However the position can not. And it will still be possible to draw over other windows.
coldtea 8y ago
>You should not dismiss "crude" methods so easily: the same output can be rendered inside GNU screen or tmux, which would be complicated otherwise. Yes, but still a throwback to 3 decades past+
- marmaduke 8y ago
  Why fix what ain’t broke?
  - coldtea 8y ago
    Because it's not only "broke" things that people want to fix -- it's also half-arsed, inadequate, slow, limited, etc things. And terminal graphics are all those.
Eduard 8y ago
Not sure if it was implied. Sixel has lots of overhead compared to ascii/Unicode braille art. Using sixel to transmit decent images over ssh is very data-demanding

by csdvrx 8y ago

sprash 8y ago

With a serialized GPU commands the remote host does not need a GPU since everything is rendered locally. Only the machine running the terminal emulator needs one. And this would also work within screen or tmux if they don't meddle with unknown escape codes.

csdvrx 8y ago
With the history of ^O bracketed paste handling exploits and the more recent spectre/meltdown exploits, I'm not sure serialized GPU rendering is such a bright idea. If the concern is the speed of the scrollback on device rendering the content, wouldn't adding GPU support to say mlterm be enough? Anyway, if someone has a desperate need of graphical output inside a terminal, this is an actual solution working with little risks and default tools: I only recompiled gnuplot with the proper compile-time flag, exported the GNUTERM variable, and voila!!
chubot 8y ago
Even if they don't mess with unknown escape codes, wouldn't they have to know how wide what is being drawn is? I ran into this issue while writing a shell. All shells use wcwidth() to determine the width of a unicode character. I think all terminals need that information too, and they would also need the analogous information for unknown escapes.
- sprash 8y ago
  It will certainly mess up multi window screen/termux arrangements. The dimensions of the current terminal can be obtained easily. However the position can not. And it will still be possible to draw over other windows.

coldtea 8y ago

>You should not dismiss "crude" methods so easily: the same output can be rendered inside GNU screen or tmux, which would be complicated otherwise. Yes, but still a throwback to 3 decades past+

marmaduke 8y ago
Why fix what ain’t broke?
- coldtea 8y ago
  Because it's not only "broke" things that people want to fix -- it's also half-arsed, inadequate, slow, limited, etc things. And terminal graphics are all those.

Eduard 8y ago

Not sure if it was implied. Sixel has lots of overhead compared to ascii/Unicode braille art. Using sixel to transmit decent images over ssh is very data-demanding