Question

I’m writing a opengl program that use freetype2 as text rendering engine.

Using its LCD subpixel rendering, I found that there are always some noise pixels in the rendered result, why is that happening? Besides, although it’s manual says that the LCD mode will generate buffer with width a multiple of 3, I often found the width to be 3n+1 or 3n+2, and inconsistent with the face->glyph->bitmap->width.

Answer 1

Actually, after hours of trying and testing, I realized that the rasterized glyph data has some non-relevant bytes called padding. Illustratively, imaging below is a glyph data in a buffer: (o/x are meaningful data, while . are non-relevant)

  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 . .

There are three numbers describing the size of this buffer, the first two are obvious:

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

However, there is actually a third one:

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

If you ignore this property of buffer like me, and got the wrong idea that the width is the actual width, you’ll be rendering a distorted or translated glyph shape.

My understanding of this ‘padding’ is like Dhaivat Pandya has said, it’s a compensation. However, it’s not a compensation for parity, (obviously +2 is not changing parity,) by default it’s a compensation to make the actual width a multiple of 4. But yes, you can change the 4 into 2 or even 1. I guess by forming a data matrix with its width a multiple of 4, it can be loaded faster, for example, to be loaded in longint instead of byte.

But still, the insightfulness of R.. really impressed me. I think you guys just can’t image I could make such a basic mistake.