8

I have a problem with very low rendering time on an android tablet using the NDK and the egl commands. I have timed calls to eglSwapBuffers and is taking a variable amount of time, frequently exceeded the device frame rate. I know it synchronizes to the refresh, but that is around 60FPS, and the times here drop well below that.

The only command I issue between calls to swap is glClear, so I know it isn't anything that I'm drawing causing the problem. Even just by clearing the frame rate drops to 30FPS (erratic though).

On the same device a simple GL program in Java easily renders at 60FPS, thus I know it isn't fundamentally a hardware issue. I've looked through the Android Java code for setting up the GL context and can't see any significant difference. I've also played with every config attribute, and while some alter the speed slightly, none (that I can find) change this horrible frame rate drop.

To ensure the event polling wasn't an issue I moved the rendering into a thread. That thread now only does rendering, thus just calls clear and swap repeatedly. The slow performance still persists.

I'm out of ideas what to check and am looking for suggestions as to what the problem might be.

edA-qa mort-ora-y
  • 30,295
  • 39
  • 137
  • 267
  • try checking if measurement itself does not eat time, just in case. – Vasaka Jun 28 '13 at 14:54
  • `eglSwapBuffers` is a blocking call in android and it does effect the fps sometimes. Also did you try `android:hardwareAccelerated` – blganesh101 Jul 04 '13 at 12:35
  • Can you post some code? Including your benchmarking code if possible. Usually, calls that "commit" an OpenGL state (a buffer swap might be one of them) screw up benchmarking because they're the ones that actually process all the previous commands you called. However, I'm not sure it's possible since you're only glClear'ing between buffer swaps. Anyways, let's see some code. – anthonyvd Jul 05 '13 at 03:36
  • @lukewm, can you followup? I'm quite far removed from this code now and not able to post examples/give details anymore. – edA-qa mort-ora-y Jul 05 '13 at 06:39

2 Answers2

3

There's really not enough info (like what device you are testing on, what was you exact config etc) to answer this 100% reliable but this kind of behavior is usually caused by window and surface pixel format mismatch eg. 16bit (RGB565) vs 32bit.

arcone1
  • 224
  • 2
  • 8
0

FB_MULTI_BUFFER=3 environment variable will enable the multi buffering on Freescale i.MX 6 (Sabrelite) board with some recent LTIB build (without X). Your GFX driver may needs something like this.

Ray
  • 5,269
  • 1
  • 21
  • 12