Repository navigation
Android (OnePlus 8 Pro, Android 11): 'Failed to append drawIndexed' thrown from SceneView paint, repeating every frame #444
Description
Summary
In a release build of a game using flutter_scene, RenderPass.drawIndexed throws Exception: Failed to append drawIndexed from inside SceneView painting on one Android device. Once it starts, it repeats on subsequent frames (2–4 reports within the same second, 10 reports across 3 sessions over two days). Other devices running the same build have not reported it.
Environment
- flutter_scene 0.23.0 (with flutter_scene_soloud 0.1.2)
- Flutter 3.47.4 stable, release build,
--enable-flutter-gpu - Device: OnePlus 8 Pro (OnePlus8Pro), Android 11
- Rendering backend: not captured in the report (presumably Impeller/Vulkan)
Stack trace
Exception: Failed to append drawIndexed
at RenderPass.drawIndexed (package:flutter_gpu/src/render_pass.dart:686)
at drawIndexedCompat (package:flutter_scene/src/gpu/render_pass_compat.dart)
at Geometry.draw (package:flutter_scene/src/geometry/geometry.dart:801)
at SceneEncoder._drawGeometry (package:flutter_scene/src/scene_encoder.dart:833)
at SceneEncoder._encode (package:flutter_scene/src/scene_encoder.dart:885)
at SceneEncoder.flushOpaque (package:flutter_scene/src/scene_encoder.dart:1142)
at SceneEncoder.flush (package:flutter_scene/src/scene_encoder.dart:1050)
at ScenePass.execute (package:flutter_scene/src/render/scene_pass.dart:381)
at RenderGraph.execute (package:flutter_scene/src/render/render_graph.dart:340)
at Scene._renderViewToTexture (package:flutter_scene/src/scene.dart:2792)
at Scene._renderViewToCanvas (package:flutter_scene/src/scene.dart:1914)
at Scene.renderViews (package:flutter_scene/src/scene.dart:1672)
at Scene.render (package:flutter_scene/src/scene.dart:1367)
at _ScenePainter.paint (package:flutter_scene/src/widgets/scene_view.dart:860)
Pattern
- All occurrences were in the same procedurally generated level (the scene is a few hundred static meshes: track tiles, tunnel tubes built with
GeometryBuilder, primitive decorations, a particle emitter for engine exhaust, fog off). - The first report came about 30 s after the level started, not at scene creation.
- Reports arrive in bursts (same second), which suggests the failure persists across frames rather than being a one-off.
Questions
- Is there a known device/driver condition where the native
_drawIndexedappend fails (e.g. command buffer or descriptor limits on Adreno 650 / Android 11)? - Would it make sense for
SceneEncoderto skip the failing draw (or the frame) instead of throwing out ofpaint, so one bad draw does not break every subsequent frame?
We don't have access to the device to reproduce, but can provide more details from the crash reports if useful.
Activity
bdero commentedon Oct 2, 2026
Thanks for the detailed report, the stack and the timing pattern narrowed this down a lot.
The OnePlus 8 Pro has an Adreno 650, and Flutter 3.47 turns Impeller's Vulkan backend off for Adreno 650 and older, so this device renders on Impeller's OpenGL ES backend. That likely explains why only this device reports it.
On OpenGL ES, a draw only fails to append when its pipeline is invalid, which means the driver failed to compile or link that shader program. Flutter GPU builds the program lazily at the first draw that needs it, and a failed build is cached, so every later draw with that pipeline fails too. That matches what you're seeing. It starts when something using that material first comes into view (about 30 s into the level) and repeats every frame after.
Two questions would help pin down the shader.
.fmatorShaderMaterial, and is there anything that first appears roughly 30 s in?Impeller validation:(for exampleFailed to compile fragment shader for '...'followed by the driver's error andCould not link pipeline program). If your crash reporting can capture native logs from an affected session, those lines would name the exact shader.On your second question, agreed. #455 makes the renderer skip draws whose pipeline the backend refuses, and report it once, instead of throwing out of
paint. A shader the driver rejects then costs only the meshes that use it, and the log line names the material and geometry, which will also tell us which shader to fix.mkw8263 commentedon Oct 8, 2026
@bdero
Thanks, that explanation fits what we see on that device.
1. Materials. No custom
.fmatorShaderMaterialanywhere in that build. Every mesh uses the built-inPhysicallyBasedMaterialwith factor changes only (base color, metallic, roughness, emissive factor/strength). The other draws are additiveParticleEmitterComponents (velocityStretched; engine exhaust is visible from the first frame). The level has two directional lights, no point/spot lights, and fog off.On the timing, though, I don't think a newly visible mesh explains it. The camera uses the default far plane (1000) and we don't cull or stream the track, so the whole level (~324 m, including every
GeometryBuildertunnel) is in view from the first frames. If programs are built at first draw, every static pipeline should be built within the first few seconds. The only things created mid-run are additive particle bursts (supply pickup, crash explosion), which go through the translucent pass, while the failure is influshOpaque. So nothing in our code introduces a new opaque material ~30 s in. If a program can also become invalid after a successful first build on GLES (e.g. resource or context loss on this driver), that might fit the timing better, but that's just a guess.2. Logs. Unfortunately we can't get them. Crashlytics doesn't capture native logcat, and we don't have the device.
We'll pick up #455 once it's released. If the device reports again after that, the log line naming the material and geometry should identify the shader, and I'll post it here.