为什么freetype的渲染文本中总是有一些杂音？答案

【问题标题】：Why there is always some noise in the rendered text of freetype?为什么freetype的渲染文本中总是有一些杂音？
【发布时间】：2011-05-22 14:36:58
【问题描述】：

我正在编写一个使用 freetype2 作为文本渲染引擎的 opengl 程序。

使用它的 LCD 子像素渲染，我发现渲染结果中总是有一些噪点像素，为什么会这样？另外，虽然说明书上说LCD模式会生成宽度为3倍数的buffer，但是我经常发现宽度是3n+1或者3n+2，和face->glyph->bitmap->width不一致。

【问题讨论】：

它试图用 +1 和 +2 来补偿奇偶性。
+2 如何补偿奇偶校验？它不会改变奇偶性。
查看我对 Lie Ryan 回答的评论（如果你愿意，可以接受；我不需要代表）。

标签： c opengl freetype

【解决方案1】：

实际上，经过数小时的尝试和测试，我意识到光栅化字形数据有一些不相关的字节，称为padding。举例来说，下图是缓冲区中的字形数据：（o/x 是有意义的数据，而 . 是不相关的）

  0 1 2 3 4 5 6 7
0 o x o x o x . .
1 x o x o x o . .
2 o x o x o x . .
3 x o x o x o . .
4 o x o x o x . .

有三个数字描述这个缓冲区的大小，前两个很明显：

rows = 5    //since there are 5 rows
width = 6   //since each row has 6 bytes of data

不过，其实还有第三个：

pitch = 8   //the actual width of rows, including "padding"

如果你像我一样忽略缓冲区的这个属性，并且错误地认为width 是实际宽度，那么你将渲染一个扭曲或翻译的字形形状。

我对这种“填充”的理解就像 Dhaivat Pandya 所说的那样，它是一种补偿。但是，它不是奇偶校验的补偿，（显然+2不会改变奇偶校验，）默认情况下它是使实际宽度为4的倍数的补偿。但是是的，您可以将4更改为2甚至1。我猜通过形成一个宽度为 4 倍数的数据矩阵，可以更快地加载它，例如加载到 longint 而不是 byte。

不过，R.. 的洞察力还是让我印象深刻。我想你们无法想象我会犯这样一个基本的错误。

【讨论】：

在处理原始缓冲区中的一系列固定项目的 API 中，具有不同于“步幅”（或此处的“间距”）的“长度”是一种相当常见的设计模式。正如您所注意到的，它通常用于更快的对齐访问。位图数据通常以这种方式与对齐填充一起存储（因为图像的“宽度”可以是任何整数），如果你做图形，顶点数据通常也可以。

【解决方案2】：

我从来没有使用过 FreeType 库，所以我不能以个人经验说话，但也许那个“噪音”是因为你的文本宽度或你对左上角文本坐标的计算偏离了一个？

【讨论】：

这是正确的。图像中带圆圈的像素不应该是它显示的行的最右边的像素。相反，它是下一行的最左边的像素。 OP 指向图像开头的指针偏移了一个像素。