Android + OpenGL + Screen rotation

Hi, 

Am I the only one having application freeze on Android device rotation using OpenGL renderer? I did not find any message about this issue... However I get also this issue with JuceDemo so it seems not to be related to my app only.

I tried to suspend rendering, or to switch to default rendering engine on main window resize. I tried also the continuous repainting (instead of triggerRepaint usage). But still not working.... my app gets frozen after a few screen rotation. It is not crashed, because background threads are still working, but it looks like the main thread is blocked and do not perform any rendering.

Any idea?

Thanks,

/Phil

 

Thanks - we know about this one and will get it fixed as soon as poss!

Hi Jules,

In the meantime, did you had a chance to make some progress in accelerometer/gyro support such as discussed here (http://www.juce.com/forum/topic/reading-sensors?page=1)?

It would be just a workaround, but it is OK for me if I can detect that a screen rotation is about to occur, so I can disable OpenGL rendering before window size change.

 

Me... again.... :-s

In order to prevent the crash, since I can't handle device rotation before the resized(), I tried to enable only one desktop orientation using setOrientationEnabled().

But it seems that it is not supported under Android... I just found usage of isOrientationEnabled in juce_ios_UIViewComponentPeer.mm

WHYYYYYYYYYYYY ???? 

Really, I wish you better support Android platform, it should be a priotity. My customer is urging me to fix the "crash on rotation" issue, but I can't...... HEEEEELP!

 

We're aware of this! Fabian is our main Android-master and he'll get onto it as soon as we've got some other (also Android-related) stuff done.

OK...

=> Fabian, I promise you a BIG box of Belgian chocolates, but please solve this issue ASAP! 

Thanks! :-)

You can stop the orientation change by modifying the Android Manifest file. I threw in that hack for our quick work-around. It is something like:

[code]
<activity android:name=".SomeActivity" android:label="@string/app_name" android:screenOrientation="portrait">
[/code]

The reference is here:

http://developer.android.com/intl/ko/guide/topics/manifest/activity-element.html

Since the bug crashes the Juce Demo I kept hoping a fix would popup, though if it takes too much longer I'm going to have to go spelunking, ugh!

In Jule's & Co's defense, Android is a major pain in the #$%^ to debug on the NDK (C++) side. I've tracked down a few crashes/problems over the last couple of years when Jule's was too busy and it is always, and I mean always, a major pain.

 

Great! 

Thank you, this is a perfect work-around waiting for the Juce fix!

Yes I know that Android development is not so easy. For me it is already a miracle that Juce allows us to share code so easily between such different operating systems without being a guru on each platform :-)

Moreover I understand that Android is not a priority for Juce team since iOS is the main mobile platform in music domain, but I was surprised to note the pro-audio users expectation for Android apps... 

So I hope the Juce team is aware of this and that Android related fixes will be available soon ;-)

Actually, Android is a very big priority for us right now - lots of Android-related work going on!

Thanks Jules! Very good news! :-)

FWIW, this rotation issue is sort of a catch 22. I find that I use OpenGL more specifically because Android graphics performance doesn't keep up with the other platforms. Then Android turns out to be the most problematic OpenGL implementation...

I really wouldn't mind at all if I could ever figure out a reasonable C++/NDK debugging setup! I always seem to end up using the gdb command line and hand mangling function names!

As Jules already said, we are aware of the Android issues and they have high priority for us right now. In fact, beyond actually fixing the Android issues themselves, we are also actively working on providing a better experience for Android development with JUCE -- including a reasonable debugging setup etc.