На самом деле, после нескольких часов попыток и тестирования, я понял, что у растеризованных глиф-данных есть несколько не относящихся к делу байтов, называемых 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
- это фактическая ширина, вы будете воспроизводить искаженную или переведенную форму глифа.
Мое понимание этого «отступа» похоже на то, как сказал Дайват Пандья, это компенсация.Тем не менее, это не компенсация четности (очевидно, что +2 не меняет четность) по умолчанию это компенсация, чтобы сделать фактическую ширину кратной 4. Но да, вы можете изменить 4 на 2 или даже 1. Я думаю,формируя матрицу данных с шириной, кратной 4, ее можно быстрее загружать, например, загружать в longint
вместо byte
.
Но, тем не менее, проницательность R..
действительно впечатлил меня.Я думаю, что вы, ребята, просто не можете представить, что я могу совершить такую основную ошибку.