Android: Go to background and touch handler

[solan-solan]

I caught the following case for Android application.

1. AppDelegate::applicationDidEnterBackground() was called (I know it since there was set global variable to indicate)
2. Then Java_org_axmol_lib_AxmolRenderer_nativeTouchesBegin(...) Was called (while I pressed many times on screen)
3. Touch handler should to create some buffers/texture/shaders but all glGenBuffers/glGenTextures/glCreateShader/glGetError return 0.

I just added Director::getInstance()->getEventDispatcher()->setEnabled(false) to AppDelegate::applicationDidEnterBackground() and revert it inside AppDelegate::applicationWillEnterForeground()

Now it looks that to help

[rh101]

I just added Director::getInstance()->getEventDispatcher()->setEnabled(false) to AppDelegate::applicationDidEnterBackground() and revert it inside AppDelegate::applicationWillEnterForeground()

That is a sensible way to handle it.

[crazyhappygame]

Should not we update our templates and add

Director::getInstance()->getEventDispatcher()->setEnabled(false);
...
Director::getInstance()->getEventDispatcher()->setEnabled(true);

here:

axmol/templates/cpp/Source/AppDelegate.cpp

Line 90 in 1fff0fa

void AppDelegate::applicationDidEnterBackground()

[crazyhappygame]

@rh101 I see that EVENT_COME_TO_BACKGROUND is use only to for ANDROID texture cache AX_ENABLE_CACHE_TEXTURE_DATA. Do we have plan to remove androit texture cache for next axmol version?

[rh101]

@rh101 I see that EVENT_COME_TO_BACKGROUND is use only to for ANDROID texture cache AX_ENABLE_CACHE_TEXTURE_DATA.

EVENT_COME_TO_BACKGROUND and EVENT_COME_TO_FOREGROUND may be used by Android, but they're not specific to Android. They are also used by WinRT.

Applications may also use these events to carry out tasks prior to the application going to the background, and after it comes to the foreground, so it wouldn't be wise to remove them. Also, I realise that applicationDidEnterBackground and applicationWillEnterForeground exist for such purposes, but there may be situations where a notification is required.

Do we have plan to remove androit texture cache for next axmol version?

I don't know; I personally don't use the cache, as having the application restart on a context loss is a much more reliable solution.

[smilediver]

We use texture cache on Android, so one vote for against removing this feature. :)

[crazyhappygame]

@smilediver most of us use now texture cache for android - this is axmol default for Android.
Why do you think that texture cache is needed for Android? All other engines I am aware (e.g.: gotdot, unity) does not have texture cache

[smilediver]

For reloading gfx resources when OpenGL context is lost. AFAIK Unity does support that.

[crazyhappygame]

@rh101 You are right EVENT_COME_TO_BACKGROUND and EVENT_COME_TO_FOREGROUND is triggered for winRT but I do not see usage... I agree we can not remove EVENT_COME_TO_BACKGROUND but maybe we should have this even triggered for all platforms for consistency.

[solan-solan]

There is one thing that Java code which calls Java_org_axmol_lib_AxmolRenderer_nativeOnPause works in the main thread, but all jni/axmoll functions work in the gl thread. Since that, it is needed to stop all gl activities right after 'go to background' accepted.

[crazyhappygame]

@solan-solan I am so sorry I do not undersand your comment. Could you clarify? Generally axmol/cocos2d-x is single threaded. Most operation (OpenGL Context, Scene Graph Updates, Event Handling) are exectuted on one thread. In the case axmol and Android it is UI thread.

[solan-solan]

@crazyhappygame
Really I am not so familiar with java part, and it was hasty confirmation from my side, but I realised to this data from the Android debuger. How can this be explained?

[rh101]

They are different threads, which is why any code that needs to run in the Axmol main thread needs tot use AxmolEngine.getActivity().runOnUiThread() or Director::getInstance()->getScheduler()->runOnAxmolThread.

Coming from Java_org_axmol_lib_AxmolRenderer_nativeOnPause, you just need to ensure that no calls are made to any code that needs to be run on the Axmol thread, otherwise you would need to wrap it in one of the above calls, but that may an issue, because if I understand it correctly, that code wouldn't be executed until the next loop. Given that the app has been paused, if the director is also paused, so running the main loop, then the scheduled call to run on the Axmol UI thread won't happen (I haven't checked if this is the case).

[solan-solan]

Thanks for clarification about it.
Do I properly understand, that there is some Java application thread, which get different events from Android and separate Axmol thread where Director works? And Java app should access to libAppname.so through the jni calls from the thread where Director exists?

[smilediver]

Yes, essentially there are 2 threads on Android: a UI thread and a GL thread. UI thread receives events like touches, and this is where the most of the Java code executes. This is a thread you can see named as a "main" in above screenshots. Btw, IIRC this is not the actual main thread, it just inherited name "main" because it was created by the actual main thread (but I may be wrong here, since it was awhile since I've checked it).

Then there's a GL thread which receives events to do the actual rendering and this is where "Director" works, ie, where main game loop executes. This is called as a "GLThread" you see in above screenshots. Btw, if GL context is lost, then this thread is destroyed and a new one is created when new GL context is recreated, so you must be careful if you use thread local variables.

So for example when a touch comes, it goes to the UI thread (AxmolGLSurfaceView.onTouchEvent()), then UI thread passes it down to the GL thread for processing using this.queueEvent(new Runnable(). Likewise, if something executing in main loop wants to run something in UI thread, then it calls AxmolEngine.getActivity().runOnUiThread().

[crazyhappygame]

@rh101 @smilediver @solan-solan
Thank you a lot!!!

Could you confirm my current understanding:

1. On Android applicationDidEnterBackground/applicationWillEnterForeground is running on Android ui thread not on axmol thread
   Therefore it is unsafe to access (and especially modify) anything axmol related (Director/Nodes/Button/Sprites etc) inside applicationDidEnterBackground/applicationWillEnterForeground
2. On All other platforms applicationDidEnterBackground/applicationWillEnterForeground is executed on axmol thread (I do not see runOnUiThread() call for other platform)

[smilediver]

No, it starts in UI thread, but then GL thread is notified and it does the rest of the job. The sequence is like this:

• App goes to background
• UI Thread: AxmolGLSurfaceView.onPause() is called:

  axmol/core/platform/android/java/src/org/axmol/lib/AxmolGLSurfaceView.java

  Line 199 in 31acc99

  public void onPause() {

• UI Thread: this adds a callback to be executed in the GL thread:

  axmol/core/platform/android/java/src/org/axmol/lib/AxmolGLSurfaceView.java

  Lines 200 to 205 in 31acc99

  	this.queueEvent(new Runnable() {
  	@Override
  	public void run() {
  	AxmolGLSurfaceView.this.mRenderer.handleOnPause();
  	}
  	});

• GL Thread: it sees there's a new callback scheduled, so it is executed and starts here:

  axmol/core/platform/android/java/src/org/axmol/lib/AxmolGLSurfaceView.java

  Lines 202 to 204 in 31acc99

  	public void run() {
  	AxmolGLSurfaceView.this.mRenderer.handleOnPause();
  	}

• GL Thread: this later calls Java_org_axmol_lib_AxmolRenderer_nativeOnPause(), which in turn calls applicationDidEnterBackground():

  axmol/core/platform/android/jni/Java_org_axmol_lib_AxmolRenderer.cpp

  Lines 46 to 54 in 31acc99

  	JNIEXPORT void JNICALL Java_org_axmol_lib_AxmolRenderer_nativeOnPause(JNIEnv*, jclass)
  	{
  	if (Director::getInstance()->getGLView())
  	{
  	Application::getInstance()->applicationDidEnterBackground();
  	ax::EventCustom backgroundEvent(EVENT_COME_TO_BACKGROUND);
  	ax::Director::getInstance()->getEventDispatcher()->dispatchEvent(&backgroundEvent);
  	}
  	}

Btw, you can see this sequence in above 3 screenshots, and see the threads in the debugger's view.

[crazyhappygame]

Thank you.

[crazyhappygame]

Should not we add to

applicationDidEnterBackground
Director::getInstance()->getEventDispatcher()->setEnabled(false);

and

applicationWillEnterForeground
Director::getInstance()->getEventDispatcher()->setEnabled(true);

as was proposed here: #1633 (reply in thread)