notcurses
notcurses copied to clipboard
dankamongmen
draw sixels on the bottom row
@klamonte worked out a method using DECSDM whereby we can draw sixels to the bottom row without scrolling. rip it off, earnestly!
:) Currently xterm maxes out at 1000 pixels in either direction, so we are limited to bottom rows that fit in that upper-left quadrant. (I do want to report that, but first we need to stop bricking xterm.) And xterm might be buggy even within that range.
I'm working to fix wezterm too. Which will hopefully make it look better and be slightly faster for the notcurses 3.0 demo.
I haven't yet checked, but I think DECRQM/DECRPM can be used to test for support of DECSDM.
:) Currently xterm maxes out at 1000 pixels in either direction, so we are limited to bottom rows that fit in that upper-left quadrant. (I do want to report that, but first we need to stop bricking xterm.) And xterm might be buggy even within that range.
well this depends on your xterm configuration:
notcurses 3.0.4 on XTerm 370 (Linux 5.16.1nlb)
61 rows (23px) 312 cols (11px) 1403x3432 rgb+256 colors
gcc-11.2.0 (LE)
terminfo 6.3.20211021 libdeflate 1.8 GPM 2.1.0
avformat 58.76.100 avutil 56.70.100 swscale 5.9.100 avcodec 58.134.100
af+ ab+ sum- vpa+ hpa+ sgr0+ op+ fgop+ bgop+ bce+ rect+
bold+ ital+ struck+ ucurl- uline+ u7+ ccc+ rgb+ el+
utf8+ 2x1+ 2x2- 3x2- 4x2+ img+ vid+ indn+ gpm- kbd-
default fg 0xffffff default bg 0x333333 pmouse+
max sixel size: 1380x1980 colorregs: 1024
this comes from XTerm*maxGraphicSize: 1980x1440. hrmm, i wonder where 1380 is coming from.
I'm working to fix wezterm too. Which will hopefully make it look better and be slightly faster for the notcurses 3.0 demo.
immaterial to me -- any wezterm shipping with this will also support kitty by default, meaning i will always use kitty (and thus not run into the bottom row problem). i of course encourage your fixing it for sixel users.
hrmmmmmm with that said, maybe i ought emit sixel instead of kitty when it would not result in color loss and the resulting sequence is smaller. eh, probably not; if they ever moved the result, i'd have to do grotesque sixel moves.
this comes from
XTerm*maxGraphicSize: 1980x1440. hrmm, i wonder where 1380 is coming from.
Oh cool! I should have known that, he's allowed that to be set in XTSMGRAPHICS since 2019 at least. Well yet another thing to set/query and use. :-)
Oh cool! I should have known that, he's allowed that to be set in XTSMGRAPHICS since 2019 at least. Well yet another thing to set/query and use. :-)
i don't think you can XTSMGRAPHICS beyond the value specified in Xresources?
Was just playing with it, and it looks like:
- Default is 1000x1000
- You can make it bigger via .Xresources
- If you specify "auto" in .Xresources, then the max is set smaller than 1000x1000 (800x480).
- You cannot change it via XTSMGRAPHICS. And xterm does appear to be responding with success or failure either.
this comes from
XTerm*maxGraphicSize: 1980x1440. hrmm, i wonder where 1380 is coming from.
cells are 23 pixels high geometry is 1403x3432 can't blit to last row, so 1403 - 23 == 1380 1380 / 6 == 230
thus maximum sixel is 1380 tall; this makes sense