Creator 版本号：1.4.2
运行时目标平台：android和浏览器
电脑浏览器上webgl模式渲染1500以上就只有42帧，我电脑是i74790K，16G的win7
android真机性能比较差：
小米3，渲染300以上，帧数大概在40左右
三星S6，渲染700，帧数只有30了
下面图片第一张是电脑浏览器的
这是用了系统字体引起的，目前系统字体还没有办法做 batching，会导致 drawcall 比较多。建议改成 bitmap font
好的，我试一下
这次确实有点大失望了，翻了一下几个月的帖子，发现creator的性能确实是个大问题，建议官方重点解决这个问题，要不然creator没法用，一个场景drawcall随便都要上300，真机android300以上只有30帧了，这根本没法用啊
cocos2d-js貌似都没有这样的问题，昨天把游戏做得差不多了，跑了一下真机，就傻眼了，游戏场景20帧+，用户体验实在太差了
可以直接建一个空场景测试，就一个简单的for循环，循环内部就做简单的加减法，然后循环1000万次；分别运行在web和android手机，就可以发现效率不在一个级别。
spidermonkey版本太老了！
1赞
原生平台性能确实比较差，我们已经准备进行底层升级了。这里的 drawcall 还是太高了，对 benchmark 来说有点吃力。建议跑 benchmark 时要多利用自动合图，把 drawcall 降下来。
我现在就是在求性能优化的版本，月底能出吗？
除了 Jare 提到的 draw call 以外，渲染性能受到填充率的影响同样非常大，你渲染的像素数量越多，性能就越低。你缩小这个 UI 圆钮的尺寸也可以获得性能的提升，所以并不是说 creator 在这些环境下就只能跑这么多 draw call
我们目前已经开始做 Spidermonkey 的升级工作，也开始了其他方面的性能优化，需要一些时间，这个月底确实是不可能
这就比较尴尬了，一个场景500个drawcall，一个对象2-3个drawcall，500个也就100多个对象，确实不多，我用layabox的写的同样的场景，用手机浏览器跑1400个对象，5000个drawcall，帧数40，相信以前cocos2d-js的也能跑1000+个对象，不知道creator为什么和cocos2d-js的性能为什么相差如此之大
如果是 web 的话，我们经过几轮优化，差距没有你说的 10:1 那么夸张，在特定场景下可能性能会差一点但不会差超过一倍。如果是评估实际项目，我这边测试的在手机上能比 -JS （3.13）快 23%
而且桌面浏览器和手机浏览器的性能在初始化的性能差别有点大啊。我哪怕是用6的苹果机打开一个多item的界面都会卡顿2-3秒，桌面基本上是秒开。
当我在cocoscreator里面编辑了碰撞区后，我有没有办法在不启动碰撞功能的情况下，获取每个碰撞区的数据啊？（如四边形）四个点坐标，我这边因为要用这个功能，我想用这个碰撞数据自己做碰撞检测。
填充率还是非常非常重要，你可以对比一下 laya 做出来场景的像素分辨率以及 creator 的像素分辨率（canvas.width 和 canvas.height，不要用引擎 API 获取）。cocos2d-js 或者 creator 为了更好的显示质量，一般都开启了 retina，canvas 的真实像素数量一般要比设计分辨率高。
话说，现在native版本和webgl版本，有这两个的性能对比么。
不过webgl不同浏览器性能差距也挺大的
不知道如果webgl取最优情况下对比如何。
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也不会变
drawcall 问题确实存在，现在只能自己调整一下层级顺序，或者设置 zIndex。这一块的优化要看 @panda 是否有计划了。
这是因为你在编辑器外操作了资源。要操作资源请在编辑器内。
1.4 报错信息就详细很多了，可以看出错误原因
因为资源修改后，如果要更新所有用到这个资源的场景中的 md5，抛开性能不说，还会造成大量的 Git 冲突。
目前Drawcall确实非常高，目前的合并规则就是按照场景树的顺序如果这个 的materialid和上一次rendercommand一致就合并，这样几乎是没有一个drawcall是合并的了的，实际项目中不可能用这种规则来构建场景
你这里确实要注意到 像素填充率对性能 的影响 ，我感觉这个比drawcall更吃性能