A vector graphics rendering method based on a rendering engine

Abstract

The application relates to the technical field of vector graphics rendering, in particular to a vector graphics rendering method based on a rendering engine, which comprises the following steps: in the rendering engine initialization stage, a rendering kernel and a multilingual adaptation layer independently running are built, color font analysis logic is built in the kernel, color composite data is analyzed through an improved font table traversal algorithm, and glyph description information is stored in an independent glyph cache pool; a rendering request in an upper layer is converted into an instruction stream through the adaptation layer, a target glyph is extracted, a vector path is precompiled, an intermediate representation of hardware acceleration adaptation is generated, and pixel cache-aware rasterization calculation is performed to generate a raster image. The method can stably analyze color glyph data, glyph storage and calling are more efficient, the rendering kernel and the multilingual interface are more adaptable, hardware acceleration matching is higher, rasterization calculation and cache resource adaptation are more coordinated, and the overall rendering process is smoother.

Description

Technical Field

[0001] This invention relates to the field of vector graphics rendering technology, and in particular to a vector graphics rendering method based on a rendering engine. Background Technology

[0002] In conventional vector graphics rendering systems, color font parsing largely relies on general font processing components, font table traversal uses conventional traversal logic, the rendering kernel construction is largely dependent on the host runtime environment, and multi-language interface adaptation is achieved through scattered external encapsulation modules. After the vector graphics file is loaded, the glyph data directly participates in subsequent drawing stages, vector path processing lacks a pre-compilation stage, rasterization calculations are performed according to fixed logic, and adaptive calculations are not performed in conjunction with the running state of the pixel cache.

[0003] Under existing rendering methods, the general font table traversal logic cannot accurately adapt to the complex data structures in colored fonts. Color glyph data parsing suffers from process redundancy, glyph description information lacks an independent storage area, and data retrieval and reuse are hindered. The rendering kernel is tightly coupled with the host environment, exhibiting weak independent operation capabilities. The adaptation standards for multi-language interfaces are inconsistent, resulting in low efficiency in the instruction conversion of rendering requests from upper-layer applications. Vector paths directly participating in the drawing process are difficult to match with hardware-accelerated operating architectures. The operational states of rasterization calculations and pixel caching are disconnected, leading to resource mismatches during raster image generation. The rendering process is subject to numerous unstable factors.

[0004] During rendering system runtime, the font table traversal logic needs to be optimized to adapt to the parsing requirements of color composite data, while an independent glyph data storage area needs to be built. An independently running rendering kernel and a standardized multi-language adaptation structure need to be constructed, vector paths need to be pre-processed to generate intermediate data adapted for hardware acceleration, and rasterization calculations need to be performed in conjunction with pixel cache states to improve the rendering process. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a vector graphics rendering method based on a rendering engine.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a vector graphics rendering method based on a rendering engine, comprising: During the initialization phase of the rendering engine, a self-contained rendering kernel and a multi-language adaptation layer are created. The rendering kernel is written in a system programming language to achieve independent operation, and the multi-language adaptation layer encapsulates the interface specifications of multiple host languages. The rendering kernel incorporates color font parsing logic, loads vector graphics files, and the color font parsing logic calls an improved font table traversal algorithm to identify and parse the color composite data in the font file. The improved font table traversal algorithm is used to extract the color glyph description information, and the color glyph description information is stored in an independent glyph cache pool. Receive rendering requests from upper-layer applications, which are then converted into an instruction stream that the rendering kernel can process via the multi-language adaptation layer; In the rendering kernel, target glyph description information is extracted from the glyph cache pool according to the instruction stream, and vector path pre-compilation processing is performed to generate an intermediate representation suitable for hardware-accelerated rendering; The rasterization processing unit is invoked to perform pixel-cached rasterization calculations on the intermediate representation suitable for hardware-accelerated rendering, generating the final raster image.

[0007] As a further aspect of the present invention, the improved font table traversal algorithm includes the following steps: Receive the font file data stream that needs to be parsed and locate all the data tables contained in the font file; The table labels of each data table are read sequentially, and the table labels are compared with a predefined list of color-coded character table feature labels. When a feature containing the feature label list of the color glyph table is matched, the sequential reading is paused and the process is switched to the composite data deep parsing mode. In the composite data deep parsing mode, the matched current data table is expanded in a hierarchical structure, and the contour vector data, color layer data, and layer blending rule metadata are separated from the current data table; The separated contour vector data, color layer data, and layer blending rule metadata are decompressed and re-encoded, and combined into independent color glyph description information that can be directly interpreted by the rendering kernel; After completing the deep parsing of the current data table, record the parsing progress and resume the sequential reading of subsequent data tables until all data tables have been traversed.

[0008] As a further aspect of the present invention, the pre-compilation processing of the execution vector path includes the following steps: Retrieve the color glyph description information corresponding to the current rendering instruction from the glyph cache pool; The colored glyph description information is parsed, and the contour vector data is extracted from it. The contour vector data is represented by a quadratic Bézier curve command sequence or a cubic Bézier curve command sequence. The quadratic or cubic Bézier curve command sequence is converted into a polygonal approximation representation containing line segments and specific control points, forming a discretized set of path points. Planar scanline analysis is performed on the discretized set of path points to calculate the intersection of each scanline with the path boundary, and a closed filling region description is generated according to the odd-even filling rule. The filling region description is associated with the color layer data in the color glyph description information, and an independent drawing batch identifier is assigned to each associated filling region. The associated filled regions carrying the drawing batch identifier are organized into an intermediate representation suitable for hardware-accelerated drawing, the structure of which is suitable for parallel shading by a streaming processor or a graphics processor.

[0009] As a further aspect of the present invention, performing pixel-cached-aware rasterization calculation on the intermediate representation suitable for hardware-accelerated rendering includes the following steps: Allocate a pixel buffer area with the same resolution as the output target for the current graphics target to be rendered; Read the data corresponding to one of the drawing batch identifiers in the intermediate representation applicable to hardware-accelerated drawing; Based on the description of the filling area corresponding to the drawing batch identifier, the pixel range covered by the filling area is calculated, and the pixel range is defined by the minimum bounding rectangle; Within the area defined by the minimum bounding rectangle, traverse each pixel and determine whether the center point of the pixel is located within the boundary described by the filling area; For pixels that are determined to be within the boundary, the corresponding color layer data is searched from the color glyph description information according to the association mapping relationship, and the final color value of the pixel is calculated through color synthesis operation; The calculated final color value is written to the corresponding memory location in the pixel buffer. After processing one drawing batch identifier, the next drawing batch identifier is processed in a loop until all batches are processed. At this time, the data stored in the pixel buffer constitutes the final raster image.

[0010] As a further aspect of the present invention, the management of the character cache pool includes the following steps: Initialize a memory region with a fixed capacity as the glyph cache pool, and establish a hash index table for the glyph cache pool with glyph identifiers as keys and memory addresses as values; When the color font parsing logic generates new color glyph description information, the byte length of the color glyph description information is calculated; Check whether the remaining free capacity of the character cache pool is greater than or equal to the byte length; If the remaining free capacity meets the requirements, then a space of the corresponding size is allocated in the contiguous free memory block of the character cache pool to store the colored character description information, and the allocated memory starting address and the corresponding character identifier are registered in the hash index table; If the remaining free capacity does not meet the requirements, one or more cached items are evicted from the glyph cache pool to free up space according to the least recent use principle, and the hash index table is updated before the allocation and storage operations are performed.

[0011] As a further aspect of the present invention, the operation of the multilingual adaptation layer includes the following steps: During the initialization phase of the rendering engine, the host language application programming interface type provided by the current runtime environment is detected; Based on the detected host language application programming interface type, the corresponding interface binding code is loaded, and the interface binding code converts the function calling convention of the host language into a call to the internal function of the rendering kernel; Define a set of rendering description protocols that are independent of the host language, which are used to describe the graphics type, coordinates, color, font name and text content; Receive raw rendering commands from the host language environment and serialize the raw rendering commands into a standard data stream according to the rendering description protocol; The serialized standard data stream is bound to code through the interface and passed as the instruction stream to the rendering kernel for subsequent processing.

[0012] As a further aspect of the present invention, serializing the original rendering command into a standard data stream according to the rendering description protocol includes: Analyze the semantics of the original rendering commands to identify the command types, which include drawing text, drawing paths, or drawing images; Based on the identified command type, rendering parameters are extracted from the original rendering command. For a text drawing command, the extracted parameters include the text string, font identifier, font size, and starting coordinates; for a path drawing command, the extracted parameters include the path point coordinate sequence and drawing style; for an image drawing command, the extracted parameters include the image resource identifier, target position, and size. The extracted rendering parameters are encoded in a binary format defined by the rendering description protocol, the binary format including a fixed command header, parameter length field, and parameter value field; The encoded binary data block is appended to the end of the buffer queue of the current rendering task. When the amount of data in the buffer queue reaches a preset threshold or a refresh signal is received, all the binary data blocks in the buffer queue are concatenated in order to form the complete standard data stream.

[0013] As a further aspect of the present invention, the method further includes a post-processing step for the raster image: After the rasterization processing unit generates the final raster image, it checks whether the final raster image contains alpha channel information. If alpha channel information is included, then alpha mixing calculation is performed on the final raster image based on the pre-configured background color or the underlying image; Based on the color characteristic description file of the target output device, the image data after alpha mixing calculation is converted to color space, from the linear color space used inside the rendering kernel to the target color space; A dithering algorithm is applied to the image data after color space conversion to reduce color banding when displayed on high color depth devices; The image data processed by the dithering algorithm is packaged into an image format data packet that meets the requirements of the target output interface.

[0014] As a further aspect of the present invention, the alpha hybrid computing employs a hybrid pipeline, the steps of which include: Receive the source color value and the target color value to be mixed. The source color value comes from the color layer data in the color glyph description information, and the target color value comes from the value currently stored at the corresponding position in the pixel buffer or the pre-configured background color. Read the preset blending mode identifier of the current layer from the layer blending rule metadata of the color glyph description information; Based on the blending mode identifier, a corresponding blending function is selected from a predefined blending function library. The blending function defines the mathematical relationship of how to calculate the output color value based on the alpha channel of the source color value, the alpha channel of the target color value, and the color components. The selected blending function is invoked, passing in the source color value, the target color value, and optional additional blending parameters, to calculate the blended output color value; The calculated output color value is returned as the result.

[0015] As a further aspect of the present invention, planar scanline analysis is performed on the discretized set of path points, including: Obtain the minimum and maximum Y coordinate values ​​in the vertical direction of the discretized path point set to determine the total coverage area of ​​the scan line; Multiple horizontal scan lines are generated within the total coverage area with a fixed step value, and each scan line corresponds to a specific Y coordinate value; For each scan line, the intersection points of the scan line and each polygon edge formed by the discretized set of path points are calculated sequentially, where the polygon edge is formed by connecting adjacent path points. Sort all the calculated intersection points in ascending order according to their X coordinate values ​​to generate a sequence of intersection points for the scan line. According to the odd-even filling rule, starting from the first intersection of the intersection sequence, every two consecutive intersections are defined as a filling interval, and pixels located within the filling interval are considered to be within the path boundary. Merge all filling intervals corresponding to the current scan line to generate the contribution of the current scan line to the description of the closed filling region; Traverse all scan lines and integrate the contributions generated by all scan lines to form a complete description of the filled region consisting of multiple horizontal filled interval bands.

[0016] Compared with the prior art, the advantages and positive effects of the present invention are as follows: The improved font table traversal algorithm is integrated into the color font parsing logic of the rendering kernel. It can accurately identify the color composite data within the font file and extract the color glyph description information, storing it in an independent glyph cache pool. The color font parsing process does not rely on an external font parsing module. The parsing logic and the rendering kernel form an integrated structure. The parsing process of color composite data is streamlined. The storage area for glyph description information is isolated from the regular data storage area. The retrieval of glyph data does not require multiple data retrieval steps. The storage and retrieval of glyph data form a dedicated process. The parsing and transmission of color glyph data is smoother, and the reuse status of glyph data is aligned with the execution rhythm of the rendering process.

[0017] The rendering kernel is written in a system programming language and can run independently. A multi-language adaptation layer encapsulates interface specifications for various host languages, allowing rendering requests from upper-layer applications to be smoothly converted into instruction streams that the rendering kernel can process. Vector paths undergo pre-compilation processing based on the instruction stream, generating an intermediate representation adapted for hardware-accelerated rendering. The rasterization unit then performs pixel-buffer-aware rasterization calculations on this intermediate representation. The intermediate representation can directly match the hardware-accelerated rendering logic, eliminating the need for vector paths to directly participate in the hardware rendering process. Rasterization calculations can adjust their logic based on the actual state of the pixel buffer, resulting in a closer integration between rendering instructions and hardware resources. The rendering kernel's operation is not limited by the host environment. The multi-language interface conversion process is standardized, leading to a higher degree of compatibility between the instruction stream and the rendering kernel's processing logic, and a more coherent raster image generation process. Attached Figure Description

[0018] Figure 1 This is a state diagram of a vector graphics rendering method based on a rendering engine according to the present invention. Figure 2A flowchart of the pre-compilation process for vector paths; Figure 3 A flowchart illustrating the work of the multilingual adaptation layer. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] See Figure 1 This invention provides a vector graphics rendering method based on a rendering engine, the overall implementation of which is as follows: During the startup and preparation phase of the rendering engine, a self-contained rendering kernel and a multi-language adaptation layer need to be created. The rendering kernel is written in a system programming language such as C++ or Rust, enabling it to independently perform computational tasks without relying on a specific high-level language runtime. The multi-language adaptation layer is designed as an abstraction layer encapsulating the interface specifications of various host languages, providing a unified bridging entry point for languages ​​such as JavaScript, Python, or Java. Internally, the rendering kernel incorporates dedicated color font parsing logic. This logic is responsible for loading vector graphics files in formats such as OpenTypeSVG or COLR / CPAL. Its core function is to call an improved font table traversal algorithm to systematically identify and parse the color composite data contained in the font files. Through this improved font table traversal algorithm, the color glyph description information containing geometric and color information can be accurately extracted. This information is stored in an independently managed glyph cache pool. When the rendering engine runs, rendering requests from upper-layer applications first reach the multi-language adaptation layer. This layer is responsible for converting calls from different language paradigms into a standardized instruction stream that the rendering kernel can directly understand and process. Inside the rendering kernel, the processor locates and extracts the target glyph description information from the glyph cache pool based on the received instruction stream. It then performs pre-compilation processing of the vector path, converting the description information into a high-efficiency intermediate representation suitable for subsequent hardware-accelerated rendering. The rasterization unit is then invoked, performing a pixel-buffer-aware rasterization calculation on the generated intermediate representation, determining color and transparency pixel by pixel to generate the final raster image ready for display or output.

[0022] In one embodiment of the present invention, the improved font table traversal algorithm receives a font file data stream to be parsed. The font file data stream is provided in binary form, such as an OpenType format file stream. The beginning of the font file data stream contains a font directory structure. The improved font table traversal algorithm parses the font directory to locate the position and size of all data tables contained in the font file. In some embodiments, the font directory is located at the starting offset position of the font file data stream. The improved font table traversal algorithm reads the table number field in the font directory and then sequentially reads the record of each table entry. Each table entry record contains a table label, checksum, offset, and length. The improved font table traversal algorithm locates the specific position of each data table in the font file data stream based on the offset and length. The algorithm sequentially reads the table labels of each data table. Each label is a four-character identifier; for example, "cmap" represents a character mapping table, "glyf" represents a glyph data table, and "COLR" represents a color glyph table. The table labels are compared with a predefined list of color glyph table feature labels, which includes labels such as "COLR" and "SVG". When a matching table label is found in the predefined list, the sequential reading process pauses, and the improved font table traversal algorithm switches to a composite data deep parsing mode. In this mode, the algorithm performs a hierarchical expansion of the matched data table, separating contour vector data, color layer data, and layer blending rule metadata. For example, for the "COLR" table, the algorithm parses the COLR table's header structure, then traverses the layer records, extracting the contour vector data pointed to by the glyph index, reading the color layer data from the associated CPAL table, and simultaneously reading the layer blending rule metadata from the COLR table's extended header.

[0023] The separated contour vector data, color layer data, and layer blending rule metadata are decompressed and re-encoded. The contour vector data may be stored in a compressed format. The improved font table traversal algorithm calls the decompression routine to decompress the contour vector data into a standard Bézier curve command sequence. The color layer data contains color value indices or gradient definitions. The improved font table traversal algorithm maps color value indices to specific color values ​​and converts gradient definitions into internal representations. The layer blending rule metadata contains blending mode enumeration values. The improved font table traversal algorithm maps blending mode enumeration values ​​to blending opcodes that the rendering kernel can recognize. After decompression and re-encoding, the improved font table traversal algorithm combines the contour vector data, color layer data, and layer blending rule metadata into independent, directly interpretable color glyph description information. The color glyph description information adopts a compact binary format, including a header, geometric segments, and color segments. After completing the deep parsing of the current data table, the improved font table traversal algorithm records the parsing progress, such as recording the index of the currently parsed data table, and resumes the sequential reading of subsequent data tables. The improved font table traversal algorithm continues to read the table labels of the next data table, repeating the comparison and parsing process until all data tables are traversed. It can be understood that the improved font table traversal algorithm reduces the processing overhead of non-color tables by pausing sequential reading and deep parsing of color tables, compared with the traditional traversal algorithm that continuously reads all tables sequentially. In some embodiments, the predefined list of color glyph table feature labels is dynamically configurable, allowing table labels to be added or removed at runtime to accommodate the expansion of different font formats.

[0024] In its implementation, the improved font table traversal algorithm uses byte comparison operations when matching table labels. For example, the table label "COLR" is represented by four bytes. The improved font table traversal algorithm compares the four bytes read with each entry in the predefined list of color glyph table feature labels byte by byte. Optionally, the improved font table traversal algorithm can use a hash function to accelerate the matching process, converting the table label into a hash value, and then comparing it with the hash value set of the predefined list of color glyph table feature labels. The matching process can be represented by the following formula:

[0025] in: This indicates the table label of the currently read data table. This represents the first character in the predefined color glyph table feature label list. Each feature label This indicates the length of the predefined list of color glyph feature labels. Represents the logical OR operation. Indicates whether a match was found. When true, the improved font table traversal algorithm switches to composite data deep parsing mode. In specific implementation, composite data deep parsing mode expands the matched current data table hierarchically. Taking the "COLR" table as an example, the "COLR" table contains an array of base glyph records. Each base glyph record points to a layer array. Each layer record in the layer array contains a target glyph index and a color index. The improved font table traversal algorithm traverses the base glyph record array. For each base glyph, the improved font table traversal algorithm reads the layer array, extracts the target glyph index from the layer record, obtains the outline vector data from the "glyf" table based on the target glyph index, and simultaneously obtains the color layer data from the "CPAL" table based on the color index. It also reads the layer blending rule metadata from the extended header of the "COLR" table. The improved font table traversal algorithm temporarily stores the extracted data in an intermediate buffer and then performs decompression and re-encoding.

[0026] In practice, the separated contour vector data, color layer data, and layer blending rule metadata are decompressed and re-encoded separately. The contour vector data may use simple byte encoding or a more complex compression algorithm. The improved font table traversal algorithm identifies the compression type and calls the corresponding decompressor. The color layer data may be stored in the form of an index. The improved font table traversal algorithm converts the index into RGBA color values ​​by looking up the table. The layer blending rule metadata may be stored in the form of an enumeration value. The improved font table traversal algorithm maps the enumeration value to an internal blending mode identifier. The re-encoding process converts the decompressed data into an internal format defined by the rendering kernel. The internal format includes a type flag, data length, and payload. The improved font table traversal algorithm packages the re-encoded contour vector data, color layer data, and layer blending rule metadata into color glyph description information. The color glyph description information is stored in the form of binary blocks, including a version number, data segment offset, and checksum. After completing the deep parsing of the current data table, the improved font table traversal algorithm records the parsing progress, such as updating the counter of parsed tables and resuming the sequential reading of subsequent data tables. The improved font table traversal algorithm continues to read the next table entry from the font directory, obtains the table label of the next data table, and repeats the above process until all table entries are processed. In some embodiments, the improved font table traversal algorithm ignores data tables that do not match the predefined color glyph table feature label list during the traversal process, and only skips these data tables without performing deep parsing, thereby optimizing the parsing time. Optionally, after parsing the color glyph table, the improved font table traversal algorithm can directly store the color glyph description information into the glyph cache pool.

[0027] In one embodiment of the present invention, see [reference] Figure 2The system retrieves the color glyph description information corresponding to the current rendering command from the glyph cache pool. This color glyph description information is parsed to extract contour vector data, which is typically represented by a sequence of quadratic or cubic Bézier curve commands. The extracted quadratic or cubic Bézier curve command sequences are converted into a polygon approximation representation composed of numerous short straight line segments and specific control points using a subdivision algorithm, thus forming a discretized pathpoint set. Planar scanline analysis is performed on this discretized pathpoint set to obtain the minimum and maximum Y-coordinate values ​​in the vertical direction, thereby determining the total coverage of the scanline. Multiple horizontal scanlines are generated within this total coverage area with a fixed step value, each scanline corresponding to a specific Y-coordinate value. For each scanline, the intersection points of the scanline with each edge of a polygon formed by connecting adjacent points in the discretized pathpoint set are calculated sequentially. All calculated intersection points are sorted in ascending order according to their X-coordinate values ​​to generate a sequence of scanline intersection points. Based on the odd-even fill rule, starting from the first intersection of the intersection sequence, every two consecutive intersections are defined as a fill interval. Pixels within these fill intervals are considered to be within the path boundary. All fill intervals corresponding to the current scan line are merged to generate the contribution of the current scan line to the description of the closed fill region. This process is repeated for all scan lines, integrating the contributions generated by all scan lines to form a complete fill region description consisting of multiple horizontal fill interval bands. This fill region description is then mapped to the color layer data in the color glyph description information, and each mapped fill region is assigned an independent drawing batch identifier. The mapped fill regions carrying the drawing batch identifiers are organized into an intermediate representation suitable for hardware-accelerated rendering. This intermediate representation is optimized for parallel shading computation by streaming processors or graphics processors.

[0028] In practice, the colored glyph description information corresponding to the current rendering instruction is retrieved from the glyph cache pool. The rendering instruction contains the target glyph identifier. By querying a hash index table with the glyph identifier as the key, the memory address of the colored glyph description information can be obtained from the glyph cache pool, and its data can be read. The colored glyph description information is parsed to extract the contour vector data. The colored glyph description information has a predefined binary layout, and its header contains data segment offsets. The parsing process locates the contour vector data segment based on the header information. The contour vector data is represented by a quadratic or cubic Bézier curve command sequence. The command sequence consists of an opcode and coordinate parameters. For example, a quadratic Bézier curve command contains one control point coordinate and one endpoint coordinate, while a cubic Bézier curve command contains two control point coordinates and one endpoint coordinate. The command sequence of quadratic or cubic Bézier curves is converted into a polygon approximation representation containing line segments and specific control points. The conversion process uses a subdivision algorithm. For a Bézier curve, the subdivision algorithm recursively divides the curve into shorter line segments until the maximum deviation of all line segments from the original curve is less than a set tolerance threshold. The endpoints of these short line segments constitute a discretized set of path points. It can be understood that the discretized set of path points is a sequence of vertices of polygon edges.

[0029] Planar scanline analysis is performed on the discretized pathpoint set to obtain the minimum and maximum Y-coordinate values ​​in the vertical direction. This determines the total coverage area of ​​the scanline. The minimum and maximum Y-coordinate values ​​are obtained by iterating through the Y-coordinates of all points in the discretized pathpoint set and taking the minimum and maximum values. Multiple horizontal scanlines are generated within the total coverage area with a fixed step value, typically one pixel. Each scanline corresponds to a specific Y-coordinate value; for example, a Y-coordinate of... ,in Integer index, This is the step value. For each scan line, the intersection points of the scan line and each edge of the polygon formed by the discretized set of path points are calculated sequentially. The polygon edges are formed by connecting adjacent path points, i.e., points... Time When calculating the intersection points of line segments, it is determined whether the Y-coordinate of the scan line lies within the Y-coordinate range of the line segment, and the X-coordinate of the intersection point is calculated using a linear interpolation formula. All calculated intersection points are sorted in ascending order according to their X-coordinate values ​​to generate a sequence of scan line intersection points. A quicksort algorithm can be used for this sorting. According to the odd-even filling rule, starting from the first intersection point in the sequence, every two consecutive intersection points are defined as a filling interval. Pixels within a filling interval are considered to be within the path boundary. It can be understood that when the number of intersection points in the sequence is odd, the last intersection point does not participate in forming a filling interval. All filling intervals corresponding to the current scan line are merged to generate the contribution of the current scan line to the description of the closed filling region. This process is repeated for all scan lines, integrating the contributions generated by all scan lines to form a complete filling region description consisting of multiple horizontal filling interval bands. Each horizontal filling interval band contains Y-coordinates and a series of X-coordinate start and end pairs.

[0030] The filled region description is associated with the color layer data in the color glyph description information. The color layer data is stored in the color segment of the color glyph description information. The association mapping is achieved by looking up the original layer index to which the filled region belongs, and each associated filled region is assigned an independent drawing batch identifier, which is an incrementing integer number. The associated filled regions carrying the drawing batch identifiers are organized into an intermediate representation suitable for hardware-accelerated rendering. The intermediate representation adopts a structured data format. For example, each drawing batch identifier corresponds to a data block, which contains a batch identifier, a pointer to the Y range and X interval array of the filled region description, and a pointer to the associated color data. In some embodiments, the following formula can be used to determine whether a pixel is located within the filled region in planar scanline analysis:

[0031] in: This represents the X coordinate of the center of the pixel to be determined. and Indicates the current scan line number The starting and ending X coordinates of each filled interval This indicates the total number of fill intervals for the current scan line. Represents a logical OR operation. This represents the logical AND operation. This indicates the judgment result; a true value means the pixel is within the boundary of the filled region description. In specific implementations, when performing planar scanline analysis on the discretized set of path points, the intersection point with the polygon edge is calculated for each scanline. For points... and points The defined polygon edges, when the scan line Y coordinate satisfy and When calculating the X coordinate of the intersection point. All calculated intersection points are sorted in ascending order of their X-coordinate values. The odd-even filling rule stipulates that, starting from the first intersection point in the sorted sequence, intersection points with even indices are paired with their immediately following odd-numbered indices to form a filling interval. In practice, after generating the scan line intersection point sequence, starting from the first intersection point, every two consecutive intersection points are defined as a filling interval. For example, the sorted intersection point sequence is... This forms a filled interval. and Pixels located within these fill intervals are considered to be within the path boundary. It can be understood that fill intervals are left-closed and right-open intervals. All fill intervals corresponding to the current scan line are merged to generate the contribution of the current scan line to the description of the closed fill region. The contribution of each scan line is represented as a (Y coordinate, interval list) pair. All scan lines are traversed, and the (Y coordinate, interval list) pairs generated by all scan lines are integrated into an array to form a complete fill region description. Optionally, consecutive scan lines with identical interval lists can be merged, represented as a Y coordinate range and an interval list. In some embodiments, when associating the fill region description with the color layer data in the color glyph description information, it is necessary to query the layer index of the original vector path corresponding to the fill region, and then read the color information of the corresponding layer from the color layer data segment of the color glyph description information. The color information can be a description of a solid color, linear gradient, or radial gradient. The association mapping adds a color data pointer to each fill interval. Optionally, the color data pointer points to a structure containing color type and parameters. In practice, each associated fill region is assigned an independent drawing batch identifier, which increments from zero. After assigning the drawing batch identifier, the associated fill region contains the drawing batch identifier, Y coordinate, X interval array, and color data pointer. The associated fill region carrying the drawing batch identifier is organized into an intermediate representation suitable for hardware-accelerated rendering. The data structure of the intermediate representation is designed to be suitable for parallel shading by a streaming processor or graphics processor. For example, the intermediate representation can be a buffer in which the metadata and geometric data of each batch are stored in the order of the drawing batch identifier.

[0032] In one embodiment of the invention, a pixel buffer with the same resolution as the output target is allocated to the currently rendered graphics target. The size of the pixel buffer is determined by the output width and height specified in the rendering request. Each pixel occupies a fixed number of bytes to store color values; for example, for a format containing red, green, blue, and transparency components, each pixel occupies 4 bytes. Data corresponding to a drawing batch identifier in an intermediate representation suitable for hardware-accelerated rendering is read. The intermediate representation is organized as a structure array, and each element contains a drawing batch identifier, an associated fill region description, and a color data pointer. Based on the fill region description corresponding to the drawing batch identifier, the pixel range covered by the fill region is calculated. The fill region description consists of multiple horizontal fill intervals. The pixel range covered by the fill region is defined by a minimum bounding rectangle. The left boundary of the minimum bounding rectangle is the floor value of the minimum starting X coordinate among all intervals, the right boundary is the floor value of the maximum ending X coordinate among all intervals, the upper boundary is the minimum Y coordinate value, and the lower boundary is the maximum Y coordinate value. Within the area defined by the minimum bounding rectangle, each pixel is traversed, and it is determined whether the pixel's center point coordinates are within the boundary described by the fill area. This is done by determining the Y-coordinate of the scan line where the pixel's center point is located and searching for a fill interval containing the X-coordinate of that pixel's center point within the corresponding horizontal fill interval band. For pixels determined to be within the boundary, the corresponding color layer data is retrieved from the color glyph description information based on the associated mapping relationship. The final color value of the pixel is calculated through color compositing operations, which may involve mixing different color components and calculating transparency. The calculated final color value is written to the corresponding memory location in the pixel buffer. The memory location is calculated using pixel coordinate offsets. For example, for a pixel with coordinates (x, y), its offset in the row-major pixel buffer is (y, y). Output width + x) The number of bytes per pixel. After processing one drawing batch identifier, the next drawing batch identifier is processed in a loop until all batches are processed. At this point, the data stored in the pixel buffer constitutes the final raster image. The management of the glyph buffer pool accompanies the above process. A memory region with a fixed capacity is initialized as the glyph buffer pool. The fixed capacity of the glyph buffer pool is configured when the rendering engine starts, and a hash index table is created for the glyph buffer pool, with glyph identifiers as keys and memory addresses as values. The hash index table uses a linked list method to resolve collisions. When the color font parsing logic generates new color glyph description information, the byte length of the color glyph description information is calculated. The byte length includes the sum of the description information header, geometric data segment, and color data segment. It is checked whether the remaining free capacity of the glyph buffer pool is greater than or equal to the byte length of the color glyph description information. The remaining free capacity is obtained by subtracting the total size of the allocated blocks from the total capacity. If the remaining free capacity meets the requirement, space of the corresponding size is allocated in a contiguous free memory block of the glyph buffer pool to store the color glyph description information, and the allocated memory starting address and the corresponding glyph identifier are registered in the hash index table. If the remaining free capacity does not meet the requirements, one or more cached items are evicted from the character cache pool to free up space according to the least recent use principle. The eviction process traverses the hash index table, records the last access timestamp of each cached item, removes the item with the earliest timestamp, updates the hash index table, and then performs allocation and storage operations.

[0033] In some embodiments, the color composition operation employs an Alpha blending formula, where the source color value comes from the color layer data in the color glyph description information, and the target color value comes from the currently stored value at the corresponding position in the pixel buffer. The blending operation can be expressed as:

[0034] in: Represents the source color value (e.g., red, green, or blue components). Indicates the target color value. This represents the opacity component of the source color. This represents the output color components after mixing. In specific implementation, the minimum bounding rectangle is calculated based on the fill region description corresponding to the drawing batch identifier. For example, a fill region description contains three horizontal fill interval bands with Y-coordinate and X-interval pairs as follows: (Y=10, X interval [5,15]), (Y=11, X interval [4,16]), and (Y=12, X interval [6,14]). Then, the left boundary of the minimum bounding rectangle is 4, the right boundary is 16, the upper boundary is 10, and the lower boundary is 12. When traversing pixels, the center point of each pixel is checked one by one within the rectangular area defined by the minimum bounding rectangle (X from 4 to 15, Y from 10 to 12). It is determined whether the center point of the pixel is within the boundary of the fill region description. For a scan line with Y=10, only the center point of pixels with X coordinates in the interval [5,15) is considered to be within the boundary. This determination process avoids processing pixels that are completely outside the fill region. In practice, the corresponding color layer data is retrieved from the color glyph description information. The structure pointed to by the color data pointer in the color glyph description information may contain color types. For example, a solid color type stores RGBA values, while a linear gradient type stores the start and end coordinates and a list of color stop points. The retrieval process calculates the specific source color value based on the color type and pixel position through interpolation. and The calculated final color value is written to the corresponding memory location in the pixel buffer. The write operation may be a direct assignment to memory. On hardware that supports parallel computing, pixel calculation and writing corresponding to different drawing batch identifiers can be executed in parallel. Optionally, the pixel buffer can be allocated in the graphics processor's video memory to accelerate access.

[0035] The management of the glyph cache pool involves data structure maintenance. The key glyph identifier of the hash index table may be an integer composed of the font index and character encoding, with a value that is a pointer to a cache entry structure. The cache entry structure contains the memory starting address, data length, last access timestamp, and previous and next pointers used to construct an LRU linked list. In specific implementation, when the color font parsing logic generates new color glyph description information, the byte length of the color glyph description information is calculated. Assuming that a color glyph description information contains 10 paths and 2 colors, its byte length may be 512 bytes. The remaining free capacity of the glyph cache pool is checked. Assuming that the total capacity of the glyph cache pool is 1MB and 900KB has been used, the remaining free capacity is 124KB, which is greater than 512 bytes, thus meeting the requirement. Allocate 512 bytes of space in a contiguous free memory block in the character cache pool to store the color character description information. The memory allocator searches for the first block of at least 512 bytes in the free memory block linked list of the character cache pool, divides it, and registers the starting address of the allocated memory (e.g., 0xA7B30010) and the character identifier (e.g., 0x00010041) in the hash index table. If the remaining free capacity is insufficient, for example, 200 bytes of free capacity while the new color glyph description information is 512 bytes long, then cached items are evicted according to the least recently used principle. The hash index table stores the last access timestamp of each cached item; the timestamp can be an incrementing integer counter. The eviction process finds the cached item with the smallest timestamp value, assuming its glyph identifier is 0x00010020. This key-value pair is deleted from the hash index table, and the memory block it occupies (e.g., 256 bytes) is marked as free. Optionally, multiple cached items may need to be evicted until the cumulative free space is greater than or equal to 512 bytes. Then, space is allocated and stored for the new color glyph description information. See Table 1 for the memory allocation corresponding to different glyph identifiers in the glyph cache pool. Table 1: Character Cache Pool Entries

[0036] In some embodiments, the remaining free capacity of the glyph cache pool is checked to see if it is greater than or equal to the byte length of the color glyph description information. This comparison operation is an integer comparison. If the condition is met, the memory allocator allocates space in a contiguous block of free memory in the glyph cache pool. The allocation strategy can be a first-fit algorithm, finding the first sufficiently large free memory block, allocating the requested size of space from the starting address of that block, and forming a new free block if the remaining portion is large enough. In specific implementations, cached items are evicted from the glyph cache pool according to the least recently used principle. The least recently used principle can be implemented by maintaining a doubly linked list. Each time a cached item is accessed, it is moved to the head of the list, and when evicted, the item at the tail of the list is removed. It can be understood that the item at the tail of the list represents the least recently used cached item. Updating the hash index table involves deleting the key-value pairs corresponding to the evicted items and may merge adjacent free memory blocks to form larger free blocks for subsequent allocation.

[0037] In one embodiment of the present invention, see [reference] Figure 3 During the initialization phase of the rendering engine, the multi-language adaptation layer detects the host language application programming interface (API) type provided by the current runtime environment. Based on the detected host language API type, it loads the corresponding interface binding code. This binding code internally implements the logic of converting the host language's function calling conventions and parameter passing methods into calls to the rendering kernel's internal C interface functions. The multi-language adaptation layer defines a host language-independent rendering description protocol, which is used to standardize the description of rendering elements such as graphics type, coordinates, colors, font names, and text content. It receives raw rendering commands from the host language environment and serializes these commands into a standard data stream according to the rendering description protocol. The serialization process analyzes the semantics of the raw rendering commands to identify the command type, which may include drawing text, drawing paths, or drawing images. Based on the identified command type, it extracts rendering parameters from the raw rendering commands. For text drawing commands, the extracted parameters include the text string, font identifier, font size, and starting coordinates; for path drawing commands, the extracted parameters include the path point coordinate sequence and drawing style; for image drawing commands, the extracted parameters include the image resource identifier, target location, and size. The extracted rendering parameters are encoded according to the binary format defined by the rendering description protocol. This binary format includes a fixed command header, parameter length field, and parameter value field. The encoded binary data blocks are appended to the end of the current rendering task's buffer queue. When the data volume in the buffer queue reaches a preset threshold or a refresh signal is received, all binary data blocks in the buffer queue are concatenated in sequence to form a complete standard data stream. Finally, the serialized standard data stream is bound to code via an interface and passed as an instruction stream to the rendering kernel for subsequent processing.

[0038] In its implementation, during the rendering engine initialization phase, the multi-language adaptation layer detects the host language application programming interface (API) type provided by the current runtime environment. This detection mechanism might involve checking for the existence of predefined global objects or function pointers; for example, detecting the `window` object and the `CanvasRenderingContext2D` constructor in a JavaScript environment, and detecting `ctypes` or the `CFFI` module in a Python environment. Based on the detected host language API type, the corresponding interface binding code is loaded. This code translates the host language's function calling conventions into calls to functions within the rendering kernel. For instance, for the JavaScript host language, the interface binding code might be a set of glue functions generated through WebAssembly's import / export mechanism or the `embind` tool. These glue functions convert JavaScript's `Number` type to C's `double` type and call the `render_text` function exported by the rendering kernel. The multi-language adaptation layer defines a rendering description protocol independent of the host language. This protocol describes the graphics type, coordinates, color, font name, and text content. It uses binary encoding and has a fixed frame header structure, containing the protocol version, total command length, and checksum. Receive raw rendering commands from the host language environment. The raw rendering commands have a host language-specific form. For example, in JavaScript, it may be a call to the drawText method and parameters, while in Python, it may be an instruction to call a specific drawing library function. Serialize the raw rendering commands into a standard data stream according to the rendering description protocol.

[0039] Serializing raw rendering commands into a standard data stream according to the rendering description protocol involves the following steps: First, analyzing the semantics of the raw rendering commands and identifying the command type. Command types include drawing text, drawing paths, or drawing images. The identification process is based on matching function names or method names. Second, extracting rendering parameters from the raw rendering commands based on the identified command type. For drawing text commands, extracted parameters include the text string, font identifier, font size, and starting coordinates. For drawing paths commands, extracted parameters include the path point coordinate sequence and drawing style. For drawing images commands, extracted parameters include the image resource identifier, target location, and size. Third, encoding the extracted rendering parameters according to the binary format defined by the rendering description protocol. The binary format includes a fixed command header, a parameter length field, and a parameter value field. The command header occupies a fixed number of bytes and includes a command type enumeration and the number of parameter blocks. The parameter length field indicates the number of bytes in the subsequent parameter value field. Fourth, appending the encoded binary data blocks to the end of the current rendering task's buffer queue. The buffer queue is a first-in, first-out memory buffer. When the data volume in the buffer queue reaches a preset threshold or a refresh signal is received, all binary data blocks in the buffer queue are concatenated in sequence to form a complete standard data stream. The serialized standard data stream is passed to the rendering kernel as an instruction stream through the interface binding code for subsequent processing. The interface binding code passes the memory pointer and length of the standard data stream to the entry function of the rendering kernel.

[0040] In some embodiments, the total length of a single command data block can be calculated using the following formula: (The binary format defined by the rendering description protocol can be used to calculate the total length of a single command data block.)

[0041] in: Indicates the total byte length of a single command data block. Indicates the byte length of the fixed command header. This indicates the number of parameters included in the command. Indicates the first The number of bytes in the parameter length field of each parameter. Indicates the first The parameter value field specifies the byte length of each parameter. In practice, the semantics of the original rendering command are analyzed. For example, upon receiving a JavaScript call `context.drawText("Hello", 10, 20, {font:"Arial", size: 12})`, the command type is identified as drawing text. Rendering parameters are extracted from the original rendering command. The text string is "Hello", the font identifier is obtained as an integer ID5 by looking up the font mapping table, the font size is 12, and the starting coordinates are (10, 20). The extracted rendering parameters are encoded. The command header is set to the drawing text type enumeration value 0x01, the number of parameters is 4, and the parameter length and parameter value fields are arranged sequentially. The string "Hello" is encoded as a UTF-8 byte sequence with a 2-byte length field added before it. The encoded binary data block is appended to a buffer queue. The preset threshold of the buffer queue may be 4KB. When the accumulated data reaches 4KB, a concatenation operation is triggered to form a complete standard data stream. This buffering mechanism reduces the overhead of frequently calling the underlying interface. When passing command streams, the interface binding code may need to copy the standard data stream from the host language environment's memory space to a shared memory space accessible by the rendering kernel. Optionally, in environments that support zero-copy, a pointer to the memory buffer can be passed directly. See Table 2 for the binary layout of commands in the rendering description protocol. Table 2: Rendering Description Protocol Command Format Table

[0042] In specific implementations, rendering parameters are extracted from the original rendering command based on the identified command type. For a drawing path command, the original rendering command may contain a point array and a drawing style object. The point array is extracted and encoded as a continuous sequence of floating-point numbers, and the drawing style object is extracted and encoded as a structure containing subfields such as color and line width. For an image drawing command, the image resource identifier may be a string or an integer handle, and the target position and size contain four floating-point numbers. The encoded binary data blocks are appended to the end of the buffer queue of the current rendering task. The buffer queue is implemented in memory as a circular buffer or a dynamic array. When the amount of data in the buffer queue reaches a preset threshold or an explicit refresh signal is received from the host language environment, all binary data blocks in the buffer queue are concatenated in order. The concatenation process is a memory copy operation, forming a complete standard data stream. In some embodiments, the corresponding interface binding code is loaded. For the Java host language, the interface binding code may be a series of native methods generated through the Java native interface. These native methods convert the parameters in the Java object into basic types or structures in the C language, and then call the functions of the rendering kernel. The multilingual adaptation layer defines a rendering description protocol independent of the host language. The design of this protocol ensures that the same rendering intent emitted from different host languages ​​will produce identical standard data streams. This effectively decouples the rendering kernel from the upper-layer application language. The serialized standard data stream is then passed to the rendering kernel through interface binding code. This interface binding code may also need to manage the status or error codes returned by the rendering kernel and convert them back to exceptions or return values ​​in the host language environment.

[0043] In one embodiment of the present invention, after the rasterization processing unit generates the final raster image, a post-processing step is performed on the raster image to check whether the final raster image contains alpha channel information. This check is achieved by analyzing the storage format of each pixel data in the pixel buffer. For example, if the pixel format is RGBA, containing four components (red, green, blue, and transparency), it is determined to contain alpha channel information; if it is RGB, containing only three components (red, green, and blue), it is determined not to contain alpha channel information. If the check determines that alpha channel information is present, alpha mixing calculation is performed on the final raster image based on a pre-configured background color or a lower-layer image. The pre-configured background color may be an RGBA color value, and the lower-layer image is another image data already present in the output target. The alpha mixing calculation uses a mixing pipeline, which receives the source color value and the target color value to be mixed. The source color value comes from the value written to the pixel buffer after rasterization of the color layer data in the color glyph description information. The target color value comes from the currently stored value at the corresponding position in the pixel buffer or the pre-configured background color. From the layer blending rule metadata of the color glyph description information, the preset blending mode identifier of the current layer is read. The blending mode identifier is an integer value, such as 0 for normal blending and 1 for multiply. Based on the blending mode identifier, the corresponding blending function is selected from the predefined blending function library. The predefined blending function library is a static array or lookup table. The blending function defines the mathematical relationship of how to calculate the output color value based on the alpha channel of the source color value, the alpha channel of the target color value, and color components. The selected blending function is called, passing in the source color value, the target color value, and optional additional blending parameters, to calculate the blended output color value. The calculated output color value is then written back to the pixel buffer as the result.

[0044] Based on the color profile of the target output device, the image data after alpha mixing is converted to a different color space. The color profile defines the conversion parameters between the source and target color spaces, such as a linear conversion from the sRGB color space used internally by the rendering kernel to the AdobeRGB color space. A dithering algorithm is then applied to the color-space-converted image data. Dithering reduces color banding on high color depth devices by spreading quantization errors between adjacent pixels; for example, the Floyd-Steinberg error diffusion algorithm. Finally, the dithered image data is packaged into an image format data packet that conforms to the target output interface requirements, such as a PNG data stream with a header or a BMP file data block containing a pixel array.

[0045] In its implementation, the Alpha Hybrid Computation uses a hybrid pipeline execution step that receives the source color values ​​to be mixed. With target color value Source color value The pixel color corresponding to the color layer data from the color glyph description information includes , , and Four components, target color value The value currently stored at the corresponding position in the pixel buffer or the pre-configured solid color background, including , , and Components. Read the current layer's preset blending mode identifier from the layer blending rule metadata of the color glyph description information. Mixed mode identifier The metadata header stored in the color layer data. Based on the blending mode identifier. Select the corresponding blending function from the predefined blending function library. The predefined mixin library is indexed by a mixin mode identifier, for example Time selection function To achieve "normal" mixing, Time selection function To achieve a "Multiply" blending mode, call the selected blending function. Input source color value Target color value And optional additional mixing parameters, to calculate the mixed output color value. It is understandable that the mixture function The specific calculation rules are defined by the blending mode standard. The calculated output color values... The result is returned and the pixel buffer is updated. In some embodiments, for the "normal" blending mode, the blending calculation can be expressed by the following formula:

[0046] in: The color components that represent the source color value. The color components that represent the target color value. The opacity component representing the source color value. This represents the output color components after mixing. This calculation is applied to the red, green, and blue color channels respectively.

[0047] In practice, the image data after alpha mixing calculation is converted to a different color space based on the color characteristic description file of the target output device. The color characteristic description file can be an ICC profile, and the conversion process uses a 3x3 color transformation matrix. Perform a linear transformation on the RGB value of each pixel, resulting in the transformed pixel value. ,in It is a pixel vector in the source color space. This refers to the pixel vectors in the target color space. A dithering algorithm is applied to the color space-converted image data. The dithering algorithm iterates through each pixel in the image, calculating the error between the color value of the current pixel after color space conversion and quantization and the original continuous color values. This error is then distributed to adjacent, unprocessed pixels according to a predetermined ratio. For example, the Floyd-Steinberg algorithm allocates 7 / 16 of the error to the right pixel, 3 / 16 to the lower left pixel, 5 / 16 to the bottom pixel, and 1 / 16 to the lower right pixel. The image data processed by the dithering algorithm is then packaged. The packaging operation arranges the pixel data according to the target image format specifications and adds necessary file headers and information blocks. For example, when packaging to PNG format, IHDR blocks, IDAT blocks, and IEND blocks need to be generated.

[0048] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A vector graphics rendering method based on a rendering engine, characterized in that, The method includes: During the initialization phase of the rendering engine, a self-contained rendering kernel and a multi-language adaptation layer are created. The rendering kernel is written in a system programming language to achieve independent operation, and the multi-language adaptation layer encapsulates the interface specifications of multiple host languages. The rendering kernel incorporates color font parsing logic, loads vector graphics files, and the color font parsing logic calls an improved font table traversal algorithm to identify and parse the color composite data in the font file. The improved font table traversal algorithm is used to extract the color glyph description information, and the color glyph description information is stored in an independent glyph cache pool. Receive rendering requests from upper-layer applications, which are then converted into an instruction stream that the rendering kernel can process via the multi-language adaptation layer; In the rendering kernel, target glyph description information is extracted from the glyph cache pool according to the instruction stream, and vector path pre-compilation processing is performed to generate an intermediate representation suitable for hardware-accelerated rendering; The rasterization processing unit is invoked to perform pixel-cached rasterization calculations on the intermediate representation suitable for hardware-accelerated rendering, generating the final raster image.

2. The vector graphics rendering method based on a rendering engine according to claim 1, characterized in that, The improved font table traversal algorithm includes the following steps: Receive the font file data stream that needs to be parsed and locate all the data tables contained in the font file; The table labels of each data table are read sequentially, and the table labels are compared with a predefined list of color-coded character table feature labels. When a feature containing the feature label list of the color glyph table is matched, the sequential reading is paused and the process is switched to the composite data deep parsing mode. In the composite data deep parsing mode, the matched current data table is expanded in a hierarchical structure, and the contour vector data, color layer data, and layer blending rule metadata are separated from the current data table; The separated contour vector data, color layer data, and layer blending rule metadata are decompressed and re-encoded, and combined into independent color glyph description information that can be directly interpreted by the rendering kernel; After completing the deep parsing of the current data table, record the parsing progress and resume the sequential reading of subsequent data tables until all data tables have been traversed.

3. The vector graphics rendering method based on a rendering engine according to claim 2, characterized in that, The pre-compilation processing of the execution vector path includes the following steps: Retrieve the color glyph description information corresponding to the current rendering instruction from the glyph cache pool; The colored glyph description information is parsed, and the contour vector data is extracted from it. The contour vector data is represented by a quadratic Bézier curve command sequence or a cubic Bézier curve command sequence. The quadratic or cubic Bézier curve command sequence is converted into a polygonal approximation representation containing line segments and specific control points, forming a discretized set of path points. Planar scanline analysis is performed on the discretized set of path points to calculate the intersection of each scanline with the path boundary, and a closed filling region description is generated according to the odd-even filling rule. The filling region description is associated with the color layer data in the color glyph description information, and an independent drawing batch identifier is assigned to each associated filling region. The associated filled regions carrying the drawing batch identifier are organized into an intermediate representation suitable for hardware-accelerated drawing, the structure of which is suitable for parallel shading by a streaming processor or a graphics processor.

4. The vector graphics rendering method based on a rendering engine according to claim 3, characterized in that, The pixel-cached-aware rasterization computation for the intermediate representation suitable for hardware-accelerated rendering includes the following steps: Allocate a pixel buffer area with the same resolution as the output target for the current graphics target to be rendered; Read the data corresponding to one of the drawing batch identifiers in the intermediate representation applicable to hardware-accelerated drawing; Based on the description of the filling area corresponding to the drawing batch identifier, the pixel range covered by the filling area is calculated, and the pixel range is defined by the minimum bounding rectangle; Within the area defined by the minimum bounding rectangle, traverse each pixel and determine whether the center point of the pixel is located within the boundary described by the filling area; For pixels that are determined to be within the boundary, the corresponding color layer data is searched from the color glyph description information according to the association mapping relationship, and the final color value of the pixel is calculated through color synthesis operation; The calculated final color value is written to the corresponding memory location in the pixel buffer. After processing one drawing batch identifier, the next drawing batch identifier is processed in a loop until all batches are processed. At this time, the data stored in the pixel buffer constitutes the final raster image.

5. The vector graphics rendering method based on a rendering engine according to claim 1, characterized in that, The management of the character cache pool includes the following steps: Initialize a memory region with a fixed capacity as the glyph cache pool, and establish a hash index table for the glyph cache pool with glyph identifiers as keys and memory addresses as values; When the color font parsing logic generates new color glyph description information, the byte length of the color glyph description information is calculated; Check whether the remaining free capacity of the character cache pool is greater than or equal to the byte length; If the remaining free capacity meets the requirements, then a space of the corresponding size is allocated in the contiguous free memory block of the character cache pool to store the colored character description information, and the allocated memory starting address and the corresponding character identifier are registered in the hash index table; If the remaining free capacity does not meet the requirements, one or more cached items are evicted from the glyph cache pool to free up space according to the least recent use principle, and the hash index table is updated before the allocation and storage operations are performed.

6. The vector graphics rendering method based on a rendering engine according to claim 5, characterized in that, The operation of the multilingual adaptation layer includes the following steps: During the initialization phase of the rendering engine, the host language application programming interface type provided by the current runtime environment is detected; Based on the detected host language application programming interface type, the corresponding interface binding code is loaded, and the interface binding code converts the function calling convention of the host language into a call to the internal function of the rendering kernel; Define a set of rendering description protocols that are independent of the host language, which are used to describe the graphics type, coordinates, color, font name and text content; Receive raw rendering commands from the host language environment and serialize the raw rendering commands into a standard data stream according to the rendering description protocol; The serialized standard data stream is bound to code through the interface and passed as the instruction stream to the rendering kernel for subsequent processing.

7. A vector graphics rendering method based on a rendering engine according to claim 6, characterized in that, Serializing the original rendering commands into a standard data stream according to the rendering description protocol includes: Analyze the semantics of the original rendering commands to identify the command types, which include drawing text, drawing paths, or drawing images; Based on the identified command type, rendering parameters are extracted from the original rendering command. For a text drawing command, the extracted parameters include the text string, font identifier, font size, and starting coordinates; for a path drawing command, the extracted parameters include the path point coordinate sequence and drawing style; for an image drawing command, the extracted parameters include the image resource identifier, target position, and size. The extracted rendering parameters are encoded in a binary format defined by the rendering description protocol, the binary format including a fixed command header, parameter length field, and parameter value field; The encoded binary data block is appended to the end of the buffer queue of the current rendering task. When the amount of data in the buffer queue reaches a preset threshold or a refresh signal is received, all the binary data blocks in the buffer queue are concatenated in order to form the complete standard data stream.

8. The vector graphics rendering method based on a rendering engine according to claim 1, characterized in that, The method also includes a post-processing step for the raster image: After the rasterization processing unit generates the final raster image, it checks whether the final raster image contains alpha channel information. If alpha channel information is included, then alpha mixing calculation is performed on the final raster image based on the pre-configured background color or the underlying image; Based on the color characteristic description file of the target output device, the image data after alpha mixing calculation is converted to color space, from the linear color space used inside the rendering kernel to the target color space; A dithering algorithm is applied to the image data after color space conversion to reduce color banding when displayed on high color depth devices; The image data processed by the dithering algorithm is packaged into an image format data packet that meets the requirements of the target output interface.

9. A vector graphics rendering method based on a rendering engine according to claim 8, characterized in that, The alpha hybrid computing employs a hybrid pipeline, and its steps include: Receive the source color value and the target color value to be mixed. The source color value comes from the color layer data in the color glyph description information, and the target color value comes from the value currently stored at the corresponding position in the pixel buffer or the pre-configured background color. Read the preset blending mode identifier of the current layer from the layer blending rule metadata of the color glyph description information; Based on the blending mode identifier, a corresponding blending function is selected from a predefined blending function library. The blending function defines the mathematical relationship of how to calculate the output color value based on the alpha channel of the source color value, the alpha channel of the target color value, and the color components. The selected blending function is invoked, passing in the source color value, the target color value, and optional additional blending parameters, to calculate the blended output color value; The calculated output color value is returned as the result.

10. A vector graphics rendering method based on a rendering engine according to claim 3, characterized in that, Perform planar scanline analysis on the discretized set of path points, including: Obtain the minimum and maximum Y coordinate values ​​in the vertical direction of the discretized path point set to determine the total coverage area of ​​the scan line; Multiple horizontal scan lines are generated within the total coverage area with a fixed step value, and each scan line corresponds to a specific Y coordinate value; For each scan line, the intersection points of the scan line and each polygon edge formed by the discretized set of path points are calculated sequentially, where the polygon edge is formed by connecting adjacent path points. Sort all the calculated intersection points in ascending order according to their X coordinate values ​​to generate a sequence of intersection points for the scan line. According to the odd-even filling rule, starting from the first intersection of the intersection sequence, every two consecutive intersections are defined as a filling interval, and pixels located within the filling interval are considered to be within the path boundary. Merge all filling intervals corresponding to the current scan line to generate the contribution of the current scan line to the description of the closed filling region; Traverse all scan lines and integrate the contributions generated by all scan lines to form a complete description of the filled region consisting of multiple horizontal filled interval bands.

Images