Feature: glyph alignment about fontbm HOT 3 CLOSED

I don't think it will be useless, so I'm in.
BTW, does the GPU also require even width? I know some GPU likes 32-bit aligned addresses, but never heard about even numbers.
It would be nice to cover more cases, so I'd like more info how the GPU uses font textures.

from fontbm.

I don't think it will be useless, so I'm in.

Cool. I'll make some time to work on that.

BTW, does the GPU also require even width?

It does not.

I know some GPU likes 32-bit aligned addresses, but never heard about even numbers. It would be nice to cover more cases, so I'd like more info how the GPU uses font textures.

The GPU we are experimenting with is from the FTDI EVE series. They are quite constrained: just 1 MB of texture memory and an 8 KB display list. Both of those constraints are relevant to the even alignment support. To minimize the texture memory used by fonts, we store them as 4-bit gray pixels, so each byte contains two pixels. To draw the glyphs, we use the BITMAP_SOURCE command, which takes the starting address of the bitmap, along with the BITMAP_SIZE command to define the width and height of the bitmap to draw. When the glyph has an odd x offset, the starting address of the bitmap is one pixel (4 bits) before the start of the glyph. To render it correctly, we set a clip using the SCISSOR_* commands (and eventually restore the clip) to exclude the that pixel. The scissor commands use more of the limited display list, which in turn limits how many glyphs can be rendered on a single screen.

I admit it is a strange case, but it is very cool that fontbm makes it so straightforward to make optimal use of the very limited display list (in addition to fontbm providing the smallest glyph atlas size we've seen from any tool, which saves texture memory too!)

For completeness, I should mention that the GPU has another way of storing fonts, basically as a vertical column of constant size glyphs. Less display list memory is required render these, but it is a very inefficient use of texture memory. We don't have plans to use this approach.

from fontbm.

Closing this issue as the PR to implement it has been merged. (Thank you!)

from fontbm.