爲什麼在freetype的渲染文本中總會有一些噪音？

我正在寫一個使用freetype2作爲文本渲染引擎的opengl程序。爲什麼在freetype的渲染文本中總會有一些噪音？

使用其液晶子像素渲染，我發現總有一些在渲染結果一些噪音像素，這是爲什麼發生？此外，雖然手冊中說LCD模式會產生寬度爲3的倍數的緩衝區，但我經常發現寬度爲3n + 1或3n + 2，與face->glyph->bitmap->width不一致。

enter image description here

來源

2011-05-22 trVoldemort

它試圖補償與+1和+2奇偶校驗。 – 2011-05-22 14:38:14

+2補償平價如何？它不會改變平價。 – trVoldemort 2011-05-22 14:47:17

查看我對Lie Ryan的回答的評論（如果你喜歡，請接受它;我不需要代表）。 – 2011-05-22 16:34:32

其實，嘗試和測試小時後，我意識到，光柵化字形數據有一些所謂的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"

如果你忽視的buff這個屬性呃像我一樣，並得到錯誤的想法，width是實際的寬度，你會呈現扭曲或翻譯的字形形狀。

我這個「填充」的理解是一樣Dhaivat潘迪亞說，這是一個補償。然而，這不是補償平價，（顯然+ 2不會改變平價），默認情況下，它是一個補償，使實際寬度爲4的倍數。但是，你可以將4改爲2或甚至1。通過用其寬度形成數據矩陣的4的倍數，其可以被加載速度更快，例如，在longint代替byte被加載。

但儘管如此，中R..的洞察力真正打動我。我認爲你們無法想象我會犯這樣一個基本的錯誤。

來源

2011-05-23 01:24:20 trVoldemort

具有不同於「跨度」（或「間距」這裏）的「長度」是處理原始緩衝區中的一系列固定項目的API中相當常見的設計模式。正如你注意到的那樣，通常是爲了更快地對齊訪問。位圖數據通常以這種方式與對齊填充一起存儲（因爲圖像的「寬度」可以是任何整數），並且如果您使用圖形，頂點數據通常也可以。 – 2011-05-23 01:46:07

我從來沒有使用FreeType庫，所以我不能以個人的經驗談，但也許是「噪音」，是因爲你的文字寬度或您的左上角文字的計算座標爲關閉一個？

來源

2011-05-22 14:54:14

這是正確的。圖像中的圓圈像素不應該是它顯示的線的最右邊像素。相反，它是下一行的最左邊的像素。 OP指向圖像開頭的指針偏離一個像素。 – 2011-05-22 16:33:27

爲什麼在freetype的渲染文本中總會有一些噪音？

回答

相關問題