ref(opt): scale Clay's arena with the terminal grid - #120
Merged
Conversation
|
Size Increased — +0.1 KB 100.2 KB unpacked |
commit: |
natemoo-re
marked this pull request as ready for review
September 1, 2026 19:11
Clay preallocates its arena from a fixed default of 8192 max elements, so an 80x24 terminal reserved 4.85 MB of linear memory before rendering anything. Element capacity drives nearly all of Clay_MinMemorySize (~600 B/element on wasm32); the measure-text word cache is second-order. Derive the cap from the grid instead: 2x cells, clamped to [2048, 8192]. Leaf elements occupy at least one cell and internal nodes with branching >= 2 can at most double the leaf count, so 2x cells bounds realistic trees while leaving headroom for floating elements and wrapper chains. The ceiling keeps large grids at exactly today's capacity; the floor protects tiny panes. Arena for 80x24 drops 4.85 MB -> 2.39 MB (-51%); 20x5 bottoms out at 1.23 MB; 200x50 is unchanged. Render benches are flat. The capacity setters run at the top of both clayterm_size() and init() so the size the host queries always matches what init consumes, for the first init and for in-place re-init alike: Clay_MinMemorySize prefers the live context's caps and Clay_Initialize inherits them from the old context, so the update() resize flow (#113) sizes correctly in both directions. Verified against a local merge of nm/feat/resize: full suite passes, and renders stay error-free across 80x24 -> 200x50 -> 20x5 -> 132x43 in-place resizes. Exceeding the cap degrades the same way it always has, just at the new boundary: Clay stops opening elements and the frame surfaces an error through RenderResult.errors.
natemoo-re
force-pushed
the
ref/grid-scaled-arena
branch
from
September 1, 2026 20:47
998cef7 to
3205fbd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Clay reserves a fixed arena sized for 8192 elements regardless of terminal size, so an 80x24 pane holds 4.85 MB before drawing anything.
In this PR, we adjust the arena size to match an element cap derived from the grid size: 2x cells, clamped to [2048, 8192]. Every leaf takes at least one cell and internal nodes with 2+ children at most double the leaf count, so 2x cells bounds realistic trees with headroom for floating and wrapper chains. The ceiling preserves today's capacity on large grids; the floor protects tiny panes. 80x24 drops to 2.39 MB (-51%); 200x50 is unchanged; render benches are flat.
The cap is set at the top of both
clayterm_size()andinit()so the size the host queries always matches what init consumes. That's what lets this compose with #113 — a resize re-runs both and grows the arena correctly in either direction.