突破 Label 的缓存模式：CHAR 无限模式

引擎中关于 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 打断，内存增加，影响动态合批图集等问题。

 

严重一点，如果一直不重建图集，那么