Reduce the engine's per-frame floor #34

New issue

Open

opened 2026-09-13 17:35:28 +00:00 by icub3d · 0 comments

icub3d commented

2026-09-13 17:35:28 +00:00

Owner

Deferred deliberately by ADR 0006.

#31 attributed the mission view's 19.91 ms frame on a Pixel Tablet:

Cost	ms
Terrain, units, light	2.91
MSAA 4x	2.25
Tonemapping	0.64
Everything else	14.10

With nothing drawn, no MSAA and no tonemapping, a frame still costs 14.10 ms — 85% of a
60 fps budget, spent before the game draws anything. Of that, 5.94 ms is the main
schedule and 8.16 ms is spent waiting on the render thread, the GPU, and present.

This is what the engine costs to produce a frame on this device. It is the only thing
standing between the game and a 60 fps target, and ADR 0006 chose 30 fps rather than
fight it.

Why this is not scheduled

It is open-ended work against someone else's code, with no guarantee of a win. One
hypothesis has already been tested and failed: disabling unused plugins. bevy_pbr
panics without GltfPlugin, which cannot be disabled independently in Bevy 0.19, and
audio and gilrs are worth fractions of a millisecond.

Going further needs a profiler rather than A/B builds — bevy/trace with a trace viewer,
against the render schedule and the present path. That is a different kind of job from
anything M1 needs.

Worth doing when

30 fps turns out not to be good enough once the camera is moving with a real scene
under it, or
a Bevy upgrade claims mobile rendering improvements and the floor should be re-measured,
or
the budget gets tight for an unrelated reason and 14 ms of floor becomes the cheapest
place to find room.

Re-measure first either way: android/build.sh --install --features perf reproduces the
whole table, and a number from an older Bevy is not evidence about the current one.

Done when

Either the floor is reduced enough to change the frame-rate target — in which case
ADR 0006 is superseded — or it is understood well enough to say it cannot be, in which
case that is recorded and this closes.

Deferred deliberately by [ADR 0006](../src/branch/main/docs/adr/0006-target-thirty-frames.md). #31 attributed the mission view's 19.91 ms frame on a Pixel Tablet: | Cost | ms | | --- | --- | | Terrain, units, light | 2.91 | | MSAA 4x | 2.25 | | Tonemapping | 0.64 | | **Everything else** | **14.10** | With nothing drawn, no MSAA and no tonemapping, a frame still costs 14.10 ms — 85% of a 60 fps budget, spent before the game draws anything. Of that, 5.94 ms is the main schedule and 8.16 ms is spent waiting on the render thread, the GPU, and present. This is what the engine costs to produce a frame on this device. It is the only thing standing between the game and a 60 fps target, and ADR 0006 chose 30 fps rather than fight it. ## Why this is not scheduled It is open-ended work against someone else's code, with no guarantee of a win. One hypothesis has already been tested and failed: disabling unused plugins. `bevy_pbr` panics without `GltfPlugin`, which cannot be disabled independently in Bevy 0.19, and audio and gilrs are worth fractions of a millisecond. Going further needs a profiler rather than A/B builds — `bevy/trace` with a trace viewer, against the render schedule and the present path. That is a different kind of job from anything M1 needs. ## Worth doing when - 30 fps turns out not to be good enough once the camera is moving with a real scene under it, or - a Bevy upgrade claims mobile rendering improvements and the floor should be re-measured, or - the budget gets tight for an unrelated reason and 14 ms of floor becomes the cheapest place to find room. Re-measure first either way: `android/build.sh --install --features perf` reproduces the whole table, and a number from an older Bevy is not evidence about the current one. ## Done when Either the floor is reduced enough to change the frame-rate target — in which case ADR 0006 is superseded — or it is understood well enough to say it cannot be, in which case that is recorded and this closes.

icub3d added the

labels

2026-09-13 17:35:32 +00:00

icub3d referenced this issue

2026-09-13 17:35:53 +00:00

Find out what the frame is actually spent on, and pick a target #35

icub3d referenced this issue from a commit