flutter3d_backend 0.6.0

Picks the graphics backend a build draws through: Impeller on a desktop, WebGL2 in a browser, and a software rasteriser at runtime if Impeller will not start.

0.6.0

• Three decisions now, not two, and the third is the browser's. Web or native stays a conditional export decided at compile time; Impeller or the software rasteriser stays a try/catch at run time; and on the browser half WebGPU is tried before WebGL2 by the same try/catch, because whether navigator.gpu hands out an adapter depends on the browser, the driver and the machine's blocklist, none of which a compiler can see.
• It is off unless a build asks for it, and that is a decision about bundle size. --dart-define=FLUTTER3D_WEBGPU=true turns it on; bool.fromEnvironment folds to a constant and the branch folds with it, so a build that did not ask carries one backend rather than two. The price was measured rather than assumed: flutter build web --release on the strategy demo writes a 2,529,865-byte main.dart.js with the flag off and a 2,906,514-byte one with it on — 376,649 bytes, 14.9% more script, and 368 KiB over the whole of build/web. That is a WebGPU device, its encoder, its pipeline cache and its WGSL arriving in a bundle that will never open them.
• A fall back says so on the console. openWebGpu turns an absent navigator.gpu and a refused adapter alike into one StateError; this catches it, names the backend the frame is actually coming from and opens WebGL2. Silence would leave a WebGL2 picture being read as a WebGPU one.
• What it still does not decide: the resolution, the shadow budget, or which backend a browser build ought to prefer. WebGL2 remains what an ordinary web build draws through — it is the browser backend with a recorded reference set behind it, and a default that quietly moved every build onto the newer API would change what shipped games look like without anybody asking.
• flutter3d_webgpu is a real dependency rather than a dev one, because the branch above is reachable code; openDevice still returns a GraphicsDevice and still names no graphics API in any signature.

0.5.2

• A browser build can ask for WebGPU, and has to ask. --dart-define=FLUTTER3D_WEBGPU=true makes the web half try openWebGpu first and fall back to WebGL2 where the browser has no navigator.gpu or refuses an adapter — the same try/catch shape, and for the same reason, as the native half's fall back to the software rasteriser. Without the define nothing changes: an ordinary web build opens WebGL2 and never mentions WebGPU.
• Why it is a define and not simply the behaviour. A probe that can call either opener keeps both backends reachable, and dart2js ships what it can reach. Measured on apps/flutter3d_demo_strategy, flutter build web --release writes 2,529,865 bytes of main.dart.js with the flag off and 2,906,514 with it on — 376,649 bytes, 14.9%, of device, encoder, pipeline cache and WGSL that a build which never opens WebGPU would be carrying anyway, and 368 KiB on the whole of build/web. That is a trade a game makes, not one this package makes for it. Both readings are from the same afternoon and the same checkout; an earlier pair over a smaller tree said 372,686, which is why the figure is taken again rather than quoted.
• The browser half now has tests of its own, and a tool/ci.sh step that runs them. It had never been executed anywhere: the existing suite says outright that a VM run is the native half, and which backend a web build opens was a decision with nothing holding it.
• Floors again, for the same reason as 0.5.1 and a different feature. An engine at 0.5.2 binds a MorphInfo block and a morph_texture sampler in its vertex stages; a backend older than that has neither in its bundle and cannot upload the float texture the deltas travel in. Impeller throws, naming the block; the software backend and WebGL read what is missing as nothing and go on drawing the base shape, saying nothing. ^0.5.2 on all three.

0.5.1

• The floors move to the 0.5.1 backends, and the reason is a coupling the version graph could not otherwise state. flutter3d 0.5.1 changed what the surface buffer's alpha means and added a member to the FogInfo uniform block, so an engine at 0.5.1 and a backend at 0.5.0 disagree about the shape of a block and about the units of a depth. Nothing forced them to move together: the engine names no backend — that is a structure rule — so this package is the only edge in the graph where the requirement can be written down, and it said ^0.5.0.
• What that mismatch actually does, since a floor is worth what it prevents: Impeller throws a StateError naming the block and the member, which is the failure this package's floor now makes unreachable; the software backend is quieter and merely goes on drawing the old picture, which is the case that wanted the floor most.
• One direction only. This package does not depend on flutter3d, so it cannot say "an engine at least as new as these backends". A project that pins the engine down while letting the backends float is still able to assemble a pair that disagrees.

0.5.0

• No API change. Its floors move to the 0.5.0 backends.

0.4.0

• No changes of its own; the version moves with the workspace, whose sibling constraints name a single release. The README's closing section now says what the engine around this package is.

0.3.0

• Picks the graphics backend a build draws through, with a conditional import rather than a runtime branch: the two pull in worlds that do not compile for each other's platform.
• openDevice was three files in each of three games and byte-identical in two of them.
• Deliberately does not decide resolution or shadow budget. Those are a game's trade against its own scene, and a shared constant would be wrong for two of the three.