Keeping Inside a Sixteen-Millisecond Budget

Sixty frames a second means 16.7ms for everything. Here is where it goes and how it was measured.

Sixty frames a second gives you 16.7 milliseconds per frame for simulation, drawing and everything else. That is the whole budget.

Measuring the right thing

The first mistake is measuring frames per second in a test environment and drawing conclusions. Software rasterisation in a headless container produced 12 to 21 frames a second for this game, which sounds alarming and means almost nothing about real hardware.

The number that matters is how long your own code takes, isolated from whatever the compositor is doing. Time the drawing work directly and compare it against the budget.

For a full versus board plus eight hundred particles, that measures about 2.4 milliseconds median, 3.7 at the 95th percentile. Roughly seven times the headroom needed for sixty frames a second.

Where the time was going before

Two things dominated, and neither was obvious.

Per-block gradient construction. Around four hundred gradient objects and twelve hundred path operations per frame. Fixed by caching each block face as a bitmap.

Full-screen composites. Three additive nebula gradients, a vignette, and three hundred scanline rectangles, all every frame. Fixed by baking the static layers once per resize and rendering the nebula small and upscaling it.

The one that was not JavaScript at all

The title screen measured slower than gameplay, which made no sense until the cause turned out to be CSS: a full-viewport backdrop-filter blurring an animating canvas on every frame. Confining the blur to the menu panel fixed it.

Worth remembering that the frame budget is shared with the browser's own work, and a single CSS property can consume more of it than all your drawing code.

The clamp

Delta time is clamped to 50 milliseconds. If a frame takes longer, the simulation advances by 50 milliseconds rather than the true elapsed time.

That prevents a stall from teleporting pieces through the stack. The trade is that a genuinely slow device runs the game in slight slow motion rather than skipping ahead, which is the right failure mode for a game about precise placement.

Read next

• Rendering: Sprite Caches and Layer BakingDrawing four hundred glowing blocks per frame is slow. Drawing four hundred cached bitmaps is not.
• Every Sound Is Generated, Not RecordedOscillators, filtered noise and a reverb impulse built from decaying random numbers. No audio files anywhere.
• The Soundtrack Is a Sequencer, Not a FileA four-bar progression with drums, bass, arpeggio and a lead, whose tempo and arrangement climb with your level.
• Online Play With No Server At AllWebRTC connects the two browsers directly; a public relay handles only the introduction.
• Six-Three Stacking and Why Some Players Prefer ItSplitting the board into two flat regions instead of one gives you somewhere to put the awkward pieces.
• Keyboard, Controller or Touch?The input device matters less than people claim, but it matters in specific and predictable ways.