Measure render resolution scaling #29

New issue

Closed

opened 2026-09-13 17:06:08 +00:00 by icub3d · 0 comments

icub3d commented

2026-09-13 17:06:08 +00:00

Owner

Settles ADR 0004, which is
Proposed rather than Accepted because this measurement has not been taken.

The spike measured the mission view on a Pixel Tablet (Mali-G710, 2560x1600, 60 Hz):

Build	Mean frame	Effective	Median interval
As shipped	31.9 ms	31 fps	33.26 ms
Shadow maps disabled	26.7 ms	37 fps	33.25 ms

The median is exactly two refresh intervals, so the frame misses its 16.7 ms budget and
waits for the next vsync. The scene is 96 terrain columns, four primitives, one light,
nothing animating, and a static camera — there is no headroom for the game M1 still has
to add.

Only shadows were isolated, and removing them bought 6 fps of the ~29 needed. The rest
has not been attributed between fragment shading at 4.1 Mpixel, the CPU clustering
fallback Bevy reported, and draw-call overhead.

Measure

Render at a fraction of native resolution and plot frame time against pixel count. If
halving resolution roughly doubles the frame rate, the cost is fill-rate and a
resolution cap may be sufficient on its own — which would make dropping PBR unnecessary
and ADR 0004 wrong.

If it does not scale with pixels, the cost is elsewhere and ADR 0004's reasoning holds.

Note that on Android the surface size is system-owned, so WindowResolution's
scale_factor_override may not be the right lever; a render target the camera draws
into and a blit may be.

Done when

The measurement exists, and ADR 0004 is either accepted or superseded by one that says
what the numbers actually support.

Settles [ADR 0004](../src/branch/main/docs/adr/0004-mobile-render-budget.md), which is Proposed rather than Accepted because this measurement has not been taken. The spike measured the mission view on a Pixel Tablet (Mali-G710, 2560x1600, 60 Hz): | Build | Mean frame | Effective | Median interval | | --- | --- | --- | --- | | As shipped | 31.9 ms | 31 fps | 33.26 ms | | Shadow maps disabled | 26.7 ms | 37 fps | 33.25 ms | The median is exactly two refresh intervals, so the frame misses its 16.7 ms budget and waits for the next vsync. The scene is 96 terrain columns, four primitives, one light, nothing animating, and a static camera — there is no headroom for the game M1 still has to add. Only shadows were isolated, and removing them bought 6 fps of the ~29 needed. The rest has not been attributed between fragment shading at 4.1 Mpixel, the CPU clustering fallback Bevy reported, and draw-call overhead. ## Measure Render at a fraction of native resolution and plot frame time against pixel count. If halving resolution roughly doubles the frame rate, the cost is fill-rate and a resolution cap may be sufficient on its own — which would make dropping PBR unnecessary and ADR 0004 wrong. If it does not scale with pixels, the cost is elsewhere and ADR 0004's reasoning holds. Note that on Android the surface size is system-owned, so `WindowResolution`'s `scale_factor_override` may not be the right lever; a render target the camera draws into and a blit may be. ## Done when The measurement exists, and ADR 0004 is either accepted or superseded by one that says what the numbers actually support.

icub3d added the

labels

2026-09-13 17:06:15 +00:00

icub3d added this to the M1 — Playable Vertical Slice milestone

2026-09-13 17:06:16 +00:00

icub3d referenced this issue

2026-09-13 17:23:02 +00:00

Attribute the fixed per-frame render cost #31