麻烦引擎组看看，这creator性能好像有点问题

Creator 2.x
#18

话说，现在native版本和webgl版本，有这两个的性能对比么。
不过webgl不同浏览器性能差距也挺大的
不知道如果webgl取最优情况下对比如何。

#19

laya的drawcall优化得确实非常好，native下
现有A图和B图
creator渲染顺序ABABABABABAB，如果循环1000次，drawcall得到的是2000，而laya的drawcall只有2

我做的游戏是在场景内下注筹码，筹码是4个不同颜色的图片，每次下注都是随机添加到场景中，creator的drawcall一直在增加，因为是4张不同的图片随机顺序渲染，场景筹码到一定的数量后，帧率就直线下降了
但我同样的方式在laya上做，筹码再多drawcall也只有4，当筹码达到1000个，creator的drawcall就是1000了，帧率只有12，但laya1000个筹码drawcall永远是4，帧率还是60，也就是说ABABAB循环越多，两者差距将会越来越大

creator还有个问题就是uuid很容易丢失，特别是删除文件，换文件名等操作，uuid一丢失图片就显示不出来了，我已经遇到过好几次这样的问题，场景都编辑好了，不知道弄了什么操作编辑器就会报一大堆错，找不到错误原因，然后删除mate文件让编辑器重新生成，结果uuid变了，场景里面图片全部不见了，为什么uuid的生成不用文件的md5，这样删除mate再重新生成uuid也不会变

#20

drawcall 问题确实存在，现在只能自己调整一下层级顺序，或者设置 zIndex。这一块的优化要看 @panda 是否有计划了。

这是因为你在编辑器外操作了资源。要操作资源请在编辑器内。

1.4 报错信息就详细很多了，可以看出错误原因

因为资源修改后，如果要更新所有用到这个资源的场景中的 md5，抛开性能不说，还会造成大量的 Git 冲突。

#21

目前Drawcall确实非常高，目前的合并规则就是按照场景树的顺序如果这个 的materialid和上一次rendercommand一致就合并，这样几乎是没有一个drawcall是合并的了的，实际项目中不可能用这种规则来构建场景

#22

你这里确实要注意到 像素填充率对性能 的影响 ，我感觉这个比drawcall更吃性能

#23

只看不说话。。。。 期待新版本！

#24

要多注意分层，把相同的尽量分到一层去

#25

@panda
那期待panda了，这问题是硬伤啊，弄了1个多星期的laya，不得不说laya的优化太牛B了，但编辑器和UI功能都没有creator好用
但是我觉得奇怪的是cocos2d-js的性能一直都很好，我用的是3.6，虽然有些小bug，但都可以用其它实现方式绕过，为什么creator的引擎不是用的cocos2d-js的

laya还有一个很方便的是热更新，超级好用，creator可以借鉴一下他的实现方式

#26

我们测试的结果不是这样的…… 仅凭感觉容易造成幸存者偏差

#27

目前使用的是creator 1.6.1。
问下这个ABAB渲染的问题，draw call还是很高，现在是用什么做法降低？

#28

希望大大们，优先解决性能问题～

我们也是laya换过来的。只从支持ts后，果断的换过来了，

然后和大大们一起期待ccc变强大～

#29

ABAB 问题，现在只能手动调整层级关系来避免了。
@panda @pandamicro 重写渲染引擎后，会支持 globalZOrder，到时改起来会方便点。

#30

@jare 大大，这次drawcall优化，有没有一个时间表呢？
@panda 能看到吗？

#31

期待cocos creator变得更好。

#32

他看到了，没有具体时间表，估计没那么快

#33

没事，1.7 肯定会有这方面的优化。
坐等。。。:slightly_smiling:

#34

这个是 2.0，不是 1.7

#35

好漫长的期待。一切都是值得的。

#36

AB放在一个图集里，不管放多少个drawcall都是1

1赞
#37

这是正解,放在一个图集 就一个drawcall