JuceDemo's very sluggish on Samsung Galaxy S3

Ok, I discovered that these GC messages were caused by a repaint() in a timer in my code. If I comment the repaint() out I don’t get these messages in a loop, so this was misguiding.

But I still have strange issues: each repaint() calls in my app generates GC_FOR_ALLOC and GC_CONCURRENT messages, but also mouse events:

Each time I press a component in my app, when mouseDown gets called, these messages appears (and the app slows down). What is really strange is that I still get these messages even if the mouseDown implementation is empty! I really don’t get it, but I’ll try to make a minimal app to locate the problem more precisely.

Apparently the problem comes from the Component::paint() method.

I can reproduce this problem with a very simple introJucer project. Here’s the test component used:

class TestComponent: public Component
{
private:
	bool pressed;
public:
	TestComponent()
	{
		pressed = false;
	}

	void paint(Graphics &g)
	{
		if (pressed)
			g.setColour(Colours::red);
		else
			g.setColour(Colours::white);
		g.fillAll();
	}
	
	void mouseDown(const MouseEvent &e)
	{
		pressed = true;
		repaint();
	}
	void mouseUp(const MouseEvent &e)
	{
		pressed = false;
		repaint();
	}
};

Then I added this to the private members in MainWindow.h

TestComponent * testComponent;

And here’s the constructor implementation in MainWindow.cpp:

MainAppWindow::MainAppWindow() : DocumentWindow ("Juce Android Lag", Colours::white, 0) { setOpaque(true); testComponent = new TestComponent(); testComponent->setBounds(10,10,200,200); addAndMakeVisible(testComponent); setTitleBarHeight(0); setFullScreen(true); setVisible (true); }

Since my MainAppWindow is set to opaque, I added a paint method to it:

void MainAppWindow::paint(Graphics &g) { g.setColour(Colours::black); g.fillAll(); }

With this test app, each mouseDown and mouseUp events generate these messages on recent android devices:

If your apps are running faster on older, single-core devices, bear in mind with newer, multi-core devices you could be having thread-affinity problems. Android could be scheduling the next timeslice of your code to run on a core that is powered down, for example.

see http://miss-cache.blogspot.se/2013/01/android-running-native-code-on-multiple.html and
http://stackoverflow.com/questions/7467848/is-it-possible-to-set-affinity-with-sched-setaffinity-in-android

[quote=“0xDEADBEEF”]If your apps are running faster on older, single-core devices, bear in mind with newer, multi-core devices you could be having thread-affinity problems. Android could be scheduling the next timeslice of your code to run on a core that is powered down, for example.

see http://miss-cache.blogspot.se/2013/01/android-running-native-code-on-multiple.html and
http://stackoverflow.com/questions/7467848/is-it-possible-to-set-affinity-with-sched-setaffinity-in-android[/quote]

Interesting read, but here there’s no particular threading involved as it’s reproducible with just a minimal GUI; except maybe some threading Juce could use internally (repaint ?), I don’t know.

I’m not sure if this is the case, it was just a thought. Even if the paint() method is on a single thread, between invocations it could be context switched out to allow another processes thread to run on the powered-up core and then context switched in again on a different core that is spun-down at the time. If one can test to set the affinity of the GUI thread to a certain core and this ameliorates the problem, then at least one would know where to start looking. Of course it is likely nothing to do with this as the kernel scheduler should just work™

This topic solved the issue for me : http://www.rawmaterialsoftware.com/viewtopic.php?f=13&t=9839

Now I have working Juce apps on all android devices, yay! :smiley: the downside being to be only android 3.0 and later compatible…

Btw, I just noticed that on the android developer website:

[quote]Don’t create render objects in draw methods
A common mistake is to create a new Paint or a new Path every time a rendering method is invoked. This forces the garbage collector to run more often and also bypasses caches and optimizations in the hardware pipeline.[/quote]

This could be one of the reason why the paint methods in Juce triggers all these GC messages.

I'm still undergoing catastrophic results with the JuceDemo on the same Galaxy S3. About 4 fps without OpenGL and crash if I enable OpenGL.

I've tried one of the suggestions with setting the flag hardwareAccelerated to false in the AndroidManifest file but didn't change anything.

It really looks that they are two threads competing indeed and the GUI one gets utterly slow down.

Doesn't seem to bother any other jucer though, am I still the only one who wants to develop an app on Android with Juce in 2013? :)

If not done already, try updating Juce to the latest version, and enable OpenGL rendering for 2D components, it helped me a lot.

 

Sorry about reviving an ancient thread, but the problem still exists in 2020, and the link you shared is broken now, do you still remember how you solved the problem?