Whether DECFRA/DECERA clear sixel pixel data is terminal-dependent, not standardised. The VT420 spec defines DECFRA as a text-plane operation only. On real VT340 hardware, DECERA did not affect sixel graphics. xterm added sixel-clearing to DECFRA/DECERA in patch #370 (2021), but this is an xterm extension adopted by some modern terminals.
From the VT510 Programmer Reference:
"DECFRA replaces the rectangular area's character positions and attributes with the specified fill character. The fill character assumes the visual character attributes set by the last select graphic rendition (SGR) command. DECFRA does not change the current line attributes."
No mention of graphics plane interaction whatsoever. DECFRA is specified purely as a character-cell operation.
Similarly, DECERA erases "character values and visual attributes" -- text-plane only.
The VT330/VT340 used a separate bitmap framebuffer for graphics (VT330/VT340 Programmer Reference, Chapter 3):
- VT340: 4-plane bitmap (4 bits/pixel, 16 colours from 4096-colour palette), 800x480 pixels
- Text and graphics were rendered on independent planes
- Screen erase (ED 2) erases all planes
- No dedicated "clear graphics plane" escape sequence exists in the VT3xx text-mode spec
From hackerb9/vt340test#16 ("Determine whether DECERA applies to Sixel"):
- DECERA does NOT affect sixel graphics on real VT340 hardware
- EL (Erase in Line) DOES erase sixel graphics on VT340
- This inconsistency is acknowledged: "if DEC was being consistent it would erase sixels as the other erase commands do"
- Text written into a cell overwrites the graphics pixels in that cell (no alpha blending)
xterm extended the VT420 spec to make DECFRA/DECERA clear sixel graphics:
From the xterm changelog, patch #370:
Modified DECERA and DECFRA to "erase corresponding area in SIXEL graphics"
This was driven by:
- notcurses#1740 -- Nick Black's use case for updating glyphs underneath transparent graphics
- hackerb9/vt340test#16 -- empirical VT340 testing establishing that DECERA didn't affect sixel on real hardware
The implementation function is chararea_clear_displayed_graphics() -- it clears
sixel bitmap data within character-cell-coordinate rectangles when DECERA/DECFRA
are invoked.
Design rationale (from community consensus in vt340test#16): even though real VT340 hardware did not have DECERA affect sixels, modern terminal emulators should make rectangular operations affect both text cells AND sixel data for semantic consistency -- treating "mass action" operations as acting on the unified visible surface.
Also modified: DECSERA. Also announced on debian-x mailing list.
| Terminal | DECFRA clears sixel? | Notes |
|---|---|---|
| Real VT340 | No | DECERA/DECFRA are text-plane only |
| xterm ≥370 | Yes | Extended in patch #370 (2021) |
| Windows Terminal | Unknown | j4james implemented sixel (PR#17421) but DECFRA+sixel interaction unclear |
| Konsole | N/A | No DECFRA support (no rectangular area ops) |
| foot | Unknown | Has both sixel and DECFRA but interaction undocumented |
| mlterm | Unknown | Has sixel support, DECFRA support unclear |
The current PR approach is robust:
-
Spaces (primary) -- writing a space character over sixel pixel data clears it in most terminals because text overwrites graphics (confirmed on real VT340 hardware and modern terminals). This is the universal, reliable method.
-
DECFRA (opportunistic) -- used when
TERM_DECFRAis set. On xterm ≥370 this will also clear the sixel graphics layer. On other terminals it at minimum fills the text layer. Belt-and-suspenders.
The spaces-first approach means cleanup works even on terminals where DECFRA doesn't affect the graphics plane. DECFRA is a bonus that may provide more thorough cleanup on xterm and terminals that adopted the same extension.
nicm's observation about DECFRA not clearing to default background:
printf '\033[42m\033[2Jxxx\033[0m\033[32;1;1;100;100$x'
The DECFRA cleared "xxx" text but did not reset the green background because the SGR was reset to default before the DECFRA. ThomasDickey confirmed this is expected -- "background color is absence of color as set by the application."
This does not affect sixel cleanup because:
- We're clearing sixel pixel data, not trying to set a specific background colour
- The spaces we write use whatever the current SGR state is
- Even if DECFRA leaves attributes in place, the visual effect of clearing pixels is achieved by the character fill itself