为什么在freetype渲染的文本中总是有一些噪音？

Question

我正在编写一个OpenGL程序，使用freetype2作为文本渲染引擎。使用其LCD亚像素渲染时，我发现渲染结果总是有一些噪点像素，这是为什么？此外，尽管它的手册说LCD模式将生成宽度为3的倍数的缓冲区，但我经常发现宽度为3n+1或3n+2，并且与face->glyph->bitmap->width不一致。

- xzhu

---

它试图通过+1和+2来补偿奇偶校验。 - Dhaivat Pandya

+2 补偿奇偶校验吗？它不会改变奇偶校验。 - xzhu

请查看我对Lie Ryan答案的评论（如果您喜欢，可以接受它；我不需要声望）。 - R.. GitHub STOP HELPING ICE

Answer 1

实际上，在尝试和测试了数小时后，我意识到光栅化的字形数据中有一些无关的字节称为“填充”。举个例子，下面的图像是缓冲区中的一个字形数据：（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所说，这个“padding”是一种补偿。然而，默认情况下，它不是为了偶数而补偿（显然+2不会改变偶数），而是为了使实际宽度成为4的倍数。但是，你确实可以将4改为2甚至1。我猜通过形成一个数据矩阵，使其宽度成为4的倍数，它可以更快地加载，例如加载到longint而不是byte中。

但是，R..的深刻见解仍然给我留下了深刻印象。我想你们可能无法想象我会犯如此基本的错误。

- xzhu

---

具有与“步幅”（或此处的“间距”）不同的“长度”，是处理原始缓冲区中一系列固定项目的API中相当常见的设计模式。正如您所指出的那样，这通常是为了更快的对齐访问。位图数据通常以这种方式存储对齐填充（因为图像的“宽度”可以是任何整数），如果您进行图形处理，则顶点数据也通常可以如此。 - Ben Zotto

Answer 2

我从未使用过FreeType库，所以无法通过个人经验谈论，但也许“噪音”是因为您的文本宽度或左上角文本坐标的计算有误导致的？

- Lie Ryan

---

这是正确的。图像中圈出的像素不应该是它所显示的行的最右边的像素。相反，它是下一行的最左边的像素。OP指向图像开头的指针偏移了一个像素。 - R.. GitHub STOP HELPING ICE