Search Unity

How on-demand rendering can improve mobile performance

, February 7, 2020

It’s not always desirable to render a project at the highest frame rate possible, for a variety of reasons, especially on mobile platforms. Historically, Unity developers have used Application.targetFrameRate or Vsync count to throttle the rendering speed of Unity. This approach impacts not just rendering but the frequency at which every part of Unity runs. The new on-demand rendering API allows you to decouple the rendering frequency from the player loop frequency.

What is on-demand rendering?

On-demand rendering allows you to skip rendering frames while still running the rest of the player loop at a high frequency. This can be especially useful on mobile; bypassing rendering can bring significant performance and power savings, while still allowing the application to be responsive to touch events.

Why would I use on-demand rendering?

Here are some example scenarios of when you may want to lower the frame rate:

  1. Menus (e.g., the application entry point or a pause menu): Menus tend to be relatively simple Scenes and as such do not need to render at full speed. If you render menus at a lower frame rate, you will still receive input during a frame that is not rendered, allowing you to reduce power consumption and to keep the device temperature from rising to a point where the CPU frequency may be throttled, while keeping a smooth UI interaction.
  2. Turn-based games (e.g., chess): Turn-based games have periods of low activity when users think about their next move or wait for other users to make their move. During such times, you can lower the frame rate to prevent unnecessary power usage and prolong the battery life.
  3. Static content: You can lower the frame rate in applications where the content is static for much of the time, such as automotive user interface (UI).
  4. Performance management: If you want to manage power usage and device thermals to maximize battery life and prevent CPU throttling, particularly if you are using the Adaptive Performance package, you can adjust the rendering speed.
  5. Machine learning or AI applications: Reducing the amount of work the CPU devotes to rendering may give you a little bit of a performance boost for the heavy processing that is the central focus of your application.

Where is it supported?

Everywhere! On-demand rendering works on Unity 2019.3 with every supported platform (see the system requirements) and rendering API (built-in render pipeline, Universal Render Pipeline and High Definition Render Pipeline).

How do I use on-demand rendering?

The on-demand rendering API consists of only three properties in the namespace UnityEngine.Rendering.

This is the most important part. It allows you to get or set the render frame interval, which is a dividing factor of Application.targetFrameRate or QualitySettings.vSyncCount, to define the new frame rate. For example, if you set Application.targetFrameRate to 60 and OnDemandRendering.renderFrameInterval to 2, only every other frame will render, yielding a frame rate of 30 fps.

This property gives you an estimate of the frame rate that your application will render at. The estimate is determined using the values of OnDemandRendering.renderFrameInterval, Application.targetFrameRate, QualitySettings.vSyncCount and the display refresh rate. But bear in mind that this is an estimate and not a guarantee; your application may render more slowly if the CPU is bogged down by work from other things such as scripts, physics, networking, etc.

This simply tells you if the current frame will be rendered to the screen. You can use non-rendered frames to do some additional CPU-intensive work such as heavy math operations, loading assets or spawning prefabs.

What else do I need to know?

  • Even though frames will not be rendered as often, events will be sent to scripts at a normal pace. This means that you may receive input during a frame that is not rendered. To prevent the appearance of input lag we recommend that you call OnDemandRendering.renderFrameInterval = 1 for the duration of the input to keep buttons, movement, etc. responsive.
  • Situations that are very heavy on scripting, physics, animation, etc. but are not rendering will not benefit from using on-demand rendering. The results may appear choppy and with negligible reduction in CPU and power usage.


Here is a simple example showing how on-demand rendering could be used in a menu to render at 20 fps unless there is input. 


Here is an example project demonstrating how on-demand rendering can be used in a variety of situations.

Are you using on-demand rendering?

Let us know in the forums how on-demand rendering is working for you. We’ve tested it on Windows, macOS, WebGL, iOS, and Android, both in the Unity Editor and with Standalone players, but we’re always open to more feedback.

20 replies on “How on-demand rendering can improve mobile performance”

I think on-demand rendering is an excellent solution for achieving performance. My team has not tested yet, but thanks for the article!

“Where is it supported?” – Now it has become popular to use pre rendering (SPA), even in e-commerce projects. For example –, this is just a fashion website!
But even in e-commerce, they work on productivity, creating SPA.

Above all, aim to create a website that can balance aesthetics and performance on mobile, and achieve real conversion metrics. A collaborative, iterative performance optimization process will help you achieve this.

Right from the start of the project, encourage the internal team to work together under a mobile mindset by setting a strict performance budget. Build an understanding of the client and server-side factors that determine website performance on mobile. Then you can meet the goal set by implementing a mixture of the targeted optimization techniques I have described. Of course, there’s still a trade-off between having a striking design, high performance and security in some cases; a collaborative design and development team can decide what’s best for the business, checking with relevant project managers and stakeholders.


What are the differences between use of OnDemandRendering.renderFrameInterval 2 with Application.targetFrameRate 60 or directly use Application.targetFrameRate 30 manually? Also, if you recommend using OnDemandRendering.renderFrameInterval 1. Where do we gain performance? Thanks in advance!

1) Application.targetFrameRate will affect how often Update is called. OnDemandRendering will keep your Update cycle at the targeted rate, but rendering will only be performed once every n cycles.

2) targetFramerate is not intended to be manipulated frequently at runtime. Using it as an alternative to renderFrameInterval seems to function well enough on iOS, but can cause flickering on some Android devices.

I submitted a bug report regarding OnDemandRendering on Jan 28th and haven’t heard back. (1214921)

The issue seems to be that cameras rendering into render textures don’t get throttled correctly, and update their textures additively, affecting transparency.

Should I also start a forum thread to actually get attention?

I think that any resource can be used unethically. I had not considered this way of discussing a bad habit of on-demand rendering, but this sounds to me an easy case to be verified in stress tests.

I’m getting errors upon opening the example project.
“The name ‘RenderPipeline’ does not exist in the current context”

Thank you for adding this feature! This see this feature helping the application I am developing significantly.

Recently there were a lot of smartphones coming with advertised 90 & 120Hz screen refresh rates, which in reality are refreshing screen at 60Hz or less most of the time.
With 120Hz Samsung and iPhone phones coming this year, I foresee already an avalanche of mobile games coming soon with *120 screen refresh rate support!!!* ads labelled all over them, which in reality won’t reach even 60FPS most of the time. With developers saying “oh, you know, our game actually runs at 120FPS, we are just using on-demand rendering at 30FPS most of the time to save your battery, you know”. So this feature will come in handy for developers who want to cash in on the newest hype of high refresh screens, I suppose. Not so good for customers, who will be fooled again by yet another creative marketing.

I was hoping to see “Rendering layers”, still its a cool feature and absolutely will use it as soon as possible. Thanks Unity, Keep it up

What about rendering in layers e.g. Onion Skybox’s so basic turning without moving can work with minimum rendering overhead?

Comments are closed.