re: refute my own batching hypothesis -- blend state, not linkage

Last iteration I proposed that the two sweeps share one indices=8 draw
because ptloop01 links to ptloop02, and said testing it needed a
loading-screen capture I lack. Wrong twice: a linked pair was already in
every capture, ptbtn00 -> ptbtn00f.

Measured: ptbtn00f is drawn ALONE in 899 (f6b) and 1441 (f6) draws and
batched in ZERO, while the sweeps pair up in 1092 and 1744. Linkage does not
batch. The constraint is blend state -- ptbtn00f is additive and its linked
partner alpha-over, which cannot share a draw. The sweeps batch because both
are additive on one page.

Page+blend is necessary but not sufficient: 8154/alpha-over appears as two
separate draws in a single frame, 2108 such draws in f6b. This removes a
wrong cause rather than supplying a batching rule.

Extends read_draws.py to preserve draw grouping (draw index and quad count
per draw); check_labels.py still passes unchanged as a regression control.

Refutation attempt on the port's 0x3002/0x3003 menu-item reading: survives.
958 of 970 stems contain "btn"; the 12 exceptions are psselect_slot and
psselect_slot_blank, which are menu rows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/batching-is-blend-not-linkage.md

@@ -0,0 +1,61 @@
+# 🔴 Refuted — the sweeps are batched by **blend state**, not by being linked
+
+**Question:** are two linked records drawn in the same GPU draw call?
+
+**What the human looks at:** nothing — this kills a hypothesis of mine before it
+reaches anything user-visible.
+
+**What this does NOT cover:** F5's code route, still open.
+
+**Instrument:** ⟨capture⟩ ×2, read with `read_draws.py` (now preserving draw
+grouping).
+
+## The hypothesis, and it was mine
+
+Last iteration I noticed `ptloop01 --focus_link--> ptloop02` and suggested that
+the two sweeps share one `indices=8` draw **because they are linked**, rather
+than because they share a texture page. I recorded it 🟡 with the experiment
+named, and said it needed a loading-screen capture I do not have.
+
+**That was wrong twice over.** A linked pair was already in every capture:
+`ptbtn00 --> ptbtn00f`.
+
+## Measured — the linked pair is NEVER batched
+
+| | `ptbtn00f` drawn **alone** | batched with anything |
+|---|---|---|
+| `f6b` | **899 draws** | **0** |
+| `f6` | **1441 draws** | **0** |
+
+Against the sweeps, which pair up in **1092** and **1744** draws respectively.
+
+So linkage does not cause batching. **The constraint is blend state:**
+`ptbtn00f` is drawn additive (`0x01010101`) while its linked partner is
+alpha-over (`0x07010701`), and two different blend states cannot share one draw.
+The sweeps batch because they are **both additive on one page**.
+
+⚠️ Page + blend is **necessary, not sufficient**. A single settled frame carries
+`8154`/alpha-over as *two separate* draws (draws 5 and 7), and the census counts
+2108 such draws in `f6b`. Submission order and intervening state changes still
+split them; this finding removes a wrong cause, it does not supply a complete
+batching rule.
+
+## Refutation attempt — the port's `0x3002`/`0x3003` menu-item reading
+
+Their rule treats that kind as the class menus are built from. I asked whether the
+class is uniformly menu-row-shaped, disc-wide:
+
+```
+0x3002/0x3003 elements: 970 across 91 name-stems
+stems containing "btn": 958 of 970  (98.8%)
+the 12 exceptions: psselect_slot (6), psselect_slot_blank (6)
+```
+
+**It survives.** The only non-`btn` members are save-slot rows, which are menu
+items. Recorded as an attempt that did not land.
+
+## Reach
+
+The batching result is about two captures of one screen. It shows linkage is not
+sufficient and blend state is a hard constraint; it does not establish what else
+splits a draw.