转载自http://blog.csdn.net/musicvs/article/details/28226299
===========以下是回忆,是我对Auto-batching产生疑惑的过程,可以忽略不看=========
大家可以看看这个帖子:Cocos2d-x3.0 Auto-batching 三个小实验
对着这份文档看,以及调试源码,总算弄明白这个问题了。
简单地说,要绘制的精灵(应该说是Node)先存放到队列里,然后由专门的渲染逻辑来渲染。对于队列中的精灵,一个个取出来(其实存取的不是精灵,这里先简单这么理解),发现材质一样的话(相同纹理、相同混合函数、相同shader),就放到一个批次里,如果发现不同的材质,则开始绘制之前连续的那些精灵(都在一个批次里)。然后继续取,继续判断材质。
如果相同材质的精灵,中间间隔了不同材质的精灵,那也没法在同一个批次里渲染。
这就是那个问题的答案:为什么不连续创建的精灵(相同纹理、相同混合函数、相同shader)不能满足Auto-batching的要求,因为只要中间有不同材质的渲染对象,就会中断,会先把之前连续的相同材质的对象进行批渲染。
========================以上是回忆,回忆结束========================
渲染流程
现在,一个渲染流程是这样的:
(1)drawScene开始绘制场景
(2)遍历场景的子节点,调用visit函数,递归遍历子节点的子节点,以及子节点的子节点的子节点,以及…
(小若:够了!给我停!)
(4)初始化QuadCommand对象,这就是渲染命令,会丢到渲染队列里
(5)丢完QuadCommand就完事了,接着就交给渲染逻辑处理了。
(7)是时候轮到渲染逻辑干活干活,遍历渲染命令队列,这时候会有一个变量,用来保存渲染命令里的材质ID,遍历过程中就拿当前渲染命令的材质ID和上一个的材质ID对比,如果发现是一样的,那就不进行渲染,保存一下所需的信息,继续下一个遍历。好,如果这时候发现当前材质ID和上一个材质ID不一样,那就开始渲染,这就算是一个渲染批次了。
看官方的一张图就完全明白了:
(8)因此,如果我们创建了10个材质相同的对象,但是中间夹杂了一个不同材质的对象,假设它们的渲染命令在队列里的顺序是这样的:2个A,3个A,1个B,1个A,2个A,2个A。那么前面5个相同材质的对象A会进行一次渲染,中间的一个不同材质对象B进行一次渲染,后面的5个相同材质的对象A又进行一次渲染。一共会进行三次批渲染。
(小若:突然发现,第6条哪去了啊?被你吃了吗)
这么一说,太含糊了,我们再来一次,用代码来罗列。
首先是开始,简单点,看代码:
接下来,drawScene函数里有一小段代码(我就不贴全部了,多吓人):
if(_runningScene)