Give the canvas a deliberate pixel budget
Give the canvas a deliberate pixel budget. A runnable teaching fixture with synthetic cases, a broken branch, and explicit untested cells.
CSS size and canvas backing resolution answer different questions. This fixture checks a deliberate density cap so a high-density input does not silently multiply the playable's pixel workload.
This article is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.
What the documentation actually supplies
MDN: dpr buffer is the governing reference for the browser primitive. MDN defines devicePixelRatio as the relationship between physical and CSS pixels and notes that page zoom can affect it. The cap used here is our laboratory policy, not an official browser or ad-network limit. The fixture policy around that primitive is ours.
The failure the fixture isolates
The corrected function multiplies CSS dimensions by the smaller of the supplied density and an illustrative cap of two. The broken branch always allocates at the supplied density. At density three it creates a larger buffer than the declared budget permits, even though both branches may appear sharp on a screen.
The broken branch is retained so a producer can see the exact mistake, not only the repaired output.
| Case | Input | Expected (fixed) | Broken output |
|---|---|---|---|
| density one | `[300,200,1]` | `[300,200]` | `[300,200]` |
| density two | `[300,200,2]` | `[600,400]` | `[600,400]` |
| density three capped | `[300,200,3]` | `[600,400]` | `[900,600]` |
All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.
What a pass does not prove
Passing the test proves buffer arithmetic for the supplied values. It does not measure frame time, memory pressure or perceived sharpness on a physical device. The tradeoff is explicit: limiting resolution can reduce pixel work while softening details, so a producer still needs to review text and art at the chosen setting.
Untested cells in this article: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.
Next check on a real build
Record the CSS dimensions and backing dimensions in a real build's diagnostics. Recompute when relevant layout or density changes occur, and redraw from logical coordinates. Profile an actual device before choosing a cap for production; do not adopt two as a universal optimum.
Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.
Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.
