Call-to-OpenGL ES API with no current context and fatal signal 11

Recently, when using cocos2dx3.4, a JNI call was used to discover a phenomenon

When JNI is not used completely normal, all the text that uses JNI to go back becomes black block, and probability program crashes, comes with two log

Call-to-OpenGL ES API with no current context and Fatal signal 11

But the same cocos2dx, the same JNI code, the other project is normal. After a long search, I found the reason.

COCOS2DX 3.x later version is no longer a process run to the end:

Quote: "cocos2d-x from the 2.x version to last week just released Cocos2d-x 3.0 final version, its engine drive core is still a single-threaded" dead loop ", once a frame encountered" big job ", For example, a large size texture resource load or network IO or a large number of calculations, the screen will inevitably appear sluggish and unresponsive phenomenon. From the old Win32 GUI programming Then, the guru told us, "Don't block the main thread (UI thread), let the worker thread do the" big jobs ". Mobile games, even casual games, often involves a lot of texture resources, audio and video resources, file read and write and network communications, processing a little bit of the picture will appear sluggish, interactive situation. Although the engine provides some support in some ways, but sometimes it is more flexible to sacrifice the worker thread, the following is the Cocos2d-x 3.0 final version of the game as an example (for Android platform), say how to do multi-threaded resource loading. We often see a number of mobile games, start after the first display a company logo splash screen (flash screens), and then enter a game welcome scene, click "Start" to formally enter the main scene of the game. and the flash screen here often in the background will do another thing, that is to load the game's picture resources, music sound resources and configuration data read, this is a "fake" bar, the purpose is to improve the user experience, This allows subsequent scene rendering and scene switching to use the data that has already been cache to memory, without any further loading. "

The problem is that the new version of COCOS2DX actually has two threads openglview the drawing thread and the main thread of the program. When the JNI callback C + + function has similar sprite creation, deletion, modification and so on, the two errors will occur, causing the whole memory is chaotic.

After analyzing another normal project, I found that the JNI callback in this project did not do any action such as loading pictures, just updated the data and changed the text, so there was no big problem.

Analysis may be loading pictures such operations can not be done in the main thread, and the activity directly callback JNI is the main thread, so the solution is very simple, is to put the callback in the Openglsurfaceview as follows

Class EventHandler extends Handler {
@Override
public void Handlemessage (Message msg) {
{


Cocos2dxglsurfaceview.getinstance (). Queueevent (New Runnable () {
@Override
public void Run () {
Payresultcode (Mpayid, 0);
}
   });
}

}
}

The core is here, please pay attention to.

Call-to-OpenGL ES API with no current context and fatal signal 11