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

docs: MyMistakes.md — take-22 full fix for widget scale/position + transparency

Browse Source
This commit is contained in:
Llama Chile Shop
2026-09-08 11:18:12 -07:00
parent ed9d7c1ffc
commit 84aa70f532
1 changed files with 18 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MyMistakes.md
+18 -9
View File
@@ -15,7 +15,7 @@
## 🔬 Recipes registry
### ⚠ SPIN GUARD TRIGGERED → RESOLVED (take-21) — web overlay composites dark over the webcam
### ⚠ SPIN GUARD TRIGGERED → RESOLVED (take-21, 22) — 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`).
@@ -23,14 +23,23 @@ The crop→UniformToFill zoom insight was RIGHT, but the commit ALSO introduced
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.
**Take-21 (`e002847`): FIXED.** Root cause confirmed: `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`. Epoch increments per frame so
array identity stays unique without the ring. The `0f441d8` insight was correct — the ring was the
"additional crap."
**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-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.
### Shrink / re-encode an image for the README (screenshots → small hero image)