cocos creator 2.1 文本渲染分析。为啥创建Label性能差？

Posted 2023-04-23

参考技术A

拿 creator 制作了个排行榜页面，不到20个Item,一个Item里只有两个 Label :名称和关卡。
发现在微信小游戏中打开，会卡顿。 对页面的创建过程计时，发现主要耗时在创建 Label 上。遂来分析下 cocos creator 2.1 的文本渲染流程。
感叹下，能看到源码真是太好了~~
求教，厦门有什么好的游戏开发的交流渠道呀，群也大都死水一潭，现实中也找不到交流的同好和空间。感觉太封闭了
回归正题...

cocos creator 的文本渲染有两种:

其中采用系统字体的，应该也是归属于 ttf 中。
涉及到的文件有：

还有其他相关的文件也是跟文本渲染相关，但是本文聚焦在 2d 、 webgl 和 ttf 渲染上，其他的就略过。

Label组件作为属性的容器，并在属性变更时，调用 _updateRenderData
Label的 _assembler 的定义在 core/renderer/webgl/label/index.js 找到
根据类型，找到 _assembler 的实现在 core/renderer/webgl/label/2d/ttf.js 中
core/renderer/webgl/label/2d/ttf.js 继承了 core/renderer/utils/label/ttf.js

通过 _getAssemblerData 可知，所有的 Label 组件共享同一个 canvs 元素

updateRenderData 做实际的文本计算（字体、宽高、基线等），并绘制纹理。

_updateTexture 首先清空 canvas （注意，此canvas全局唯一，所有TTF Label共享的)
然后绘制描边，绘制文本，有需要的话，绘制下划线，最后调用 _texture.handleLoadedTexture 将 canvas 提交到 gpu 纹理上。

以上可知，每个 Label 的创建，都要经历清空重绘 canvas ，然后提交纹理的步骤。每个 Label 的纹理都是单独的，并没有重用。
当时在微信小游戏上测试，平均创建一个 Label 耗时约30ms,创建十几二十个 Label ，感知到明显的卡顿。 最终弃用ttf label,改用 bmfont label避开这个问题。感觉这里有优化的空间？

一直以来，好奇 cocos creator 的描边实现，自己一直往 shader 那边，什么纹理扩边，卷积啥的去想。
实际上：
在文件 core/renderer/utils/label/ttf.js 第255行：

cocos creator锚点分析

参考技术A 锚点（Anchor） 是节点的另一个重要属性，它决定了节点以自身约束框中的哪一个点作为整个节点的位置。我们选中节点后看到变换工具出现的位置就是节点的锚点位置。
1.锚点由 anchorX 和 anchorY 两个值表示，它们是通过节点尺寸计算锚点位置的乘数因子，范围都是 0 ~ 1 之间。(0.5, 0.5) 表示锚点位于节点长度乘 0.5 和宽度乘 0.5 的地方，即节点的中心。

2.锚点属性设为 (0, 0) 时，锚点位于节点本地坐标系的初始原点位置，也就是节点约束框的左下角。

3.锚点属性设为 (1, 1) 时，锚点位于节点本地坐标系的右上角。

同理，锚点在其他位置是，直接在该位置画坐标系即可知道节点A下节点B的位置。

4.如果改变节点锚点时，会以原来锚点原点为标准。

以上就是对creator锚点的分析，不知道各位看懂了木有。。。