【发布时间】：2017-05-18 17:00:27
【问题描述】：
情况：
我有一个项目，将产品信息呈现到给定模板（自定义 XML 格式）上，然后呈现并转换为自定义二进制 LCD 格式（步骤简化）
我们的客户现在需要自动调整文本容器。 （客户给了一个特定大小的盒子，所有类型的字符串都必须自动调整大小以适合该容器
为此，我必须为多种字体大小（例如 100pt 不适合、99pt 不适合、98pt 不适合...、...、65pt 适合！）计算字符串的宽度（freetype：每个字符/字形）！ )
问题：
问题是 freetype 每个自动调整元素都需要很长时间（~20-30 ms），而我的整个应用程序只有~100ms 可以使用。 （所以当客户再添加 5 个自动调整元素时，它已经保证超过 ~100 毫秒）
尝试：
一个自制的字体缓存生成器，它接受一个字体文件并计算从 1pt 到 100pt 的字体大小的每个 unicode 字符的宽度。然后它会像这样从数据中生成 C 源代码：
//
#define COUNT_SIZES 100 // Font-Size 1-100
#define COUNT_CHARS 65536 // Full Unicode Table
int char_sizes[COUNT_SIZES][COUNT_CHARS] =
{
{1,1,2,2,3,1,1,2,2,3,1,2,2,1,2,2,3,1,2,.......// 65536
{2,2,3,3,4,2,1,3,3,4,2,3,3,2,3,3,4,2,3,.......// 65536
{2,3,4,3,5,2,2,4,4,5,2,4,4,2,4,3,5,3,3,.......// 65536
// ...
// 100 font sizes
};
在动态库 (.so) 中编译的文件大小为 25 MB，“dlload”大约需要 50 毫秒，“dlsym”大约需要 10 毫秒（WAAAAAAY 太多了！）
以相同的方式，但只有 ASCII 表（因此只有 65536 个中的 128 个）编译成 58 KB 的 .so 文件，“dlload”需要 ~500µs，“dlsym”需要 ~100µs（非常好！）
我的下一个尝试是将 font-cache-generator 集成到我的项目中，并仅缓存特定客户所需的字形（欧洲客户需要约 500 个字形，亚洲客户（例如繁体中文）需要约 2500 个字形（只是例子，不完全确定，可能更需要）
但在我踏上艰苦的旅程之前 (:() 我想问你是否知道更好的方法？一个图书馆/项目就是这样做的？
我不敢相信这是不可能的，否则浏览器应该如何在不加载秒数的情况下显示 lorem ipsum？ :D
你知道如何解决这个性能问题吗？
关于数据缓存的任何信息链接以及对缓存的极快访问（有点
系统信息：
- Unix (Ubuntu 16.04) 64bit
- x86 AND arm 架构存在！
【问题讨论】：
标签： c++ performance unix caching freetype2