Determine whether DECERA applies to Sixel

[dankamongmen]

from http://vaxhaven.com/images/5/55/EK-VT420-RM-002.pdf p164 (original) p186 (pdf)

Erase Rectangular Area (DECERA)

This control function erases characters from the specified rectangular area in page memory. When an area is erased, DECERA replaces all character positions with the space character (2/0). DECERA erases character values and visual attributes from the specified area. DECERA does not erase line attributes.

Available in: VT400 mode only

Format

CSI	Pt	;	Pl; Pb; Pr	$	z
9/11	3/n	3/11	********	2/4	7/10

Parameters
Pt, Pl, Pb, and Pr define the rectangular area to be erased:
Pt is the top-line border. Pt must be less than or equal to Pb.
Default: Pt = 1.

Pl is the left-column border. Pl must be less than or equal to Pr.
Default: Pl = 1.

Pb is the bottom-line border.
Default: Pb = the last line of the active page.

Pr is the right-column border.
Default: Pr = the last column of the active page.

Notes on DECERA
• The coordinates of the rectangular area are affected by the setting of
origin mode (DECOM).
• DECERA is not affected by the page margins.
• If the value of Pt, Pl, Pb, or Pr exceeds the width or height of the
active page, the value is treated as the width or height of that page.
• DECERA does not change the active cursor position.

---

your mission, if you choose to accept it, is to determine whether or not DECERA applies to Sixel. i've got the following patch outstanding for XTerm:

diff -ur xterm-368/screen.c xterm-368-decera/screen.c
--- xterm-368/screen.c	2021-03-01 03:54:26.000000000 -0500
+++ xterm-368-decera/screen.c	2021-06-26 02:43:34.180469144 -0400
@@ -2550,6 +2550,16 @@
 		}
 	   })
 	}
+	TRACE(("text erasing cur_col=%d cur_row=%d cols=%d rows=%d\n",
+		left,
+		top,
+		numcols,
+		numrows));
+	chararea_clear_displayed_graphics(screen,
+						left,
+						top,
+						numcols, numrows);
+
 	ScrnUpdate(xw,
 		  top,
 		  left - b_left,

but @ThomasDickey is hesitant to apply it without experimental confirmation

[dankamongmen]

oh, this is vt400+-only, huh? i guess it's not going to work on your vt340 then =\

[hackerb9]

Tested and, indeed, DECERA did nothing on the VT340. However, if DEC was being consistent it would erase sixels as the other erase commands do affect sixels. For example, EL, Erase in Line:

(The text in the background is just cat -v cat3.six to make it more clear that a line is being erased instead of this being an image of a cat whose identity has been hidden by a black bar over his eyes.)

[dankamongmen]

when you say "did nothing", you mean "did nothing to sixel or text, because it's not supported on vt340", right? just making sure.

[hackerb9]

Not supported on the vt340.

[christianparpart]

While being at it. I must admit i am actually a big fan of the rectangular functions and do recluse that. It might be worth finding out about the others wrt sixels?

Another stupid question. Why is sixel only on 240/340 and not on the successor models like 510/525?

Wrt conformance i considered sticking to my current behavior but as soon as a specific VT conformance level is selected i should try to adhere to that until undone. (Still thinking about that idea).

[hackerb9]

Another stupid question. Why is sixel only on 240/340 and not on the successor models like 510/525?

This is sheer speculation on my part, so take it with a grain of salt, but you can see DEC's marketing material from around that time showing them making a big push for X terminals for graphics and focusing their text terminals as being cheaper than PCs. PCs had fallen dramatically in price and were able to show better graphics than sixel/ReGIS and, more importantly, display images much, much faster. Of course, neither X nor PCs allowed one to mix classic command line terminals with graphics the way sixel/ReGIS can, but back then it probably didn't occur to people that that mattered. Graphics were cool, "Multimedia" was the buzzword, and everyone knew that text user interfaces were doomed.

Another killer had to have been the baudrate. The VT340 defaults to 9600 and tops out at 19,200 bps. Sixel is a neat trick, but until the baudrate got fast enough, it wasn't usable for anything serious. I haven't seen many contemporaneous applications that output sixel, perhaps the best known was WordPerfect for VMS which allowed previewing print outs, but it was so slow that you wouldn't want to do it very often. I think DEC made their own slide presentation program, but can't find any info on how well it worked. There was a mouse-driven drawing program by S. Mike Dierken that used ReGIS, but I imagine it would have felt unusably slow when the gal in the cubicle next door has a MacPlus running MacDraw.

[j4james]

Tested and, indeed, DECERA did nothing on the VT340. However, if DEC was being consistent it would erase sixels as the other erase commands do affect sixels. For example, EL, Erase in Line:

This is something I've been meaning to discuss, because it's kind of weird the way the DEC terminals handle the interaction of text controls with images. My understanding (from experimenting on the VT240, as well as the results of some of our tests on the VT340), is that the text backing buffer gets completely erased when an image is output (or at least the lines of text covered by the image) . However, the existing rendering of that text remains visible.

For the most part you don't notice the effects of this. You can scroll the page up and down, and the images and text will appear to move in sync, but that's just because it's manipulating the pixel buffer. It starts to fall apart when you try and do something like inserting text in a row (e.g. with ICH). Since that requires re-rendering the content from the text backing buffer (which has already been erased), you'll end up with part of the row being replaced with a run of spaces.

One of the few benefits of this is that you can trick the terminal into displaying both single width and double width text on the same line. Outside of that, though, it seems more of a handicap than a feature, and I suspect most modern terminals would find it very difficult to emulate, so it doesn't seem like something worth encouraging.

The bottom line is I think there's more value in allowing rectangular text controls (like DECCRA) to manipulate both text and images (as I think @christianparpart has suggested before), even though that would most likely not have worked if it were implemented on the VT340. And the same applies to the row-based controls like ICH and DCH. I don't currently support them myself (in terms of shifting images), but I definitely wouldn't suggest TEs not support them, just because they don't work on the VT340.

[jerch]

Sorry for chimming in.
I second, that rect functions should apply to SIXELs, even if it was no concern on older devices. Beside ICH and DCH I would even consider row/col functions to act that way (e.g. things like IL, DL, SR, SL, DECIC, DECDC). This would keep the semantics of those "mass actions" as close as possible to the known behavior as for text content.

[j4james]

Beside ICH and DCH I would even consider row/col functions to act that way

Yeah, I was just mentioning ICH and DCH because they don't work on the VT340. But I know IL and DL actually do work, assumedly because they're implemented by scrolling the pixel buffer rather than re-rendering the text buffer.