idea.ts

type CharDataNew = [
  number,  // flags 1 - current flags
  number,  // flags 2 - store missing RGB values
  number   // content - UTF32 char or pointer to combined string (at the end of the memory)
]

type SomeType = null; // to be implmented

/**
 * memory layout:
 * | CharDataNew | CharDataNew | ..cols | pointer target segment (combined chars) |
 * on resize:
 * | CharDataNew | CharDataNew | ..cols + new | moved: pointer target segment (combined chars) |
 * => copy mem, if to small
 * => fix local pointers of combined chars (rare case)
 */
class BufferLine {
  private _memory: Uint32Array;
  constructor(public cols: number, ch?: CharDataNew, public isWrapped: boolean = false) {
    this._memory = new Uint32Array(this.cols * 3);
  }
  getData(index: number): SomeType { return null; }
  setData(index: number, value: SomeType): void {}
  public insertCells(pos: number, n: number, ch: CharDataNew): void {}
  public deleteCells(pos: number, n: number, fill: CharDataNew): void {}
  public replaceCells(start: number, end: number, fill: CharDataNew): void {}
  public resize(cols: number, fill: CharDataNew): void {}
}

Pro:

• no extra storage objects needed
• memory is at hand, all self containing (good locality, eassy to carry around)
• no ref stuff outside of the line with complicated/expensive tracking, a ref is only valid within a line
• easy GCable

Con:

• resize is abit more exp, needs to fix local pointers after enlarging and copy mem if to small

Some possible memory models for a buffer line. The summaries marked with ==> only contain stuff that will be quite different from the others (penalty for combining chars not listed as will occur in all models).

• uint32 with RGB attr pointer

|      uint32     |      uint32     |
|  9  |   UTF32   | flags  | fg/bg  |
                               |
                               +
                  | x  |     fg     | x  |     bg     |

Example row with 100 cols:
   ascii with default colors               - 800 bytes
   5 non RGB color changes                 - 800 bytes
   5 RGB color changes                     - 840 bytes
   2 combining high + 5 RGB color changes  - 1040 bytes
   all different RGB                       - 1600 bytes
   2 combining high, all different RGB     - 1800 bytes

==> initial moderate memory usage, doubles for rare cases
==> RGB attr pointer, hard to find already used ones to reuse them (ref counter? tree?)
==> runtime penalty for RGB data to insert/resolve pointer

• uint32 all in cell slot

|      uint32     |      uint32     |      uint32     |
|  9  |   UTF32   | f1 |     fg     | f2 |     bg     |

Example row with 100 cols:
   ascii with default colors               - 1200 bytes
   5 non RGB color changes                 - 1200 bytes
   5 RGB color changes                     - 1200 bytes
   2 combining high + 5 RGB color changes  - 1400 bytes
   all different RGB                       - 1200 bytes
   2 combining high, all different RGB     - 1400 bytes

==> initial high memory usage, overall quite stable, smaller for rare cases than others
==> no attr indirection, only index + bit shift
==> no specific runtime penalty

• uint16 with char and attr pointer

|     uint16     |     uint16     |
        |                |
        |                +
        |        |     uint32     |    uint32     |
        |
        +
| width |  len   |...             |

Example row with 100 cols:
   ascii with default colors               - 400 bytes
   5 non RGB color changes                 - 440 bytes
   5 RGB color changes                     - 440 bytes
   2 combining high + 5 RGB color changes  - 1040 bytes
   all different RGB                       - 1200 bytes
   2 combining high, all different RGB     - 1800 bytes

==> small initial memory usage, can grow 5 times for rare cases
==> all attr as pointer, again hard to find already used ones
==> runtime penalty on all cells for attr insert/access
==> runtime penalty for codepoints > 8192