拿creator制作了个排行榜页面，不到20个Item,一个Item里只有两个Label:名称和关卡。
发现在微信小游戏中打开，会卡顿。 对页面的创建过程计时，发现主要耗时在创建Label上。遂来分析下cocos creator 2.1的文本渲染流程。
感叹下，能看到源码真是太好了~~
求教，厦门有什么好的游戏开发的交流渠道呀，群也大都死水一潭，现实中也找不到交流的同好和空间。感觉太封闭了
回归正题...
cocos creator的文本渲染有两种:
- bmfont
- ttf
其中采用系统字体的，应该也是归属于ttf中。
涉及到的文件有：
core/components/CCLabel
core/renderer/utils/label/ttf.js
core/renderer/webgl/label/2d/ttf.js
core/renderer/webgl/label/index.js
core/renderer/render-engine.js
还有其他相关的文件也是跟文本渲染相关，但是本文聚焦在2d、webgl和ttf渲染上，其他的就略过。
Label 渲染流程
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 () {
if (cc.game.renderType === cc.game.RENDER_TYPE_CANVAS) {
_sharedLabelData = _canvasPool.get();
}
else {
if (!_sharedLabelData) {
let labelCanvas = document.createElement("canvas");
_sharedLabelData = {
canvas: labelCanvas,
context: labelCanvas.getContext("2d")
};
}
}
_sharedLabelData.canvas.width = _sharedLabelData.canvas.height = 1;
return _sharedLabelData;
},
通过_getAssemblerData可知，所有的Label组件共享同一个canvs元素
updateRenderData (comp) {
if (!comp._renderData.vertDirty) return;
this._updateFontFamily(comp);
this._updateProperties(comp);
this._calculateLabelFont();
this._calculateSplitedStrings();
this._updateLabelDimensions();
this._calculateTextBaseline();
this._updateTexture(comp);
comp._actualFontSize = _fontSize;
comp.node.setContentSize(_canvasSize);
this._updateVerts(comp);
comp._renderData.vertDirty = comp._renderData.uvDirty = false;
_context = null;
_canvas = null;
_texture = null;
},
updateRenderData做实际的文本计算（字体、宽高、基线等），并绘制纹理。
_updateTexture () {
_context.clearRect(0, 0, _canvas.width, _canvas.height);
_context.font = _fontDesc;
let startPosition = this._calculateFillTextStartPosition();
let lineHeight = this._getLineHeight();
//use round for line join to avoid sharp intersect point
_context.lineJoin = 'round';
_context.fillStyle = `rgba(${_color.r}, ${_color.g}, ${_color.b}, ${_color.a / 255})`;
let underlineStartPosition;
//do real rendering
for (let i = 0; i < _splitedStrings.length; ++i) {
if (_isOutlined) {
let strokeColor = _outlineColor || WHITE;
_context.strokeStyle = `rgba(${strokeColor.r}, ${strokeColor.g}, ${strokeColor.b}, ${strokeColor.a / 255})`;
_context.lineWidth = _outlineWidth * 2;
_context.strokeText(_splitedStrings[i], startPosition.x, startPosition.y + i * lineHeight);
}
_context.fillText(_splitedStrings[i], startPosition.x, startPosition.y + i * lineHeight);
if (_isUnderline) {
underlineStartPosition = this._calculateUnderlineStartPosition();
_context.save();
_context.beginPath();
_context.lineWidth = _fontSize / 8;
_context.strokeStyle = `rgba(${_color.r}, ${_color.g}, ${_color.b}, ${_color.a / 255})`;
_context.moveTo(underlineStartPosition.x, underlineStartPosition.y + i * lineHeight - 1);
_context.lineTo(underlineStartPosition.x + _canvas.width, underlineStartPosition.y + i * lineHeight - 1);
_context.stroke();
_context.restore();
}
}
_texture.handleLoadedTexture();
},
_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行：
if (_isOutlined) {
let strokeColor = _outlineColor || WHITE;
_context.strokeStyle = `rgba(${strokeColor.r}, ${strokeColor.g}, ${strokeColor.b}, ${strokeColor.a / 255})`;
_context.lineWidth = _outlineWidth * 2;
_context.strokeText(_splitedStrings[i], startPosition.x, startPosition.y + i * lineHeight);
}
网友评论