terminal: add ScreenFormatter.pin_offsets#12882
Conversation
When you want to know where specific Pins land in formatter output but don't need the full per-byte Pin array, pin_offsets is a lighter alternative to pin_map. The caller supplies a list of Pins to watch and the formatter fills in the byte offset where each one first appears in the emitted output. Internally, PageListFormatter scans the per-chunk Coordinate scratch buffer it already builds for pin_map consumers, so PageFormatter itself is unchanged. pin_map and pin_offsets can be set independently or together; when neither is set, no scratch buffer is allocated. A future caller that needs only a handful of positions can avoid the cumulative pin_map allocation. For a 10MB scrollback that's ~160MB of transient Pin storage traded for ~360KB of per-chunk scratch.
| // track Pins directly. When the caller has asked for a pin_map | ||
| // or pin_offsets we feed PageFormatter a per-byte Coordinate | ||
| // scratch buffer and convert to Pins at the chunk boundary. | ||
| const PointMap = struct { |
There was a problem hiding this comment.
There's an opportunity to hoist up this type and share it between PageListFormatter and PageFormatter:
ghostty/src/terminal/formatter.zig
Lines 834 to 837 in 16f2fdc
... but that will trigger a bunch of test code updates too, and I didn't want to make this initial PR too noisy.
If the pin_offsets idea looks good, I can add another commit here that shares the type, or we can look at it in a separate change.
|
The initial motivation for this capability is a more efficient "slice of the entire screen that's currently visible" search for #12881. |
|
This isn't quite the right shape for the current version of #12881. I'm going to close this now and will revisit as a future optimization. |
1 participant
When you want to know where specific Pins land in formatter output but don't need the full per-byte Pin array, pin_offsets is a lighter alternative to pin_map. The caller supplies a list of Pins to watch and the formatter fills in the byte offset where each one first appears in the emitted output.
Internally, PageListFormatter scans the per-chunk Coordinate scratch buffer it already builds for pin_map consumers, so PageFormatter itself is unchanged. pin_map and pin_offsets can be set independently or together; when neither is set, no scratch buffer is allocated.
A future caller that needs only a handful of positions can avoid the cumulative pin_map allocation. For a 10MB scrollback that's ~160MB of transient Pin storage traded for ~360KB of per-chunk scratch.