Say that FR-DSP-2 is waiting on S6, not that it was rewritten

R5's note said FR-DSP-2 "was rewritten rather than implemented". It was
not: the clause still demanded viewport tiling, the matrix listed it
unbuilt, and frame-budget.md's rewrite had been proposed and never
applied. Decided 2026-09-19 to keep it as written until S6 runs on a
mid-range Android device, because the measurement that argues against
tiling was taken on a discrete desktop GPU and the clause exists for the
device whose memory the image exceeds. Both notes now say that.
This commit is contained in:
2026-09-19 12:25:03 +02:00
parent 95458356da
commit d259c0d4bb
+16 -2
View File
@@ -83,8 +83,11 @@ results.
**On R5's tiling.** An earlier draft added two clauses to R5's criterion: *"only visible tiles are
computed; panning recomputes only newly exposed tiles"*. They have been struck, and the reason is
the same one FR-DSP-2 was rewritten for rather than implemented:
[frame-budget.md](frame-budget.md) measured it.
the one [frame-budget.md](frame-budget.md) measured — the same measurement that argues FR-DSP-2
should be rewritten rather than implemented. FR-DSP-2 itself has **not** been rewritten: it
stands as written until spike S6 has run on constrained Android hardware, because the desktop
measurement cannot speak for a device whose GPU memory the image exceeds (decided 2026-09-19;
see the note under FR-DSP-2).
R5's actual demand is met and tested. The display pipeline works at viewport resolution:
`Framing::view` shrinks the sampled region while the render target keeps its size, so zooming raises
@@ -563,6 +566,17 @@ processes approximately 2000px of data, not 60MP.
intersecting the viewport are computed. Panning computes only newly exposed tiles; already-valid
tiles are reused.
> **Status, 2026-09-19: as written, unbuilt, and waiting on S6.** The interactive path does not
> tile, and [frame-budget.md](frame-budget.md) argues it should not on the reference desktop: a
> fused pass over a 4K viewport costs 4.5 ms of a 16 ms budget, a tile cache could save at most
> that, and the one stage over budget is a convolution that tiling makes worse. That argument is
> a desktop measurement. The case this clause was written for — an image larger than the GPU
> memory of a mid-range Android device (NFR-RES-2, ARCH §6.2) — has not been measured, and S6 is
> the spike that measures it. Until it runs the clause stands, so that a decision is taken on a
> number from the device the clause is about rather than from the one it is not. If S6 finds the
> fused pass inside budget there too, FR-DSP-2 becomes a scheduling concern for export and
> thumbnailing as frame-budget.md proposes; if not, S6 names the stage to tile.
**FR-DSP-3 — Interactive latency.** Moving a slider updates the visible region within one frame
budget at proxy resolution. When a full-resolution result is needed it is computed
asynchronously, and the proxy result remains on screen until it is ready.