Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support
github.com
github.com
> Sorry guys, but I don't want you to hold Linux terminal users hostage for your petty concerns over what is the "right" way to do something like sixels. [...] It's something that has been done successfully for over 30 years.
...
> Still, you could successfully block sixel support by having control over the terminal emulators or the libraries. Ok, but now, try to prevent your users from running sixel-tmux!
...
> Also, you guys like to say that the only voices that matters are from those who can code? Hmm, ok for that too. Let's see how you like the code I release to show the pointlessness of your petty fights, and free your users from your questionable decisions.
Also, I wasn't familiar with the term "sixel". They've been around since DEC introduced them in the 80's: https://en.wikipedia.org/wiki/Sixel
I can't agree. Like most rants, I found it to be very needlessly emotional, lacking in the technical department, and motivating towards the wrong goal (trying to fight and argue with maintainers, accusing them of negative things like "holding users hostage", etc) rather than doing the right thing for users (delivering new and useful features in a way that isn't broken). I wish open source programmers would make less rants and emotionally-driven forks, it's not helpful to someone like me who just wants to get something new like images in their terminal. The issues in the GNOME/WT bug trackers are what actually contain technical information. And just from looking at that, it appears there is an open development branch for VTE that contains sixel support: https://gitlab.gnome.org/GNOME/vte/-/issues/253
So if you use GNOME, I would say just use that and work on that, the quality is going to be better than the degraded functionality you get from de-rasterizing. In my opinion, it would be better from a technical standpoint if the author just wanted to work on that, or wanted to work on getting it implemented proper in WT. The degraded-image approach used by this tmux fork is unusable for the cited use case of getting nice graphs in the terminal, and I can't see how it's going to make it any easier for those other terminals to solve the real technical issues with sixel.
Edit: I also want to respond to this comment in the rant:
>What will happen as Wayland replaces X?
Nothing? XTerm still works. But there is also a Wayland-native terminal called "Foot" that supports sixel, if that's your thing: https://codeberg.org/dnkl/foot
2nd edit: To those downvoting, please reply to me instead of doing that. If you disagree with me it would be better to know why so I could potentially change my view, a downvote communicates nothing of value towards changing my mind.
It was an accurate assessment of the situation. Read @hpa technical analysis if you prefer, but you'll see he and I seem to concur: there's nothing technically wrong in sixels.
> So if you use GNOME, I would say just use that and work on that
The difference between you and I is you still believe what they say. I don't. And I question the motives of people associated with a project whose official stance is that it's acceptable to plan technical hurdles to prevent people from using themes: https://news.ycombinator.com/item?id=28559716
> In my opinion, it would be better from a technical standpoint if the author just wanted to work on that
I have no interest in wasting hours writing then submitting code to people who have put into writing the reasons why they are playing the clock against sixel support (as if I couldn't have read between the lines...), and who have said previously they would use their positions to veto the inclusion.
By default, I no longer trust them. It's up to them to prove they have changed. In the meantime, sixel-tmux will exist to push for change, as a pebble in their shoe.
> The degraded-image approach used by this tmux fork is unusable for the cited use case of getting nice graphs in the terminal, and I can't see how it's going to make it any easier for those other terminals to solve the real technical issues with sixel
Don't be so focused on one format. There needs to be a foot in the door, after which other formats can be added. It's just a bootstrapping problem.
Said differently, if tmux can understand sixels and store them into some internal representation, it's easy to convert from that into other formats as needed (iterm, kitty...) meaning others terminals will enjoy the graphical formats in pixel perfect quality, as long as they support at least one format.
Meanwhile, gnome users will be left to wonder why they are left to deal with a derasterized output, and fingers will be pointed into the right direction.
Maybe that will encourage the VTE team to do what the users want? If not, it will make it easier for alternatives to emerge (like "foot" for Wayland that was mentioned here)
What I'm doing is totally a political move, I grant you that.
> solve the real technical issues with sixel.
THERE IS NO TECHNICAL ISSUE WITH SIXEL (!!)
Try the nyancat linked below. Look at the FPS. 30 fps in the terminal is good enough for most uses.
The only issue with sixel is some people hold personal grudges against it.
Sorry, but I don't play ball with them anymore.
If these issues keep coming up, and you keep saying "sixel isn't broken" then we have nothing technical to discuss and it's going off into emotional rant territory. You have to respond to the actual technical concerns. In addition to all those things, the restriction to only paletted images makes it so I personally won't use it, it cannot be used to do any kind of accurate graphics. If you wanted to work on a new protocol that wasn't broken, I think that would be great too.
Also I think you are making more erroneous and emotional arguments when you say these things:
>And I question the motives of people associated with a project whose official stance is that it's acceptable to plan technical hurdles to prevent people from using themes
This is misinformation, GNOME is not preventing people from using themes. I can go into more detail if you like.
>I have no interest in wasting hours writing then submitting code to people who have put into writing the reasons why they are playing the clock against sixel support (as if I couldn't have read between the lines...), and who have said previously they would use their positions to veto the inclusion.
You don't need to submit any code, you could produce a fork as you already have done. Then once that's done, you could send it to someone else who could get it cleaned up for submission, if you were interested. Please don't fixate on fighting someone or arguing with one person's statements when the actual state of the project contradicts that.
>Don't be so focused on one format. There needs to be a foot in the door, after which other formats can be added. It's just a bootstrapping problem.
This doesn't make sense, the issue here seems to be the sixel protocol itself, and getting a foot in the door won't help when the format itself is broken. You would need to go back to square one in any case to design a new protocol. I think it's good to have a project that can convert between the different formats, but starting with a baseline of a broken format that doesn't work is just going to ensure that everything stays broken.
Also, using sixel to display animations seems like an extremely bad idea. You'll always get horrible performance that way. That to me seems just like it's growing towards a really bad and outdated reinvention of an X11 or RDP-style protocol. I'd say it's a mistake to pursue that.
>Maybe that will encourage the VTE team to do what the users want?
I posted a link to it, but VTE already has started adding support for Sixel.
Second, tell me why 24 bits colors is insufficient for drawing into the terminals?
> starting with a baseline of a broken format that doesn't work
Look at that https://github.com/hackerb9/sixvid and that https://github.com/libsixel/libsixel and tell me precisely what doesn't work, in your own words.
If you can't...
> then we have nothing technical to discuss
... I think you may be right there!
>tell me precisely what doesn't work, in your own words.
I already explained it, I've used sixel in Xterm and Foot and I don't like it, the restriction to paletted images makes everything look bad. Also, changing the font size breaks the images. Also, the protocol is still terrible on bandwidth, if you use it to try to transmit 1080p video over ssh (as someone is bound to do) then you will encounter the same bandwidth issues. Again please read this issue if you want to know more about my stance, I agree with everything it's saying: https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
So sixel-tmux is not going to help me, sorry. It may even make things worse for me if apps are trying to use it when I don't want it. If you want some more suggestions on what to do to help, I can give those. But you're also welcome to not listen to me if you disagree. Maybe you have to accept that I am just not in your target audience, but that's no reason to accuse other maintainers of trying to hold me hostage.
Edit: I said earlier that I think it would be a good goal to support the various image protocols, I would be happy to use this if eventually an image protocol was added there that wasn't seriously flawed. But the apps and terminal emulators will still have to be changed to support that, so supporting sixel doesn't really help towards that goal at all, and in some ways it impedes it because those projects might be expected to maintain that as a backwards compatibility option. That's what I meant earlier, I think you may be approaching this problem from the wrong angle.
Not with 16 million colors. That's what 24 bit color mean (2^16) also called "truecolor" mode
> Also, changing the font size breaks the images.
Not on mintty. I can change the font size up and down, it even resizes the sixels in proportion so the images remain aligned to the text in a pixel-perfect way.
It's a terminal problem. You are using bad terminals. I grant you that xterm is the least worst option on linux, but do yourself a favor and try mintty on Windows.
> Also, the protocol is still terrible on bandwidth
Are you using telnet on remote hosts? Unless you do that, with ssh, compression means I can stream video (!!!) just like on local hosts (where bandwith is not an issue)
> It may even make things worse for me if apps are trying to use it when I don't want it.
In the future, sixel-tmux will intercept sixels live and rewrite them into other format, like iTerm or kitty.
How is that making things harder for you?
If you really don't want sixel even if your terminal supports them, use the appropriate terminfo and you will see nothing.
> seriously flawed
You have yet to tell me the flaws in your own words, flaws that are not due to a given terminal.
Try to use sixel to play videos in mintty, with 24 bit support so palettes aren't a problem. Then try tweaking the font size (why not!), notice how it remains a perfect user experience, then we'll talk again.
For now, all I see is FUD.
>Try to use sixel to play videos in mintty, with 24 bit support so palettes aren't a problem.
You are confusing sixel with the iTerm image protocol which is different. Sixel is a really old and outdated, inefficient protocol that only supports uncompressed 6-bit paletted images. It would be best if we could just stop talking about sixel altogether, because this is not even what you're referring to anymore. I'm actually concerned that you're conflating these two, it would also best if you could be clear about this in terms of your project so it's not confusing as to what your project supports. Maybe the name should change from sixel-tmux at some point?
SSH compression is not going to be better than the image's native compression, you really don't want to rely on that to compress your images when we already have dozens of other better ways to transmit video.
>Not on mintty. I can change the font size up and down, it even resizes the sixels in proportion so the images remain aligned to the text in a pixel-perfect way.
I'd love to look into how that's accomplished but I can't use mintty because I use a Mac, sorry. I'm also not really interested in trying to mess with mingw just to get this set up.
This isn't FUD either, you're saying the terminals are bad, well, there is no terminal I can use that works correctly, I suggested to help out fixing the terminals if you know how and you basically said no. So what am I supposed to do? Part of making a good protocol is making one that is easy for the apps and terminal emulators to implement correctly, if that doesn't exist, then like I said you have to go back to square one. Adding this support to tmux is useful in some cases, but it still isn't going to help with getting the terminals to implement this right.
>In the future, sixel-tmux will intercept sixels live and rewrite them into other format, like iTerm or kitty.
This is a good idea, please do this instead of trying to get other terminals to adopt Sixel when they are just going to have to replace it down the line anyway.
No I'm not.
> Sixel is a really old and outdated protocol that only supports 6-bit paletted images.
No it doesn't.
sixels can be 16 million colors, that's precisely what the snake.six outputs tests: if you can't see the precise degradation of the snake skin greens and yellows, your terminal is broken.
With so many bad terminals, it's no wonder that a lot of people have such a bad opinion about sixels!
> It would be best if we could just stop talking about sixel altogether, because this is not even what you're referring to anymore. I'm actually concerned that you're conflating these two
Actually, with what you said, I think you're the confused one here. When you could not express in your own words which practical limitations were imposed by sixels, I was 99% sure.
Now I'm 100% sure you have no idea of what you are talking about. Sorry if it's blunt, but take the time to run the tests I've suggested to correct your misconceptions about sixels.
Maybe you'll end up loving the format once you see what it's really capable of?
> I'd love to look into how that's accomplished but I can't use mintty because I use a Mac, sorry. I'm also not really interested in trying to mess with mingw just to get this set up.
Intel macs can run Windows natively. You've also got your pick of emulators, from parallels to vmware, if you roll that way.
So install Windows one way or another, go to msys2.org, download the latest release, click on install. No messing required, mintty is here by default.
You can then use pacman if you want more, which BTW is far better than most of the package managers available on Mac: simply follow the pacman update steps clearly explained with many screenshots on the first page.
Then you'll have an up-to-date msys2 install, with most of the linux tools you want running natively (no WSL involved) or just a `pacman -S` away.
>> In the future, sixel-tmux will intercept sixels live and rewrite them into other format, like iTerm or kitty.
> This is a good idea, please do this instead of trying to get other terminals to adopt Sixel when they are just going to have to replace it down the line anyway.
What you've written makes about as much sense as saying a drawing program should stop trying to support BMP format since it will have to be replaced down the line by JPG or PNG.
gimp, paint and others support many formats. Nobody is complaining. People just click on open. They don't care about the underlying formats.
Am I reading this incorrectly? It seems I was wrong, it supports 8-bit color, not 6-bit color. But that's still terrible, and every Sixel implementation I've ever used has spit out dithered images. The only terminal that is able to display full color images for me is iTerm, using the iTerm escape sequences, which are different escape sequences from sixel. So again, please help out with fixing this for me if you know how. Because so far you have not adequately explained what is going on here, or corrected any misconceptions, or helped to fix anything that is wrong with these terminals. And even the various libsixel examples seems to show dithering: https://github.com/saitoha/libsixel
If I'm confused then you could be in a great position to help me out, so please explain what apparently myself and the libsixel authors are both doing wrong. Then maybe at some point in the future I could help you out and return the favor.
And there are also other problems with the iterm escape sequences that I suspect will prevent you from correctly implementing them in tmux (see here: https://gitlab.com/gnachman/iterm2/-/issues/3898). So all paths point towards needing to make some new protocol for this. You may be in the best position to do that too.
>Intel macs can run Windows natively. You've also got your pick of emulators, from parallels to vmware, if you roll that way.
I'm not going to dual boot Windows or use a VM just to use a terminal emulator for a couple minutes, sorry. If you could just explain what that terminal does that's special so that it could be implemented in other terminals, or show a video, that would help.
>What you've written makes about as much sense as saying a drawing program should stop trying to support BMP format since it will have to be replaced down the line by JPG or PNG. gimp, paint and others support many formats. Nobody is complaining. People just click on open. They don't care about the underlying formats.
If GIMP was attempting to pressure other projects to output BMP files then yes, that would be a problem. I suspect other projects wouldn't go for that just because they asked.
Looks to me like the limited pallete is mostly as XTerm limitation, but a limitation of the protocol.
You are pushing the goalpost. I was talking about 24 bit color (2^24= 16 millions).
Now you are saying the lack of 32 bit color support is an issue?
Maybe let's start with 24 bit color, which is far more than what the human eye can discern anyway (about 10 million) even if we'd then have to talk about color spaces, and how 32 bit may be better for some specific applications)
Also the PNG format is extremely common and supports 32-bit color, so if you don't support that then you cannot accurately display PNG images, or any other RGBA format. Without this you're about 25 years out of date.
Yes
> It seems I was wrong, it supports 8-bit color, not 6-bit color.
Good.
A positive first step is knowing when to admit error.
> But that's still terrible, and every Sixel implementation I've ever used has spit out dithered images
OMG, I spoke too fast, there you go again!
I've given you a step-by-step guide to try the best terminal there is.
> So again, please help out with fixing this for me if you know how.
I HAVE TOLD YOU AT LEAST 4 TIMES: YOU NEED TO USE A STATE OF THE ART TERMINAL TO FIRST CORRECT YOUR MISCONCEPTIONS.
Then if you are speaking in good faith, we will talk again.
> Because so far you have not adequately explained what is going on here, or corrected any misconceptions, or helped to fix anything
I'm at a loss. I can't hold your hand while you install msys2 so you realize yourself you were wrong, just like you did with the 24 bit colors which you wrongly assumed to not be supported by sixels.
Let's try a Bayesian approach: considering you have been proved wrong, you should update your priors and consider the likelihood of being wrong again is greater than me being wrong, since I have 1) quite an experience with sixels 2) so far I've been proven right.
> I suspect will prevent you from correctly implementing them in tmux (see here: https://gitlab.com/gnachman/iterm2/-/issues/3898)
You are pointing me to a 6 years old bug report about tmux eating sequences important to display sixels, which funny enough is the original concept behind sixel-tmux: click on my profile and you will notice "Show HN: Sixel-tmux, display graphics because it does not eat escape sequences" by csdvrx on Nov 27, 2019
I agree it was a serious issue, enough to motivate me. I didn't know it was also affecting iterm. At least I learned something too from this exchange, thanks a lot!
> So all paths point towards needing to make some new protocol for this. You may be in the best position to do that too.
All path point toward you mixing up terminal issues and sixel issues, not using the right tool, refusing to even try to use the right tool.
But yes, a few of us are in a position to push for better standards. I think @christianparpar and @hpa have the deepest understanding of the alternative standards. Eventually a few standard may emerge... or not. It doesn't matter. BMP, GIF, PNG and JPG can all coexist, each have their pros and cons. There's no need to make a choice when all apps support loading and saving in the user favorites formats.
> I'm not going to dual boot Windows or use a VM just to use a terminal emulator for a couple minutes, sorry.
Then I'm not going to try to explain you what you are understanding in a wrong way, as only seeing how mintty handle sixels WITH YOUR OWN EYES may correct your misconceptions at this point.
> If you could just explain what that terminal does that's special so that it could be implemented in other terminals, or show a video, that would help.
Click on the url and you'll see a few demos, including the snake.six displayed in a wonderful example of 24 bit "truecolor" support.
Your request to add a video showing how mintty handle font changes seems resonable. It will make a nice addition to sixel-testsuite.
> If GIMP was attempting to pressure other projects to output BMP files then yes, that would be a problem
If other projects did not even support BMP, but only knew about drawing ASCII art with a 8 colors palette, yes, refusing to implement BMP in 24 bit mode as a first step, while spending 6 years debating the best way to achieve the perfect format that will have absolutely no drawback (chasing a wild goose) would indeed be a problem...
Now the actually tricky parts: The spec states (DEC STD 070), that the palette should be of size 256 at least on decoder side, and an encoder should not create more than 256 colors, and any higher palette index gets mapped back (not specced out, but mostly done with modulo). Older devices (old DEC printers or VTs) were even more limited in palette regards, from monochrome like VT240 to 16 colors on a VT340 for screen output. Thats what xterm does with `-ti 340` and it is totally right about it - it emulates what a VT340 was capable to do. What mlterm started to do (and others followed) - well it did not care for strict VT340 emulation, and increased the palette to 256 colors. Furthermore it applied "printer-behavior" (note - sixel was developed as printer protocol) deviating from DECs VT behavior by immediately applying colors to pixels. While DEC's sixel capable VTs always were bound to the fixed palette. That terminal vs printer behavior distinction is important, as it opens sixel to actually use more colors than the palette has room for by redefining color slots on the fly.
Hope this helps to get some details straight.
The sixel format has much bigger issues beside its reduced color resolution - no alpha channel, need for really expensive quantization and printer head movements serialization, with bad cache locality due to its 6-pixel offset in y direction. Its compression is lousy. All that said, encoding/decoding sixels is a mainly CPU-bound resource hungry task with high bandwidth needs - all for worse quality compared to modern formats. With modern hardware, where beefy GPUs exist, it is really a shame to insist on using this format (which was effectively dead for >20ys).
On terminal side there are more issues about sixels and how they relate to cursor advance and the terminal grid, but going into these details will only bore ppl in a rant thread.
>Good.
Please avoid these snarky responses, this is not helping explain anything and will not serve to change anyone's mind.
>I HAVE TOLD YOU AT LEAST 4 TIMES: YOU NEED TO USE A STATE OF THE ART TERMINAL TO FIRST CORRECT YOUR MISCONCEPTIONS.
Please avoid the caps lock, this is also not helpful. I have told you multiple times: I don't have access to one of those terminals, so if you want me to use that, you will either have to try to help those other projects, or you will have to explain how this can be fixed to bring those projects up-to-date. You cannot seriously expect everyone to switch to your terminal of choice just to use a special version of tmux. If you're presenting a new version of tmux that you want to get adoption then you will need to support many terminals, not just your favorite.
And actually upon looking into this it appears that libsixel is what is doing the quantization, so this statement seems to have nothing to do with either of our setups at all. Have you modified your libsixel not to do this? Or is there some other command I need to type? Please explain these things instead of just telling me I have misconceptions with no description of what they actually are.
>considering you have been proved wrong
Well I'm happy to be proven wrong but you never did this despite me asking repeatedly. It was only explained by someone else in a sibling comment. This is why I suggest against making rants, in every single case I've ever seen a developer posting rants, it prevents the actual technical issues from getting explained. And your hostile responses towards me have actually further discouraged me from using sixel or from using your tmux fork, and even from trying out mintty eventually. This is not the way to be persuasive.
>You are pointing me to a 6 years old bug report about tmux eating sequences important to display sixels
No, this is wrong. The issue is about iTerm escape sequences, not sixels. Imgcat doesn't use sixel. Please make sure to get this correct, it's very important to your project. Also this bug report is not just about eating the escape sequences, but that the escape sequences cannot possibly be processed by tmux because they lack enough information to display correctly.
>Click on the url and you'll see a few demos, including the snake.six displayed in a wonderful example of 24 bit "truecolor" support.
This doesn't help, I mean a video that actually explains what is going on technically. You could make a youtube video that walks through the code and explains to other terminal developers how to do it.
>If other projects did not even support BMP, but only knew about drawing ASCII art with a 8 colors palette, yes, refusing to implement BMP in 24 bit mode as a first step, while spending 6 years debating the best way to achieve the perfect format that will have absolutely no drawback (chasing a wild goose) would indeed be a problem...
We already have better protocols than sixel though.
It's titled as a rant, in a file called RANTS.md, and unless you've gone out of the way to read it, the rest of the immediately available documentation looks to be perfectly professional and courteous. I'm not sure what you are expecting?
I dislike when this sort of stuff is front-and-center on a project but it seems perfectly reasonable to accept that a developer might have opinions and feelings that caused them to "scratch an itch". People who aren't annoyed with existing systems don't in general try to replace or work around them, and there's certainly a load of projects I've found with disagreeable approaches to contributions or governance that I would rather not put my own time into. I imagine they feel the same, and appreciate that they documented that frustration.
Open source in general has a problem with this, if it's left unchecked it leads to toxic behavior very quickly. That's my experience anyway. Traditional diplomacy doesn't help because some people seem to see open source as a "I can do whatever I want" type of thing, which it is. It's fine to do whatever you want in your free time but once you combine that with an attitude of "I will never change my mind or stop ranting" then is when it gets destructive and harmful towards someone who is trying to build a community and convince other projects to collaborate and adopt a shared standard. So if that's the goal then the ranting and bad attitudes need to stop. (Full disclosure: I'm saying this as someone who used to rant quite a lot, and damaged many relationships over it. It felt good for me but it made everyone around me become distrustful of each other)
If you want to downvote me again then that's fine, but if you have something to say then please reply. A downvote or an upvote can't mend a broken relationship like a strong conversation can.
I normally just default to using Gnome Terminal on Linux, which sadly doesn't support Sixels, so I'll definitely give this a go.
Looking around I've just found Foot, which looks like it does support Sixel on Wayland[1].
So that might be a more permanent way forward.
In terms of customization and configuration, I'd say foot falls between Alacritty and Kitty with Kitty being the most customizable and configurable while Alacritty being the least.
One of the things I really like about Alacritty and foot is that they don't enforce italic and bold monospace variants while Kitty does. I despise italic variants of monospace fonts. Most monospace fonts don't even have proper italic variants. They're just slanted.
I tried using foot a few days ago but went back to Alacritty because of this issue.
https://codeberg.org/dnkl/foot/issues/628
I think I might move back to foot though because it felt a bit faster (lesser latency) and for some reason, text on Alacritty is sometimes blurry for me.
But I think having the possibility of italic, bold, bold+italic in the TE is a very good thing. And if you do not want that I think Kitty allows you to just use another font then; please correct me here, but I think that is configurable. Bold text in the TE world is yet another heated discussion. Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).
Indeed, and the right solution is a config options, just as was done in Windows Terminal, since nobody is wrong: it's just a matter of preferences!
The right technical way of handling preferences is offering more choices to the users, with some sane default that will satisfy most users.
Personally, I love italics (I use vim and I want comments shown in italics, and I make an heavy use of bold+italics, cf https://github.com/csdvrx/indent-rainbow/blob/main/after/syn... ) but I would not want to force this option to people who don't want italics, for their own reasons that are none of my business (actually, if they reasons are good enough, it may cause me to change the default choices, but I would never remove the user freedom to make such choices in the first place)
IMHO that's the key difference between MacOS/iOS/Gnome/new school linux on one side (fewer freedoms) and Windows/KDE/old school Linux (more freedoms)
Do you really believe that's reasonable? That I should stop using my favorite monospace fonts just because a terminal emulator doesn't let me disable italic variants of that font when other terminal emulators like Alacritty and foot do?
I don't think that's reasonable and so I stopped using Kitty. And no, I'm not gonna resort to fontconfig hacks or manually delete the italic otf/ttf files. I'd rather use a terminal that gives me choice rather than imposes it.
Kitty supports images via a custom API. There's loads of really cool plugins for it but what's interesting about Sixel support is that it's a standard, even if it's primitive.
I'm not sure that Alacitty can support images or, at least, I couldn't see that reported anywhere (it's been a while since I ran it myself).
In terms of performance Foot seems to compare well to both[1].
1. https://codeberg.org/dnkl/foot/src/branch/master/doc/benchma...
Here's another explanation why VTE based terminals are best avoided.
https://github.com/thestinger/termite
Here's a complete list.
https://wiki.archlinux.org/title/List_of_applications#VTE-ba...
I think VTE is fine if you don't mind development happening at a glacial pace...
https://gitlab.gnome.org/GNOME/vte/-/issues/253#note_1049040
Which was then obviated by the first download of an animated gif. Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code.
By not supporting sixels, it forces people to use a whole browser to show images. Graphics support in the terminal is more than just QoL for the users, it is also a power savings and a hardware lifetime issue.
You are fighting the good fight.
Indeed, penny wise but pound foolish... and I guess they were proud of themselves!
> You are fighting the good fight.
Thanks, hopefully due to kicking the ant nest with my rants and now sixel-tmux, VTE will be forced to deliver something, anything really, even if it may be 6 years too late and not enabled by default (!!)
At least Linux distributions would have the possibility to compile it in?
But at this point, even that I can't believe. I think they will weasel out at the last minute with some half-baked more or less plausible excuse, like your example about firefox code increasing by a few kb.
My hopes for gnome are extremely low, so "I'll believe it when I can see it" and not before, say when it's shipping in Ubuntu.
It's not! Gnuplot in the terminal open many new use cases, such as examining data on remote hosts with scripts without even bothering to scp the data first.
Also, Notebooks in the terminal is wonderful!
Check https://github.com/koppa/matplotlib-sixel
As for kitty format, adding support in sixel-tmux is planned, but you are welcome to write a patch if you want it sooner!
Imagine sixel-tmux as some middleware, because it is totally possible to intercept sixel sequences and rewrite them on the fly into something more palatable to kitty or iTerm.
This way, even if gnuplot doesn't support kitty, you could still view the results. If it's done well enough, you may not even perceive the difference!
That's the direction I want to follow, so that users can take any software and play with it on their terminal regardless of the underlying format.
I have to check the current state of rstudio/ipython console support with sixels: doing everything from the terminal is a luxury I want in 2021, especially now that hidpi/4k screens are becoming mainstream :)
Last time I tried in uni on a "new" Thinkpad R52 (well, new for me as it wall already over 10 years old, but it had such a glorious 1400x1050 display!) quite a few things were missing.
You misunderstood me, I was saying Kitty graphics protocol feels more like a toy in how well it can produce graphics (GIFs, videos, etc). Sixel is more common in actual use cases (at the moment). But, take notcurse's graphics demo for example, using the kitty backend, it's very unreal terminal experience. But once Kitty's graphics protocol has more widespread support, for example in graphing tools, it'll be just as useful as Sixel :)
Or compile it yourself using MinGW64 : after installing from msys2.org, pacman -S base-devel etc
It works fine here. I have a Windows Terminal settings to start sixel-tmux instead of bash, using script to provide a pty: just have the command line be:
C:/msys64/usr/bin/env.exe MSYS=winsymlinks:nativestrict MSYSTEM=MSYS /usr/bin/script -c /usr/bin/tmux /dev/null
It's due to a cygwin and how /dev/cons* are different from /dev/pty* cf https://cygwin.com/pipermail/cygwin/2020-May/244878.html
I've tried to explain that a bit better in server-client.c (check line 251) to give the user a clue of what's happening with *cause = xstrdup(c->ttyname)
Unfortunately, even in 2021, properly configuring a terminal can be complicated.
That's why sixel-tmux page has a step-by-step configuration guide, and why I often provide config files in other projects like https://github.com/csdvrx/indent-rainbow : if needed, check https://github.com/csdvrx/indent-rainbow/blob/main/config/wi... even if I need to update it that should give you a good base to start tweaking from.
I strongly encourage you to check your configuration with the steps suggest on the sixel-tmux page, or at least the minimal set of steps shown in http://github.com/csdvrx/sixel-testsuite (which I should update to show how font change should work, with sixels being resize to be kept in perfect alignment with the text, as done in mintty, as several people seem to believe it's a sixel limitation)
At first I was afraid the project would take the easy way out and ignore hard features or take shortcuts (ex: SGR1 : bold or bright? or both? or none?) but you have shown you are willing to do what it takes to properly support applications.
This is not just in line with the reputation of Microsoft when it comes to backwards compatibility, but going above and beyond to make sure everything works perfectly.
When sixel support is added to WT, it will replace mintty as my favorite terminal -- and I'm very picky when it comes to terminals.
WT is a wonderful contribution to the open source world, and I hope it will inspire similar terminals on Linux (or be usable through wine)
Oh, and uh, my apologies if you felt my contribution to the sixel thread (PR #448) were out of line. Since your last message, I've realized my posts may be off topic, as a degraded mode is not what most people may want, even as a stopgap measure, so I've stopped posting there.
This looks fun
Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance.
https://github.com/floooh/chips-test/blob/master/examples/as...
I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).
That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid
Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecommen...
The issue may be in your code.
I think I have similar performance issues, as the glyph selection process could be more optimized.
Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality.
Reducing the set of glyph to something that could benefit from optimizations could help.
> I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses)
Sixel performance is quite decent: personally, I can play videos in my terminal.
Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183
I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL
When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels.
Indeed! It's nice to see what's possible!
As for video playback, while it may not be realistic with the current sixel-tmux due to the size of the search space, it may be possible once the new 1FBxx block https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing is integrated into derasterize and the suggested fonts: restricting ourselves to the 1FB0x-1FB3x subset would only require adjudicating about 64 characters.
Some very basic programming tricks (a bloom filter after binarization of the input, memoizing...) may be sufficient to derasterize sixel videos in real time, even on an average system.
> I still suspect it's a performance issue in the terminal(s) I tested
If you don't use Windows, try xterm and mlterm. For xterm, I maintain a set of config files giving you a decent out-of-the box experience, cutexterm
> I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels.
Indeed :) It's a format that has been unfairly dismissed. It's old, but we have great tools like libsixel to do anything we want with it in this millenium.
Speaking of libsixel, also check https://github.com/libsixel/libsixel a recent fork that's open to PR
If you are a Mac user, could you please consider writing a patch? The ability to dogfood it means whatever you write will still be better than whatever I may come up with.
This is not based on technical facts, but bias against an old format.
> png/gif/jpg--for higher quality output & lower bandwidth
For bandwidth, my ssh stream is compressed.
For quality, I can't see difference in a 24 bit bitmap when comparing with a png or jpg, unless I compress them too much, in which case the compression artifacts start playing AGAINST the formats you recommend.
I came to Linux last year, and I've been on it 100% no windows during this entire period.
I'm using Sway (Wayland), a DE (well, really just a window manager) you cannot replicate in the windows graphical environment, and I'd never go back. Everything is so smooth, and of course you may say that it's "because vsync is used in Sway and vsync = bad blah blah", but I've never agreed with that and a good implementation of vsync with minimal latency increases is worth it, especially paired with freesync/adaptive sync (which works on the desktop just as it does in Windows).
Fyi, before my Linux days, I was a very competitive gamer, and absolute windows power user. I went out of my way to get every last bit of performance and latency reduction possible (just so you know where I'm coming from).
My terminal emulator is Foot, a wayland native terminal with a focus on TUI performance, especially in TUI editors like (neo)vim (my editor of choice). It has amazing Sixel support with a developer who goes out of his way to fix even the smallest imperfections with the implementation. Foot has features I really love, like link following by keyboard shortcuts, great font fallback customisation, and no bloat (a feature in my book)
My multi-resolution setup is not impacted by Linux because Sway, and Wayland ecosystem in general, handles multi resolution tremendously, and supports integer and fractional scaling per display. Multi display freesync/adaptive-sync (and gsync whenever Nvidia starts playing ball) works great too, just as it does on windows.
The majority of stuff you complain about is due to crusty old X11 (whether you're stuck on X because of nvidia or not, it's not a fair argument). Or because you think the way Windows does something is better than the way Linux does that thing (even though in most cases I think the opposite, clearly a subjective thing).
Oh, and yea I think Windows sucks and Linux does <insert> better. But I'm saying that as a zoomer, not a "geek millennial" (as you said in your rant) :)
He also tried getting sixel support in tmux but was rejected again. All he did was make a hard fork to get the feature that he wanted. That's it. The end. There are some things that Windows does better and some things that Linux does better. Generalizing your anecdotal experience and implying that one is entirely "better" than the other is what fundamentalism and fanaticism looks like.
Also they go on from there about how they want to encourage Linux users to jump over to Windows. Again, I think this is just frustration with their perception that there are too many control freaks in the opensource world acting as gatekeepers for important feature availabilities (the core of their rant is just that they really wish they could have done graphical plots in their default terminal when they were in school years ago).
To my reading, it sounds like someone who wanted to support free software who jumped over to Windows in disgust, not really a "Windows fanboy."
So I guess in a way OP is (sort of) seeing the light on free software here too. Don't like it? Fork it!
EDIT: Yup, as suspected, the author doesn't intend to keep his fork updated with upstream and I don't blame him for that. This essentially makes this fork a proof of concept, nothing more. Unless it gets merged in tmux itself, people might as well forget that this fork exists.
To be honest, Windows fangirl? guilty as charged!
But I try to keep my personal opinions separate, which is why my rants are on a separate page.
Still, you nailed it: sixel-tmux was made to try to help correct the direction that has been taken, with 6 years wasted.
I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool".
Desperate times call for desperate measures. Publishing this fork was a last resort move, for the exact reasons you stated: forks are often lost in obscurity.
However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel!
A compile time flag is not ideal, but if at least derasterize can be added by default, so that every tmux user can have some kind of graphics in the terminal, even if said graphics are not sixels but derasterized, that would be "good enough" to me.
No problem. I know maintaining forks isn't an ideal thing to do and support should ideally land upstream.
> I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool".
I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision.
https://github.com/thestinger/termite/blob/master/README.rst...
I'm just a random spectator but perhaps your efforts might've been better spent on an independent terminal project (like Alacritty, for example) rather than trying to get features merged upstream in a GNOME project.
> However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel!
Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.
Wow, this confirms a lot of my impressions:
>> In 2012, we submitted a tiny patch exposing the APIs needed for the keyboard text selection, hints mode and other features. Despite support from multiple other projects, the patch was rejected. It's now almost a decade later and no progress has been made. There is no implementation of these kinds of features in VTE and it's unlikely they'll be provided either internally or as flexible APIs. This is the tip of the iceberg when it comes to their hostility towards other projects using VTE as a library. GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use.
This is exactly why sixel-tmux exists as a separate entity!
> Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.
I'll keep my fingers crossed, but right now, there seems to be a lot of good will. I will do everything I can.
Here you mention some other things unrelated to terminals, and I was mostly addressing those. It seems to me you want a specific type of experience on Linux, but you can't get that, so therefore dismiss the merits of Linux. I think a lot of your impressions on Linux come from using an X11 based setup instead of Wayland. Completely different beasts, and I think a lot of your grievances would be solved by the latter.
For me, I cannot go back to Windows, ethical reasons aside: Sway on Wayland is perfect for me, and it's what I want out of my computing experience.
I actually agree with a lot that is written in those rants, particularly the VTE and gnome terminal situation. It's just your comments on windows vs linux came across as very personal imo, so I suppose I have retorted here with also a somewhat personal rant.
Also, I don't think either platform has many good terminal choices. Besides mintty, I don't think there are that many good (platform exclusive) terminal emulators on Windows. And on Linux, Foot is one of the few that meets my criteria, including top tier Sixel support (though Wezterm meets my criteria too if it wasn't so slow, hopefully it gets faster). But, for example, I could never really like mintty if I was forced to use Windows, because it lacks features I want.
What I'm trying to say: different needs, different use cases, different tastes. Sorry that my original rant came off so negatively to you and that I wasn't able to convey this point I was trying to make.
However, I think my expectations and opinions on terminals are quite fair, and that most people would enjoy an equivalent of mintty if there was one on Linux: it has been polished by years of adding small functionalities that adds up to make a whole that's greater than the sum of the parts.
You seem to generally agree with my takes, so I'm curious, what is lacking in mintty for your own uses? Personally, the only missing functionality that I sometimes regret is tab support.
As for platform exclusives, Windows Terminal has great tab support and is right now the best terminal for someone who doesn't need sixels: the ability to configure different shells ("profiles") is by itself quite admirable. The attention to details (SGR1) and configurability of said details seals the deal: different colors for different tabs of different profiles, so you don't mix your remote sessions!
As for Wayland, I can't say. I may have tried it for 10 minutes or 1 hour then found limitations, and decided it may not give the best argument in favor of Linux so I'd rather skip it. I will try Linux again in 2022, and I'll spend time with foot since everyone seem to love it, so I'll give another try to Wayland!
Besides having a great terminal experience (as I do most of my work there), one of the silly details that matters to me the most is having a consistent white theme which both removes the perception of reflections on glossy displays in the daytime, and allows an easy dark mode if you do a screen inversion + a red shift at the night time. NegativeScreen is a gem to do that on Windows: night mode for every app as soon as you press a button!
If I can't do that on Wayland (no more xrandr) like I do on Windows, the lack of support for themes in future gnome versions worries me, as pure white themes (for eInk) and pure black themes (for OLED) are extremely rare by default.
Still, I would love to be able to use Linux, because I love ZFS, but so far the terminal experience and the UI have kept me firmly in Windows land.
I'll see how the situation evolves... if it doesn't change enough, I may do something weird, like a GPU passthrough with everything on Windows, storage on a zvol handled by Linux as the virtualizer.
Also, there are other wayland environments besides GNOME, so don't feel you have to use that.
I have a few things that I can't stand and I have no problem ditching something that doesn't offer me what I want. For example, I ditched Kitty because it doesn't let me disable italic variants of monospace fonts. In a hypothetical scenario, if tmux/screen didn't exist and Kitty was the one terminal which had these features, I would be frustrated as well if the dev didn't budge from his position of not letting users disable italic fonts. Fortunately, tmux exists and Alacritty lets me disable italics.
It's pretty naive and immature to get married to the tools you're using. Unfortunately, you see this a lot in the FOSS world.
[0] https://github.com/csdvrx/cutexterm#wait-i-thought-people-sa...
But yes, I do believe people claiming that Linux offers the best terminal experience are either doing that for social credit and validation of their peers (in an "emperor has no clothes" way) or due to misinformation and a lack of personal experience with alternatives (in a "micro$oft only knows embrace, extend, extinguish" way)
Some do that for both reasons, and I'll let you make your own conclusion about their demographic group.
The rant in this repo links to a related rant in another one of the author's repos: https://github.com/csdvrx/cutexterm#wait-i-thought-people-sa...