jerch

@PerBothner Drafted a quick demo PR to test the idea above (see #48). Ofc this cannot be used until the serialize addon sees major changes. Also the image re-encoding is...

There is prolly a simpler solution possible - the image addon currently always draws on top of FG/BG content not erasing it. Thus it should be possible to keep most...

Addendum regarding a proper protocol: It turns out that IIP has all the basics to guarantee a stable cell coverage, if dimensions are set with plain numbers denoting row/col extend,...

The QOI image format might be a good choice for image serialization, as it provides very fast encoding/decoding with okish compression rate. Some early numbers testing QOI decoding speed with...

@PerBothner Well, thats what my playground branch does atm: https://github.com/jerch/xterm-addon-image/blob/a23a3725fa16368a4e59d7cd9e0ac3e6b5fd75be/src/ImageAddon.ts#L322-L329 and the encoding speed is underwhelming - it takes ~70ms for an image of 420x420 pixels. To me this seems...

Haha - stumbled over the next hassle - fast bytearray to string conversion. I really dont get it why JS has no fast `Uint8Array.toByteString` method, thats literally a malloc +...

@PerBothner Imho QOI is the right decision, as it is able to serialize things 2.5 - 5x faster than with browser methods (see full roundtrip numbers and explanation here: https://github.com/jerch/xterm-addon-image/pull/48#issuecomment-1484145335).

@PerBothner Hmm, currently the serialize plugin is pretty slow, it takes ~170 ms to serialize a 10k scrollbuffer of 87 cols (tested with `ls -lR /usr/` generating ~500kB of string...

Well the issue with the serialize addon is simple - it is convoluted for no good reason, so I dont like to alter things there and introduce an interface on...

> For grapheme clusters, why do you need to store codepoint attributes, assuming you're using either dom or canvas renderers? The browser takes care of that. You may need to...