Some discussion on Cocos2d-x multi-Threading rendering

Feasibility:

The game cycle mainly includes these parts: 1, hardware events, mainly refers to touch screen events, key events and mouse events, 2, game events, mainly refers to timer events and pre-defined events, such as schedule;3, game logic, for the fat script end, this refers to the script logic; 4, rendering data generation, Inside the engine is the node's visit, which calculates all the data that will be sent to OpenGL, including attribute data such as vertex texture coordinates, uniform data such as transform matrix textures, mixed mode and other rendering states; 5, All data is sent to OpenGL via the OpenGL interface. In these steps, only the fifth step involves the OpenGL operation, and the previous four steps are prepared for the fifth step, and the fifth step does not need or seldom requires the feedback data to the first four steps. This is a typical producer-consumer model, where the overhead of very low thread synchronization takes the form of multithreaded processing.

Necessity:

Processing game logic (including the first four steps) takes too much CPU, and sending data to OpenGL can be time consuming, especially when multiple render state transitions are involved. Separating the two on multicore CPUs can improve parallelism and improve the game frame rate.

Some programmes:

A big change after cocos2d-x3.0 is not to render in visit, but to generate render commands in visit, and send commands to the render class cache, waiting for a moment to process these commands, rendering. This is a typical command pattern, as long as the data that is guaranteed to be executed by these commands is different from the main thread (the execution threads of the game logic), and the thread safety is ensured by the lock-up and the data mutex of the main thread. Most of the data we can create a copy in visit (actually draw), and for fewer numbers but each containing a large number of vertex data, we can do mutual exclusion by locking, such as particle system. Fewer thread mutexes do not cause too much thread traffic overhead. The main loop of the game is to perform the four steps related to the game logic first, and then tell the render thread that the data is ready with the condition variables. We can also use a dual-cache system, which creates two render command caches, where the main thread logic can send rendering commands to another cache when the render thread uses a command cache for rendering. If the main thread logic does require OpenGL processing to get some data, we can also use some of the less efficient compromises. The main thread sends commands to the render thread in a way similar to schedule, and then waits for the render thread to maintain one such command queue, with each cycle prioritizing the queue and notifying the main thread when processing is complete. This practice is not easy to use. As an example, create textures synchronously and generate sprites, and this is where the texture parts need to be placed on the render thread. In fact, the game logic does not need to care about what the texture really looks like, the main thread can not wait until the rendering thread processing to complete the texture and then continue to run, the rendering thread after the completion of the texture, the main thread through schedule, the main thread update the Texture2d object's texture ID can be, greatly improve efficiency.

Some discussion on Cocos2d-x multi-Threading rendering