Skip to content

Performance

Haze uses the best available rendering path on each platform, but real-time effects still add work. The impact depends on the device, the affected area, how many effects are visible, and how often their input changes.

  1. Start built-in effects with the default Style and HazePerformanceMode.Default; custom effects continue to use HazeSampling.Default.
  2. Build the real screen, including its scrolling, transitions, and interactions.
  3. Measure a release-like build on representative physical devices.
  4. Change one setting at a time and compare both frame timing and visual quality.
  5. Keep an override only when it provides clear value on the devices you support.

Performance mode

HazePerformanceMode controls the quality and cost trade-off for built-in effects:

  • Default or Adaptive: Recommended for most applications. Built-in effects adjust the quality and cost trade-off automatically.
  • Quality, Balanced, or Performance: Select a named, deterministic profile.
  • Fixed(qualityFraction): Select a normalized, deterministic profile when the named profiles are not the right fit.

Default is Adaptive, and Quality replaces the previous built-in full-resolution choice. There is no formula for translating a previous built-in fixed input-pixel fraction: remeasure an explicit Fixed(qualityFraction) choice on the effect and layout you actually use. Blur and Glass adapt differently, so compare their results independently. Custom effects instead use HazeSampling to control how much input they process.

Common cost drivers

  • Affected area: Larger effects process more content.
  • Number of effects: Several independent effects cost more than one.
  • Changing input: Scrolling and animation require more work than a stable background.
  • Effect complexity: Progressive effects, masks, and advanced optics can add cost.
  • Device and display: Resolution, refresh rate, and GPU capability affect the result.

Effect-specific guidance

For Blur, see Performance mode and layer expansion. For Glass, see the Glass performance guide, which covers optical and interaction choices specific to that effect.

Measure on target devices

Use a release-like build on physical hardware and reproduce the interactions users will perform. Keep device conditions and refresh rate consistent between runs. Measurements from another device or layout are useful context, not a guarantee for your application.

For Android, Macrobenchmark is a good starting point for repeatable frame measurements.

A reference point, not a target

In Haze's 2026-08-04 Glass reference run on a Pixel 6 (Android 17/API 37, 1080×2400 at 60 Hz), the Gallery's productPager journey measured 7.5 ms P90 CPU frame duration and its playgroundTimeline journey measured 11.2 ms. These are one workload on one device, not a performance budget or promise for other devices and layouts. See the Glass reference measurements for the setup and controlled scenarios.