5 ms·

Author of sixel-tmux (and of the matching rant) here. Your description of sixels using words like 'cosplaying' or 'late 90s japanese cellphone' is not very tec

by csdvrx 3y ago

Author of sixel-tmux (and of the matching rant) here. Your description of sixels using words like 'cosplaying' or 'late 90s japanese cellphone' is not very technical. It seems biased. In any case, it would be better than being stuck with the 60s "text only" VT100 like protocols. We can talk about technicalities, as some people do not like how sixels work under the hood, but... they work fine: I can play video in my terminals. I use gnuplot everyday. Could it be done better by a protocol that would use compression and other features? Maybe. But does it have to be? Why should we waste time reinventing the wheel when locally there's plenty of bandwidth, and remotely too often enough? Personally, I like sixels because prefer a standard that is well defined, and can't change on someone whim: I like stable interfaces. I think users are unfairly held back due to biases like the one you demonstrated, and that seem very common in the free software world, which was the point of my rant: there is no logical reason sixels couldn't be offered today in gnome terminal if the key people making sure that doesn't happen changed their mind.

deleted 3y ago
[deleted]
kragen 3y ago
a couple of minor corrections emoji support, not sixel support, is "cosplaying as a 90s japanese cellphone" the vt100 is from 01978 my 'cosplaying' comment was a specific response to teddydd's 'cosplaying computers from the sixties' --- i've been playing video and plotting functions from remote machines on terminals since 01993, but using x11, not sixel i think h.264 (cosplaying as an mp4 player from 02005) is probably a better approach for graphical applications; that's what xpra uses
- csdvrx 3y ago
  My apologies for the confusion for the vt100 year. I should have checked instead of assuming it was a rough contemporary of ascii. With these clarifications, I now understand your reply better, and it is indeed accurate: emojis are too limited. However, their frequent use in text interfaces demonstrate the need to transmit more information density that regular text can carry. Personally, in terminals I suggest the use of sixels, since they work well enough. Bandwidth is never an issue for local terminals: playing videos with mpv demonstrates that.
  - kragen 3y ago
    bandwidth is almost always an issue for local terminals; a 4k (3840×2160) terminal at 120fps and 32bpp is 4 gigabytes per second, and according to https://news.ycombinator.com/item?id=35694801 https://news.ycombinator.com/item?id=35694801, typically with ddr4 ram you get 30 or 40 gigabytes a second if you send all that video data through the ddr4 bus twice (once writing, once reading) you're using about 20–25 percent of the machine's memory bandwidth, but the linux tty subsystem actually makes several copies and runs many instructions per byte [citation needed] so you can't get anywhere close to that in practice. especially not if you're spending a lot of time repacking bits into six-bit bytes in order to feign compatibility with the vt340, a misguided engineering dead end from 37 years ago that only supported 16 colors and 800×480 anyway other protocols like x11 and xpra work considerably better, but x11 video reproduction on a local terminal normally uses xshm or its moral equivalent with xvshmputimage or gl. if you're on a local terminal, you might as well use x11; the only benefit to putting the pixels in the same bytestream as text is if the your terminal is connected to your drawing application over a bytestream such as an ssh connection, a tcp connection, an spi connection, or a uart i think we could do better by designing a bytestream protocol that minimizes copies and pixel format conversions and is therefore within epsilon of the speed of xshm, but sixel isn't it, and neither is x11 without xshm. a bidirectional bytestream protocol could include flow control to also avoid transmitting pixels that won't be visible and increasing latency due to bufferbloat as for emoji, they don't improve information density; there are only 2666 emoji in unicode 10.0, so at a maximum they convey only 13 bits of information, and they normally occupy roughly the space of two letters like 'n', so you have slightly fewer bits per pixel. people use emoji because they are cute and colorful, not because they are ithkuil. they're not some technologies, like the unix shell, smalltalk, and tcp/ip, make hard things easy and easy things possible. others, like retrocomputing, code golf, and malbolge, make easy things hard and hard things impossible. sixel makes easy things hard and hard things impossible, like the rest of retrocomputing. that's a fun way to spend my time when i choose to (e.g., in https://asciinema.org/a/390271 https://asciinema.org/a/390271 i did real-time 3d graphics in a unicode terminal emulator with braille) but it's not how i want my primary user interface to my computer to work
    - ratboy666 3y ago
arp242 3y ago
> there is no logical reason sixels couldn't be offered today in gnome terminal if the key people making sure that doesn't happen changed their mind. I read through that entire Bugzilla page, and IMHO the usability and technical concerns are pretty valid. You can say "well, those are not an issue for me" or "I can live with it" and that's entirely fair, but I can understand how a maintainer would want it to work really well before merging. Also, I believe it did get merged in 2020? The current status is a bit unclear to me.
kergonath 3y ago
> I use gnuplot everyday. Same. Sixel support in gnuplot is very useful: it’s great to have decent graphics without relying on X with dodgy vpns. It’s probably not the most useful feature, but it was a significant QoL improvement when I found out the Sixel terminal.

by csdvrx 3y ago

deleted 3y ago

[deleted]

kragen 3y ago

a couple of minor corrections emoji support, not sixel support, is "cosplaying as a 90s japanese cellphone" the vt100 is from 01978 my 'cosplaying' comment was a specific response to teddydd's 'cosplaying computers from the sixties' --- i've been playing video and plotting functions from remote machines on terminals since 01993, but using x11, not sixel i think h.264 (cosplaying as an mp4 player from 02005) is probably a better approach for graphical applications; that's what xpra uses

csdvrx 3y ago
My apologies for the confusion for the vt100 year. I should have checked instead of assuming it was a rough contemporary of ascii. With these clarifications, I now understand your reply better, and it is indeed accurate: emojis are too limited. However, their frequent use in text interfaces demonstrate the need to transmit more information density that regular text can carry. Personally, in terminals I suggest the use of sixels, since they work well enough. Bandwidth is never an issue for local terminals: playing videos with mpv demonstrates that.
- kragen 3y ago
  bandwidth is almost always an issue for local terminals; a 4k (3840×2160) terminal at 120fps and 32bpp is 4 gigabytes per second, and according to https://news.ycombinator.com/item?id=35694801 https://news.ycombinator.com/item?id=35694801, typically with ddr4 ram you get 30 or 40 gigabytes a second if you send all that video data through the ddr4 bus twice (once writing, once reading) you're using about 20–25 percent of the machine's memory bandwidth, but the linux tty subsystem actually makes several copies and runs many instructions per byte [citation needed] so you can't get anywhere close to that in practice. especially not if you're spending a lot of time repacking bits into six-bit bytes in order to feign compatibility with the vt340, a misguided engineering dead end from 37 years ago that only supported 16 colors and 800×480 anyway other protocols like x11 and xpra work considerably better, but x11 video reproduction on a local terminal normally uses xshm or its moral equivalent with xvshmputimage or gl. if you're on a local terminal, you might as well use x11; the only benefit to putting the pixels in the same bytestream as text is if the your terminal is connected to your drawing application over a bytestream such as an ssh connection, a tcp connection, an spi connection, or a uart i think we could do better by designing a bytestream protocol that minimizes copies and pixel format conversions and is therefore within epsilon of the speed of xshm, but sixel isn't it, and neither is x11 without xshm. a bidirectional bytestream protocol could include flow control to also avoid transmitting pixels that won't be visible and increasing latency due to bufferbloat as for emoji, they don't improve information density; there are only 2666 emoji in unicode 10.0, so at a maximum they convey only 13 bits of information, and they normally occupy roughly the space of two letters like 'n', so you have slightly fewer bits per pixel. people use emoji because they are cute and colorful, not because they are ithkuil. they're not some technologies, like the unix shell, smalltalk, and tcp/ip, make hard things easy and easy things possible. others, like retrocomputing, code golf, and malbolge, make easy things hard and hard things impossible. sixel makes easy things hard and hard things impossible, like the rest of retrocomputing. that's a fun way to spend my time when i choose to (e.g., in https://asciinema.org/a/390271 https://asciinema.org/a/390271 i did real-time 3d graphics in a unicode terminal emulator with braille) but it's not how i want my primary user interface to my computer to work
  - ratboy666 3y ago

arp242 3y ago

> there is no logical reason sixels couldn't be offered today in gnome terminal if the key people making sure that doesn't happen changed their mind. I read through that entire Bugzilla page, and IMHO the usability and technical concerns are pretty valid. You can say "well, those are not an issue for me" or "I can live with it" and that's entirely fair, but I can understand how a maintainer would want it to work really well before merging. Also, I believe it did get merged in 2020? The current status is a bit unclear to me.

kergonath 3y ago

> I use gnuplot everyday. Same. Sixel support in gnuplot is very useful: it’s great to have decent graphics without relying on X with dodgy vpns. It’s probably not the most useful feature, but it was a significant QoL improvement when I found out the Sixel terminal.