JuceDemo's very sluggish on Samsung Galaxy S3


#1

Hi,

I’ve just compiled the latest build from Git in order to try it out on our new Samsung Galaxy S3 (Android 4.1.1) at work.

So, after struggling with setting up the ant build script on my Mountain Lion (just a tad… no worries), I’ve finally managed to compile the juce_jni module and to deploy the JuceDemo on the phone successfully.

To be honest, I didn’t expect that to be that easy.
In fact, I had a very bad experience last year when I tried building that up from scratch… until I finally reached the point of starting to tear my hair out (which turned out to be damn painful indeed cuz, judging by your avatar, it seems to be as long as your Jules :wink: ).
Anyway, so no big issues encountered along the road on that side…

But god! It turns out to be slow as hell so far.
The default demo (without any advanced animation enabled) hardly reaches the 10 FPS, and it drops to ca. 3 FPS if I enable all the fancy animations in the bottom-right corner.
I first compiled it with the SDK r10 so I thought this could have explained such bad performance, so thereby I’ve updated the project to build for the SDK r16 (Android 4.1.2)… and no big changes here the performance are still unbelievably slow.

Am I the only one experiencing that?
I thought the Samsung Galaxy S3 was supposed to be renowned for being a quite powerful smartphone, if not the best actually.

Cheers!

PS: Originally, I wanted to upload the tiny video that I’ve made earlier but it seems the 17 MB are perhaps a bit too much for the forum. Too bad.


#2

Hi!

Just to mention, I just tried that out as well on a Samsung Galaxy Tab II and the performance wasn’t good neither.
I’ve got an average of 20 FPS and it drops to 10 FPS when enabling the animations.

Judging by the other feedbacks, I’ve got the feeling that I’m the only one who’s been encountering these problems. So I guess I might be doing something wrong here perhaps.

Cheers,


#3

Well, android uses the software-based renderer by default, and now that high-res screens are starting to appear, that’s really becoming non-optimal, because of the sheer quantity of data it needs to move around. You might want to try using the openGL renderer, which should be faster on bigger displays.

(Also you didn’t mention whether you were using a release build. If not, that should go considerably faster)


#4

Hi, I haven’t got an Android product but I was just wondering if you see any performance differences when using the OpenGL renderer (selectable from the Look-and-feel menu).

EDIT: Jules beat me to it!


#5

Yep, everything was run with the openGL renderer enabled from the Look-and-feel menu.

Well I must confess I was only profiling with the debug version, didn’t know it could make a big drastic change with the performance.
I mean… I know those dudes are like chalk and cheese but the “place for improvement” seems to be pretty big here.

I’m gonna test that right away and tell you more about that afterward. :arrow:

Cheers!


#6

oops


#7

Unless I’m doing something wrong again, release doesn’t make much of a difference here, sadly.

I don’t know, perhaps you could shed some light on what I’m doing wrong:

  1. ant release
  2. Run the release of JuceDemo from Eclipse

This just can’t be the reason. My colleagues and I played for a while yesterday with the Need For Speed game coming along with the factory partition and it ran seamlessly.


#8

Hi guys!

Back from holidays, and still got the same issues happening here. I was wondering whether somebody would know a bit more about that in the meantime?

Btw, I’ve just watched a video on Youtube where the guys from MoSync are benchmarking WebGL vs OpenGL on many handheld devices.
And some results were odd… not to say completely contradictory and unexpected.
It turns out that sometimes it seems WebGL is way faster on the most recent devices than OpenGL itself. It might explain why Juce is so sluggish on my devices, likely?

Cheers!


#9

first baby steps on Android and I can confirm it works but it’s slow indeed:

on my Nexus 7 JuceDemo (release build) reports a render time of about 45ms. This is the out-of-the-box graphics demo with just position being animated. Screen size is 760x832. OpenGL renderer is enabled (software renderer takes about 75ms). On my PC this render time is about 1ms, so 45 times faster!

So assuming this is as good as it gets for standard Juce GUI components, what would be the best strategy for (dramatically) speeding up animated graphics while still using standard Juce components/drawing primitives for the less critical UI parts?
Would handcrafted OpenGL code be a solution? Can this be drawn on top of regular Juce components?

(BTW this question applies equally well to IOS, although I have to admit that JuceDemo OpenGL render times are somewhat better here: 16ms on an IPad 1)


#10

I’m also experiencing poor performances, but only on recent devices.

I have a juce test project that runs fine on a Galaxy S1 and a LG E300, but it’s horribly slow on a Hero 9300: with a single square button on the screen, there’s a huge latency when you press it (only about 5 touch/display updates per second)


#11

doing my first steps on android…(galaxy nexus). When even a ipad 1 has a better performance, which has a much slower cpu, i suppose there is just a stupid performance bottleneck somewhere…

Did anyone tried to profile?
http://developer.android.com/tools/debugging/debugging-tracing.html


#12

[quote=“shini”]I’m also experiencing poor performances, but only on recent devices.

I have a juce test project that runs fine on a Galaxy S1 and a LG E300, but it’s horribly slow on a Hero 9300: with a single square button on the screen, there’s a huge latency when you press it (only about 5 touch/display updates per second)[/quote]

I am experiencing this exact thing as well. Samsung Nexus and Nexus 7 seems to be about 5 a second whereas the older devices are instant. It seems to be worse with OpenGL. If you run the demo and go to the slider demo page it is silky smooth on Software but switch to OpenGL and I’m lucky to get the 5 fps. Sliders lag horribly. This is all under release builds too. Switching rendering contexts will also hang the app on the new devices but will not on my Galaxy S1 or older LG. TBH, I have not done any profiling yet.


#13

I think that this slowdown is related to a garbage collector issue. When I debug my app on a recent android device, I get hundred of messages like this:

On my Galaxy S, the app runs fine and all these messages doesn’t appear.

It seems that something in Juce gets reallocated at every frame, and causes this.

I didn’t have a chance to investigate further (it wasn’t my own android device), but the problem may come from handlePaint in ComponentPeerView.


#14

Could be font rendering, I guess… That’s the only obvious place where a lot of allocations would happen when drawing. Sounds like we may end up having to use freetype on android by default.


#15

It may be related to fonts indeed.


#16

I made some tests today and it can’t be related to fonts, or at least not font display.

I have these garbage collector messages with a fullscreen app with just a SVG button on it.


#17

Some more analysis with a Sony Xperia LT28H, android 4.04:

It seems that a 1-byte array get allocated and freed in a loop and causes this (hightlighted in the screenshot):

When debugging I see the largest allocation size of this 1-byte array quickly alternate between 1MB and 3.5MB. On my Galaxy S1 this byte array is only 2.148KB and doesn’t get reallocated/freed.

And here we can see the garbage collector pausing the main thread because of this allocation loop:


#18

Puzzling… Looking through the code, there’s only one place that allocates a byte array, and that’s in WebInputStream, so very unlikely to be the cause. If some other OS class is allocating a byte array internally, I’m not sure how to track down the culprit…


#19

Since it’s something that apprently only occurs on multi-core devices, maybe it’s a threading problem?


#20

No… that doesn’t seem likely to me. Threading all happens at the posix level, there’s no reason why any java object allocations would be involved.