Add a fall-back Sixel shim

[WSLUser]

Now that we're trying to get notcurses working on Windows, it's time we evaluate supporting all terminals that don't have Sixel implemented. While majority of terminals on WIndows do not support Sixel, I believe there are a few others that don't exist on Windows that also haven't enabled Sixel graphics. By providing a fall-back for those terminals, notcurses TUI applications will have even more terminals that can be supported.

If you're wondering if there's precedence for this, recently even Tmux is enabling a fall-back (which is what inspired me to write this issue). See https://github.com/tmux/tmux/tree/sixel (which appears to have forked a version of sixel.c from BSD from reading the file, wouldn't recommend using that particular implementation as result).

Also see #1891 and the linked issue to the WT repo which is related to this.

[dankamongmen]

By fallback, what exactly do you mean? Notcurses works on plenty of terminals that don't support any kind of pixel bitmaps. In such a case, we fall back to the best cell-based blitter available. See https://notcurses.com/notcurses_visual.3.html.

Do you refer to some other bitmap protocol?

But yeah, if you try using NCBLIT_PIXEL where unsupported, Notcurses will fall back depending on the scaling type. If NCSCALE_NONE or NCSCALE_SCALE, it will default to NCBLIT_2x1 (to preserve aspect ratio), or NCBLIT_3x2 otherwise.

[WSLUser]

So I'd like this library to have something like Tmux has as linked above.

Notcurses works on plenty of terminals that don't support any kind of pixel bitmaps.

This is what I'm referring to, providing a minimal bare effort support of pixel bitmaps for terminals that don't support it similar to Tmux. I'm pretty sure your demos don't work as well as they could in those terminals and basically want to ensure I can use Sixel applications that rely on notcurses. In the WT issue, the tmux maintainer showed using his Sixel fall-back to run Sixel applications on Windows though it required using a remote Linux host due to the ioctls not being supported on Windows side (not sure if that's something you can handle as well but that would pertain to your other issue and just want to at least get the remote story good before we concern ourselves with local).

I've seen you've been looking at taking on libsixel as a dependency and maintain a fork now. Basically I'm suggesting making use of that to allow Sixel applications to run as intended if they use notcurses as the backend library.

[dankamongmen]

I've seen you've been looking at taking on libsixel as a dependency and maintain a fork now. Basically I'm suggesting making use of that to allow Sixel applications to run as intended if they use notcurses as the backend library.

i'm still not sure i understand.

i do not intend to bring in libsixel, necessarily, but we have our own sixel implementation. we emit sixel wherever they're supported. we determine that support via XTSMGRAPHICS queries.

if they don't support sixel, or some other bitmap protocol, i fall back to cell blitting (as opposed to pixel blitting), using the best one available. this is determined off unicode support.

so, i think what you're asking is already handled? can you point to a problematic config?

[WSLUser]

Maybe it is already handled. I don't often mess with Sixel stuff but would like to, main reason I haven't is due to Windows not having Sixel support yet and that is my primary OS with Linux being my secondary (I use both on daily basis). I guess what I'm asking is for something that works faster, which I believe the pixel blitting does since I assume cell blitting is akin to software rendering vs gpu rendering.

[dankamongmen]

nope, that's not the difference.

A terminal can entirely lack pixel blitting support, and most do.

• A GUI assumes a rectangular matrix of individually-controllable elements called pixels.
• A TUI assumes a rectangular matrix of individually-controllable elements called cells, usually made up of many dozens of pixels.

A pixel is set to a color; a cell is set to a glyph, a foreground color, a background color, and a style.

Most terminals only support cells. When you say "go to coordinate 2,2", you're going to the second cell on the second row (or third, if 0-indexed). When you say "draw the number 0", you're going to draw that glyph, and move to the next cell. On such terminals, we perform cell-based blitting: https://nick-black.com/dankwiki/index.php?title=Notcurses#Blitters

these are the four cell blitters, right-to-left in ascending resolution: Space, Half, Quad, and Sex. the rightmost, Space, is the only one that works in pure ASCII mode. it blits using space characters, setting the background color.

the downside of this is of course that you are blitting to much larger regions of the screen than pixels, so the size required for a given number of pixels is larger. watch the keller demo to get a better sense of this. you can hold the absolute size constant, but then you're going to have much lower resolution.

but yes, if there is no pixel blitting available, or if you choose them, you get cell blitters. a pixel blitter is never required, unless you as the user select NCBLIT_PIXEL together with NCVISUAL_OPTION_NODEGRADE, indicating that you would rather get an error than fall back to a blitter having less resolution than NCBLIT_PIXEL.

as for sixel vs kitty vs iterm vs linux framebuffer, that's all abstracted away behind NCBLIT_PIXEL.