Consider changing null cell data to all zeros

On resize when the cols in the terminal increases, we fill in cell data at the end of the buffer here:

https://github.com/xtermjs/xterm.js/blob/1431210ecddebcc180002f1277473191abbe8694/src/common/buffer/BufferLine.ts#L353

This is doing a relatively large amount of work as each individual index of the cell needs to be set directly off the cell object:

https://github.com/xtermjs/xterm.js/blob/1431210ecddebcc180002f1277473191abbe8694/src/common/buffer/BufferLine.ts#L218-L220

If we made “null cell data” all zeroes, we could then use a single typed array fill call, at least when the fill data is all default background and foreground colors which is the typical case.

This would involve either adapting the code so null cells have a width of 0 instead of 1, or change a cell’s width=1 to actually be encoded as 0 << Conten.WIDTH_SHIFT:

https://github.com/xtermjs/xterm.js/blob/1431210ecddebcc180002f1277473191abbe8694/src/common/buffer/CellData.ts#L83

[jerch]

Yeah - that summarizes it pretty well, sadly. And putting such a hack in place is dangerous, in several months no ones remembers exactly it was all about and boom 🙈

[jerch]

Ah well I meant it this way - if we just fill all excess uint32 slots from current NULL_CELL.CONTENT value it should just work, because it will just contain (1<<22) in all slots, thus also for FG and BG, where it is technically wrong. But it is not harmful, as the FG/BG value dont eval the lower 3 bytes (RGB section, thus bit 1…24) since CM_MASK is zero. (For CM_MASK==0 the RGB section has no meaning in FG/BG.) I know thats quite hacky, thus my warning about a proper doc note, if we’d go that route.

In summary we’d only need to do:

• fill excess uint32 slots from current NULL_CELL.CONTENT
• place proper doc warning about “width in NULL_CELL.CONTENT must always map into non-evaled regions in FG & BG”
• and better never touch NULL_CELL repr again (to avoid clashing with that rule)