As the title suggests I am having issues with v-sync on android. I've set the v sync Count to Don't sync in the qualitySettings panel for the used quality level. However when i run my application on the samsung galaxy S6 its having a constant fps of ~15 due to waiting on vsync to happen (where it is ~60 fps with some spikes to 30 without v-sync).
profiler with v-sync tracked:
profiler without v-sync tracked:
As you can see it is crealy caused by v-sync happening. What i find strangest about this is that this only started happening a couple of days ago, and was working fine before. Even going back to a commit that 100% worked before v-sync starts messing it up.
I'm using Unity 2017.2.1f1. And have not done any updates to my android version.
Could this be caused by my phone forcing v-sync in some way (or is it happening becuase it is in VR using a samsung gear? and if it is can i turn that off somehwere?
EDIT: Running my application in the editor doesn't have the issue and V-sync doesn't happen at all, neither does it try to v-sync when i'm running the application on a onePlus 3 in non-vr
Related
First of all thanks for taking the time to read this question - we're thankful for any input/suggestions/thoughts.
In our Unity game, we're seeing a problem that we cannot solve for weeks. At random points in the game, the FPS drops to zero and nothing moves for 3-4 seconds, then everything gets updated in 1 frame as if the freeze has not happened. It seems it's a rendering problem because absolutely nothing goes wrong with the game's logic and functionalities, everything works as expected after the mini-freeze. Even the user's touches in that time window are processed afterward.
Clues:
Unity version: 2019.4.31f1
Optimized Frame Pacing: Disabled
Use incremental GC: Enabled
Target Architectures: ARMv7 + ARM64 built as an AAB file
Scripting Backend: IL2CPP
Graphics API: OpenGLES2
Application.targetFrameRate : 60
Vsync count: Don't Sync
Multithreaded Rendering: Enabled
Additional Information:
It is not a full freeze. New frames do get rendered if you wait long enough.
In the unity profiler we can see, that when the issue occurs the main thread seems to be waiting for "gfx.presentframe" on the render thread.
We could reproduce the issue on these devices: (All are 64-bit, Androids are 11 or 12)
Samsung Galaxy A30
Samsung S20 FE
Xiaomi Poco X3
Samsung A21s
Huawei Honor 50
Samsung S22 Ultra
Our problem is exactly like this Question, The difference is that in our game, Optimized Frame Pacing is already disabled, so disabling it cannot solve the issue for us.
Here's a Screenshot of the Unity profiler when this problem occurred, Look at the selected frame.
We are really stuck with the problem and any helpful thoughts or suggestions will make us smile! Thanks in Advance!
My Samsung Galaxy Note 4 received an OTA update to 6.0.1. I have Android Studio 2.2.3. Before the update my debugging speed was OK. Now it is about 100 times slower, and pretty much unuseable - it takes literally minutes to hit a breakpoint. Nothing else changed in my environment as far as I know, other than the update to 6.0.1. What can I do to get normal debugging speed back?
Check if you have not added any method breakpoint. That's usually the main reason behind the significant slowness of the debugging speed.
Follow the few steps below if that the case:
Go to the debugger and select view breakpoints
Make sure the Java method Breakpoint is unchecked.
Just wanted to share an experience I had to see if anyone came across such issue, if they found the cause and more importantly how they fixed it.
The problem is pretty simple: while debugging native code on a Nexus 6, which as the Adreno 420 GPU, eglSwapBuffer could crash under certain circumstances when using Android 5.1 (5.0 worked perfectly).
Since I could not repro it I am unable to tell you what went wrong. According to the documentation, elgSwapBuffer calls internally glFlush; and so if I call glFlush before calling eglSwapBuffer all of a sudden it works perfectly.
My guess is that the driver does not flush properly thus crashing when swaping the buffers.
Any comments on this?
Cheers,
D
I'm having the same problem and I can reproduce it. It happens obviously because it runs out of stack memory due to deep nested loops in the rendering process.
Android Lollipop 5.1: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x9e985ff8 in tid 4093 (RenderThread) / when using lot of nine patch graphics
I've already reported it to the google issue tracker:
https://code.google.com/p/android/issues/detail?id=163100
Update: Meanwhile I found a way to work around this issue. It's definitely not a long time solution, but for the moment, it's just the best available to stop my apps from crashing.
I disabled GPU rendering for particular graphic layers. It slows the drawing down a bit, but not significant.
So the nightmare is over for now, but I still think, this issue must be fixed on the driver itself. It cannot be that something that worked perfect with 5.0.2 and below, immediately stops to work with 5.1.
I have seen some weird behavior on the N6 as well, and while I cannot rule out app bugs, it looks to me like the Adreno driver is to blame.
Specifically, in landscape mode, our GLSurfaceView only renders one half of it's content, but occasionally flickers all of it. And with certain scenes being rendered there is intermittent flickering. In a case of extra weirdness, I have seen one half of the screen completely freeze, stuck on app content, even after returning to the launcher via the home button. It appears kind of like it would if it used multi stream transport and one of the streams was getting lost.
I'm developing for android (API 14) deploying for Nexus One on Genymotion simulator and to a Galaxy Note N8000 tablet, but my app it's having a strange behaviour: in one of the activities, when I press the back button, the app shows the right activity but my debugger disconnects.
Using the simulated Nexus One I have a log message related to OpenGL out of memory and I've found out that OpenGL support for simulators it's usually bad, but using physical note n8000 I have nothing in my logs that can help me. The app behaves like it should but I loose debugging.
Does anyone had a problem similar to that? How did you fix it?
I face the same issue sometimes, my guess is that the Exception actually forces application closing (disconnecting it from debugger), but somehow it gets automatically restarted restoring the previous 'state'.
In your case, maybe is just a simulator issue, but you should consider testing in a real Nexus One device, just to make sure.
I got strange behavior on my galaxy tab 10.1 (4.0.4) and SGS 3 (4.1.4)
DDMS profiler shows that Bitmap.nativeCreate extremely slow. And 97% of cpu time take VMDebug.startGC()
Another tablet Lenovo IconTab (4.1.1) works pretty well and profiler doesn't show any any abnormal GC execution.
So my application performance greatly differs on Lenovo and Samsung devices.
There is no any Debug.start_anything_() in my code.
I tried to make debug and release builds, run from Android Studio, and manually copy release apk to device. Reset devices to factory default. But it still extremely slow and profiler show .
Any ideas what could provoke VMDebug.startGC()?
It may be late but this issue may turned out to be caused by too much object allocation. You can check this article for reference.