Just a tip for people that may not know about the “on-demand rendering” api Unity implemented a while ago. Great way of lowering FPS where it is not needed with all the impact that has on your device.
Sorry if you seen this before
++
Just a tip for people that may not know about the “on-demand rendering” api Unity implemented a while ago. Great way of lowering FPS where it is not needed with all the impact that has on your device.
Sorry if you seen this before
++
Thanks i did not know this at all!
Excellent info to know when developing for mobile.
It’s a useful feature and there is more discussion of it in the original beta thread.
It should be noted though that when a frame skips being rendered some callbacks in Unity may or will no longer fire such as WaitForEndOfFrame. I also discovered recently in 2019.4.21f if using the Unity Device Simulator package and a world space canvas that the canvas will only be visible for the rendered frame and disappears for non-rendered frames causes it to flash on and off. This only happened in the Device Simulator view and not the game view and may well be addressed in 2020 where the Simulator is now native to Unity editor.
Overall point being it’s a great feature but has a couple of gotcha’s to watch out for.
I haven’t been able to get this work with UI yet and apparently at least one other person has the same issue:
All canvases disappear for one frame whenever the renderFrameInterval is changed, meaning that I can only modify it when there is absolutely no canvases visible (which is never). I don’t use the Device Simulator, so that is not the cause.
EDIT:
Oh, it works if I change the interval only when willCurrentFrameRender returns true
Strange i’d not noticed any problems with other canvases, but that WillCurrentFrameRender tip sounds interesting will definitely explore that a bit more.
THANK YOU! I was the one filing that bug report 8 months ago. I’d noticed that the bug happened about 2/3 of the time when going from renderFrameInterval 3 to 1, but didn’t make the jump to realising it happened exactly when willCurrentFrameRender is false… Seems like an obvious correlation in retrospect, but that’s hindsight for you
Seeing as the flickering made the feature completely unusable for me I just put it aside and hoped they would eventually fix it. I just tried it again now though and your workaround works great.
Again, thank you so very very much!