gramps/LlamaCasty
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: update HANDOFF + MyMistakes.md — take-23 stride fix landed, chat missing from recording, landmines refreshed

Browse Source
This commit is contained in:
Llama Chile Shop
2026-09-08 12:11:45 -07:00
parent f6802c7124
commit 5175c1c8c9
2 changed files with 37 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MyMistakes.md
+15 -19
View File
@@ -15,31 +15,27 @@
## 🔬 Recipes registry
### ⚠ SPIN GUARD TRIGGERED → RESOLVED (take-21, 22) — web overlay transparency + scale
### ⚠ SPIN GUARD TRIGGERED → RESOLVED (take-21, 22 broke, 23 fixed) — web overlay transparency + scale
**Take-19 (`0f441d8`): FAILED.** Attempted to feed the compositor the FULL canvas instead of the
alpha crop. User verdict: "didn't work at all — broke additional crap." Reverted (`1295e0e`).
The crop→UniformToFill zoom insight was RIGHT, but the commit ALSO introduced `CanvasRing` (8-deep
full-canvas buffer ring) alongside the fix — the ring reuse poisoned the paste cache (array identity
collisions via the Epoch mechanism), causing additional breakage beyond the transparency issue.
full-canvas buffer ring) alongside the fix — the ring reuse poisoned the paste cache.
**Take-21 (`e002847`): PARTIAL FIX — transparency confirmed, but widget appeared shrunk and offset.**
Root cause of transparency: `bccdb48` introduced `FindContentBounds` alpha cropping; the CROP was
fed to the compositor (`session.LatestFrame = VideoFrame(cropW, cropH, outPixels)`). `UniformToFill`
then zoomed the opaque crop content to cover the whole element rect, covering whatever was beneath
(webcam). Fix: keep the single `CanvasScratch` buffer (no ring), feed the FULL `1920×1080` canvas
to the compositor (`session.LatestFrame = VideoFrame(pixW, pixH, pixels)`), use the alpha crop only
for the preview `WriteableBitmap`. Transparent margins revealed layers beneath — BUT the widget
content appeared at ~1/3 scale and misplaced: the compositor's `UniformToFill` used `src=1920×1080`
for a WebSource element sized 703×389, computing scale=0.366. The preview showed `Stretch="Fill"` with
the CROPPED `PreviewBitmap` — completely different math, hence "looks correct in preview, wrong in
recording."
**Take-21 (`e002847`): PARTIAL FIX.** Feed full canvas, transparent margins revealed — but the
widget appeared shrunk and offset. `UniformToFill` used `src=1920×1080` for a 703×389 element
→ scale=0.366. The preview used `Stretch="Fill"` on the CROPPED bitmap — different math.
**Take-22 (`ed9d7c1`): FULL FIX.** `VideoFrame` gets `CropBounds?: (X,Y,W,H)` metadata. The full
canvas still goes to the compositor, but `BlitContentRaw` detects `CropBounds` and switches from
`UniformToFill` to Fill-style scaling (stretch to cover, no aspect preservation) using the actual
crop dimensions. This matches the preview's `Stretch="Fill"` on the crop. Widget content now fills
the element rect at the correct position; transparent margins still reveal layers beneath.
**Take-22 (`ed9d7c1`): BROKE IT.** Added `CropBounds` metadata but the pixel index in
`BlitContentRaw` used `w = cbW` (crop width, e.g. 800) instead of `src.Width` (canvas stride
= 1920) for buffer indexing. Since `s = src.BgraPixels` is the FULL canvas buffer, multiplying
by crop width instead of canvas stride computed completely wrong memory offsets — garbage pixels,
"original content destroyed." Reverted.
**Take-23 (`f6802c7`): CORRECT FIX.** `BlitContentRaw` CropBounds path now uses `src.Width`
(canvas stride = 1920) for ALL pixel indexing. The Fill-style scale centers the crop content
in the element rect. Transparent margins of the full canvas are preserved and reveal layers
beneath. `srcStride` is explicitly named `srcStride = src.Width` to prevent this mistake recurring.
### Shrink / re-encode an image for the README (screenshots → small hero image)