Any width change currently drops every image in the buffer (TerminalBuffer.Resize → ClearImages), so widening a window loses your pictures. The reasoning in the comment is right about reflow shuffling tiles into a mosaic — but that only applies to lines that actually re-wrap, and it's dropping images on every resize including the common one.
I think the real fix is a storage change, and I'd rather ask before building it.
Right now a decoded bitmap is scattered across cells, each holding an image id and a tile coordinate — so the cell grid is the picture's only storage, and anything that truncates cells destroys pixels. If instead a line holds a placement — image id, anchor column, natural width in cells, source rect — the renderer draws min(width, line width) and resize becomes a no-op: narrow shows less, widen shows more, nothing is destroyed. It also makes Kitty graphics mostly a decoder rather than a second architecture, since that protocol already works this way.
The question: that changes BufferCell.Image / ImageCol / ImageRow. Since BufferCell is a struct, a cell copied out of a line has no idea which line or column it came from, so these can't just become lookups into the line's placements — the geometry has to move regardless. Two options:
- Line-level accessor. All three go away, replaced by something like
line.PlacementAt(col). Cleanest, and the two repos move together.
- Cell keeps the image id only.
cell.Image and IsImage keep working, because identity is one int in the cell; ImageCol / ImageRow move to the line, since geometry is what a placement owns. Partial source compatibility for the cost of keeping one field.
Iciclecreek's DrawImageRun reads all three, so either way the two repos move together — option 2 just keeps more of the call sites intact.
Is cell.Image worth keeping as identity-only, or would you rather it moved to the line entirely?
Any width change currently drops every image in the buffer (
TerminalBuffer.Resize→ClearImages), so widening a window loses your pictures. The reasoning in the comment is right about reflow shuffling tiles into a mosaic — but that only applies to lines that actually re-wrap, and it's dropping images on every resize including the common one.I think the real fix is a storage change, and I'd rather ask before building it.
Right now a decoded bitmap is scattered across cells, each holding an image id and a tile coordinate — so the cell grid is the picture's only storage, and anything that truncates cells destroys pixels. If instead a line holds a placement — image id, anchor column, natural width in cells, source rect — the renderer draws
min(width, line width)and resize becomes a no-op: narrow shows less, widen shows more, nothing is destroyed. It also makes Kitty graphics mostly a decoder rather than a second architecture, since that protocol already works this way.The question: that changes
BufferCell.Image/ImageCol/ImageRow. SinceBufferCellis a struct, a cell copied out of a line has no idea which line or column it came from, so these can't just become lookups into the line's placements — the geometry has to move regardless. Two options:line.PlacementAt(col). Cleanest, and the two repos move together.cell.ImageandIsImagekeep working, because identity is one int in the cell;ImageCol/ImageRowmove to the line, since geometry is what a placement owns. Partial source compatibility for the cost of keeping one field.Iciclecreek's
DrawImageRunreads all three, so either way the two repos move together — option 2 just keeps more of the call sites intact.Is
cell.Imageworth keeping as identity-only, or would you rather it moved to the line entirely?