Icon rendering method and electronic equipment

Abstract

The invention relates to the technical field of mobile application development, and discloses an icon rendering method and electronic equipment, which are applied to the electronic equipment without an Android running environment, and the method comprises the following steps: obtaining a source file of an Android vector icon; analyzing a root element of the source file to obtain a size attribute and a viewport attribute; based on the size attribute and the viewport attribute, creating a rendering canvas and establishing a mapping matrix from a viewport coordinate system to a canvas coordinate system; all elements in the source file are rendered step by step from the root element in a recursive processing mode; and outputting the bitmap after rendering is completed. According to the method, accurate analysis and efficient rendering of the vector diagram target in a server-side environment which is not supported during Android operation are realized, the technical problem that a complex vector path and a transformation matrix cannot be processed in a pure Java environment is solved, and high fidelity and compatibility of icon extraction are ensured.

Description

Technical Field

[0001] This invention relates to the field of mobile application data processing and graphics rendering, and in particular to an icon rendering method and an electronic device. Background Technology

[0002] In related technologies, it is impossible to correctly parse and render Android VectorDrawable format vector icons in a server-side Java environment, especially due to the lack of support for SVG path syntax and transformation matrices, resulting in rendering difficulties and poor performance. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an icon rendering method and an electronic device that enables the rendering of Android vector format icons in a server environment without an Android running environment.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: An icon rendering method, applied to electronic devices without an Android operating environment, the method comprising: Get the source files of Android vector icons; Parse the root element of the source file to obtain its size and viewport attributes; Based on the size and viewport attributes, a rendering canvas is created and a mapping matrix from the viewport coordinate system to the canvas coordinate system is established. The source file is rendered by recursively rendering all elements starting from the root element. After rendering is complete, output a bitmap.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described icon rendering method.

[0006] The beneficial effects of this invention are as follows: By parsing the root element of the source file to obtain size and viewport attributes, a rendering canvas is created based on these attributes, and a mapping matrix from the viewport coordinate system to the canvas coordinate system is established, achieving accurate conversion from logical coordinates to physical pixel coordinates and solving the technical problem of the inability to adapt the vector viewport mechanism in non-Android environments. Through recursive processing, all elements in the source file are rendered level by level starting from the root element, replicating the native layer rendering logic of the Android system. This allows for complete parsing and processing of complex tree-like hierarchical structures and nested transformation relationships, outputting a bitmap after rendering. Thus, for the first time, accurate rendering of Android vector format icons is achieved on a server-side system without Android runtime support, filling the processing capability gap in this technical scenario. This method establishes a feasible technical path from source file parsing and coordinate space mapping to recursive rendering, enabling the server to automatically generate and apply the original design intent without relying on the mobile operating system. Figure 1 The high-quality icon bitmaps effectively support the rigid requirements of application icon visualization in server-side business scenarios such as application distribution and security testing. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of an icon rendering method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an icon rendering method provided in an embodiment of the present invention; Figure 3 This invention provides an SVG path parsing algorithm flow as an embodiment of the present invention; Figure 4 A flowchart of a transformation matrix application provided in an embodiment of the present invention; Figure 5 A path command processing state machine diagram provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] In related technologies, accurately extracting application icons from APK installation packages is a fundamental and frequently required function in third-party application markets, enterprise application distribution platforms, or mobile security detection systems. Icons are not only used for front-end display on application detail pages but also for brand identification and counterfeit application detection. However, related technologies lack effective methods for parsing and rendering new Android vector icons in non-Android runtime environments. With the introduction of Vector Drawable in Android 5.0 and Adaptive Icons in Android 8.0, application icons are no longer limited to static bitmap files (such as PNG) but widely adopt vector graphics defined based on XML. Because there is no corresponding adaptive icon recognition framework on the server side, it is impossible to effectively parse this format, resulting in icon extraction failures, inability to synthesize adaptive icons, or abnormal display of extracted icons, leading to missing application display information.

[0013] For example, modern APK application icons often use an Adaptive Icon structure, with their foreground or background layers referencing Vector Drawable XML files containing complex SVG path syntax. In standard Java environments (such as OpenJDK) typically running on the server side, the lack of support from core APIs like Context, Resources, or VectorDrawable in the Android Framework layer prevents the system from directly reading and parsing these XML files. When the app store backend attempts to extract the icon, it is unable to process the XML format resources, resulting in broken icons, displaying the default Android robot image, or completely blank icons on the user's device. Furthermore, the complex path transformations (such as translation, rotation, and scaling) and group structures in Vector Drawable lack direct implementations in standard Java graphics libraries; forcibly parsing them often leads to graphic distortion or color loss.

[0014] Furthermore, in order to obtain the rendered icon, related technologies typically require relying on Android emulators or real device environments for screenshotting or API calls, or using parsing libraries that only support resource path reading but not graphics rendering. The former consumes a lot of resources and has a slow processing speed, making it difficult to meet the high-concurrency throughput requirements of the server; the latter cannot handle the rasterization conversion of vector graphics. Existing pure Java parsing libraries do not yet have a mature solution that can completely parse SVG path data and simulate the Android rendering pipeline, making it difficult to obtain high-fidelity application icon bitmaps when not in an Android device environment.

[0015] To address the aforementioned problems, this application provides an icon rendering method and an electronic device. The icon rendering method of this application is described in detail below.

[0016] The icon rendering method in this application can be used in scenarios such as server-side environments without Android runtime environment support, cloud application processing platforms, or local Java development environments. The electronic device in this application can be an electronic device running a standard operating system such as a server, cloud host, data processing workstation, or personal computer without Android runtime environment support, such as an application market backend server or application market cloud server.

[0017] The following describes in detail one of the icon rendering methods of this invention, with reference to the appendix. Figure 1 This includes steps 110 to 150.

[0018] Step 110: Obtain the source files of the Android vector icons.

[0019] On the server or non-Android device, the vector icon file to be processed is read. This source file is defined in XML format and contains the hierarchical structure of the vector graphics, path data, and related attribute information.

[0020] Step 120: Parse the root element of the source file to obtain the size and viewport attributes.

[0021] The obtained XML source file is parsed to locate the root element. The size attribute is extracted from the root element, which defines the width and height of the icon in physical display; at the same time, the viewport attribute is extracted, which defines the width and height of the virtual coordinate system on which the vector path data is based (i.e., the viewport).

[0022] Step 130: Based on the size and viewport attributes, create a rendering canvas and establish a mapping matrix from the viewport coordinate system to the canvas coordinate system.

[0023] Based on the extracted size attributes, a rendering canvas of the corresponding size is created in memory. Since the coordinates of the vector path are virtual coordinates defined based on viewport attributes, while the canvas uses pixel coordinates, a mapping matrix needs to be established. This matrix maps points in the virtual coordinate space to the pixel coordinate space of the canvas by calculating the proportional relationship between the viewport attributes and the size attributes.

[0024] Step 140: Render all elements in the source file level by level, starting from the root element, using a recursive processing method.

[0025] Starting from the root element of the XML, the entire document tree is traversed. The system maintains the rendering state, and for each element encountered, its type is determined. If the element contains child elements (such as group elements), the process recursively proceeds to the next level; if the element is a graphical definition (such as a path element), it is drawn based on the current coordinate transformation state. This recursive mechanism ensures the correct representation of the graphical hierarchy.

[0026] Step 150: Output a bitmap after rendering is complete.

[0027] Once all elements have been traversed and rendered, the final graphic data is stored in the rendering canvas. At this point, the canvas content is output as a bitmap file for use by the application market or server-side business.

[0028] This application obtains size and viewport attributes by parsing the root element of the source file. Based on these attributes, a rendering canvas is created, and a mapping matrix from the viewport coordinate system to the canvas coordinate system is established, achieving precise conversion from logical coordinates to physical pixel coordinates. This solves the technical challenge of the vector viewport mechanism not being compatible in non-Android environments. By recursively rendering all elements in the source file from the root element, it replicates the native layer rendering logic of the Android system, enabling complete parsing and processing of complex tree-like hierarchical structures and nested transformation relationships, and outputting a bitmap after rendering. This achieves accurate rendering of Android vector format icons on a server-side system without Android runtime support for the first time, filling a processing capability gap in this technical scenario. This method establishes a feasible technical path from source file parsing and coordinate space mapping to recursive rendering, enabling the server to automatically generate and apply the original design intent without relying on the mobile operating system. Figure 1 The high-quality icon bitmaps effectively support the rigid requirements of application icon visualization in server-side business scenarios such as application distribution and security testing.

[0029] In one embodiment of this application, the path rendering logic in step 140 above includes steps 210 to 220.

[0030] Step 210: If the current element is a path element, then parse the command corresponding to the path element.

[0031] During the recursive traversal, when the currently processed element is identified as a path element, the path data defined in that element is read. This path data consists of a series of SVG path syntax characters, containing specific drawing instructions and coordinate parameters.

[0032] Step 220: Perform the drawing operation according to the command type and update the coordinates of the current drawing point.

[0033] The system decomposes the read path data into instructions, identifying each independent drawing command. For each command, it executes the corresponding geometric drawing operation based on its type (e.g., move, draw line). During execution, the system updates the current drawing point coordinates in real time to ensure that the next command can start drawing from the correct position.

[0034] In this way, this embodiment decomposes the complex vector path definition into atomic drawing operations. By parsing the specific commands in the path elements and combining them with the dynamic update of the current point coordinates, the process of converting the text-described path data into geometric shapes is realized, ensuring the accurate drawing of the vector shape outline.

[0035] In one embodiment of this application, steps 310 to 320 are also included, which may be performed when rendering all elements in the source file in step 140.

[0036] Step 310: If the element being processed is a group element, parse the geometric transformation attribute of the group element.

[0037] When traversing to a group element, this element is typically used as a container to manage a group of child elements. The system reads the geometric transformation properties defined in the group element, which include parameters such as translation, rotation, and scale.

[0038] Step 320: Perform coordinate transformation operation according to the geometric transformation attributes, and update the transformation matrix of the current drawing coordinate system.

[0039] Using the parsed geometric transformation attributes, a corresponding transformation matrix is ​​constructed. The system performs operations (such as matrix multiplication) between the transformation matrix in the current drawing environment and the newly constructed matrix, thereby updating the current drawing coordinate system. When processing the sub-elements of this group, the updated transformation matrix is ​​applied to achieve a uniform transformation of all graphics within the group. Typically, after processing this group of elements, it is necessary to restore the previous transformation state.

[0040] In this way, modular transformation control of graphics is achieved by processing the geometric transformation attributes of group elements. By updating the transformation matrix, the correct transmission and application of complex operations such as translation, rotation, and scaling between parent and child levels are supported, ensuring the correctness of the spatial position and shape of the combined graphics.

[0041] In one embodiment of this application, steps 410 to 420 are also included, which may be executed during the parsing of the path command in step 220.

[0042] Step 410: Read the commands in the path elements one by one. When the target command is read, parse the corresponding command parameters according to the command type of the target command.

[0043] The system scans the path string using a path parser, reading characters sequentially. When a character representing a command is detected, the command type is determined. Subsequently, the system continues to read the numerical content following the command character, parsing it into the specific parameters required by the command (such as coordinates, angles, etc.).

[0044] Step 420: Based on the command parameters, generate the corresponding path segment and update the coordinates of the current drawing point.

[0045] Based on the parsed command type and corresponding parameters, a specific geometric path segment is constructed. For example, the parsed coordinate parameters are applied to the geometric path object (GeneralPath) to generate the corresponding line segment or curve segment, and the endpoint of the path is recorded as the new coordinates of the current drawing point.

[0046] In this way, a parsing bridge is built from character streams to geometric objects. By reading and parsing commands and their parameters one by one, it is compatible with the definition of SVG path syntax, accurately converting abstract string data into computer-recognizable path segment objects, and providing basic data for graphic rasterization.

[0047] In one embodiment of this application, step 420, which involves processing different command types, includes steps 510 to 530.

[0048] Step 510: If the command type is a move command or a line command, obtain the coordinates of the target point and generate a straight line path segment based on the current point position and the target point coordinates.

[0049] When the parsed command is a move command (M / m), update the current drawing point position to the target point; when it is a line command (L / l), generate a straight line path segment based on the current point position and the parsed target point coordinates, and update the current point.

[0050] Step 520: If the command type is a curve command, obtain the curve parameters and generate a curve path segment based on the current point position.

[0051] When the parsed command is a curve command (C / C), the control point and endpoint parameters contained in the command are extracted. The system uses these parameters, combined with the current point position, to calculate and generate smooth path segments such as Bézier curves, accurately reproducing the curve shape in the design draft.

[0052] Step 530: If the command type is a closing command, obtain the closed path and generate a closed path segment based on the current point position.

[0053] When the parsed command is a closure command (Z / z), the system automatically finds the starting point of the current sub-path and generates a connecting line segment between the current point and the starting point, thus forming a closed geometric region for subsequent filling operations.

[0054] This approach covers the basic geometric primitives of vector drawing. By classifying and processing the move, line, curve, and close commands, it enables the mathematical description of arbitrarily complex vector contours. In particular, the support for curve commands ensures that the edges of the graphics remain smooth when zoomed in or out, demonstrating the high-quality characteristics of vector graphics.

[0055] In one embodiment of this application, step 610 is also included, which can be executed when processing different command types in step 420.

[0056] Step 610: When parsing command parameters fails, a preset fault tolerance strategy is adopted for handling; the preset fault tolerance strategy includes skipping erroneous commands, replacing with default values, and terminating the current path parsing.

[0057] During the process of reading path data, if parsing fails due to non-standard characters or missing parameters, the system triggers a fault tolerance mechanism. Based on preset strategies, the system can choose to ignore the erroneous command and attempt to read the next command, replace the erroneous parameter with a default value, or directly stop parsing the current path to prevent program crashes.

[0058] This approach enhances the system's robustness and stability. Through fault-tolerance strategies, the system can handle source files with non-standard formats or minor errors, preventing service interruptions due to parsing anomalies and improving the availability of the icon extraction service.

[0059] In one embodiment of this application, the process of establishing the mapping matrix in step 130 includes steps 710 to 730.

[0060] Step 710: Calculate the first ratio of the logical width of the viewport attribute to the physical width of the size attribute.

[0061] The system obtains the viewport width value defined in the XML and the physical width value defined in the size attribute. By calculating the ratio of the physical width to the viewport width, the horizontal scaling ratio (first ratio) is obtained.

[0062] Step 720: Calculate the second ratio of the logical height of the viewport attribute to the physical height of the size attribute.

[0063] Similarly, the system obtains the viewport height value and the physical height value in the size attribute, and calculates the ratio of the physical height to the viewport height to obtain the vertical scaling ratio (second ratio).

[0064] Step 730: Based on the first and second scales, generate a scaling transformation matrix as a mapping matrix.

[0065] Using the calculated first and second scales, a scaling transformation matrix is ​​constructed. This matrix will be applied to the rendering canvas context, so that all subsequent drawing commands based on the viewport coordinate system will be automatically multiplied by this scale during execution, thus correctly mapping to the physical pixel size.

[0066] In this way, a standardized conversion from logical coordinates to physical coordinates is achieved. By calculating the aspect ratio and constructing a mapping matrix, vector graphics can adapt to physical canvases of any size while maintaining their shape, achieving resolution-independent rendering effects.

[0067] In one embodiment of this application, step 810 is also included, which can be performed during the process of establishing the mapping matrix in step 130.

[0068] Step 810: When the first scale and the second scale are not equal, perform a non-uniform scaling transformation.

[0069] In some cases, the viewport scale defined in the source file is inconsistent with the physical size scale of the target output. In this situation, the values ​​of the first scale and the second scale are different. The system performs a non-uniform scaling transformation, applying different scaling factors in the horizontal and vertical directions, to ensure the graphic fills or adapts to the specified target size.

[0070] This approach provides flexible size adaptation capabilities. By supporting non-uniform scaling, the system can meet the need to render icons to specific non-standard sizes, ensuring that graphic content is fully rendered on canvases with different aspect ratios.

[0071] In one embodiment of this application, step 910 is also included, which can be performed when the rendering canvas is created in step 130.

[0072] Based on the parsed size attributes (width and height), the system allocates corresponding image data space in memory and instantiates a bitmap object. This bitmap object serves as the carrier entity (Canvas) for drawing operations, receiving pixel data generated by subsequent path rendering.

[0073] In this way, the initial preparation for the rendering process is completed. By creating a bitmap object of a specified size, a physical storage medium is provided for the rasterization of vector data, ensuring that subsequent rendering operations have a clear output target.

[0074] In summary, this invention establishes a precise mapping matrix from the viewport coordinate system to the canvas coordinate system by acquiring and parsing the size and viewport attributes of the Android vector icon source file, thus solving the coordinate adaptation problem in the physical pixel conversion process of vector graphics. By recursively traversing the source file structure and combining the geometric transformation attributes of group elements with the cascading update mechanism of the transformation matrix, it accurately replicates the dynamic transformation logic of complex nested levels, translation, rotation, and scaling. Furthermore, by constructing a state machine-based path parser, it decomposes the abstract SVG path string into atomic geometric commands such as movement, straight lines, curves, and closure. Combined with real-time updated drawing point coordinates and fault-tolerance strategies, it ultimately achieves high-fidelity rendering and bitmap output of Vector Drawable icons on server devices without an Android runtime environment. This solution effectively overcomes the technical barrier of lacking underlying graphics API support in non-Android environments, significantly improving the parsing compatibility and rendering quality of new Android application icons in application markets and backend systems.

[0075] The following combination Figure 2 (Flowchart illustrating an icon rendering method) Figure 3 (Flowchart of an SVG path parsing algorithm) Figure 4 (A flowchart of a transformation matrix application) and Figure 5 (A path command processing state machine diagram), detailing the specific implementation logic of the present invention step by step.

[0076] Step 1: Source file acquisition and document parsing (corresponding to...) Figure 2 Steps S1 to S2 correspond to obtaining the source file of the Android vector icon in step 110 above.

[0077] The system first loads the input Vector Drawable XML file. On the server side without an Android environment, a standard XML parser is used to read the text content of the file and convert it into a DOM tree or event stream in memory, so that the attribute data of the root node and child nodes can be extracted later.

[0078] Step 2: Root attribute extraction and viewport definition (corresponding) Figure 2 The relevant processes in steps S3, S4.1 and S5.1 correspond to the root element of the parsed source file in step 120 above.

[0079] The parser locates the root tag of the vector, extracts the width and height as physical dimensions, and extracts the viewport as a viewport attribute. The viewport defines the virtual coordinate space of the vector graphics, with units independent of the actual displayed pixels, providing a unified logical coordinate system basis for subsequent path drawing.

[0080] Step 3: Canvas Creation and Global Mapping Establishment (corresponding) Figure 2 The steps S6 and S7 correspond to creating the rendering canvas and establishing the mapping matrix in step 130 above.

[0081] Based on the extracted physical dimensions, the system creates a bitmap object with corresponding width and height, along with the corresponding Graphics2D drawing context, in memory. Simultaneously, it calculates the ratio of the physical dimensions to the viewport dimensions and constructs an initial global affine transformation matrix. This transformation matrix ensures that subsequent graphics defined based on viewport coordinates can be accurately mapped onto the physical pixel canvas.

[0082] Step 4: Recursive traversal and group transformation processing (corresponding to) Figure 2 Steps S8, S9.1 and Figure 4 The entire process), corresponding to all elements in the source file at the recursive point in step 140 above.

[0083] The system enters a recursive rendering process. When traversing a group element, it first parses its transformation properties such as translateX, translateY, rotation, scaleX, and scaleY. A local transformation matrix is ​​constructed using these properties and multiplied with the matrix of the current context. Before rendering child elements, the system saves the current transformation operation, then recursively calls the rendering process to handle nodes within the group. After the child elements are rendered, a transformation state restoration operation is performed, ensuring that complex nested transformation logic (such as scaling graphics within a rotation group) is correctly applied without interference.

[0084] Step 5: Path data extraction and parser initialization (corresponding to...) Figure 2 intermediate step S10.1 and Figure 3 The process in step S2 corresponds to the path parsing and initialization in step 210 above.

[0085] When the recursive traversal reaches a path element, the system extracts the SVG string from the tag's `android:pathData` attribute. A private path parser class is instantiated and its parsing state is initialized, preparing for character-by-character scanning and parsing of the string stream.

[0086] Step 6: Command parsing based on state machine (corresponding to...) Figure 3 Middle step S4 and Figure 5 (State machine full process), corresponding to step 220 above.

[0087] Reference Figure 5 The state machine logic involves the instantiated PathParser entering the command reading state. The system identifies key characters (M / L / C / Z, etc.) in the path string to switch state branches. If M / m is detected, proceed to the movement command branch, parse the coordinates, and execute the movement command. If L / l is detected, enter the line command branch, parse the coordinates and execute the line command; If C / c is detected, enter the curve command branch, parse the control point and endpoint, and execute the curve command; If Z / z is detected, enter the closure command branch and execute the closure path command.

[0088] After parsing is complete, update the current point coordinates and loop to read the next command until the end of the string.

[0089] Step 7: Geometric path construction and graphic drawing (corresponding) Figure 3 intermediate step S12 and Figure 2 (Steps S10.3 and S10.4 in the process) correspond to the bitmap output after rendering in step 150.

[0090] During the parsing process, the system adds the parsed geometric instructions to the Java AWT GeneralPath object in real time. This object serves as the geometric carrier of the vector data, containing complete contour information. When path parsing is complete, the system combines the fill and stroke colors defined in the XML and uses the Graphics2D context to draw the GeneralPath object, rendering it onto the bitmap created in step 3.

[0091] Step 8: Rendering Completed and Result Output (corresponding) Figure 2 The process in step S11 corresponds to the bitmap output after rendering in step 150 above.

[0092] After all group and path elements in the XML document have undergone the recursive, transform, parsing, and drawing process described above, the canvas in memory displays the complete icon. The system then encodes the bitmap object into a target format (such as PNG) for output, completing the entire rendering process.

[0093] In summary, this application constructs a complete server-side vector rendering engine by combining XML structure parsing, matrix transformation management, and a state machine-based SVG path parsing algorithm. It utilizes the GeneralPath object to carry complex geometric paths and precisely processes SVG instructions through a PathParser, solving the problem of being unable to parse Vector Drawables in an environment without Android. Furthermore, through recursive transformation processing of group elements, it achieves perfect support for complex hierarchies and dynamic transformations, ensuring that the generated bitmaps are highly consistent with the rendering results on Android devices in terms of geometry, proportions, and visual effects.

[0094] Please refer to Figure 6The present invention also provides an electronic device 400, including a memory 402 and a processor 401, and a computer program stored on the memory 402 and running on the processor 401. When the processor 401 executes the computer program, it implements the various steps in the icon rendering method described above.

[0095] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0096] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An icon rendering method, characterized in that, The method, applied to electronic devices without an Android operating environment, includes: Get the source files of Android vector icons; Parse the root element of the source file to obtain its size and viewport attributes; Based on the size and viewport attributes, a rendering canvas is created and a mapping matrix from the viewport coordinate system to the canvas coordinate system is established. The source file is rendered by recursively rendering all elements starting from the root element. After rendering is complete, output a bitmap.

2. The icon rendering method according to claim 1, characterized in that, The step of recursively rendering all elements in the source file, starting from the root element and proceeding level by level, includes: If the current element is a path element, then parse the command corresponding to the path element, perform the drawing operation according to the command type of the command, and update the coordinates of the current drawing point.

3. The icon rendering method according to claim 1, characterized in that, The method of recursively rendering all elements in the source file, starting from the root element and proceeding level by level, also includes: If the element being processed is a group element, then the geometric transformation attribute of the group element is parsed, a coordinate transformation operation is performed according to the geometric transformation attribute, and the transformation matrix of the current drawing coordinate system is updated.

4. The icon rendering method according to claim 2, characterized in that, The step of parsing the command corresponding to the path element, performing drawing operations according to the command type of the command, and updating the current point position further includes: The commands in the path elements are read one by one. When the target command is read, the corresponding command parameters are parsed according to the command type of the target command. Based on the command parameters, the corresponding path segment is generated and the coordinates of the current drawing point are updated.

5. The icon rendering method according to claim 4, characterized in that, The step of parsing the corresponding command parameters based on the command type of the target command includes: If the command type is a movement command or a line command, obtain the coordinates of the target point; If the command type is a curve command, obtain the curve parameters; If the command type is a closing command, obtain the closing path; The step of generating the corresponding path segment and updating the coordinates of the current drawing point based on the command parameters includes: Based on the move command and the line command, a straight path segment is generated according to the current point position and the coordinates of the target point; Based on the curve command, generate a curve path segment according to the current point position; Based on the closure command, a closed path segment is generated according to the current point position.

6. The icon rendering method according to claim 5, characterized in that, Also includes: When parsing the command parameters fails, a preset fault tolerance strategy is used for handling. The preset fault tolerance strategies include skipping erroneous commands, replacing them with default values, and terminating the current path resolution.

7. The icon rendering method according to claim 1, characterized in that, The step of creating a rendering canvas and establishing a mapping matrix from the viewport coordinate system to the canvas coordinate system based on the size attribute and viewport attribute also includes: Calculate a first ratio between the logical width of the viewport attribute and the physical width of the size attribute; Calculate a second ratio between the logical height of the viewport attribute and the physical height of the size attribute; Based on the first ratio and the second ratio, a scaling transformation matrix is ​​generated as the mapping matrix.

8. The icon rendering method according to claim 7, characterized in that, Also includes: When the first ratio is not equal to the second ratio, a non-uniform scaling transformation is performed.

9. The icon rendering method according to claim 1, characterized in that, The step of creating the rendering canvas also includes: Create a bitmap object with specified width and height as a rendering canvas based on the size attributes.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the icon rendering method according to any one of claims 1-9.

Images