Develop

Set Display Refresh Rates

Updated: Oct 16, 2026

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.

Get refresh rates supported by the device

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

Device Model	60 Hz	72 Hz	80 Hz	90 Hz	96 Hz	100 Hz	120 Hz
Quest	Media apps only	✓	-	-	-	-	-
Quest 2	Media apps only	✓	✓	✓	✓	✓	✓
Quest Pro	-	✓	✓	✓	-	-	-
Quest 3	-	✓	✓	✓	✓	✓	✓
Quest 3S	-	✓	✓	✓	✓	✓	✓

On Meta Quest 3, the list of supported rates includes 96 Hz and 100 Hz for apps built against OpenXR 1.0.63, 1.1.63, or any later patch version. Apps built against an earlier version don’t see these rates in the list, but can still request them. 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.

To see the current refresh rate on your headset:

Enable developer mode on the Meta Horizon mobile App. For instructions, see Enable Developer Mode.
Use the Meta Quest Developer Hub desktop to:
- Install the OVR Metrics Tool. For instructions, visit the Meta Horizon Store⁠.
- Configure the Metrics Performance HUD Settings in the Meta Quest Developer Hub to display the frame rate by choosing the settings gear icon, and then check the two boxes for Average FPS.

To get the list of refresh rates supported by a device:

Note: 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. The one exception is described in Apps built against earlier OpenXR versions. To maximize compatibility with future headsets, stay with refresh rates listed on the chart above.

You need to enable the XR_FB_display_refresh_rate⁠ extension to display the supported refresh rates. For example:

uint32_t rateCount = 0;
CHECK_XR(xrEnumerateDisplayRefreshRatesFB(session, 0, &rateCount, nullptr));

std::vector<float> rates(rateCount, 0.0f);CHECK_XR(xrEnumerateDisplayRefreshRatesFB(session, rateCount, &rateCount, rates));

Set a refresh rate

If you want to set refresh rates other than 72 Hz for your app, you need to enable the XR_FB_display_refresh_rate extension. For example:

float desiredRate = 90.0f;  // or whichever rate you wish to set
CHECK_XR(xrRequestDisplayRefreshRateFB(session, desiredRate));

Considerations for changing refresh rates

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).

Handle refresh rate change events (Optional)

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 get this information from the ‘predictedDisplayTime’ field of the ‘XrFrameState’ in ‘xrWaitFrame’. For more information, see Frame Submission⁠ in the OpenXR Guide.

Testing how an app handles 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 xrGetDisplayRefreshRateFB function.

Meta Quest 3 extended refresh rates

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 require HorizonOS v2.7 or later.

Extended refresh rates depend on the specific display hardware in Meta Quest 3. Do not assume that a future headset will support rates above 120 Hz, and do not make an extended rate a requirement for your app to run. Fall back to a rate from the list the device reports when a request for an extended rate does not succeed.

144 Hz, 180 Hz, 200 Hz, and 207 Hz (standard)

On Meta Quest 3, apps can request 144 Hz, 180 Hz, 200 Hz, and 207 Hz through the standard APIs described above, with no additional setup. For apps 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.

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

Apps built against earlier OpenXR versions

On Meta Quest 3, apps built against OpenXR 1.0 earlier than 1.0.63, or OpenXR 1.1 earlier than 1.1.63, see only 72 Hz, 80 Hz, 90 Hz, and 120 Hz in the list of supported rates. So that apps that already ship keep working, the runtime still accepts a request from these apps for 96 Hz, 100 Hz, 144 Hz, 180 Hz, 200 Hz, or 207 Hz. It rejects any other rate that is not on the list.

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.

Up to 240 Hz (developer mode)

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 ''

Motion blur at extended refresh rates

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.

Performance considerations for extended refresh rates

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

Refresh rate	Frame budget
72 Hz	13.9 ms
90 Hz	11.1 ms
96 Hz	10.4 ms
100 Hz	10.0 ms
120 Hz	8.3 ms
144 Hz	6.9 ms
180 Hz	5.6 ms
200 Hz	5.0 ms
207 Hz	4.8 ms
240 Hz	4.2 ms

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.