引擎中关于 Label 的缓存模式的描述
Label 组件目前提供三种 Cache Mode:NONE、BITMAP、CHAR。
NONE:即 Label 的整个文本内容会进行一次绘制,并进行提交,但是并不参与动态合图。
BITMAP:即 Label 的整个文本内容会进行一次绘制,并加入到动态图集中,以便进行批次合并。
CHAR:即 Label 会将文本内容进行拆分,然后对单个字符进行绘制,并将字符缓存到一张单独的字符图集中,下次遇到相同字符不再重新绘制。
三者的主要区别如下所示:
今天我们来说说第三种缓存模式,即 CHAR。
CHAR 模式的主要风险是:字符图集的大小是受限的,总大小只有2048*2048。这里带来的风险是,不能无限制地使用 CHAR 模式来显示文字,因为有可能在图集重建之前把图集用完,用完的结果将导致后续使用 CHAR 模式的 Label 无法再正常显示文字,因为新的字符无法再往这张唯一的图集中继续添加了。
常规的解决思路有以下几种:
1. 增加文字图集张数解决限制问题;
2. 发现文字图集已经用完时,改用其它模式,直到文字贴图集重建;
3. 在唯一的一张图集上重复利用。
首先,我们依次分析以上方案的可行性:
1. 增加文字图集的张数
增加文字图集的数量并不复杂,复杂的是它所带来的问题:
如果一段文本所引用的字符集索引是:0101010101 这样的排列,那么在不做特殊处理的情况下,它的 drawcall 将会是 10 个,这是不可接受的。
当然最简单的处理是做个排序,先渲染所有的 0,再渲染其它的字符。这样一个文本就要 1-2 个 drawcall。虽然也不高,但是随着文字贴图图集个数增长到 N,每个 CHAR 模式的文本的 drawcall 将会是 1 到 N 之间。
这样不稳定的 drawcall 也是不可接受的,因为不敢批量使用。
基于此,可以放弃这个做法。
2. 发现文字图集用完时,改成其它模式。
首先不讨论临时改模式的合理性,单是要检查一个 Label 上的文本是不是能用当前图集完全渲染出来都是个麻烦的事,至少增加了许多计算过程。
另外,改了缓存模式会导致不可预期的 drawcall 打断,内存增加,影响动态合批图集等问题。
严重一点