[官方大大关于2.0版本drawCall的问题 要了命了 看晕我了 求解答]

Creator 2.x
#1

B706A93CD20D7B4B1EF854724042E187.jpg1894×856 145 KB
BCC326D402A0397C37BA64EF787F45ED.jpg1938×1160 74.8 KB

image.png2298×1186 242 KB
<img
图一：使用图集来设置
图二：在2.0上的dc
图三：在1.9上的dc
很明显可以看到 1.9版本确实根据图集合并了dc 然而2.0并没有，同时2.0的dc是4很奇怪，即使没有合并dc也不应该是4啊？
复现方式很简单，2.0版本的creator新建工程即可。

另外疑问：我追了下creator的源码看到会有一个debug的Camera和这个有关系么？我自己做了一个测试后 发现更有疑问了。。

image.png1098×592 69.6 KB

如图我自己新建了另一个工程放了两个sprite和一个label
image.png2048×1126 271 KB

这次的dc竟然变成了3？我去竟然变成了我期望的效果。。可是为啥我上面会出现那个效果呢？

最后一个问题：
2.0的渲染引擎我看了下源码追了下，没发现哪里有batch的地方。RenderComponentWalker里倒是有一个变量batch的。。但是没发现有什么用。倒是看到了这么一段代码

image.png1668×522 56.5 KB

是在
image.png1544×226 29.7 KB

渲染流里根据二进制的flag走到这里的
这里看了下判断材质的哈希或者说cullingmask是否相等，不等的情况下直接flush这个时候会往scene中增加一个要渲染的model否则
image.png1348×1334 123 KB

会根据上图来填充一下vertex的数据也就是RenderComponetWalker持有的几个全局的缓冲buffer
image.png1552×246 30.7 KB

是这个来保证批次渲染的么？

@jare @panda @Knox 求大大帮忙解惑

#2

自己顶一哈

#3

我顶一个啊，说2.0性能提升很大，其实是开玩笑！！！！！！

#5

是显示问题么？dc？ 但是为啥合图并没有批次渲染哇。。按理说 texture的id应该是一样的 哇

#6

draw call 计算和显示没问题哈，官方没说过这种话

@hulifu 性能有大幅度优化是很多项目都有验证过的，目前 Web 平台的性能不论什么样的项目都是优于 1.x 的。

求各位别带节奏

1938×1160 74.8 KB

  • 1.9 的 debug 信息是使用 DOM 绘制的，所以不计算进 draw call 数量，而在 2.0 中是引擎渲染的，占用一个 draw call。
  • 2.0 中目前 Sliced Sprite 和 Simple Sprite 不能批处理，这是后面版本会优化的（本来的考虑是为了减少 Sliced 模式的顶点数量，数据计算和提交）

这个场景在 2.0 中的 draw call

  1. 背景 Sliced Sprite
  2. Logo Sprite
  3. hello label
  4. 左下角 debug 信息

2048×1126 271 KB

2.0 默认开启了一个 dyanmicAtlasManager，会在运行时自动对图像进行批处理，所以其实两个 Sprite 被合并了，这个场景的 draw call 是：

  1. 两个 logo Sprite
  2. Hello 文字
  3. 左下角 debug 信息
#7

意思说2.0以后不用再做合图了，所有Sprite 用散图就行了？

#8

感谢pandada大大的解惑，那看来多的dc就是一位debug信息也就是我断点看的PROFILE_NODE的原因吧？
还有就是 同楼下的疑问，以后都是散图就行了么？会自动处理么？

#9

http://forum.cocos.com/t/creator/66599老哥能帮我看下这个问题吗/