Closed kenny-uken closed 6 years ago
Here's a picture of our profiler while running our AR game, and then later running the HelloAR scene.
The yellow spikes are the mentioned EarlyUpdate.TangoUpdate
calls.
I downgraded our SDK to Preview 1, only making a few API changes to our code (Frame.GetNewPlanes and renaming enums) and the framerate 60fps or near-60 on a Pixel 2.
Meanwhile one of my colleagues found out that we can get much better fps (not as good as preview 1 but 30-40fps) if we background the app and then resume it; I presume this manually cycles the pause / resume functionality of ARCore.
Disabling "Match camera framerate" seems to also help a lot.
You're running into exactly the issue that had us put that workaround in to call resume on the UI thread (what the workaround you mentioned in #73 deleted). Pause/resume addresses the issue because that forces ArSession_resume to get called on the UI thread.
We're working on a fix to #73 on our end and I really appreciate your investigation so far -- it'll help us verify our fix. I'm going to close this as I am certain this is fallout from your workaround.
You can use my PixelFix linked in #70 for a workaround for ARCore Preview 2, which will address the framerate issue in addition to supporting Pixel devices with the Play Store version of ARCore.
edit: Disabling "Match Camera Framerate" in your settings will improve performance dramatically, as will backgrounding the app and resuming it
We are currently profiling our build using ARCore Preview 2 because we are getting very low fps (5-10). The culprit is a call to
EarlyUpdate.TangoUpdate
with no stacktrace. I am looking around at functions related to EarlyUpdate in the SDK (namely this one https://github.com/google-ar/arcore-unity-sdk/blob/master/Assets/GoogleARCore/SDK/Scripts/Managers/SessionManager.cs#L99) but it looks like that's intentionally being called every frame simply to update the game. Resume is not being called every frame like I thought it might be.We have made a small change to the SDK which I describe here (https://github.com/google-ar/arcore-unity-sdk/issues/73#issuecomment-358441294) which may be directly related. However, reverting that change makes ARCore inoperable so we can't really test that meaningfully.
In the HelloAR app (without the SDK changes mentioned above) it seems to eat about 15ms or so, which is a fraction of what we're seeing on our own project. It makes me wonder if there's something else we're doing that is causing that update (which seems like it's outside our control) to eat so much performance.