render: recycle the glyph atlas at a placed-slot count #459

Merged

natsukium merged 2 commits from render/glyph-slot-cap-451 into main 2026-09-25 18:53:34 +09:00

Conversation 0 Commits 2 Files changed 5 +73 -3

natsukium commented 2026-09-25 18:48:46 +09:00

Owner

Copy link

The glyph slot map was emptied only when an atlas sheet filled, so its size tracked glyph area rather than entry count. A producer printing text at many tiny OSC 66 fractional sizings rasterizes each key to a pixel or two, and a 2048² sheet holds millions of those before it recycles, so PTY output alone could grow the map that far.

The sheets now also count as full at 65 536 placed slots and recycle through the same path as a filled shelf, so the frame's second walk and the thrash logging apply unchanged and the hit path is untouched. Per-entry eviction is not possible without leaking sheet space, since the shelf packer frees no single slot. The count is twice what a sheet holds of 8×16 cells, so text at a readable size still fills the sheet first; the map's table stays under 8 MiB.

A test drives more than 65 536 distinct tiny placed glyphs through a 2048² index and checks that the cap, not the sheet, triggers the one recycle, that the placed count never exceeds it, and that the newest glyph survives. Docs: pipeline.md "Atlases", security-model.md "Resource exhaustion", REQ-704, CHANGELOG.

Closes #451

The glyph slot map was emptied only when an atlas sheet filled, so its size tracked glyph area rather than entry count. A producer printing text at many tiny OSC 66 fractional sizings rasterizes each key to a pixel or two, and a 2048² sheet holds millions of those before it recycles, so PTY output alone could grow the map that far. The sheets now also count as full at 65 536 placed slots and recycle through the same path as a filled shelf, so the frame's second walk and the thrash logging apply unchanged and the hit path is untouched. Per-entry eviction is not possible without leaking sheet space, since the shelf packer frees no single slot. The count is twice what a sheet holds of 8×16 cells, so text at a readable size still fills the sheet first; the map's table stays under 8 MiB. A test drives more than 65 536 distinct tiny placed glyphs through a 2048² index and checks that the cap, not the sheet, triggers the one recycle, that the placed count never exceeds it, and that the newest glyph survives. Docs: pipeline.md "Atlases", security-model.md "Resource exhaustion", REQ-704, CHANGELOG. Closes #451

natsukium added 2 commits 2026-09-25 18:48:46 +09:00

render: recycle the glyph atlas at a placed-slot count ... 090b20a7f8

The glyph slot map was emptied only when an atlas sheet filled, so its
size tracked glyph area rather than entry count. A producer printing
text at many tiny OSC 66 fractional sizings rasterizes each key to a
pixel or two, and a 2048² sheet holds millions of those before it
recycles; the map grew with it from PTY output alone.

The sheets now also count as full at 65 536 placed slots and recycle
through the same path as a filled shelf, so the frame's second walk and
the thrash logging apply unchanged. A per-entry eviction would leave
the evicted glyph's pixels allocated, since the shelf packer frees no
single slot. The count sits at twice what a sheet holds of 8×16 cells,
so text at a readable size still fills the sheet first, and it keeps
the map near the sheet's own 4 MiB.

Assisted-by: Claude Code

render: state the slot map's size with its spare hash capacity ... 68e3d4db07

At 65 536 entries the hash table has room for 114 688, so its buckets and control bytes come to about 6.6 MiB, not the 4 MiB the per-entry estimate gave.

Assisted-by: Claude Code

natsukium merged commit 0ec3fff3fc into main 2026-09-25 18:53:34 +09:00

natsukium deleted branch render/glyph-slot-cap-451 2026-09-25 18:53:35 +09:00

natsukium referenced this pull request from a commit 2026-09-25 18:53:35 +09:00

render: recycle the glyph atlas at a placed-slot count (#459)

natsukium referenced this pull request 2026-09-25 19:00:17 +09:00

bench: follow up the 9d1d842f cross-terminal run #405

Commenting is not possible because the repository is archived.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!459

No description provided.