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