GL Thread Priority

Hey jME Android devs,



Have you guys looked at raising the priority of the GL thread on Android? I was just looking at smoothing out stuttering in my jME-based app, and found that raising the priority of the GL thread helped quite a bit. Turning it all the way up to MAX_PRIORITY is working well for me, but I haven’t tested enough to see if that starves anything else more important.



With that, my app runs pretty smoothly even on a Nexus One running Froyo, though what it actually does in jME is very simple.

3 Likes
@sbarta said:
Have you guys looked at raising the priority of the GL thread on Android? I was just looking at smoothing out stuttering in my jME-based app, and found that raising the priority of the GL thread helped quite a bit.

Nice catch, thanks.

How does the device work with that thread being MAX_PRIORITY? Can you still minimize the app and load it later? Or perhaps lock the phone with the app visible and then unlock it?

@Momoko_Fan said:
How does the device work with that thread being MAX_PRIORITY? Can you still minimize the app and load it later? Or perhaps lock the phone with the app visible and then unlock it?


I haven't seen any issues with the thread at MAX_PRIORITY; going home to the launcher and restoring the app works okay, and no issues with locking the phone. We'll see if our QA department comes up with anything when they test the app, but it looks good so far.

There's a huge caveat, though, and that is that my app isn't a game but a data visualization tool, and its 3D usage is very, very simple -- probably two dozen texture-mapped quads, no lighting, special effects, jME-supplied animation, or anything else (I'm using jME because it's much easier than programming straight to OpenGL -- I drew the line at having to learn shader programming). As such, my GL thread isn't going to be very busy, so even with it running at MAX_PRIORITY, it shouldn't affect the system too much. In a different scenario where the GL thread had more to do, perhaps setting the priority that high might be bad, certainly on a single-core phone.

With that said, it would definitely be worth looking into setting the priority in jME, maybe in AndroidHarness with a way to override it in case it's causing problems.

I see also that jME-Android doesn’t obey AppSettings.setFrameRate (though I’m running an old code drop, and perhaps you’ve added it, though I didn’t see it in the SVN head). True?



Googling it led me to a Stack Overflow article that said that Android doesn’t really support framerate limiting in OpenGL the way it should, so you have to hack it by putting sleep statements in the render thread. I’ve got that in my app right now, and that makes me feel a little better about running it at such a high priority, though FWIW it’s only yielding about 25% of its CPU time back on my target hardware and target framerate. I don’t see much extra jitter in the animation, though, so it’s probably worth doing for the battery savings alone.

I think there is in fact some code that limits fps but I am not sure if it actually works. In any case, android has vsync enabled by default so either way you’re limited by 60 fps. The info about the thread priority is useful. I think that on honeycomb you might be fighting with the UI thread for access to the GPU since the UI is hardware accelerated on those platforms

@Momoko_Fan said:
I think that on honeycomb you might be fighting with the UI thread for access to the GPU since the UI is hardware accelerated on those platforms

..but normal jME3 apps don't use the UI..

How can i raise the priority of the GL thread on Android?



Thank you

@akramfares said:
How can i raise the priority of the GL thread on Android?

Thank you


Standard Java API calls, which the Android VM obeys:

Thread.currentThread().setPriority(...)
@Momoko_Fan said:
I think there is in fact some code that limits fps but I am not sure if it actually works. In any case, android has vsync enabled by default so either way you're limited by 60 fps. The info about the thread priority is useful. I think that on honeycomb you might be fighting with the UI thread for access to the GPU since the UI is hardware accelerated on those platforms


In case anyone interested, I think that piece of code works. A couple of days ago I tested it by changing minFrameDuration on OGLESContext to 30 (currently it is 0, meaning no cap) and was able to cap the frame rate to 33. To do that I extended class OGLESContext and load it in as the Context object.