Upload only the atlas rows new glyphs were drawn into, not the whole atlas

Any new glyph re-uploaded the whole 2048x2048 atlas: 4 MB copied into the
transfer buffer and then to the texture, about half a millisecond of CPU on
the frame, and the GPU's copy on top. Glyphs fill the atlas pen-style, a band
of rows at a time, so a frame's new glyphs sit in a band a cell or two tall.

The atlas now keeps the rows drawn into since the last upload (cachedGlyph
widens them by each raster's rows: plain glyphs, ligature strips, tagline and
grip glyphs alike), and uploadAtlas copies and uploads just those rows, at the
same offset in the transfer buffer as in the stage; the texture keeps the
rest. A reset (a font, size or tagline change) marks every row, as
the texture's first upload does, so those still send the whole atlas. A test
replays uploads over glyphs of every kind and a reset, and checks that no row
outside the dirty rows ever differs from what the texture holds.

Hidden captures of 27 layouts, including new glyphs typed and printed, font
and size switches, and Ligatures off and on, are byte-identical to before.

Over 10 interleaved rounds (160x50 cells), a frame that draws new glyphs
spends 12-50 us uploading instead of about 0.5 ms: a terminal printing twelve
new glyphs a line goes from 1.04 to 0.55 ms of renderFrame CPU on such frames
(-34% over the scenario's frames, 9 of 10 rounds faster, -20% to the GPU
fence), a typed glyph's frame from 0.89 to 0.38 ms, and opening a file of 600
new glyphs from 9.1 to 8.7 ms. The first frame and a font size change still
upload everything and cost what they did; other frames are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

0 files changed, 0 insertions, 0 deletions