Animating on iOS ... not fast enough?

[DukeRoodee]

Hi all (and of course Jules

there’s this iOS App which I’ve developed in the last few weeks, using Juce.
It’s really a charme using Juce, so I dont have to stick to ObjectiveC and all that Cocoa stuff

There’s one issue… drawing speed. Imagine I have a control component which consists basically of an animated background and a (bitmap or whatever)-control that you can move around on this canvas (something like a x/y corrdinate slider). The components canvas itself is about 80% of the (i use) iPods 4G screen size.
I use a timer (like in Juce gui demos) to repaint the canvas regularly, so i can animate.

After experimenting a lot, i measured the fps rate with the performance tool (core animation). Surely the measurements will not be 100% accurate, but they reflect the impressions that i had seeing the result on the iPod.

I get a max. of around 40 or 45 fps when running the paint method without actually painting anything.
Something around 14 or 15 fps when painting a png image as background (using drawImageAt(…), image slightly smaller than canvas, so there’s no scaling )
and something around 4 or 5 fps when additionally drawing a few moving resp. growing circles… (this is only a part of what i finally would like to animate).

I am afraid, this is by far too slow… also the slider reacts really slow.

I read some topics in theis forum and followed advices such as building for optimized arm7… however, i am really no expert in graphics and guis and still kind of new to Juce… so forgive me if this all sounds dumb.

There are a few questions that arise.
First… do i maybe just overestimate the iOS hardware ? (the app runs like a charm in the simulator)
Otherwise … is there something i can do to speed up the painting ? There are some topics talking about softwareRenderers and so…i think i understood that iOS painting is already implemented using native coreGraphics, so relatively fast and optimized for the hardware ?

What i finally need is solid 15 or better 20 fps (when additionally playing 8 audio tracks from file simultaneously…but this doesnt seem to be the problem).

I’d appreciate any kind of advice

Thanks
Rudi

[symfonysid]

People typically use OpenGL for doing anything requiring those sorts of frame rates on an iOS device. As other threads on this forum have remarked, the GPU in those sorts of devices are much better for that purpose than the CPU.

[jules]

Juce uses CoreGraphics for its rendering, and I’m in the process of adding more pervasive GL support, so there shouldn’t be much that you could do natively that would be faster than using the juce UI code. For really efficient game-like animation, GL would certainly be the best plan.

[DukeRoodee]

symfonysid, jules,

thank you
OK, so it seems CoreGraphics is not the way to go for me… i have absolutely no idea of GL, would be a reason to learn, right ?

I thought i read somewhere in the forum, that there is no possibility of putting Juce control components “on top” of the openGL display (iOS). Is this true or am i just talking bull**it ? The reason why i ask this is because i need such a control :-/

Another approach for me would be using a movie as background, and Jules, you once gave me the advice to use UIViewComponent (with MPMoviePlayerController, i guess?). I am not really good in ObjC and am currently failing at compile time … something with the separation of ObjC and C++ ( “#if OBJC” ). Is there a project around that does something like this, so I can see how its implemented ?
Another question would be if you’ll add a movie component for iOS in the near future … ?

regards,
Rudi

[jules]

that there is no possibility of putting Juce control components “on top” of the openGL display (iOS). Is this true or am i just talking bull**it ? The reason why i ask this is because i need such a control :-/

That’s why I’m building a new GL renderer - you’ll be able to render the whole UI using GL, so juce + GL drawing can be mixed. Still work-in-progress though.

Movie component - yes, soon!