I am writing to bring urgent attention to the OnDemandRendering API, which is currently unusable on Android due to existing and verified bugs. These issues render the API completely ineffective, for example making the player freeze whenever the frame interval is changed. These bug reports have been stuck “under consideration” for quite some time:
Unfortunately, the Unity versions in which this API still works are not optimized for API 34. With Google’s deadline approaching, I will be forced to stop using the OnDemandRendering API and give up its benefits!
I kindly request that these issues be addressed as a priority to ensure the OnDemandRendering API is functional on Android.
2 Likes
Another bug I found was that on Android, the Update() function is not limited to Application.targetFrameRate but instead calls runs Update() as often as it can. I solved that by using FixedUpdate() and setting “Time.fixedDeltaTime = 1f / fullFrameRate” but it’s a bug nevertheless.
Also, OnDemandRendering.effectiveRenderFrameRate on Android does not reflect the actual framerate like it does in the Editor.
Another bug (the worst) is that touch input (new input system) is processed at the (low) render framerate instead of being de-coupled from that and running faster. This makes the UI very unresponsive when a low frame rate is set to save battery, completely nullifying what OnDemandRendering is mainly suitable for.
1 Like
wow I didn’t verify these extra bugs. At least on the older versions and iOS I can confirm my UI is responsive even using the api.
Specially about the input system issue, if its true you should file a bug report. If the UI is affected then this api is really unusable even for lower frame interval values, besides higher frame intervals that freeze the player.
Seems like Unity has disregarded this api completely. Makes me worry about future health of the engine if they can just carelessly break a perfectly working api and not fix it for 1+ years. Unaware developers may have had their games jagged when updating Unity versions and others will have to stop benefiting from the api’s battery life enhancements.
Also to anyone else affected by these issues, I highly encourage you to visit the links provided and vote on the issue reports in Unity’s Issue Tracker.
Hey, I decided to check in on this issue again, did a bunch more tests this time.
Still happening in Unity 2022.3.61 and latest Unity 6.
I also tracked in which version the bug starts and found out it started in version 2021.3.35. Interesting that there are two relevant fixes on the changelog for this version:
-Android: Fixed OnDemandRendering’s ignored renderFrameInterval. (UUM-32486)
-Android: Upgraded Google’s Frame Pacing library from v1.7 to v1.10 to fix various stability and performance issues with Optimized Frame Pacing. (UUM-57566)
What we know so far:
-Bug starts at 2021.3.35
-Main thread is being blocked while rendering is throttled. input and prints are delayed. That means Unity is violating the intended behavior of ODR, which is supposed to decouple frame skipping from logic updates.
-The freeze is proportional to the frameinterval, the greater the interval the longer the freeze
-Happening with optimized framed pacing turned off
My guess:
Unity skips frames but forgets to update its internal vsync timer on WaitForTargetFPS() (lastTargetVsyncTime) - so when full-speed rendering resumes, it thinks it’s behind and freezes to “catch up”.
Not happening on iOS because WaitForTargetFPS() is not on the main thread there.
Could also still be an issue with Google Frame Pacing library. Only Unity engineers can confirm that by reversing the version.
Bug probably introduced with “fix” of UUM-32486 on 2021.3.35, which states: “On-demand rendering doesn’t work as expected on Android”. The big issue is… ODR WAS WORKING ON ANDROID BEFORE THAT! I just confirmed with profiler tests on Android on 2021.3.34 and before. Main thread is not blocked, input normalized at all times, rendering is effectively halted when requested, with the green rendering section of the graph very thin with high frame intervals and jumping 10x with renderFrameInterval set to 1.
Maybe they were trying to fix issues with OFP on (which always didn’t work with ODR), or other specific condition, but now it doesn’t work with either option!
Unity should:
-Revert or rework UUM-32486
-Ensure that skipped vsyncs are tracked correctly
-Prevent WaitForTargetFPS() from blocking the main thread
-Only throttle rendering - never game logic or input
Also, Unity seems to be marking bug reports of this as duplicate to another one that I’m not sure is related.
Consequences:
ODR is important for games with static intervals and long sessions, like word, board games etc. There are tons of games made in Unity in this category. Phone heats up or battery drains and user turns it off, affecting retention and session length.
This turns Unity into a worse option for these kinds of games than other tools like Flutter where it doesnt render every frame by design.
Indeed, OndemandRendering is broken o Android. Not working on latest Unity versions. We are having to remove it from our current projects. Seems like a dumb bug as it is simply halting the main thread . I wish I could use it.