drawcalls（_drawnBatches）分析

一、drawcalls是什么？

在引擎调用glDrawElements（函数介绍详见2.6.3）绘制图元的时候，_drawnBatches都会+1，从而可以看出_drawnBatches就是用来记录定点绘制过程中，顶点缓冲区告诉GPU渲染就会增加，可以当作图元绘制过程中的一个性能指标

二、代码分析

_drawnBatches的+1地方

其中：

1）_batchedCommands保存了当前需要显示的所有的图元单元，比如一个精灵等

2）cmd->getMaterialID();是材质ID，其生成材质ID的地方的代码如下：

可以看到纹理ID一样的时候，混合的src和dst一样的情况下，其材质ID会一样

3）纹理ID，在加载一张图片的时候，会将图片信息保存在texture对象中，这个对象就是纹理，并调用glGenTextures生成纹理的ID，一张plist生成的合图是一个texture对象

4）当使用A图片的时候，如果A图片是单独一张图片，则会调用下面函数，如果纹理已经存在（根据路径判断），则会返回这个纹理，如果不存在，则创建，故同一路径的图片，其纹理ID是一样的

三、drawcalls优化方案

从上面可以看出，drawcalls的优化是：

1）使用合图可以大大降低drawcalls,理论上合图有n张图片就可以减少n-1次

2）使用相同的纹理的节点最好是层级一致

3）骨骼动画drawcalls以上优化无效

4）场景显示的节点越少，drawcalls也会越少

注：文本控件，每一个控件不管文字内容是否一致，都会生成一个纹理，其纹理ID 都是不一样的

参考:http://forum.cocos.com/t/drawcall/43273/9

参考： https://www.2cto.com/kf/201407/318618.html（具体如下：）

Cocos2d (v.3.0) rendering pipeline roadmap

Why (the vision)

The way currently Cocos2d does rendering is good but it is beginning to feel somehow antiquate and moreover it doesn’t actually leverage modern multi core CPUs so popular nowadays on most modern tablets and mobile phones.

So we want to re design Cocos renderer, for making it more performing, elegant, scalable, flexible but still simple to use and to understand. Also we want to maintain that same familiar API that current Cocos2d users will feel immediately comfortable with, without having to bother about what’s changed or new under the hood.

We will do this maintaining the same key cornerstone concepts Cocos2d users get

to know and like as Scenes, Nodes, Layers, Sprites.

What (the goals)

Here is a high level view of the new features and improvements we would like to achieve in Cocos2d v.3.0:

Decouple the scene graph from the renderer

Visiting nodes issues graphics commands and put them on a queue, but doesn’t actually invoke any OpenGL rendering code

Viewing frustum Geometry culling

Sprites (and geometries more in general) not visible from the camera’s point of view be automatically removed from the current frame and not rendered

Rendering on a thread

The execution of all the rendering commands (i.e. OpenGL calls) will be moved to different thread than the main one (this will allow for better parallelism and usage of more than one CPUs cores where possible)

Automatic batching

Efficiently reduces the number of draw calls (automatically) batching them together when possible (i.e. sprites using the same material)

(Node based) Customizable rendering

As in the current version of Cocos, users will still be able (if needed) to customize rendering on a per node basis, calling OpenGL commands directly, disregarding the official renderer (but possibly incurring on worst performances)

How (the plan)

Central to the new design is the notion CommandQueue. While visiting a node, rendering will not call OpenGL commands directly anymore (as currently is the case); it will instead push CocosGraphicsCommands to a queue. Commands In the queue will subsequently be read by the rendering backend, processed as needed and pushed to the actual rendering API (i.e. OpenGL) (see picture)

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 Z喎�"https://www.2cto.com/kf/ware/vc/" target="_blank" class="keylink">vciBDUFUgZXhwZW5zaXZlIE9wZW5HTCBjb21tYW5kcyB3aWxsIGJlIHRoZW4gZXhlY3V0ZWQgZnJvbSB0aGUgYmFjay1lbmQgIHRocmVhZCwgbGV0dGluZyBDb2Nvc6GvIG1haW4gdGhyZWFkIGZyZWUgY29udGludWUgd29ya2luZyBvbiBwYXJzaW5nIHRoZSBzY2VuZSBncmFwaCBvciBkb2luZyBvdGhlciBub24gcmVuZGVyaW5nIHJlbGF0ZWQgdGFza3MuIFRoaXMgd2lsbCBoZWxwIHBhcmFsbGVsaXNtIGFuZCB3aWxsIGFsbG93IGZvciB1c2luZyBtdWx0aSBjb3JlIENQVaGvcyAoc2VlIHBpY3R1cmUpPC9wPgo8cD4gPGltZyBzcmM9"https://www.2cto.com/uploadfile/Collfiles/20140720/20140720085737320.png" alt="\">

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