Repair a frame-rate target when the target remains appropriate and a measurable implementation defect prevents the game from meeting it. Replace the target when hardware coverage, visual scope, latency needs, or display behavior make the old number unrealistic. Retire a mode when it cannot be supported safely or consistently and a tested alternative exists.
Repair the implementation
Repair is appropriate when a regression, shader, effect, asset stream, simulation step, synchronization point, driver issue, thermal condition, or configuration error causes a known scene to miss an otherwise achievable budget. Capture frame-time traces from the last good and first bad builds under the same hardware, resolution, refresh rate, power mode, temperature, and scene.
Android defines frame pacing as synchronization of the game loop with the operating system display subsystem and display hardware. Its guidance explains that late submissions can cause earlier frames to repeat (Android Frame Pacing library). Check pacing and slow-frame distribution, not only average frames per second.
Set a repair deadline and a performance budget by subsystem. Change one element, rerun the same trace, and record both improvement and visual or latency cost. A lower quality preset can be a workaround, but it is not proof that the regression is fixed.
Replace an unrealistic target
Replace the target when evidence across supported hardware shows that the old rate conflicts with the required resolution, simulation, visual features, battery or thermal limits, or consistent pacing. Compare a small set of candidate targets using representative gameplay, worst-case scenes, input latency, visual quality, power, temperature, and accessibility needs.
Microsoft's Frame Pacing sample demonstrates that CPU work, GPU work, swap-chain buffers, and frame scheduling interact to affect frame rate, latency, and presentation margin (Microsoft Frame Pacing sample). The replacement decision should therefore include the whole frame pipeline, not just a GPU average.
Test the candidate on minimum, common, and high-end supported hardware. Define whether the target is fixed, capped, adaptive, or tied to display modes. Document what happens when the target cannot be held and prevent rapid oscillation between modes.
Retire unsupported modes deliberately
Retire a high-frame-rate mode, platform preset, or legacy cap when it causes persistent instability, overheating, unacceptable visual compromise, or unmaintainable test burden. Preserve saved settings safely, migrate users to a supported default, update menus and documentation, and remove telemetry labels that would misclassify the new behavior.
Do not retire a mode based on one device or one synthetic benchmark. Review player hardware distribution and reproduce real scenes. Keep a rollback path through at least one release window.
Record the decision
Document the target, supported hardware, test scene, trace method, frame-time percentiles, pacing behavior, input result, visual setting, power or thermal observation, owner, and release. Mark whether the outcome is repair, replacement, retirement, or workaround. The decision is complete only when the original problem scene and broader regression suite pass on the promised hardware without disguising a tradeoff as a fix.
Sources
- Frame Pacing library — Google
- Frame Pacing Sample — Microsoft Learn, Sept. 14, 2026