2

I have been struggling for quite a few days trying to understand why my OpenGL ES 2.0 application on Android is choppy. The frames per second are quite high, generally staying at a consistent 60fps, however the game does not appear to be smooth. After ruling out simple issues such as my timestep (the same application runs fine using OpenGL ES 1.0) and overloading the math and frames (the application has been reduced to a simple rotating triangle) I came across the OpenGL Trace.

I cannot find any information explaining exactly what is going on with the OpenGL Trace. So I am a bit in the dark here, but I am seeing strange behavior such as the glClear (mask = 256) function taking 2,533,190 nanoseconds of wall time and only 61,040 nanoseconds in thread time. This will happen once, then everything will be normal for a few frames.

Another example is glDrawElements. 274,684 nanoseconds wall time, 61,040 thread time.

This possibly suggests to me, with my trial and error approach to understanding any of the information in the Trace, that there is something going on under the hood that is causing the slowdown.

What does it actually suggest? Standard or strange behavior? If strange what are some of the causes of that behavior?

And if you would be so kind, can anyone point me to information so that I may understand what I am looking at in the Trace.

I'm doing my very best, and would love to be able to get back to work on my application. Thanks for reading.

Droid Smith
  • 31
  • 2
  • 1
    It is a very bad idea to try and time the execution of individual OpenGL (ES) API calls. OpenGL buffers these calls into a command queue and flushes them whenever the need arises (e.g. full queue, you actually manually request a flush, etc.) Draw calls are often a source of command flushing, many state changes that occur before the draw call have to be finalized and the cost of the draw call is actually quite variable. Timer Query Objects were introduced in desktop GL to time how long an arbitrary series of operations takes in the pipeline. No such analog exists in OpenGL ES unfortunately. – Andon M. Coleman Oct 29 '13 at 21:03
  • 1
    This is to say, that the amount of time taken for an API call to return has little to do with the amount of time it takes to execute the command... the API call has an obligation to do things like verify the input parameters and set error state immediately, but since GL is a client/server architecture the time taken to return is only half of the equation. Eventually the server executes the command(s) the API call generated, this is why you want to do pipeline-level (server) timing and not API (client) timing. – Andon M. Coleman Oct 29 '13 at 21:15

0 Answers0