Cocos2d (v.3.0) rendering pipeline roadmap
?The rendering backend (running on his own thread) will in turn pop graphics commands from the queue, process them and actually execute them. Any locking or CPU expensive OpenGL commands will be then executed from the back-end thread, letting Cocos’ main thread free continue working on parsing the scene graph or doing other non rendering related tasks. This will help parallelism and will allow for using multi core CPU’s (see picture)
?With Cocos2d-x 3.00 we also want to introduce the concept of automatic batching. ?In fact we believe reducing the number of draw calls and render device state changes will improve drastically rendering speed.
In order to achieve very good batching, we would like to introduce also a new concept of “attributes” for Layers (formally CCLayer). There are going to (at least) 3 new Layer attributes:
?
Unordered
Static
Batch
Unordered Layer (formally CCLayer)
We want now focus on Unordered Layers, which are going to help achieving auto batching for improving rendering performance.
Rendering order in Cocos2d is dictated by the “order” nodes are arranged in the scene graph (see picture)
?This is still going to be true still in V.3.0 unless the Layer is tagged as Unordered.The Unordered attribute will instruct the Layer to disregard rendering order for all of his children (see picture)
?The graphics commands will then be put in the CommandQueue and a special “unordered tag” will be place in the command queue as well for instructing the rendered to disregard the order and re arrange graphics commands so to render all the primitives using the same material in one draw call. Rendering all primitives (that use the same “material”) in one go will make rendering much faster, especially on mobile devices.Static Layer
?
Layers tagged as static, will be treated as if all children will not going to be translated/rotated/zoomed (transformed) during the entire lifespan of the layer. This will allow Cocos performing expensive operations as matrices concatenation or computing culling information (i.e. quad-tree) only once (typically before the first rendering pass) improving drastically performance. Note that sprites in a static Layer can still be “animated” as far as they’re not transformed or scaled.
Batch Layer
?
A batch layers will behave very similarly to how a Batch Node (CCBatchNode) currently works in Cocos2d. All the children of a batch layer will HAVE to use the same “material” thus allowing the front end to combine all the draw calls for that layer in one single one. (Erroneously) Adding children that use a different material to a Batch Layer will trigger an Assert ().
Automatic Culling
?
To do
Rendering context (RenderBucket, RenderTarget, Camera, viewport)
?
To do
Rendering and materials system
?
To do
Customize rendering for nodes
To do
?
转载：https://docs.google.com/document/d/1nDX131S-k_XwKHkh7CjP4yC4pmywLk8Do3kMtyrRYwI/edit?pli=1
