fix(rune): wait for texture images to finish loading before drawing - #892
Conversation
`deserializeRune` hands the draw path an HTMLImageElement whose fetch/decode may still be in flight - `loadTexture` only waited for load when the texture arrived as a raw URL string, so an already-constructed-but-still-loading image (the normal path for runes rendered in the tab) got uploaded to WebGL as-is, leaving the 1x1 placeholder pixel (opaque blue) as the visible texture. Wait for image completion unconditionally instead. Fixes #891 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018mNjABo3YLgMJc1GS2DcpC
|
@coderabbitai review |
✅ Action performedReview finished.
|
Walkthrough
ChangesRune texture loading
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant drawRunesToFrameBuffer
participant waitForImageToLoad
participant HTMLImageElement
participant WebGL
drawRunesToFrameBuffer->>waitForImageToLoad: wait for texture readiness
waitForImageToLoad->>HTMLImageElement: inspect readiness or wait for events
HTMLImageElement-->>waitForImageToLoad: loaded image or load failure
waitForImageToLoad-->>drawRunesToFrameBuffer: resolve or reject
drawRunesToFrameBuffer->>WebGL: upload resolved texture
drawRunesToFrameBuffer->>WebGL: draw textured geometry
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/bundles/rune/src/rune.ts`:
- Around line 167-169: Update waitForImageToLoad() to register its load, abort,
and error callbacks with addEventListener instead of overwriting
HTMLImageElement handlers. Store the registered callbacks and remove all three
listeners when the promise settles, while preserving the existing resolve/reject
behavior for images supplied through Rune.of().
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: c62c6233-8f5b-4ef8-b154-fd0d23e3fdf8
📒 Files selected for processing (2)
src/bundles/rune/src/__tests__/rune.test.tssrc/bundles/rune/src/rune.ts
waitForImageToLoad previously assigned image.onload/onerror/onabort directly, which would clobber any handlers already attached to a caller-supplied HTMLImageElement (Rune.of accepts one). Not currently reachable since the only image producer (protocol.ts's imageFromUrl) never attaches handlers before handing the image off, but the helper is typed to accept any HTMLImageElement, so use addEventListener/removeEventListener instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018mNjABo3YLgMJc1GS2DcpC
Summary
rune.ts'sloadTextureonly awaited image load when the texture arrived as a raw URL string. When a rune is deserialized on the tab side (protocol.ts'sdeserializeRune), it constructs anHTMLImageElement, sets.src, and hands it back immediately without waiting for the fetch/decode to finish -loadTexturethen took thetypeof imageSource !== 'string'branch and uploaded that (possibly still-loading) image straight to WebGL, racing the actual download. Losing the race left the 1x1 placeholder pixel (opaque blue) as the visible texture instead of the real image.loadTexturewaits for image completion unconditionally, regardless of whether the image was just constructed from a URL or handed in already (maybe) loading.Fixes #891
Test plan
src/bundles/rune/src/__tests__/rune.test.tscoveringdrawRunesToFrameBuffer: a texture image that's still loading is not uploaded until it firesonload; an already-loaded image uploads immediately; an already-errored image rejects. Verified the first two tests fail against the pre-fix code (confirms they catch the regression) and pass after the fix.yarn buildtools test --project src/bundles/rune- all 51 tests passyarn buildtools tsc- cleanyarn eslinton changed files - clean🤖 Generated with Claude Code
https://claude.ai/code/session_018mNjABo3YLgMJc1GS2DcpC