fix(export): default Lightning renderer to WebGL to avoid Pixi batch crash on Linux - #1012
swadhinbiswas wants to merge 1 commit into
Conversation
…crash Pixi caches a single module-level batch shader (`DefaultBatcher`'s `defaultShader`) sized by the texture limit of the first renderer created in the page, and pixi.js 8.14 never regenerates it. The editor preview initializes WebGL first; on Mesa drivers WebGL exposes 32 texture units while WebGPU exposes 16, so the modern export renderer reused a bind group layout that expected 32 textures but only had 16 and crashed on the first frame with "Cannot read properties of undefined (reading '_resourceType')". Default the Lightning (modern) export renderer to WebGL-first, keeping WebGPU as the fallback. This matches the editor preview, the legacy frame renderer, and getDefaultLightningRenderBackend(), so the export always shares the same backend family (and therefore the same batch texture limit) as the preview. Fixes webadderallorg#948 Fixes webadderallorg#644
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: webadderallorg/Recordly/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe exporter now attempts WebGL first when no backend is specified. An explicit WebGPU preference still uses WebGPU first with WebGL fallback. Tests record Pixi initialization options and verify the default WebGL path. ChangesExporter backend selection
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to Exports without an explicit backend now prefer WebGL while preserving explicit WebGPU support and fallback behavior. The covered change is merge-ready with no actionable blocking risk identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
|
Linux Testing Verification ReportI tested this PR on Linux x64 (AppImage v1.4.0) and can confirm that this fix completely resolves the export crash issue! Before (on v1.4.0):
After (with this patch applied):
- Export defaulted gracefully to **WebGL (`Path: WebGL + WebCodecs`)**.
- The export is buttery smooth, running at **~124.6 FPS** with zero crashes.
Attached is the live export screenshot. Highly recommend merging! |
2 participants
Description
Default the Lightning (Beta) / modern export renderer to WebGL-first when no render backend is explicitly requested. WebGPU remains the fallback.
Motivation
Lightning exports crash on Linux (e.g. Arch + Mesa) on the first frame with:
(#948, #644)
Root cause: pixi.js 8.14's
DefaultBatchercaches a single module-level batch shader sized by the texture limit of the first renderer created in the page, and never regenerates it:The editor preview initializes WebGL first. On Mesa drivers WebGL exposes 32 texture units, while WebGPU exposes 16 (
maxSampledTexturesPerShaderStage). The modern export renderer passedpreferredRenderBackend: undefinedand treated "auto" as WebGPU-first, so it reused a bind group layout expecting 32 textures while its batch bind group only supplied 16.BindGroupSystem._createBindGroupthen read an undefined resource and threw. On macOS/Windows both backends report 16 (ANGLE), which is why only Linux is affected.Both the legacy frame renderer (
src/lib/exporter/frameRenderer.ts) and the editor preview already default to WebGL-first, andgetDefaultLightningRenderBackend()returns"webgl"(currently unused). This change makes the modern renderer consistent with them, so the export always shares the same backend family — and therefore the same batch texture limit — as the preview.Note: this is an alternative, root-cause fix to #951. #951 keeps WebGPU-first and falls back to WebGL after detecting the limit mismatch at runtime; this change avoids constructing the incompatible renderer in the first place and keeps all backend-selection paths consistent.
Type of Change
Related Issue(s)
Fixes #948, fixes #644. Alternative to #951.
Screenshots / Video
Not applicable — backend-selection change, no UI change.
Testing Guide
npx vitest --run src/lib/exporter/modernFrameRenderer.test.ts— with no explicit backend and WebGPU available, the first renderer init usespreference: "webgl".npm ci --ignore-scripts && npm rebuild ffmpeg-static && npm test(1346 tests).npx tsc --noEmitandnpm run lint.Checklist
Summary by CodeRabbit