拿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);
}