megboyzzandClaude
f8744f0392
Shim_AndroidBitmap_lockPixels handed the guest a NULL pixel pointer whenever the real buffer lived outside the guest region, on the documented assumption that "texture decode FROM a Bitmap ... reads pixels via other means, not by writing through this specific pointer". Measurement disproved that assumption. The glyph atlas path is exactly a read through this pointer: AndroidBitmap_lockPixels rc=0 hostAddr=0x... -> guest=0x0 bitmap 1024x1024 stride=4096 format=1 (RGBA_8888) 1024x1024 is precisely the atlas size independently derived from the glyph UVs (u1 = 35/1024 for a 35px glyph), which is why glyph positions, sizes, pen advance and UVs all measured correct while the pixels were coloured noise: BitmapGraphics rendered the glyphs fine, the guest asked for them, got nothing, and uploaded guest address 0 as the font texture. Fixed with a bounce buffer - real pixels copied into a guest-visible buffer on lock, copied back and freed on unlock. The copy-back also closes the write direction the original comment called a known gap. Costs one height*stride copy each way, a handful of times per session. Verified in both directions on the Pixel 6a: text renders correctly, and the added "no bounce buffer was made" warning fired zero times, so every lock genuinely got a buffer rather than silently falling back to the old NULL path. Co-Authored-By: Claude <noreply@anthropic.com>