Adaptive Performance uses operation modes to decide whether to prioritize frame rate, battery life, or consistent frame time.
An operation mode sets the goal that Adaptive Performance optimizes. Each mode uses the scalers differently to reach that goal, which changes how your application’s quality is adjusted at runtime.
Adaptive Performance provides three built-in operation modes:
| Mode | Goal | Behavior |
|---|---|---|
| Normal mode | Highest achievable frame rate | Adjusts scalers based only on the device’s thermal and performance state. This is the default mode. |
| Battery mode | Longer battery life | Lowers the target frame rate, enables battery-oriented scalers, and reduces quality when the player is idle. |
| Stable frame mode | Consistent frame time | Minimizes frame-time variance to keep frame pacing smooth. Lowers quality when frames become uneven and raises it when they stabilize. |
Normal mode is the default operation mode. It responds to the device’s thermal and performance state and adjusts scalers to maintain the highest frame rate the device can sustain without thermal throttling. Use normal mode for regular gameplay where responsiveness matters most.
Battery mode prioritizes battery life over frame rate. When it becomes active, it:
AdaptiveOnDemandRendering, AdaptivePhysics, and AdaptiveFramerate.Where supported, battery mode requests the device’s energy-efficiency mode. On Android, the provider uses the APerformanceHint_setPreferPowerEfficiency function from the Android Dynamic Performance Framework (ADPF). Support for energy efficiency and power saving varies by provider. For more information, refer to Feature support by provider.
Use battery mode when your application displays static or low-interaction content, such as menus, turn-based gameplay, or idle screens.
Battery mode adjusts scalers based on the device’s performance state until the application meets the target frame rate.
After the application reaches the target frame rate, it keeps reducing quality to save power up to the Save Target value. Battery mode measures this against a baseline of CPU and GPU frame times, reducing quality until both drop by the saving target fraction below the baseline. For example, with the default value of 0.1, CPU and GPU frame times must be at least 10% lower than the baseline.
Battery mode establishes the baseline (default 30 fps) over 100 consecutive frames after meeting the target frame rate. This avoids capturing the baseline during performance spikes. If a frame misses the target, the count restarts.
If the device is in low power mode, battery mode starts counting these frames immediately, without requiring the application to meet the target frame rate first.
Thermal state takes priority in battery mode. If the device heats up, battery mode adjusts scalers to cool the device first, before it pursues the saving target.
Stable frame mode prioritizes a consistent frame time over the highest achievable frame rate. It minimizes frame-time variance so the application feels smooth, even when this means running at a lower frame rate than the device can reach. Use stable frame mode for content where consistent pacing matters more than peak frame rate, such as fast-motion or camera-driven gameplay where stutter is more noticeable than a slightly lower frame rate.
When stable frame mode becomes active, it performs the following actions:
Stable frame mode disables vertical sync (VSync) and controls the frame rate itself. When VSync is enabled, a frame that misses the display’s refresh deadline is delayed until the next refresh interval, for example from 16.7 ms to 33.3 ms at 60 Hertz. This creates a large frame-time spike that works against the consistency the stable frame mode aims to provide.
With VSync off, stable frame mode enables the AdaptiveFramerate scaler and seeks the highest frame rate it can hold steadily, down to the scaler’s minimum bound. On mobile devices, the compositor paces presentation regardless of VSync setting, so disabling VSync lets stable frame mode control only the target frame rate.
Stable frame mode restores the original VSync setting when it becomes inactive.
Stable frame mode measures how much frame time fluctuates and compares it against the Target Frame Time Variance (ms²) setting. When variance rises above the target, it lowers quality. When variance falls below a quarter of the target, it raises quality. To configure this threshold, refer to Adaptive Performance provider settings reference.
On mobile devices, where the compositor presents frames at a fixed cadence, wall-clock frame time snaps to the refresh interval and hides small fluctuations. In this case, the stable frame mode measures variance from CPU and GPU work time instead of wall-clock frame time, so it still detects uneven frames.
Each operation mode uses a mode provider that implements the IAdaptivePerformanceModeProvider interface. The active mode provider controls which thermal and performance actions apply to each frame.
A mode provider differs from a platform provider. A platform provider such as the Android or Apple provider supplies device data to Adaptive Performance, while a mode provider defines how Adaptive Performance reacts to that data.
You can change the active mode provider at runtime through IOperationModeStatus.CurrentOperationalModeProvider or implement a custom operation mode. For more information, refer to Create a custom operation mode.
The mode provider and operation mode are separate. The operation mode determines which scaler settings apply, while the mode provider determines how to use them. A custom mode provider replaces the strategy for the current operation mode, but still uses the current operation mode’s settings.