7

I am rendering objects via OpenGL, and got a nice smooth framerate of 60fps in most situations. UNTIL I do something heavy in a background thread, like fetching stuff from a REST API, processing it, and adding objects to the graph (low-priority stuff, I care more about UI fluidity). The renderer will then pause for a very long period, up to 1 second (ca. as long as the background thread runs), and then resume as if nothing had happened. I noticed this because an animation is started at the same time, and it gets stuck for this period. The background thread is set to minimum priority, and garbage collection does take up to 100-200ms, but not the whole second. When I set a debug point anywhere in the background task, rendering continues just fine, without any delays.

Is it possible that my heavy background thread starves the OpenGL thread? If so, what can I do?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
manmal
  • 3,900
  • 2
  • 30
  • 42
  • Looks suspiciously like [this performance trace](http://stackoverflow.com/q/9612959/1262542)... – Stefan Hanke Jun 27 '12 at 15:57
  • Dunno what GPU, it's a Galaxy Nexus. Gonna test it on the simulator when I get home. – manmal Jun 28 '12 at 09:03
  • Stefan, the thread you posted mentions "a little sluggishness", while I have a full second of no rendering at all. I don't think it's related. – manmal Jun 28 '12 at 09:05
  • _You need to prepend an @ before my name, otherwise I'll not be notified_. That trace clearly shows the threads not running parallel. Whether it's a small or heavy task, doesn't matter. You're right, I can't say it's really relevant... – Stefan Hanke Jun 28 '12 at 16:41

1 Answers1

1

Of course! A GPU needs to be fed data, and that's done by the CPU. So, if something in the system bottlenecks, like I/O or CPU processing, then the GPU can't get fed. For example, animation is traditionally done on the CPU. This is why you get a lot of games on the PC getting higher frame rates with the same graphic chips but with different CPUs.

I also agree that profiling is a very good idea. If you can, I would suggest profiling to make sure it's actually the REST call, or if the REST call is one of many things

One thing I noticed about REST processing, and this happened to me. Since REST sometimes processes a lot of strings, and if you don't use StringBuilder, you can end up firing off a lot of garbage collection. However, it doesn't sound like you are getting this.

Joe Plante
  • 6,308
  • 2
  • 30
  • 23
  • 1
    So, why should the scheduler be allowed to put a background thread before feeding the GPU pipe? It does not make any sense. If it is so, why did Google's engineers not just give that rendering thread a higher priority? – manmal Oct 24 '12 at 09:45
  • Sometimes it's Java having to free up RAM, especially in the case of a REST call, which tends to do a bit of string processing – Joe Plante Oct 26 '12 at 18:49
  • 1
    I already mentioned that garbage collection can't be the problem here, because GC pauses are not nearly as long. They are more like 100-200ms at max, not 1.5 seconds. – manmal Oct 29 '12 at 12:54