Set Display Refresh Rates

The display refresh rate represents how many times per second a headset’s screen refreshes. A higher refresh rate enables higher frame rates, brighter output, and improved color clarity. However, higher refresh rates require your app to perform its work in shorter amounts of time.

The default display refresh rate for apps is 72 Hz. If you want to run your app at a different refresh rate, you are responsible for ensuring that your app is performant enough to sustain that rate. Apps that can’t consistently render at the desired display refresh rate will fail Meta Horizon Store review. Such apps might exhibit judder, flickering black areas on the peripheries, and other performance-related problems.

Some headset models are capable of higher display refresh rates than others. The table below lists the primary currently available refresh rates.

A cell marked “Display-dependent” means the headset offers that rate only when its own display reports the matching mode. Confirm it on the device with the method this section describes.

For 96 Hz and 100 Hz to appear in the enumerated list, the runtime must support version-gated enumeration, the app must declare OpenXR 1.0.63, 1.1.63, or a later patch version to xrCreateInstance, and its com.oculus.supportedDevices manifest entry must include that headset. On Meta Quest 3, an app that meets these conditions sees both rates. Apps that declare an earlier version don’t see these rates in the list. For details, see Apps built against earlier OpenXR versions.

60 Hz must only be used by media player apps. It is provided as a way to synchronize 30 FPS or 60 FPS video with the display refresh rate for smooth playback. Note that media apps can use higher refresh rates, as long as the refresh rates are supported by the device and the app remains performant. Non-media player apps that set the display refresh rate to 60 Hz will fail the Store review. This is a store review requirement rather than a runtime restriction: the runtime accepts 60 Hz from any app on a device that supports it.

Request a refresh rate that this API returns. The runtime rejects a rate that is not on the list, even when the display hardware can run it, with two exceptions. A request for 0.0f means “no preference”; the runtime uses the device’s default rate. The second exception applies to apps that declare an earlier OpenXR version, and is described in Apps built against earlier OpenXR versions. To maximize compatibility with future headsets, stay with refresh rates listed on the chart above.

Use the Get Available Display Frequencies Blueprint to retrieve an array of the available display frequencies.

If you want to set refresh rates other than 72 Hz for your app, the supported devices section of your Android manifest must include a device that supports this rate. In Unreal Engine, this can be done through Project Settings as described in Set Target Device.

Use the Set Display Frequency Blueprint and set it to the desired refresh rate.

If an app with a display refresh rate higher than 72 Hz experiences thermal events, dynamic throttling may change the refresh rate to 72 Hz as a first step. If thermal conditions worsen, dynamic throttling may take an additional step to change frame rate while maintaining the refresh rate (the equivalent of minVsyncs=2).

If you need your app to know if dynamic throttling reduces the refresh rate so that the app can respond in some way, you can do so through the event Blueprint Oculus Display Refresh Rate Change. The old and new refresh rates are given as the float values From Refresh Rate and To Refresh Rate.

Note: This event only fires when your project uses the OVR legacy runtime. If your project uses OpenXR, this event is not dispatched during dynamic throttling.

You can simulate the dynamic throttling from a higher display refresh rate. While your app is running, broadcast an intent through the adb shell activity manager. For example, this command simulates throttling for 10 seconds:

adb shell am broadcast -a com.oculus.vrruntimeservice.COMPOSITOR_SIMULATE_THERMAL --es subsystem refresh --ei seconds_throttled 10

If you aren’t able to see a visible change in your app, you can verify the refresh rate change by using the Get Current Display Frequency Blueprint and logging the returned value.

Meta Quest 3 supports display refresh rates above 120 Hz, up to 240 Hz. This is exclusive to Meta Quest 3. It is not available on Meta Quest 3S, and it is not available on any other headset. Meta Quest 3S uses a different display panel that does not support rates above 120 Hz.

Extended refresh rates depend on the display hardware in the headset and on the system software the headset runs. Enumerate the rates the device reports at runtime rather than assuming a fixed set.

On Meta Quest 3, apps can request 144 Hz, 180 Hz, 200 Hz, and 207 Hz through the standard APIs described above, as long as the app’s com.oculus.supportedDevices manifest entry includes quest3. For those apps, when they’re built against OpenXR 1.0.63, 1.1.63, or any later patch version, the device also includes these rates, along with 96 Hz and 100 Hz, in the list of supported refresh rates it reports. 207 Hz is the highest rate at which the system can deliver a full frame of data to the display at full resolution.

The runtime reads the OpenXR API version your app declares in XrInstanceCreateInfo::applicationInfo.apiVersion when it calls xrCreateInstance. It compares the major version against 1 and the patch version against 63, and it does not compare the minor version. An engine integration sets that value on your app’s behalf, so to find out what your own build gets, follow Get refresh rates supported by the device on the headset and check whether the extended rates appear in the list.

Other rates above 120 Hz are not available through the standard APIs.

On Meta Quest 3, apps built against OpenXR 1.0 earlier than 1.0.63, or OpenXR 1.1 earlier than 1.1.63, don’t see 96 Hz, 100 Hz, or any rate above 120 Hz in the list of supported rates. What they do see depends on the devices their com.oculus.supportedDevices manifest entry declares: an app that declares quest3 sees Meta Quest 3’s rates, and an app that doesn’t sees the rates of the most capable device it does declare.

On system software that includes the older-app request compatibility fix, an app that declares quest3 can request 96 Hz, 100 Hz, 144 Hz, 180 Hz, 200 Hz, or 207 Hz without rebuilding its OpenXR headers, loader, or SDK. This preserves requests made by older shipping apps; it does not add those rates to their enumerated list. System software without that fix can reject these requests, so handle failure and fall back to a rate the device reports.

Changing only the OpenXR loader does not necessarily change enumeration. The runtime uses the apiVersion value the app or engine passes to xrCreateInstance, not the loader’s version.

For new development, build against OpenXR 1.0.63, 1.1.63, or a later patch version, and request only rates from the list the device reports.

Rates above 207 Hz require display scaling, because a full-resolution frame exceeds the available bandwidth to the display above 207 Hz. Enable developer mode, then run both of the following commands:

adb shell setprop debug.oculus.forceDisplayScaling 1
adb shell setprop debug.oculus.refreshRate 240

The first command enables display scaling. The frame is rendered at a lower resolution, sent to the display as a smaller payload, and upscaled to the panel’s native resolution by the display hardware. The smaller payload fits within the available bandwidth at 240 Hz.

The second command sets the target refresh rate. Accepts any integer from 72 through 240.

Display scaling trades image quality for bandwidth. The upscaled image is not identical to a natively rendered full-resolution image, and the difference is visible in fine detail such as small text and thin geometry.

To reset both properties and return to the default behavior:

adb shell setprop debug.oculus.forceDisplayScaling ''
adb shell setprop debug.oculus.refreshRate ''

Perceived motion blur changes at extended refresh rates. Each frame is displayed for a shorter time, which reduces the smearing that comes from tracking a moving object across a longer frame. The change is most visible in high-contrast scenarios, such as a bright object moving across a dark background. Test the motion in your own content at the rate you plan to ship, because the result depends on your scene’s contrast and motion speed.

A higher refresh rate shortens the time your app has to produce each frame. The frame budget at each rate is:

At 240 Hz your app has less than a third of the frame budget it has at 72 Hz. An app that misses this budget will judder, which defeats the reason to raise the rate at all. Extended refresh rates suit apps that render a light scene and benefit from low latency and smooth motion, such as rhythm games, competitive shooters, sports and racing titles, and simple high-contrast environments. An app with a dense scene, heavy post-processing, or a high draw call count is a poor candidate.

Dynamic throttling applies at extended rates in the same way it applies above 72 Hz.