Make easy things hard and hard things impossible. others, like retrocomputing, code golf, and malbolge, Some technologies, like the unix shell, smalltalk, and tcp/ip, make hard things easy and easy things possible. people use emoji because they are cute and colorful, not because they are ithkuil. a bidirectional bytestream protocol could include flow control to also avoid transmitting pixels that won't be visible and increasing latency due to bufferbloatĪs 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. 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. 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 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. 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 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 so you can't get anywhere close to that in practice. 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.īandwidth 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, typically with ddr4 ram you get 30 or 40 gigabytes a second Personally, I like sixels because prefer a standard that is well defined, and can't change on someone whim: I like stable interfaces. 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? I use gnuplot everyday.Ĭould it be done better by a protocol that would use compression and other features? Maybe. they work fine: I can play video in my terminals. We can talk about technicalities, as some people do not like how sixels work under the hood, but. In any case, it would be better than being stuck with the 60s "text only" VT100 like protocols. Your description of sixels using words like 'cosplaying' or 'late 90s japanese cellphone' is not very technical. (Incidentally, I suspect Muratori’s Refterm fails this test to the point of requiring a redesign, though I haven’t checked.)Īuthor of sixel-tmux (and of the matching rant) here. Either you’re tracking the first byte to have affected the current screen (and need to store the entirety of the “a lot” and dump it onto a newly attached client) or you’re trying to discard all the stale updates while keeping the last one and the initial screen contents (and that’s just a screen buffer with extra steps). I mean, you could avoid knowing anything about the terminal state machine if you dumped the entirety of the session’s bytestream from the very beginning on each attach event, but unless you are willing to do that it seems to me that you’re going to have to track enough state to basically amount to maintaining a screen buffer (and then you do have to care about sixels).įor example, suppose the user fills the screen (maybe even with an image), then spends a lot of bytes overwriting the last line over and over (think progress bar).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |