突破 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 打断,内存增加,影响动态合批图集等问题。

 

严重一点

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值