Cegui0.7.1 font optimization draft

I personally think that cegui adopts a seemingly elegant font rendering, but it turns out to be a wrong path. (At least I think so, as is my test. Maybe there is something wrong with this idea. Find it and change it .)

First, let's talk about the basic process of cegui processing text rendering.

 

1. Font: getglyphdata

Here we need a codepoint of UTF32, and a fontglyph is returned (combining the map of codepoint and image)

 

2. freetypefont: rasterise

Here, a text within the specified codepoint range is rendered to the image in the imageset (each text is an image)

 

That's it, isn't it easy. Let's talk about other things.

 

1. Font: drawtext

Draw a string to geometrybuffer. here you need to typeset the text and use the image in fontglyph to draw it. Therefore, the text display status can be controlled here. (For example, color and spacing, some text effects can also be achieved here, such as stroke, shadow, bold, italic, and underline)

 

2. freetypefont: drawglyphtobuffer

Cegui supports bitmap fonts and Vector Fonts (FT). They are all the same (both use an image with a codepoint index, and you can also manually set an image with a specified font ). The most commonly used method is to load Vector Fonts with FreeType. Otherwise, the workload is also a problem. Use ft to render the specified text to a bitmap, and then use rgba
The pixel format is copied to a memory buffer. Then an imageset is generated and each image (text) is defined on it ). (Cegui's default glyphs_per_page is 256)

 

However, this text generation method is problematic. First, it is unnecessary for a language with limited characters (such as English) (it can be loaded once ). Second, it is not necessary for languages with a large number of characters (such as Chinese) (because cegui is rendered within a specified range, that is to say, he will generate a pile of spam text before and after Based on the codepoint to be displayed ). It looks elegant but not practical. Second, the cegui text is used in a unified and practical rgba pixel format, that is, 4 bytes per pixel. Is it better to change to the La (2 byte) format? By viewing the rendering process of Sohu tianlong 2 using the PIX, we can see that Sohu has changed to the 2B la pixel format (d3dfmt_a8l8 ). Therefore, the work to be done is becoming clearer.

 

1. Remove the generation of waste words (there is no doubt)

2. Pre-generation of text to be displayed (solve the problem of card frames when a large amount of text is instantly displayed)

3. Supports Dynamic Release of generated text (clear unnecessary text and save resources)

4. The text image pixel format uses the 2 byte la format (saving time and saving time)

5. Read the configuration from the XML file defined in the font (avoid hard encoding)

 

Text Management provides two implementation methods:

1. manual management (provide interfaces for text preparation and release, and manually load and release text as needed)

2. System Management (you only need to configure text usage, and the system dynamically manages text loading and release)