The in-frame geometry fraction, and the four things it cannot see

It covers four scene families and not the other five. parametric_curve, lsystem, star_pattern and spectrum build a CPU-side segment list and stroke it through one shared LineRenderer, and the measurement is taken there — the share of total drawn line length, segments and arcs alike, that lands inside the render target’s world rectangle [-aspect, aspect] x [-1, 1], computed inside LineRenderer::draw from the geometry and an aspect it already holds. An arc contributes |sweep| * radius, clipped as 64 sub-arcs judged by their own chords (Plan 0087 Phase 2) — which matters because since that plan a mandala’s whole figure is arcs, and a measure blind to them would report every arc-drawing preset as better-framed than it is (ADR-0083). fragment_field, reaction_diffusion, attractor, swarm and emitter build no segment list, are not covered at all, and keep pixel coverage. The split follows whether a scene rasterizes a segment list — not a line an author would guess — so this is not an engine-wide gate and no number it prints says anything about half the library.

It exists because pixel coverage cannot see a figure whose tips leave the frame. A comb roots every bar on a shared baseline and a corona roots every spoke at a centre, so clipping the tips costs a rounding error of lit pixels: Plan 0058 measured two over-scaled presets scoring above the lowest legitimate content, where no threshold ordering separates them. Repairing the same two moves this measure by 0.4975 and 0.7788 — 9x and 14x the 0.055 that pixel coverage had between its lowest legitimate preset and a plausible threshold.

Four things it does not see, each of which has its own answer:

• It measures length, not area. Stroke width and the joint extensions are not counted, so a thick stroke leaving the frame is under-counted relative to the picture it actually costs, and a hairline and a 24-px bar of the same length are weighted identically. It is the right measure for overshoot and a poor one for anything else; a stroke-width-weighted version is a different measure with a different failure mode, and it is deliberately not built.
• A figure collapsed to a point scores a perfect 1.0. Zero-length segments contribute to neither sum, and a curve that has degenerated to a dot is entirely in frame, which is all this instrument is asked. Is anything actually drawn is sanity.rs’s question — coverage against the frame’s own ground (ADR-0126) — and the two are complements rather than a progression. A figure drawing nothing reports no fraction at all (None) rather than a zero, for the same reason.
• It cannot tell a deliberately zoomed-in figure from an over-scaled one, because they are the same picture. Rose Zoom (zoom bound to 2.15..3.09) measures 0.3492 and Rose Overflow (scale to 2.84) 0.3659 — they bracket the frozen over-scaled comb’s 0.3563, one just below it and one just above, and both are working exactly as authored. No absolute threshold passes those two and fails the comb; that is why the gate is paired: it compares a configuration against its own repair, never against an absolute floor. Anyone adding assert!(fraction > 0.5) over the library would fail two shipped presets, which is precisely the mistake ADR-0083 catalogues pixel coverage making one axis over.
• It is off in the shipped render path, so it is not a runtime signal. The diagnostic is a thread-local switch (set_extent_diagnostic / take_draw_extent) and the first test in geometry_extent.rs asserts a capture with it on is byte-identical to one with it off. When on, it costs a CPU loop over the segment list per draw — bounded by the renderer’s capacity, but real.

The particle families’ equivalent, if it is ever wanted, is a genuinely different design: they have no segment list and their “figure” is a statistical cloud. It is not this measure with a different input.