use DECFRA to update glyphs underneath transparent graphic

[dankamongmen]

DEC420+ supports DECFRA (CSI Pc ; Pt ; Pl ; Pb ; Pr $ x):

CSI Pc ; Pt ; Pl ; Pb ; Pr $ x
          Fill Rectangular Area (DECFRA), VT420 and up.
            Pc is the character to use.
            Pt ; Pl ; Pb ; Pr denotes the rectangle.

see #1619 for why this might be expected to work better than P2=0. there appears to be no terminfo capability corresponding to this escape sequence, alas.

also, what the hell is defbi "define_bit_image_region" as mentioned in terminfo(5)?

[dankamongmen]

there's also DECERA

CSI Pt ; Pl ; Pb ; Pr $ z
          Erase Rectangular Area (DECERA), VT400 and up.
            Pt ; Pl ; Pb ; Pr denotes the rectangle.

[dankamongmen]

CSI Pt ; Pl ; Pb ; Pr $ {
          Selective Erase Rectangular Area (DECSERA), VT400 and up.
            Pt ; Pl ; Pb ; Pr denotes the rectangle.

when you wish to selectively nuke from orbit

[dankamongmen]

CSI Pt ; Pl ; Pb ; Pr $ {
          Selective Erase Rectangular Area (DECSERA), VT400 and up.
            Pt ; Pl ; Pb ; Pr denotes the rectangle.

when you wish to selectively nuke from orbit

it looks like this plays with DECSCA (select character protection attribute)

[christianparpart]

Most interesting i still think is DECCRA. That should also help improve performance and latency. It could be used to rerender moved parts on the screen in a single VT sequence.

[dankamongmen]

oooh DECCRA looks useful indeed, assuming it's actually widely implemented. with that said, it would be difficult for me to use it in my current model, except for sprixels without background glyphs, since everything else gets mixed down to a single layer during rendering. i could theoretically tag plane movements, and watch for interactions with other planes, and use DECCRA if there are none of the latter, but that's a fair amount of effort to avoid some glyph writes, especially if support is thin. for sixel, it could be useful indeed.

@ThomasDickey's observation here points out that styling/colors aren't copied over, which indeed looks to be the case:

The copied text takes on the line attributes of the destination area.

which is definitely the final nail in the coffin in terms of it being useful to me. the vast majority of non-bitmap bandwidth is going to styling escapes, not glyphs, so this wouldn't actually save me much bandwidth. and who knows whether it works on sixels?

nuking rectangular regions from orbit remains desirable.

[dankamongmen]

@dknl has some useful comments back in #1619:

It's hard to say though. Erasing a large sixel line-by-line can be really slow too, since the sixel may have to be copied and truncated over and over again. You definitely want to use escape sequences that erase a swat of cells in one go, rather than, say, printing spaces. There are escapes to do "rectangular editing" (and among them, a rectangular erase). Unfortunately they're not widely supported. Technically, they're only available on VT400 and newer (many terminals don't implement 400 features, or any 300 features for that matter). But, "rectangular editing" has it's own feature number in the primary DA response: 28. So, what I'm thinking is you can look for 28 in the DA response, ignore the VT level, and use DECERA (rectangular erase) if available. And fall back to ECH, ED, EL or whatever.... except that XTerm includes 28 in its DA response even in e.g VT220 mode, where it doesn't support rectangular erase. Unsure if this is a bug or if it's intentional.

his analysis of performance (and why P2=0 would likely be a miss) corresponds to a reply from @ThomasDickey a few weeks back when i reported what i thought a bug in XTerm performance.

[christianparpart]

@ThomasDickey's observation here points out that styling/colors aren't copied over, which indeed looks to be the case:

He is wrong as much as the spec is concerned at least. Quote from the spec:
"The copied text retains its character values and attributes."

There may have been buggy implementations though. - or at least it differs from my interpretation of the spec. See below.

The copied text takes on the line attributes of the destination area.

which is definitely the final nail in the coffin in terms of it being useful to me.

Check https://vt100.net/docs/tp83/appendixb.html and search for "line attributes". Line attributes are those that apply to the whole line and not those in the cell level (such as SGR attributes) unless i am completely drunk (nothing is impossible). ;-)

I hope this text is free of topys as i am writing from the phone :)

P.s. VT >= 400 for those who care

[dankamongmen]

perhaps! your reading seems reasonable, but i am still no expert in such things.

either way, rectangular copy just seems very difficult to fit to my implementation, except perhaps for bitmaps (when are rasterized as a plane, as opposed to glyphs, which are all rendered down to a single common frame first). when it comes to bitmaps, with Kitty i've got true moves, and with any new graphics protocol, i would hope for the same (and even with kitty's move, i can't use it very often due to other problems, see #1803 and #1395).

but i've got big hopes for DEC[EF]RA! need to experiment.

[dankamongmen]

looks like it might be sufficient to check for 28 in the Device Primary Attributes result.

[christianparpart]

looks like it might be sufficient to check for 28 in the Device Primary Attributes result.

Exactly, Mr.Robot.

[dankamongmen]

DECERA doesn't appear to erase sixels in at least XTerm =[

[dankamongmen]

ED (Erase Display) does seem to apply to sixels, but only gives us complete display, below cursor, or above cursor.
EL (Erase Line) does seem to apply to sixels, but gives us only complete line, left of cursor, or right of cursor

[dankamongmen]

EA (Erase Area) would presumably be perfect, but doesn't appear implemented very widely =[

[dankamongmen]

ECH looks like it might work! it's not as good as DECERA would be, but it does appear to wipe out sixel, and do so from the cursor, and through a controllable length. yessssssssssssssssssssss

[dankamongmen]

though, i was thinking about this, and it's all irrelevant. we don't go printing a ton of spaces atop sixels to erase them; we go printing whatever was in the damage buffer. otherwise, we'd just have to draw the latter for a total of two draws per cell.

• "but dank," we thought, "this would still work if the damage buffer just had a lot of clear cells. ought we microoptimize for that case?"
• "bah, other dank, who cares? that's not so frequent of a case. if we at least covered strings of every glyph, then, maybe, but this is just (uncolored) spaces"
• "but dank", we continued, "we can actually do that, right? with repeat character, from terminfo's rep"
• "don't be a maroon, other dank, we'd need identify such regions, and by then you might as well have just written them out"
• "at render time, dank, sure -- though the idea that saving a byte of output is multiplied in impact might say otherwise. but what about at raster time? all you need do is lookahead into data you're about to write if you don't find such a region. there's no extra cache misses, and the work will surely be hidden under the AMAT. then it's just emit once, and use CSI Ps b, Ps=N, which at 4 + logN bytes beats 6 reps or more, and stomps Sixels just fine. you can even use CSI Ps X, Ps=N to beat just 5 spaces, though i'd probably just want to rely on a single escape's support."
• "not too shabby, dank the third, and it makes us think--"
• "[danks 2, 3, and 4 in unison] if we did perform it at render time, we could use uplinks to find rectangular regions in O(1)"
• "danks, c'mon, remember? no rectangular replace char support atop sixels"

that original dank, such a buzzkill!

[christianparpart]

DECERA doesn't appear to erase sixels in at least XTerm =[

This sounds like a bug in xterm? Can it be fixed?

[dankamongmen]

DECERA doesn't appear to erase sixels in at least XTerm =[
This sounds like a bug in xterm? Can it be fixed?

does contour erase sixels with DECERA? i didn't test beyond XTerm. the documentation at vt100.net didn't seem to state explicitly one way or the other.

like i noted later, i don't need DECERA in any case, since i changed things up two months back or so to simply reprint the cells underneath the sixel, which annihilates it while putting up the necessary backglyphs. so it doesn't buy me anything. i could possibly make use of DECFRA in the future, but i can't yet. using it with spaces, if those knocked out the sixel, would seem functionally equivalent to DECERA, so i'd just use that for that case.

let me go take a look at the XTerm code surrounding DECFRA and see if there are any indications...

[dankamongmen]

if it was going to happen, it would presumably happen in ScrnWipeRectangle(). ScrnWriteText() calls chararea_clear_displayed_graphics(), let me see if tucking the latter into the foremost solves this problem. if so, i'll send it off as a patch to Grandmaster Dickey, and we'll see what happens.

[dankamongmen]

ScreenFillRectangle(), rather

[dankamongmen]

sweet, my patch worked immediately. i'll send it on out.

[christianparpart]

does contour erase sixels with DECERA? i didn't test beyond XTerm. the documentation at vt100.net didn't seem to state explicitly one way or the other.

Of course it does (in contour). ED is erssing it all too without mentioning Sixel, doesn't it.

Also, i am not sure the spec mentions that char writes are replacing image cells do they?

[dnkl]

@dankamongmen no intentions, up to this point at least. Simply because I'm not aware of anyone using them. If notcurses starts using them, I'll reconsider.

(assuming there's consensus on how they should interact with sixels...)

[christianparpart]

tmux can do, IIRC. I noticed that because I initially implemented them buggy.

On the other hand are we currently talking about a chicken'and'egg problem. I think they are doing good, so I think they deserve to be implemented.

(I am going to verify my claim as soon as I. At a computer).

Cheers ;-)

[dnkl]

tmux can do, IIRC

If I'm not mistaken, tmux only emits them when running on a VT420 level emulator, or newer (instead of e.g. checking for "Rectangular Editing" in the primary DA respone. If so, then adding only these escapes to foot wont be enough, since there are many other unsupported VT420 escapes.

That said, I think we can still add them, if e.g. notcurses wants them.

[dnkl]

@dankamongmen btw, I tried your ncplayer + DECFRA example (from #1740 (comment)) in XTerm 370, and it seems it now erases the sixel:

                       Patch #370 - 2021/11/13
...
* modify  DECERA  and  DECFRA  to  erase  corresponding area in SIXEL
  graphics  (patch  by  Nick  Black, notcurses #1740, vt340test #16).
  Also modify DECSERA.

[dankamongmen]

• modify DECERA and DECFRA to erase corresponding area in SIXEL
  graphics (patch by Nick Black, notcurses use DECFRA to update glyphs underneath transparent graphic #1740, vt340test Background colors aren't working properly #16).
  Also modify DECSERA.

yep =] i'm nick black =]

[dnkl]

yep =] i'm nick black =]

🤣 aye, I'm aware of that. But:

alright, it is imperative that that patch not be applied, and that the current behavior be preserved. i can pick up a big win from this.

... and I didn't see a conclusion being reached in hackerb9/vt340test#16.

But, having DECERA and DECFRA erase sixels makes sense, and is consistent with other similar escapes.

I'll get started on an implementation for foot.

[christianparpart]

Nice @dnkl , looking forward to it. (I also implement them and expose it also regardless of VT identification).

WRT tmux we could file a ticket to also respect rectangular feature exposure through DA1 in tmux.

[dnkl]

Re. DECCRA; I agree with @christianparpart that, at least according to the spec, SGR attributes are copied as well, along with the characters.

[dnkl]

I'll get started on an implementation for foot.

https://codeberg.org/dnkl/foot/pulls/864

[dnkl]

WRT tmux we could file a ticket to also respect rectangular feature exposure through DA1 in tmux.

@christianparpart tmux recognizes the non-standard terminfo capability Rect. When present, it will use DECFRA even if the DA responses don't indicate VT420 level support.

Note that it's a string capability (and not a boolean, as I first thought). See https://codeberg.org/dnkl/foot/commit/375441a99bb8a111c8a21d120e447063e49b34b9

[christianparpart]

@christianparpart tmux recognizes the non-standard terminfo capability Rect. When present, it will use DECFRA even if the DA responses don't indicate VT420 level support.

Note that it's a string capability (and not a boolean, as I first thought). See https://codeberg.org/dnkl/foot/commit/375441a99bb8a111c8a21d120e447063e49b34b9

Why does tmux keep inventing new terminfo entries. @dnkl please also advertise via DA1 at least. What you ultimatively want is:

• DECFRA - fill area
• DECERA - erase area
• DECCRA - copy area

The ones I have not yet implemented but do consider useful (i.e. will do soonish):

• DECCARA - change attribs
• DECRARA - reverse attribs (not all, checks vt100.net)

IMHO useless ones (subjective):

• DECRQCRA - request checksum of area (nice, but honestly I don't think there's any use)

You can find them all documented at: https://vt100.net/docs/vt510-rm/contents.html

I think I should probably add Rect to my terminfo though, too. Thanks for the pointer @dnkl :)

[dankamongmen]

i am currently only looking for 28 in DA1. i'm trying to get away from terminfo, so i might pick up Rect, might not; let me marinate on it for a minute.

[dnkl]

I mentioned the Rect terminfo capability as an alternative to trying to convince tmux to pick up 28 from DA1 (or as an interim solution until they do...).

Obviously, advertising via DA1 is better.

The foot PR linked above implements:

• 28 in DA1
• DECCARA
• DECRARA
• DECCRA
• DECFRA
• DECERA

[dnkl]

Why does tmux keep inventing new terminfo entries

Some of them make sense, imho. For example, the setrgbb and setrgbf (in combination with the Tc flag), as an alternative to having a separate <term>-direct terminfo file.

[christianparpart]

@dankamongmen please don't support Rect, it's wrecked.

[dankamongmen]

but is it the Tc or the RGB capability? terminfo claims the latter.

i was unaware of setrgb{bf}, sweet

[dnkl]

@dankamongmen RGB tells you the terminfo is a *-direct variant, and that the regular setab/setaf capabilities can be used to set 24-bit colors.

Tc on the other hand (another tmux addition) tells you the terminal is truecolor capable, and that the regular setaf/setab capabilities are used to set colors from the 256-color palette. And that the new setrgbf/setrgbb capabilities can be used to set 24-bit colors.

(I guess technically the Tc flag isn't needed - you can just check for setrgbf/setrgbb. Or, I've missed something).

[dankamongmen]

oh! if i understand what you're saying correctly, we're about to have much better tmux support

[dankamongmen]

(I guess technically the Tc flag isn't needed - you can just check for setrgbf/setrgbb. Or, I've missed something).

i've reached the same conclusion regarding ccc and initc.

[dnkl]

RGB tells you the terminfo is a *-direct variant, and that the regular setab/setaf capabilities can be used to set 24-bit colors.

Just to make things absolutely clear... you cannot use setaf/setab to set a 256-palette color:

% TERM=xterm-direct infocmp -x|grep setaf
	setaf=\E[%?%p1%{8}%<%t3%p1%d%e38:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m,

[dankamongmen]

tmux/tmux#2370 interesting stuff going on here. setal?

[dnkl]

tmux/tmux#2370 interesting stuff going on here. setal?

Appears to be a way to set Kitty undercurly RGB colors:

% TERM=tmux-direct infocmp -x|grep setal
	setal=\E[%?%p1%{8}%<%t5%p1%d%e58:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m,'

(58 is the SGR parameter to set the underline color in Kitty)

But it's somewhat interresting... I only saw it in tmux-direct. Not in any of the *kitty* terminfos.

[j4james]

Just FYI, my understanding is that extension 28 is implicit for terminals at level 4 and above. The VT420, VT510, VT520, and VT525 all support the rectangular area operations, but none of them report extension 28 as far as I know. So technically I think it should only be expected on terminals at level 3 and below - anyone claiming to support level 4 should support these operations regardless.

That said, the reality is that you're going to get some TEs (Gnome/VTE being one well known example) that claim to have level 4 or 5 support while not actually implementing most of that functionality. But if you rely on extension 28 being reported before you make use of any rectangular operations, you're going to miss out on a few terminals that do support them (perhaps not ones you'd care about though).

It's also worth mentioning that XTerm's implementation of these functions is different from everyone else (specifically, anything involving the default attributes). I don't want to say it's wrong, because I don't know for sure, but it seems likely that's the case. Amongst the others there's also a bit of variation, but it's usually in edge cases that I suspect wouldn't affect you.

[dankamongmen]

my only plan for rectangular editing at the moment is to use it to quickly clear (large) sixels when most of the space underneath them is blank, so if a terminal doesn't advertise sixel support, there will be no attempt to use rectangular editing. i would hope that anything advertising sixel with '4' is advertising rectangular edits with '28' when they're supported, though i have no real reason to believe that (and indeed you seem to actively contradict that happy notion).

[dankamongmen]

(the corollary that i would never be using rectangular editing in the presence of kitty graphics is indeed correct, for now)

[dankamongmen]

by the way, newest notcurses-info indicates rectangular editing support via rect+ in the first line of capabilities:

[dankamongmen]

huh that sure doesn't look like 0 bitmap emissions to me, argh, another day another bug

[dankamongmen]

huh that sure doesn't look like 0 bitmap emissions to me, argh, another day another bug

fixed in #2507

[j4james]

i would hope that anything advertising sixel with '4' is advertising rectangular edits with '28' when they're supported

In that case, I think the terminals that would be affected are RLogin and MLTerm. Last I checked, neither reported extension 28, although they both support the rectangular operations. MLTerm should really be advertising 28, since it's level 3, but RLogin is level 5, so extension 28 is implicit (at least that's my understanding).