3.0的2D渲染10000个三角面在iPhone微信小游戏上掉帧



搞个位图文本,输入很多字
都是在iPhone微信小游戏里测试
左边是 Cocos Creator 2.4.4,满帧,右边是 Cocos Creator 3.0.0,掉帧严重
安卓或 iPhone Safari 没问题。
以前我在用 Cocos Creator 3D 时就有这个问题。

1赞

标记一下疑惑回来看。也在做2d游戏也想用3.0去开发了

有几个疑问

  1. 渲染的是 Label 吗?
  2. 为什么 3.0 版本的适配那么奇怪,是不是项目配置有区别,比如 camera
  3. Label 的 cache mode 选择是完全一样的吗?

嗯,跟 Label 没关系,跟 Camera 应该也没关系

用 2.4.4 新建一个 Hello World,把代码和背景去掉,logo复制个几千份,然后分别安卓和苹果,微信小游戏,微信自带浏览器,系统自带浏览器测试走起,没问题,都满帧:


再用 3.0.0 新建一个空项目,导入上面 2.4.4 的项目,重复相同的测试,只有苹果微信小游戏掉帧:


NewProject.rar (2.7 MB)
NewProject_3.0.0.rar (4.0 MB)

应该是跟微信小游戏不支持JIT有关系,引擎在处理这10000多个三角形的信息时消耗过多CPU;
2.4.x应该是优化过这方面。

谢谢详细的测试反馈,由于 3.0 底层是一个新的渲染器,相比 2.x 确实复杂不少,在数据组织上不能套用 2.x 的逻辑,我们做了一些额外的适配,目前还没有做好优化,之后会在这方面继续改进。不过这个测试用例也是一个极端用例,我们会针对更泛用的场景进行优化

坐等引擎组更新!我觉得ios上解决了卡顿问题的时候就是creator起飞的时候吧!

也不算太极端吧,稍微复杂点的UI(一个字算俩三角面,一个小图也算俩三角面)就会降帧:

这个问题我是在去年3月份用Creator3D时发现的,当然还有一些其他问题。
没辙了就拿Creator把游戏重做了一遍。

嗯……自己尝试了一下,比我想象的麻烦很多(我原本以为先找到3.0比较耗时的操作,再抄一抄2.4.4的代码就搞定了)。
这四块各贡献了大约10毫秒,加起来一帧就几十毫秒了:

把这块注掉能快个几毫秒:


当然注掉是不可能注掉的,注掉就没画面了。

也不是没收获,在上下求索的过程中发现这篇资料:
https://www.zhihu.com/question/21320960?rf=22502132
进而发现这个iPhone应用:

如果 WKWebView 满帧,UIWebView 掉帧,就实锤是不支持JIT的问题了。

可惜没找到能在PC上禁用JIT的浏览器,不然就更方便了。

下午又来活了,坐等引擎组更新吧。

1赞

chrome 启动参数 --js-flags="--jitless" 可以禁用jit

1赞

测不出来,可能我电脑性能太好了


有个小坑,必须是第一个 chrome 实例才能正确传进去启动参数
https://www.it1352.com/2007495.html

–js-flags= 不能丢Lark20210226-095326

1赞

试验成功


UI 渲染的重构从 3.1 版本发布之后就开始了,不过确实有不少坎坷,本来打算 3.3 释出,但是打磨的仍然不够好,所以推迟到 3.4 版本,新的方案会让 CPU 和 GPU 的负载更加均衡,对大多数游戏的性能更加友好

1赞

3.4何时出啊,我们项目从半年前开始立项,想着我们花半年的时间做游戏,cocos花半年的时间总能把3.x的性能提升到和2.4.4一个级别吧。所以立项的时候选用了3.x。 现在还有1个月项目就要做完了,iPhone 微信小游戏上的性能还是差强人意。全GPU粒子,iPhone 8p上只能跑28帧,2018年的vivo手机却能稳定50帧。 :cold_sweat:

你们的性能热点在哪里?

项目比较大,迟点等项目告一段落,我试着准备一个demo。

目前先提供一下profile供您参考:

这是录了一场战斗的profile,大约30秒,整场战斗只有开始时有一处跳帧,该处的profile如图一所示。

(图一)

Main.ts 占比29%,由于层级太深,以下是几个比较耗时的操作
setParent - 不停的从池中拿出单位,显示,设置父节点
particle-system - 由于要动态改变整个粒子效果的大小,所以每次从池里拿出来,会计算一下数值。其中force-overtime, velocity-overtime, 需要反激活再激活才生效,这里在profile里占了不少比重,如图二所示

(图二)

particle-system.ts 占比11%,如图三所示

(图三)

skeleton.ts 占比9%
这个比较意外,因为只用了4个spine,而且都非常简单,每个骨骼数只有2个。考虑完全去掉spine

剩下的占比是frameMove(我认为这个应该是引擎代码,我们除了减少场景的元素,没有其他很好的优化方式,不知道对不对)了,34.8%,如图四示所示

(图四)

如果查看整场战斗的profile,那么frameMove占比会提高。如图五所示

(图五)

总的来说消耗比较平滑,没有特别消耗的地方,就是东西比较多(同屏最多25个怪,5个英雄,10个子弹(特效),受击特效,受击飘字,死亡特效),不停从池里拿出,放回。
其次每个特效基本都用了自己写的shader

================================分割线===================================
如果把chrome的jit禁用,那么frameMove占比会显著提高,以下是同一场战斗禁用了jit后的profile

准备的比较匆忙,如果需要其他信息,我可以再提供 :grin: