Not building for WebGPU alone

Context

Before writing the atelier's features into a table one by one, I had to settle the rendering path. Building on the newer API alone would spare me every fallback branch, but any environment without it would lose the feature outright.

Options

• Build WebGPU-only and simply omit the feature elsewhereRejected
• Make one implementation hold on both paths, and keep a separate static route with no 3D at allChosen

What I chose

I set the rule first — every feature has to stand on three tiers: high quality, fallback, and no 3D at all — and gave every row of that table a column for it.

Why the rest were rejected

Build WebGPU-only and simply omit the feature elsewhere

Once every row of that table carried a column for WebGL2 behaviour, a WebGPU-only row could only ever read "disabled" — and a disabled row was required to ship a substitute before the phase could close. The degraded path had to be built either way.

What I learned afterward

In the performance baseline that followed, forcing the fallback path measured a higher frame rate than the newer one on the harness. The trend held across repeated runs, but the headless browser most likely never got hardware acceleration for the newer API, so confirming the same trend on a real browser was carried over as out of scope. The rule asked which paths had to hold, not which one was faster, so the open question did not block anything.¹