iOS: component animation crash/bad performance


#1

Hello,

Have been having problems with Component Animator performance on iOS, and now I'm also getting crashes. Generally works pretty smoothly when using Core Graphics renderer, but when using OpenGL renderer things are really bad.

To reproduce:

- Run Juce Demo in simulator on on a device

- open Tabs & Widgets component, choose "Use OpenGL Renderer" from the Look and Feel drop down menu

- open Animation component. start pressing buttons. note that there is a lot of choppiness in animation. (If you want to see the slowest game of Angry Birds ever, you can also go to the Box 2D demo while using OpenGL renderer ).

- if you keep tapping buttons you will eventually get a crash like so:

Thread 1 Juce Message Thread, Queue : com.apple.main-thread
#0    0x03b7d7ca in __psynch_cvwait ()
#1    0x03b42d1d in _pthread_cond_wait ()
#2    0x03b44bd9 in pthread_cond_wait$UNIX2003 ()
#3    0x002a84a3 in juce::WaitableEvent::wait(int) const at /Users/nhdika/Code/JUCE/modules/juce_core/native/juce_posix_SharedCode.h:76
#4    0x003917f3 in juce::MessageManagerLock::BlockingMessage::messageCallback() at /Users/nhdika/Code/JUCE/modules/juce_events/messages/juce_MessageManager.cpp:232
#5    0x0038c146 in juce::MessageQueue::deliverNextMessage() at /Users/nhdika/Code/JUCE/modules/juce_events/native/juce_osx_MessageQueue.h:79
#6    0x0038c09a in juce::MessageQueue::runLoopCallback() at /Users/nhdika/Code/JUCE/modules/juce_events/native/juce_osx_MessageQueue.h:90
#7    0x0038c057 in juce::MessageQueue::runLoopSourceCallback(void*) at /Users/nhdika/Code/JUCE/modules/juce_events/native/juce_osx_MessageQueue.h:99
#8    0x046c777f in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#9    0x046c710b in __CFRunLoopDoSources0 ()
#10    0x046e41ae in __CFRunLoopRun ()
#11    0x046e39d3 in CFRunLoopRunSpecific ()
#12    0x046e37eb in CFRunLoopRunInMode ()
#13    0x053ff5ee in GSEventRunModal ()
#14    0x053ff42b in GSEventRun ()
#15    0x02292f9b in UIApplicationMain ()
#16    0x00570e65 in juce::juce_iOSMain(int, char const**) at /Users/nhdika/Code/JUCE/modules/juce_gui_basics/native/juce_ios_Windowing.mm:95
#17    0x0037df00 in juce::JUCEApplicationBase::main(int, char const**) at /Users/nhdika/Code/JUCE/modules/juce_events/messages/juce_ApplicationBase.cpp:211
#18    0x000027c0 in main at /Users/nhdika/Code/JUCE/extras/Demo/Source/Main.cpp:91

 

 

Thanks,

Nick

 


#2

meant to include the Juce assertion message I get on this crash:

JUCE Assertion failure in juce_OpenGLGraphicsContext.cpp:1034

that's in bindTexture()

 


#3

Jules, I hate to be a nag about this but it's one of my only stop-ship bugs and I'm lost. Do you have any idea what might be going wrong here?

n


#4

I can't reproduce any problems in the simulator, and the stack trace is a bit of a mystery, I'm afraid.

Does it always go wrong in that same place?


#5

It does seem to always go wrong in the same place. 

Anyway, aside from the crash are you seeing the choppy animation problem? I had thought they might be related, but maybe they aren't. This is actually as big an issue for me as the crash as it means I can't ship with any component animation. That would be more than a bit unfortunate in an iOS app.

 


#6

I didn't see any choppiness in the animation either! I'm just using the simulator, not a real device, but you said above that you also had problems in the simulator?


#7

yep, it's just even worse in the simulator. are you sure you're setting it to use the OpenGL renderer first?


#8

Yes, I did that of course.. All seemed OK to me though. Are some demos particularly bad?


#9

Hmm. Can't figure why I'd be seeing this but you wouldn't, that's odd. One thing I've noticed is clicking around to the different demos will sometimes reset the demo to use core graphics renderer. So perhaps be sure to follow the repro steps above exactly. It's also quite obvious in the Box2d demo that the rendering slows down massively when using OpenGL renderer. I would expect this to some degree in the simulator, but on a device it is also terrible. 

Another way to reproduce what I'm seeing would be to add a button to the OpenGL teapot demo that fades the overlay component in and out using a ComponentAnimator. Set the teapot to spin quickly then click the button. You'll see the teapot grind to a halt when the overlay component is fading in and out. This is the most similar case to what I'm doing in my app, and it happens whether I use a proxy component for the animation or not. 


#10

It's more noticable if you run the simulator for iPad Retina. 

Also, I just instrumented the demo on my iPad and looked at OpenGL performance on the component animator demo. It's interesting. I could send you the trace via email if you like. 


#11

Well, there's a lot more pixels to push there. Sure, I'd take a look at a trace if you want to send one over.