Runtime guidelines

Updated: Oct 6, 2025

Overview

This page categorizes guidelines into related groups. For instance, CPU capacity limits the number of panels you can have at the default texture size. This limitation means the type of content you have in panels directly influences how many panels Meta Quest devices can support. For best practices that will help maximize your app’s performance, see the design guidelines to further enhance your user experience and broaden your app’s audience.

CPU

There are a few CPU-limited tasks that trade off with each other. In general, your app can pick any linear combination of objects and panels as described below:

Objects

Object type	Max number at 90 FPS	Details
EOPT (Entity Operation Per Tick)	2,000	A read or write to the data model inside of a system
Physics object	500	A simple GLB that includes Physics. Typically, graphics are more of a bottleneck here

Panels

Column descriptions:

FPS dips below 90: Estimated number of open panels before FPS dips temporarily below 90 on each additional panel spawn, in isolation.

FPS stays below 90: Estimated number of open panels before FPS stays below 90 while running in isolation.

Panel type	FPS dips below 90	FPS stays below 90
Empty view panel	20	40
UI (only) view panel	15	40
Image view panel	15	40
Web view panel	5	30
Video view panel	3	5
Activity-based panel	2	2
Panel with layers	5	15

GPU

The primary GPU limitations are:

The number of 3D GLB objects that can be in view simultaneously.

The amount of space objects cumulatively take up in the user’s viewport.

Considering these limitations, a maximum of 100 objects when they occupy more than 50% of the viewport is recommended. Use fewer objects to take up more of the viewport. If you need to use more objects, ensure you take up less than 50% of the viewport.

Panels can also bottleneck GPU utilization as their resolution size increases. Spatial SDK defines resolutions in terms of the percentage of the screen relative to your device’s PPD (pixel per degree). The relationship between GPU utilization and pixel resolution tends to scale linearly when bound to the fill rate. For example, using a default-sized panel of approximately half the screen size will give you a resolution of 1000 by 750 pixels. Each additional 480,000 pixels will use an extra 1% of your GPU.

This configuration doesn’t scale perfectly linearly, but examples in production have rendered panels at 25 million pixels using this calculation.

Memory

Approximately 1,000 objects in the scenegraph are supported, as long as they don’t exceed the GPU and CPU limitations.

Example usage calculation

Using the information above, you should be able to mix and match limits to estimate how complex your app can be in each compute category. Here’s an example of an app that would fit inside the performance envelope:

You have 800 objects in the scene representing the scenery, birds, environment, flowerbeds, and flowers.

Through object management, you simultaneously show no more than 60 objects in the viewport.

You reserve 200 EOPTs (Entity Operation Per Tick) at any tick for growing flowers.

You have one activity-based panel representing a game ported from Android.

You have three UI panels for UI instructions, alerts, and settings.

CPU usage calculation

Feature count	Max allotment of each feature	Percentage of compute usage
200 EOPTs	2,000 EOPT	10%
1 Activity-based panel	2 Activity-based panels	50%
3 UI view panels	15 UI view panels	20%
Total estimated usage		80% CPU usage

GPU usage calculation

Feature count	Max allotment of each feature	Percentage of GPU usage
60 objects in the viewport	100 objects in the viewport	60%
4 standard (1000 x 750) panels that take up 50% of the screen	48,000,000 pixels*	6.25%
Total estimated usage		66.25% GPU usage

Note: This is a rough estimate for max pixels. Please test your apps for the best results.

Memory usage calculation

Feature count	Max allotment of each feature	Percentage of memory usage
800 objects in the scenegraph	1,000 objects in the scenegraph	80%
Total estimated usage		80% memory usage

Given these calculations, this example app still has plenty of computing power remaining to add new features and extend the experience in the future while maintaining a steady frame rate above 90 FPS.

Design guidelines

Accessibility

Balancing art and performance

Did you find this page helpful?