Method and device for embedded real-time system Chinese character drawing texture compression and dynamic loading

Abstract

This invention provides a method and apparatus for texture compression and dynamic loading of Chinese character rendering in an embedded real-time system. It employs a two-stage pipeline: an offline pre-construction stage, where the character library is processed once on the development host, generating an optimized character library file and index data structure through glyph complexity evaluation and adaptive compression, and storing it on the non-volatile storage medium of the embedded device; and a runtime loading and rendering stage, where, on the embedded device, based on character rendering requests from the application layer, corresponding glyph blocks are loaded into the memory cache on demand using an index table. The compressed texture is then directly uploaded to the video memory using the GPU's hardware decompression capabilities, achieving character rendering with zero CPU decompression overhead. These two stages are coupled through a glyph block index table, forming a highly efficient "one-time pre-construction, multiple on-demand loading" working mode.

Description

Technical Field

[0001] This invention belongs to the field of embedded graphics display and GPU texture management technology, specifically relating to a method and apparatus for texture compression and dynamic loading of Chinese character rendering in an embedded real-time system. Background Technology

[0002] In embedded real-time systems, graphical interfaces typically need to render a large number of Chinese character glyph textures for menus, prompts, and graphical controls. Due to the limited storage space and memory bandwidth of embedded devices, fully loading or decompressing an entire Chinese character library (such as GB2312 or GB18030) is often impractical. For example, a complete Chinese character library stored as a grayscale bitmap exceeds the capacity of most embedded systems.

[0003] Existing font rendering systems (such as FreeType combined with GPU textures) typically rasterize and generate glyph bitmaps on the CPU side before uploading them to the GPU for use. This approach has the following drawbacks: (1) High loading overhead: The system needs to load and decompress complete or partial unused glyph data, resulting in a waste of storage and bandwidth; (2) Lack of local update capability: When the interface switches or the font changes, even if only a few new glyphs are displayed, the entire texture block needs to be reloaded; (3) Fixed compression quality: Traditional texture compression schemes use a uniform bit rate, which wastes storage for simple characters with sparse strokes, and is prone to distortion or blurring for characters with dense strokes or complex edges, and cannot be accurately adapted according to the character characteristics. (4) Real-time limitations: When system resources are scarce or task scheduling is busy, fixed compression schemes are difficult to dynamically balance display quality and rendering performance.

[0004] Therefore, existing technologies cannot simultaneously meet the dual requirements of "high compression ratio, low bandwidth consumption, and local loading" and "adaptive display quality." An embedded Chinese character texture management method is needed that can adaptively select compression strategies based on the character complexity characteristics and support on-demand dynamic loading. Summary of the Invention

[0005] This invention provides a method and apparatus for Chinese character texture compression and dynamic loading in embedded real-time systems, addressing the problems of fixed compression strategies, uneven quality distribution, and high loading latency in existing solutions under bandwidth-constrained environments. The core objective of this invention is to adaptively select a compression strategy based on character complexity, employing a high compression rate for simple characters to save storage space and a low compression rate for complex characters to ensure display quality.

[0006] The first aspect of this invention provides a method for compressing and dynamically loading textures for Chinese character rendering in an embedded real-time system, including an offline pre-construction stage and a runtime loading and rendering stage; The offline pre-build phase includes the following steps: S1. Character complexity assessment steps: Evaluate the complexity of each character in the character library, and calculate the character complexity value based on the edge density and fill rate of the character. S2. Adaptive compression step: Based on the glyph complexity value, select texture compression algorithms with different compression ratios for glyphs of different complexities for compression, and group the compressed glyph data into glyph blocks to form a font library file. Each glyph block contains compressed data of multiple glyphs, and an index table of characters to glyph blocks is established; the font library file is stored in the non-volatile storage medium of the embedded device. The runtime loading and drawing phase includes the following steps: S3. Dynamic loading step: When the drawing application in the embedded real-time system receives a character drawing request, it locates the glyph block corresponding to the character in the font file of the non-volatile storage medium through the index table, and reads the glyph block data from the non-volatile storage medium and loads it into the memory cache. S4. GPU texture upload step: Extract the compressed data of the target character from the loaded glyph block data, and upload the compressed data to the GPU texture object for hardware decompression by calling glCompressedTexImage2D through the GPU's OpenGL ES 3.0 interface. S5. Character drawing steps: The rendering module of the drawing application draws characters based on the decompressed glyph data in the texture object.

[0007] Optionally, in step S1, the method for calculating the character complexity is as follows: the character complexity value is corrected by Gamma, and the corrected complexity value C' = C^γ, where γ is the Gamma correction coefficient, and the value range is 0.4~0.6; Wherein, the complexity value before Gamma correction is C = 0.7×En + 0.3×An; En is the edge density, En = clamp(E / 0.25, 0, 1), where clamp() is the clipping function that limits the value to the range [0,1]; E is the proportion of strong edge pixels, E = Nedge / Ntotal; Nedge is the number of edge pixels detected by the Sobel edge detection operator, and Ntotal is the total number of pixels in the glyph bitmap; An is the fill rate, An = |2×A - 0.5|; A is the proportion of black pixels, A = Nblack / Ntotal; Nblack is the number of black pixels after binarization of the glyph bitmap.

[0008] Optionally, in step S2, the rule for selecting the compression algorithm based on the corrected complexity value C' is as follows: when C' < 0.3, a texture compression algorithm with a high compression ratio is used; when 0.3 ≤ C' < 0.6, a texture compression algorithm with a medium compression ratio is used; when C' ≥ 0.6, a texture compression algorithm with a low compression ratio or no compression is used.

[0009] Optionally, the high compression ratio texture compression algorithm is the ASTC 6×6 compression format with a compression ratio of 3.56 bpp; the medium compression ratio texture compression algorithm is the ASTC 5×5 compression format with a compression ratio of 5.12 bpp; and the low compression ratio texture compression algorithm is the ASTC 4×4 compression format with a compression ratio of 8 bpp.

[0010] Optionally, in step S2, the grouping strategy for glyph blocks is as follows: grouping according to the Unicode encoding range of the characters, dividing glyphs in adjacent encoding ranges into the same glyph block, with each glyph block containing 64 glyphs.

[0011] Optionally, the index table adopts a two-level index structure: the first-level index is a hash mapping table from character Unicode encoding to glyph block number; the second-level index is a glyph offset table inside the glyph block, which records the offset position of each glyph in the glyph block and the length of compressed data.

[0012] Optionally, step S4 further includes: If the GPU is found to not support the target texture compression format, the rendering application will perform software decompression on the CPU and upload the decompressed uncompressed data to the GPU texture object through the glTexImage2D interface.

[0013] Optionally, the method further includes a cache management step: during operation, the LRU (Least Recently Used) algorithm is used to manage the eviction of glyph blocks in the cache. When the cache capacity exceeds a preset threshold, the least recently used glyph blocks are evicted first.

[0014] The second invention provides an embedded real-time system Chinese character rendering texture compression and dynamic loading device, including an offline pre-construction unit and a runtime loading rendering unit; The offline pre-built unit includes: The glyph complexity evaluation module is used to evaluate the complexity of each glyph in the font library and calculate the glyph complexity value based on the edge density and fill rate of the glyph. An adaptive compression module is used to select texture compression algorithms with different compression ratios according to the glyph complexity value to compress the glyphs, and to store the compressed glyph data in groups according to glyph blocks; The index management module is used to create and maintain an index table from characters to glyph blocks; The runtime loading and drawing unit includes: The dynamic loading module is used to locate and load glyph block data into the memory cache through the index table according to the character drawing request; The texture upload module is used to upload the compressed glyph data to the GPU texture object for decompression via the GPU's OpenGL ES 3.0 interface and the call to glCompressedTexImage2D. The cache management module is used to manage glyph block data in the memory cache, including preloading frequently used glyph blocks and cache eviction based on the LRU algorithm; The rendering module is used to draw characters based on the glyph data in the texture object.

[0015] A third aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of the first aspects.

[0016] Compared with the prior art, the present invention has the following significant advantages: (1) Efficient use of storage space: By adaptively selecting the compression rate based on the character complexity, the overall storage space occupied by the character library is reduced by about 25%~40% compared to the uniform bit rate compression scheme and by about 75%~85% compared to the uncompressed scheme, so that the complete Chinese character library can be deployed on embedded devices with limited storage space.

[0017] (2) Display quality adaptive guarantee: Low compression rate is used for complex characters, and the edge details are highly faithful, avoiding the blurring and artifact problems that occur in characters with dense strokes in the uniform compression rate scheme.

[0018] (3) Memory bandwidth is used on demand: The font block granular loading mechanism makes the runtime memory usage depend only on the current interface display requirements, rather than the full font library size. In typical scenarios, the memory usage is reduced by more than an order of magnitude compared to the full loading scheme.

[0019] (4) Real-time optimization: The GPU hardware decompression path eliminates the CPU software decompression overhead, and the font texture upload latency is reduced to the microsecond level, which meets the deterministic response requirements of embedded real-time systems.

[0020] (5) Scalability: The method has good scalability for font size, font resolution and GPU texture compression format. It can be adapted to different hardware platforms by adjusting the size of the ASTC block or replacing it with other compression formats (such as ETC2). Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention are described clearly and completely. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The features and illustrative embodiments of various aspects of the present invention will now be described in detail. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without requiring some of these specific details. The following description of embodiments is merely intended to provide a better understanding of the invention by illustrating examples of the invention. The invention is by no means limited to any specific setup and method set forth below, but covers any improvements, substitutions, and modifications to the structures, methods, and devices without departing from the spirit of the invention.

[0023] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly, encompassing both direct connection and indirect connection via an intermediate medium. Those skilled in the art can understand the specific meaning of these terms in this invention based on the specific circumstances.

[0024] It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other, and the various embodiments can be referenced and cited from each other.

[0025] This invention proposes a method and apparatus for Chinese character rendering texture compression and dynamic loading in embedded real-time systems. This method achieves a balance in Chinese character texture management across storage space, memory bandwidth, and real-time performance through a two-stage collaborative mechanism involving offline pre-construction and runtime loading / rendering stages. Based on an adaptive hierarchical classification of character complexity, this invention's method for Chinese character texture compression and on-demand dynamic loading is suitable for embedded devices with limited memory and bandwidth, such as automotive display terminals, industrial control terminals, and avionics display systems.

[0026] This invention employs a two-stage production line: Offline pre-construction phase: Perform one-time processing on the font library on the development host, generate optimized font files and index data structures through glyph complexity evaluation and adaptive compression, and store them in the non-volatile storage medium of the embedded device.

[0027] Runtime loading and rendering phase: On the embedded device side, according to the character rendering request issued by the application layer, load the corresponding glyph block to the memory cache on demand through the index table, and use the GPU hardware decompression capability to directly upload the compressed texture to the video memory, so as to realize character rendering with zero CPU decompression overhead.

[0028] The two phases are coupled through the glyph block index table to form an efficient working mode of "one-time pre-construction, multiple on-demand loading".

[0029] (1) Detailed technical solution for the offline pre-construction phase 1 Glyph complexity evaluation Glyph complexity evaluation is the prerequisite for realizing adaptive compression. The present invention proposes a two-factor evaluation model integrating edge density and filling rate to quantitatively score each glyph bitmap.

[0030] First, binarize the glyph bitmap, count the number of black pixels N_black and the total number of pixels N_total, and calculate the black pixel ratio A = N_black / N_total. The black pixel ratio reflects the overall stroke coverage degree of the glyph, but cannot capture the distribution characteristics of strokes — for example, the character "ri" (sun) and the character "hui" (enclosure) may have similar black pixel ratios, but the latter has significantly more internal closed edges than the former.

[0031] For this purpose, an edge density factor is introduced. The Sobel edge detection operator is used to perform convolution operation on the glyph bitmap, and the operator includes a horizontal gradient kernel Gx and a vertical gradient kernel Gy: Gx = [[-1, 0, 1], [-2, 0, 2], [-1, 0, 1]] Gy = [[-1,-2,-1], [ 0, 0, 0], [ 1, 2, 1]] For each pixel position, calculate the gradient magnitude M = sqrt(Gx² + Gy²). When M is greater than the preset threshold, the pixel is determined as a strong edge pixel. Count the number of strong edge pixels N_edge, define the strong edge pixel ratio E = N_edge / N_total, and normalize it through a truncation function to obtain the edge density En = clamp(E / 0.25, 0, 1), that is, divide the E value by 0.25 and then limit it to the interval [0, 1].

[0032] The fill rate factor An is defined as An = |2×A - 0.5|. This function has a minimum value of 0 when A=0.25 and a maximum value of 0.5 when A=0 or A=0.5. The physical significance of this design is that when the proportion of black pixels is close to 25% (many medium-complexity Chinese characters fall within this range), the character shape has a moderate stroke density visually; while too low a proportion of black pixels (extremely simple characters) or too high a proportion of black pixels (extremely complex characters) means that texture compression requires a more refined processing strategy.

[0033] The original complexity value C is obtained by weighted fusion of edge density and fill rate: C = 0.7×En + 0.3×An. The edge density weight of 0.7 is higher than the fill rate weight of 0.3, reflecting the design consideration that compression distortion in edge areas has a more significant impact on visual quality than that of flat surfaces. In particular, Chinese characters contain a large number of high-frequency edge features such as right angles and folded strokes, and improper compression can easily produce obvious artifacts.

[0034] Furthermore, the original complexity value is subjected to Gamma correction to enhance discriminative power: the corrected complexity value C' = C^γ, where γ ranges from 0.4 to 0.6. The nonlinear mapping characteristic of Gamma correction stretches the low complexity range and compresses the high complexity range, which is beneficial for more precise discrimination of simple glyphs and the assignment of high compression ratios during the adaptive compression stage.

[0035] 2 Adaptive Compression Strategy Based on the complexity value C' after Gamma correction, the glyphs are divided into three complexity levels, each adapted to different ASTC (Adaptive Scalable Texture Compression) texture compression formats with different compression ratios, as shown in Table 1 below.

[0036] Table 1: ASTC texture compression formats adapted to different compression ratios

[0037] The choice of the ASTC compression format is based on the following technical considerations: ASTC is a Khronos standard texture compression format that supports variable block sizes (4×4 to 12×12), and the compression ratio is continuously adjustable in relation to image quality. This invention employs three block size configurations to establish a stepped mapping between storage efficiency and visual quality. Simple glyphs use 6×6 blocks (each block containing 36 pixels sharing 128 bits of data), achieving a considerable compression ratio at a low bit rate of 3.56 bpp, while the sparse strokes ensure almost no visual degradation at this compression ratio; complex glyphs use 4×4 blocks (each block containing 16 pixels sharing 128 bits of data), and the 8.00 bpp bit rate ensures high-fidelity reproduction of edge details.

[0038] 3. Grouping of character blocks and index construction After adaptive compression, the glyph data is grouped and stored as glyph blocks. The grouping strategy adopts Unicode encoding range partitioning: 64 glyphs in adjacent encoding ranges are grouped into the same glyph block. This design is based on the principle of spatial locality in practical applications—interface text is usually composed of characters with similar semantics or adjacent encodings (such as numbers 0-9, letters A and Z, Chinese radicals, etc.), and the same glyph block can often cover most of the characters required for single-screen display.

[0039] Each glyph block is physically stored as a contiguous data segment, containing: a block header (recording the number of glyphs in the block and the compressed format distribution bitmap), a glyph offset table (recording the offset address of each glyph within the block and the length of the compressed data), and a compressed glyph data area (sequentially storing the ASTC compressed data of each glyph).

[0040] The index table uses a two-level index structure to balance search efficiency and storage overhead: First-level index: A hash map table, using character Unicode encoding as keys and glyph block numbers as values. The hash function uses modulo operation, and collision handling uses open addressing. The first-level index is compact and resides in memory.

[0041] Second-level index: A glyph offset table within the glyph block, recording the offset of each glyph relative to the block's starting address and the length of the compressed data. The second-level index is read into memory along with the glyph block.

[0042] The two-level index lookup process is as follows: given the Unicode encoding of a character, obtain the glyph block number through hash mapping; if the glyph block has been loaded into the memory cache, directly query the offset table within the block to obtain the location of the compressed data; if it has not been loaded, read the glyph block from non-volatile storage and establish a cache.

[0043] (II) Detailed technical solution for the runtime loading and rendering phase 1. Dynamic loading mechanism At runtime, the drawing application receives character drawing requests and parses the Unicode encoding sequence of the required characters. For each character in the encoding sequence, it queries the first-level index to determine the target glyph block number and checks whether the glyph block already resides in the memory cache. If the cache is hit, the compressed data address of the glyph is directly obtained from the block offset table; if the cache is not hit, a glyph block loading operation is triggered: the glyph block data is read from a non-volatile storage medium (such as NAND Flash, eMMC, etc.) into the memory buffer, and the cache record and LRU access timestamp are updated.

[0044] 2. GPU texture upload and hardware decompression After obtaining the compressed data of the target character, the compressed data is directly uploaded to the GPU texture object via the OpenGL ES 3.0 interface. The specific call path is: glCompressedTexImage2D(GL_TEXTURE_2D, 0, internalFormat,width,height, 0, imageSize, compressedData); The `internalFormat` is set to `GL_COMPRESSED_RGBA_ASTC_6x6_KHR`, `GL_COMPRESSED_RGBA_ASTC_5x5_KHR`, or `GL_COMPRESSED_RGBA_ASTC_4x4_KHR` depending on the actual ASTC compression format used. This interface transmits the compressed data to the GPU memory as is, and the GPU texture unit performs hardware decompression during texture sampling. The entire process does not require CPU involvement in decompression operations.

[0045] Regarding compatibility fallback, if the runtime detects that the GPU does not support the target ASTC compression format (which can be determined by querying the GL_COMPRESSED_TEXTURE_FORMATS extended string), it will fall back to the CPU software decompression path: the drawing application calls the ASTC decompression library on the CPU to decompress the compressed data into an RGBA pixel array, and then uploads the uncompressed texture through the glTexImage2D interface.

[0046] 3. Character Drawing and Rendering After the texture is uploaded, the GPU texture object contains the decompressed glyph bitmap data. The rendering module generates quadrilateral primitives based on the text layout information, maps them to the corresponding glyph texture coordinates, and draws the characters using standard texture sampling.

[0047] 4. Cache Management The memory cache uses an LRU (Least Recently Used) eviction policy to manage the lifecycle of character blocks. The system maintains a doubly linked list of character blocks to record the access order of the character blocks. Each time a cache hit occurs, the corresponding node is moved to the head of the list. When the cache usage exceeds a preset threshold, the least recently used character blocks are evicted starting from the tail of the list, releasing their memory space. The cache threshold can be flexibly configured according to the memory capacity of the target device and the concurrent application requirements; a typical value is set to accommodate 16 character blocks.

[0048] Example 1: Winghui RTOS Font Display System This embodiment is based on the WingHui Real-Time Operating System (RTOS) platform and adopts the "font block caching and adaptive compression loading method" described in this invention to achieve efficient font loading and GPU-side texture display in an embedded environment, and is compatible with the OpenGLES 3.2 graphics interface.

[0049] (1) Font preprocessing stage 1. Using the FreeType font engine, the set of Unicode encoded characters required by the graphics application (including commonly used Chinese characters, numbers, symbols, etc.) is rendered offline as an 8-bit grayscale bitmap (single-channel texture).

[0050] 2. Calculate the complexity metrics (edge ​​density E and fill rate A) for each glyph grayscale image, and automatically select the appropriate compression level and texture format based on the overall complexity value C′: Low-complexity glyphs: using ASTC6×6; Medium complexity glyphs: ASTC5×5; High-complexity glyphs: ASTC4×4 is used.

[0051] 3. Group and store glyph data into glyph blocks. Assign 64 glyphs from adjacent encoding intervals to the same glyph block. Set the glyph block data to include: a block header (recording the number of glyphs contained in the block and a compressed format distribution bitmap), a glyph offset table (recording the offset address and compressed data length of each glyph within the block), and a compressed glyph data area (sequentially storing the ASTC compressed data of each glyph). Construct a hash mapping table.

[0052] (2) System loading phase 1. At runtime, the drawing application receives character drawing requests. Based on the Unicode encoding sequence of the required character, it queries the first-level index to determine the target glyph block number and checks whether the glyph block is already resident in the memory cache. If the cache is hit, the compressed data address of the glyph is directly obtained from the block offset table; if the cache is not hit, the glyph block loading operation is triggered: the glyph block data is read from the non-volatile storage medium into the memory buffer, and the doubly linked list of glyph blocks is updated.

[0053] 2. After obtaining the compressed data of the target character, the compressed data is directly uploaded to the GPU texture object via the OpenGL ES 3.0 interface. The specific call path is glCompressedTexImage2D(GL_TEXTURE_2D, 0, internalFormat, width, height, 0, imageSize, compressedData); where internalFormat is set to GL_COMPRESSED_RGBA_ASTC_6x6_KHR, GL_COMPRESSED_RGBA_ASTC_5x5_KHR, or GL_COMPRESSED_RGBA_ASTC_4x4_KHR depending on the actual ASTC compression format used.

[0054] 3. If the runtime detects that the GPU does not support the target ASTC compression format (this can be determined by querying the GL_COMPRESSED_TEXTURE_FORMATS extended string), then it will fall back to the CPU software decompression path: the drawing application calls the ASTC decompression library on the CPU to decompress the compressed data into an RGBA pixel array, and then uploads the uncompressed texture through the glTexImage2D interface.

[0055] (3) Rendering stage After the texture is uploaded, the GPU texture object contains the decompressed glyph bitmap data. The rendering module generates quadrilateral primitives based on the text layout information, maps them to the corresponding glyph texture coordinates, and draws the characters using standard texture sampling.

[0056] (4) Operational effect Validated on the WingHui RTOS platform, this invention has significant advantages compared to the traditional FreeType+ uncompressed texture solution: The overall font library capacity has been reduced by approximately 45%; GPU memory and bus bandwidth usage are reduced by approximately 35%; Average font loading latency reduced by approximately 25%; The font display quality maintains a PSNR ≥ 40dB with no obvious visible distortion; In multilingual interfaces and high-frequency switching scenarios, frame rate stability is improved by about 20%, and cache hit rate is maintained above 85%.

[0057] The above detailed embodiments are a description of the present invention. It should not be considered that the specific embodiments of the present invention are limited to these descriptions. For those skilled in the art, several simple deductions and substitutions can be made without departing from the concept of the present invention, and all of these should be considered to fall within the protection scope of the present invention.

Claims

1. A method for texture compression and dynamic loading of Chinese character rendering in an embedded real-time system, characterized in that, This includes an offline pre-build phase and a runtime loading and rendering phase; The offline pre-build phase includes the following steps: S1. Character complexity assessment steps: Evaluate the complexity of each character in the character library, and calculate the character complexity value based on the edge density and fill rate of the character. S2. Adaptive compression step: Based on the glyph complexity value, select texture compression algorithms with different compression ratios for glyphs of different complexities for compression, and group the compressed glyph data into glyph blocks to form a font library file. Each glyph block contains compressed data of multiple glyphs, and an index table of characters to glyph blocks is established; the font library file is stored in the non-volatile storage medium of the embedded device. The runtime loading and drawing phase includes the following steps: S3. Dynamic loading step: When the drawing application in the embedded real-time system receives a character drawing request, it locates the glyph block corresponding to the character in the font file of the non-volatile storage medium through the index table, and reads the glyph block data from the non-volatile storage medium and loads it into the memory cache. S4. GPU texture upload step: Extract the compressed data of the target character from the loaded glyph block data, and upload the compressed data to the GPU texture object for hardware decompression by calling glCompressedTexImage2D through the GPU's OpenGL ES 3.0 interface. S5. Character drawing steps: The rendering module of the drawing application draws characters based on the decompressed glyph data in the texture object.

2. The method according to claim 1, characterized in that, In step S1, the method for calculating the character complexity is as follows: the character complexity value is corrected by Gamma, and the corrected complexity value C' = C^γ, where γ is the Gamma correction coefficient, and the value range is 0.4~0.

6. Wherein, the complexity value before Gamma correction is C = 0.7×En + 0.3×An; En is the edge density, En = clamp(E / 0.25, 0, 1), where clamp() is the clipping function that limits the value to the range [0,1]; E is the proportion of strong edge pixels, E = Nedge / Ntotal; Nedge is the number of edge pixels detected by the Sobel edge detection operator, and Ntotal is the total number of pixels in the glyph bitmap; An is the fill rate, An = |2×A - 0.5|; A is the proportion of black pixels, A = Nblack / Ntotal; Nblack is the number of black pixels after binarization of the glyph bitmap.

3. The method according to claim 2, characterized in that, In step S2, the rule for selecting the compression algorithm based on the corrected complexity value C' is as follows: when C' < 0.3, a texture compression algorithm with a high compression ratio is used; when 0.3 ≤ C' < 0.6, a texture compression algorithm with a medium compression ratio is used; when C' ≥ 0.6, a texture compression algorithm with a low compression ratio or no compression is used.

4. The method according to claim 3, characterized in that, The high compression ratio texture compression algorithm is the ASTC 6×6 compression format, with a compression ratio of 3.56 bpp; the medium compression ratio texture compression algorithm is the ASTC 5×5 compression format, with a compression ratio of 5.12 bpp; and the low compression ratio texture compression algorithm is the ASTC 4×4 compression format, with a compression ratio of 8 bpp.

5. The method according to claim 1, characterized in that, In step S2, the grouping strategy for glyph blocks is as follows: grouping according to the Unicode encoding range of the characters, dividing glyphs in adjacent encoding ranges into the same glyph block, with each glyph block containing 64 glyphs.

6. The method according to claim 1, characterized in that, The index table adopts a two-level index structure: the first-level index is a hash mapping table from character Unicode encoding to glyph block number; the second-level index is a glyph offset table inside the glyph block, which records the offset position of each glyph in the glyph block and the length of compressed data.

7. The method according to claim 1, characterized in that, Step S4 further includes: If the GPU is found to not support the target texture compression format, the rendering application will perform software decompression on the CPU and upload the decompressed uncompressed data to the GPU texture object through the glTexImage2D interface.

8. The method according to claim 1, characterized in that, The method also includes a cache management step: during operation, the LRU (Least Recently Used) algorithm is used to manage the eviction of word blocks in the cache. When the cache capacity exceeds a preset threshold, the least recently used word blocks are evicted first.

9. A device for compressing and dynamically loading textures for Chinese character rendering in an embedded real-time system, characterized in that, This includes offline pre-built units and runtime loaded drawing units; The offline pre-built unit includes: The glyph complexity evaluation module is used to evaluate the complexity of each glyph in the font library and calculate the glyph complexity value based on the edge density and fill rate of the glyph. An adaptive compression module is used to select texture compression algorithms with different compression ratios according to the glyph complexity value to compress the glyphs, and to store the compressed glyph data in groups according to glyph blocks; The index management module is used to create and maintain an index table from characters to glyph blocks; The runtime loading and drawing unit includes: The dynamic loading module is used to locate and load glyph block data into the memory cache through the index table according to the character drawing request; The texture upload module is used to upload the compressed glyph data to the GPU texture object for decompression via the GPU's OpenGL ES 3.0 interface and the call to glCompressedTexImage2D. The cache management module is used to manage glyph block data in the memory cache, including preloading frequently used glyph blocks and cache eviction based on the LRU algorithm; The rendering module is used to draw characters based on the glyph data in the texture object.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-8.

Images