有没有办法工程重回1.10啊，我都要崩溃了。
cc.EditBox中调用maxLength, 出现错误
maxLength: {
tooltip: (true, “i18n:COMPONENT.editbox.max_length”),
default: 20,
notify: function() {
this._impl.setMaxLength(this.maxLength);
}
},
其中this._impl为undefined。
说了叫先备份的。怪谁呢？！
setLocalZOrder这个用什么代替2.0，this.node.setLocalZOrder找不到了
话不能这么说。用2.0.0的哪个不是用在项目里面。再说我有备份。
2.0 不支持这种环境的运行
我在联系另一个开发者提供 demo，他遇到的是同样问题，我要重现后才知道原因
要参数做什么？
用 zIndex
需要在 Editbox preload 之后才能设置，我加一下保护
我看了一下，确实是不能够多 spine 一起批处理，是因为在 spine 的 shader 中，我们直接使用 spine node 的 matrix 作为 model 计算 MVP 矩阵，这样做可以节省在 CPU 中对 spine 所有顶点的世界坐标计算，收益非常大。但是由于不同 spine node 的 matrix 不同，所以 uniform 不同的情况下，是不可以批处理的。算是用 GPU 时间换取 CPU 时间，总体来说我们认为收益还是非常大的，除了极限情况
这改成自动的就可以，但是不能每次导入图片都改一次吧··
能知道点哪回来的啊，scene, query, relaunch 啥的啊
onShow带的参数东西不少呢，只是有些东西不知道啥意思。至少官方公布的那些还是要的
{“relaunch”:false,“scene”:1008,“reLaunch”:false,“scene_note”:“6502902275@chatroom:wxid_90v9c5vmjmsr21:1_wx04adebd6ca03209e_1190072403_1533879069_0”,“sessionId”:“SessionId@113164589#1533879156230”,“usedState”:2,“prescene”:2,“prescene_note”:“6502902275@chatroom:wxid_90v9c5vmjmsr21”,“clickTimestamp”:1533879156336,“query”:{}}
粒子系统加载异常
let node = new cc.Node();
let particle = node.addComponent(cc.ParticleSystem);
particle.file = cc.url.raw(‘resources/atom.plist’);
this.node.addChild(node);
报错 [cc.loader.load] resources must be non-nil.
为什么每次关掉prefab后，层级要全部展开并跳到最前面？节点多的时候找回去真痛苦~~
请问假设能保持 matrix 一致（我理解的一致：坐标一致，动作一致，那么计算出来的矩阵应该是一致的吧？）的情况下是否能保证drawcall不增加呢？
如果这个假设成立，我测试了一下发现drawcall还是会增加。
@panda 使用2.0测试了一下工程 发现同屏超过30个以上spine节点时（其中有同资源spine）性能反而不如1.10 ，很明显可以感受到，渲染压力太大导致的卡顿。fps里面render的耗时保持10以上。。。
然而在1.10中依赖同资源并存与一个父节点，可以保证低渲染压力。。
合并drawcall遍历渲染树的时候能加一种类似广度优先的遍历方法么，
图标列表什么的，用深度优先的遍历方式基本很难合并drawcall。因为图标上各种元素基本都是来自不同的图片集。
还有滚动列表可视区域外的drawcall似乎没有去掉。
第一张截图里大概有60个图标
第二张截图里是16个图标
第二章图里算上每个图标上的数字，drawcall也比第一个少的多
1赞
不能这么加载，要先用 cc.loader.loadRes 加载 particle 资源
我反馈一下
现在没有做这么细的判断，对于 spine 来说，因为两个节点完全重合的概率非常低，所以没有做这种优化。
你说的测试，是这些 spine 节点都可以批处理的情况下，如果你的游戏中 spine 角色很多的话，且不论你是否有办法把这些 spine 贴图都合并，也不论你是否能够将这些 spine 节点放在同一个层级下，至少我们可以说你的游戏相对比较重度。那么游戏逻辑一定不会少，尤其是控制 spine 动画，碰撞检测，战斗逻辑等，在我们观察下，相对重度的游戏，绝大多数情况下瓶颈都在 CPU，而不是 GPU，固然降低 draw call 很重要，但是针对瓶颈优化才是最有价值的。
可以大致算一下 2.0 这种做法节省的计算损耗，如果要批处理，所有顶点必须是全局坐标，那么 2.0 节省的计算量是：
Spine 个数 * 顶点数量 * Mat4 矩阵对顶点 vector 的乘法
尤其是使用了 mesh 的 spine，这里节省的计算损耗就更显著了
滚动列表还是建议尽量复用，你的第二张图是怎么做的？
第二张图就是总共只有16个图标，可视范围外没有图标
更新了2.0后，文字变模糊了，连fps的显示信息都是模糊的文字，怎么解决呢？
同样希望官方支持广度优先的渲染顺序，虽然我们定制引擎实现了这个功能，但是不支持有遮罩的节点，自己改的，用的也不放心
1.9.3这样加载木有问题啊，一直用得好好的
那你咋不继续用 1.9.3 用啥2.0