Android LibGDX: FPS crashes due to long calls EGLImpl.eglSwapBuffers
I am working on a game for Android platform using Java engine and LibGDX.
I am having a weird problem where the FPS in my game constantly drops every 30-40 seconds from 57-60 to 40-45 frames and then returns. Below are screenshots of the logcat output. The garbage collector fails at these points (nothing is filtered from the log):
I did some profiling and found out that the problem is caused by calls to EGLImpl.eglSwapBuffers taking longer than usual every 30-40 seconds. The screenshot below (taken while profiling the game menu when nothing happens at all) takes 3.7ms:
In my pumping loop for the menu, I just call MyStage.act () and MyStage.draw () which draws a set of ImageButtons - nothing special. My frame render time for the menu (average 17ms) also seems too long for such a simple render, but those long, periodic, long buffer calls boil down to my main problem.
By the way, if I profile the profile during gameplay, it gets worse - these calls to EGLImpl.eglSwapBuffers take 15ms or more and reduce the FPS to 30 and keep it permanently:
I could actually use some advice on how to research this.
source to share
You need to understand what substitution replacement means. This means that you tell OpenGL what you have done with sending all the "render commands", and now it can send the finished rendered image to the screen to render it.
What does it mean? This means your graphics card has finished rendering everything! Most GL calls return immediately without blocking. This means that your processor will continue to work, and the GPU will work in parallel, processing its turn of received render commands from the CPU.
Now, if your CPU can run much faster than your GPU, swapping buffers means the GPU must finish processing an entire queue before it can actually swap the buffer and return.
All in all this means that the problem is not with the actual eglSwapBuffers, which are taking so long, but simply that your GPU cannot keep up with the processor. This means that your scene is too complex, for example, that you have too many state changes like texture bindings, shader switches or something like that.
So by profiling the CPU side you really won't find the real problem. But I cannot tell you where the problem is. Since you are using libGDX GLProfiler
may help you here.
PS: A sudden change in FPS can also be the cause due to your device switching to power saving mode.
source to share