Image rendering method and device, electronic equipment and storage medium

Abstract

The application discloses an image rendering method and device, electronic equipment and storage medium. The method comprises the following steps: determining a target index set from a plurality of index information in an index buffer object of a rendering object according to an interactive operation of a user and a rendering window. The interactive operation comprises panning a rendering object, zooming a rendering object, rotating a rendering object or changing a rendering window. The rendering window is an area for displaying a rendering result. The rendering object is a model to be rendered. The index buffer object stores index information of a plurality of vertex data of the rendering object. The target index set comprises a plurality of index information corresponding to a plurality of vertex data located in the rendering window. The method comprises the following steps: rendering according to a vertex buffer object and the target index set to obtain a first rendering result. The vertex buffer object stores a plurality of vertex data of the rendering object. The method can reduce the data amount of GPU rendering and improve the rendering efficiency.

Description

Technical Field

[0001] This application relates to the field of image rendering and processing technology, and in particular to an image rendering method, apparatus, electronic device and storage medium. Background Technology

[0002] Traditional image rendering techniques typically employ persistent mapping buffers for reading, writing, and processing rendering data. During the rendering process, all vertex data requires attribute modification and geometric subdivision, followed by rendering window pruning based on instructions or requirements to obtain the final image data. If the rendering window needs modification or adjustment, all vertex data of the model must be re-rendered. However, what is actually displayed in the window is often only a part of the entire rendered object, resulting in a large amount of rendering computation being wasted on invisible primitives outside the window. The rendering results of these invisible primitives are directly discarded during subsequent pruning, thus causing a significant waste of GPU computing power and video memory bandwidth, and rendering efficiency needs to be improved. Summary of the Invention

[0003] This application discloses an image rendering method, apparatus, electronic device, and storage medium, which addresses the problem of insufficient rendering efficiency in the prior art.

[0004] In a first aspect, this application provides an image rendering method, the method comprising: determining a target index set from multiple index information in an index buffer object (EBO) of a rendering object based on user interaction operations and a rendering window, wherein the interaction operations include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window, the rendering window being an area for displaying the rendering result, the rendering object being a model to be rendered, the index buffer object (EBO) storing index information of multiple vertex data of the rendering object, and the target index set being composed of multiple index information corresponding to multiple vertex data located in the rendering window; and rendering based on a vertex buffer object (VBO) and the target index set to obtain a first rendering result, wherein the vertex buffer object (VBO) stores multiple vertex data of the rendering object. As can be seen, in related technologies, all vertex data of the rendering object are rendered first to obtain intermediate rendering results, and then the intermediate rendering results are clipped through the rendering window to obtain the final rendering result. In contrast, this application determines the target index set based on the rendering window. In subsequent rendering steps, only the vertex data corresponding to the index information in the target index set needs to be rendered to obtain the first rendering result of the rendering object in the rendering window. This application reduces the number of vertex data to be rendered, that is, reduces the amount of data rendered by the GPU, which can improve rendering efficiency.

[0005] In conjunction with the first aspect, in one possible embodiment, determining a target index set from multiple index information in the Index Buffer Object (EBO) of the rendering object based on the user's interaction operation and the rendering window includes: determining a first transformation matrix corresponding to the interaction operation; using a computational shader to transform multiple vertex data in the Vertex Buffer Object (VBO) based on the first transformation matrix to update the multiple vertex data in the Vertex Buffer Object; determining multiple vertex data that are still located in the rendering window after transformation based on the updated multiple vertex data and the rendering window; and determining the target index set in the EBO based on the multiple vertex data located in the rendering window. It can be seen that, according to the first transformation matrix corresponding to the interaction operation, the embodiments of this application pre-filter vertex data located within the rendering window in the computational shader, and based on this, determine the target index set composed of the index information of the vertex data still located within the rendering window from the EBO. Since the target index set does not include the index information of vertex data outside the rendering window, when rendering based on the vertex buffer object and the target index set, vertex data that is completely invisible in the rendering window can be eliminated, reducing the amount of data submitted to subsequent rendering pipelines, thus reducing the GPU vertex processing load and improving rendering efficiency.

[0006] In conjunction with the first aspect, in one possible embodiment, before determining the target index set from multiple index information in the index buffer object (EBO) of the rendering object based on user interaction and the rendering window, the method further includes: obtaining and parsing the rendering object to obtain multiple initial vertex data corresponding to the rendering object, and multiple initial index information corresponding to the multiple initial vertex data, wherein the multiple initial vertex data are part or all of the multiple vertex data; writing the multiple initial vertex data into the vertex buffer object (VBO), and writing the multiple initial index information into the index buffer object (EBO), wherein the multiple initial index information and the multiple index information have at least partially identical index information. It can be seen that because the parsed initial vertex data is written to the VBO and the multiple initial index information is written to the EBO, the vertex data and index information of the rendering object are stored separately in a GPU-dedicated buffer object. This allows for vertex data reuse through indexing when multiple primitives share a vertex in the rendering object, eliminating the need to repeatedly store the vertex data corresponding to the shared vertex of multiple primitives. Simultaneously, it provides direct data structure support for subsequent index-based rendering.

[0007] In conjunction with the first aspect, in one possible embodiment, after writing multiple initial vertex data into a vertex buffer object (VBO) and multiple initial index information into an index buffer object (EBO), the method further includes: using a compute shader to perform an initial subdivision of the primitives corresponding to the multiple initial vertex data to obtain multiple vertex data and the index information corresponding to the multiple vertex data. It can be seen that although calling the compute shader still requires CPU usage, the initial subdivision of the primitives is performed using the compute shader on the GPU side. Therefore, the data synchronized between the CPU and GPU is the data before subdivision, resulting in higher communication efficiency. Furthermore, the subdivision process by the compute shader frees the CPU from the task of subdividing primitives, releasing CPU computing resources. Since GPU computing resources are relatively redundant, transferring the task of primitive subdivision from the CPU to the GPU can also improve the overall efficiency of primitive subdivision.

[0008] In conjunction with the first aspect, in one possible embodiment, before the step of initially subdividing the primitives corresponding to multiple initial vertex data using a compute shader, the method further includes: obtaining a first edit operation by a user on a first target primitive in a rendering object, wherein the first edit operation is used to modify the geometric properties of the first target primitive, the geometric properties including shape and / or size; based on the first edit operation, using a compute shader to write a first mapping relationship between the modified vertex data and the corresponding index information corresponding to the first target primitive to a shader buffer object SSBO, wherein the position information of the modified vertex data corresponding to the first target primitive is different from the vertex data of the first target primitive in a vertex buffer object VBO; using a compute shader based on the first mapping relationship, replacing the vertex data corresponding to the first target primitive in the vertex buffer object VBO with the modified vertex data, and updating the index information in an index buffer object EBO. As can be seen, in related technologies, the modification of geometric attributes and the subdivision of vertex data are both performed on the CPU side, which consumes a large amount of computing power for the CPU. In contrast, in this embodiment, the mapping relationship between the modified vertex data and the corresponding index information is written into the SSBO through the compute shader on the CPU side, and the vertex buffer object and index buffer object are updated based on the SSBO. This process is performed on the GPU side. Since the GPU generally has higher computing power and multi-core concurrency advantages than the CPU, the processing efficiency can be improved.

[0009] In conjunction with the first aspect, in one possible embodiment, after the step of initially subdividing the primitives corresponding to multiple initial vertex data using a computational shader, the method further includes: obtaining a second editing operation by the user on a second target primitive of the rendering object, wherein the second editing operation is used to modify the target attributes of the second target primitive, the target attributes being attributes other than geometric attributes, the geometric attributes including shape and / or size; according to the second editing operation, using the computational shader to write a second mapping relationship between the modified vertex data and the corresponding index information corresponding to the second target primitive to a shader buffer object SSBO, wherein the target attributes of the modified vertex data corresponding to the second target primitive are different from the vertex data of the second target primitive in a vertex buffer object VBO; using the computational shader based on the second mapping relationship, replacing the vertex data corresponding to the second target primitive in the vertex buffer object VBO with the modified vertex data, and updating the index information in an index buffer object EBO. As can be seen, in related technologies, the modification of vertex data attributes is performed on the CPU side, which consumes a large amount of computing power for the CPU. In contrast, in this embodiment, the mapping relationship between the vertex data with the target attribute modification and the corresponding index information is written into the SSBO through the compute shader on the CPU side, and the vertex buffer object and index buffer object are updated based on the SSBO. This process is performed on the GPU side. Since the GPU generally has higher computing power and multi-core concurrency advantages than the CPU, the processing efficiency can be improved.

[0010] In conjunction with the first aspect, in one possible embodiment, rendering is performed based on a vertex buffer object (VBO) and a target index set to obtain a first rendering result. This includes: determining a layout index and a foreground index, wherein the layout index is the index corresponding to the vertex data of the layout, and the foreground index is the index corresponding to the vertex data of the foreground; retrieving the corresponding layout data from the vertex buffer object (VBO) based on the layout index and performing layout rendering to obtain a layout rendering layer; retrieving the corresponding foreground data from the vertex buffer object (VBO) based on the foreground index and performing foreground rendering to obtain a foreground rendering layer; and obtaining the first rendering result based on the layout rendering layer and the foreground rendering layer. It can be seen that because the layout index and foreground index are determined based on the rendering window, and the layout index and foreground index respectively indicate the storage location of the corresponding layout data and foreground data in the VBO, layout rendering and foreground rendering can be performed separately according to different indices. This allows the rendering work to be separated according to logical levels, and the geometric data to be rendered in the VBO can be quickly located using only the index value. Therefore, this is beneficial for subsequent overlaying of effects, dynamic annotation, or interactive highlighting, enhancing the flexibility and real-time response capability of rendering.

[0011] In conjunction with the first aspect, in one possible embodiment, the graphics processor's video memory includes at least three vertex buffer objects (VBOs), with the number of VBOs being less than 10. One or more of the at least three VBOs are used to store vertex data, one of the multiple vertex buffer objects is used to store a second transformation matrix, and one of the multiple vertex buffer objects is used to store rendering instructions. The second transformation matrix is ​​used to convert the local coordinates of the vertex data into world coordinates during the rendering process. It can be seen that because at least only the VBOs corresponding to the vertex data, the VBOs corresponding to the second transformation matrix, and the VBOs corresponding to the instructions need to be configured, the number of VBOs is reduced compared to related technologies, simplifying the storage structure of the second geometric data. During the rendering process, the GPU does not need to search for the corresponding vertex data from a large number of VBOs, enabling it to quickly locate the required vertex data and improving rendering efficiency.

[0012] In conjunction with the first aspect, in one possible embodiment, after the step of rendering based on the vertex buffer object (VBO) and the target index set to obtain a first rendering result, the method further includes: obtaining the first video memory occupied by vertex data in the vertex buffer object (VBO) that is in a valid state; obtaining the second video memory currently occupied by the graphics processor (GPU) used by the program for rendering the rendering object; determining the percentage of video memory used based on the ratio of the first video memory to the second video memory; if the percentage of video memory used is greater than or equal to a first preset threshold, and the ratio of the second video memory to the total video memory of the graphics processor (GPU) is less than or equal to a second preset threshold, then the vertex buffer object (VBO) is expanded. As can be seen, by obtaining the first video memory occupied by the effective data in the VBO and the second video memory currently being called by the GPU, the percentage of video memory used can be calculated. This allows the system to determine when there is still video memory available but the percentage of effective data in the VBO is close to a preset threshold. This expands the storage capacity of the VBO, solving the problem of excessive GPU video memory usage and the frequent discarding of effective data or video memory overflow errors due to insufficient VBO space. It also dynamically balances video memory utilization and rendering stability, thereby improving the rendering stability in long-running or complex model editing scenarios.

[0013] In conjunction with the first aspect, in one possible embodiment, the Vertex Buffer Object (VBO) includes multiple vertex storage regions used to store vertex data. After the step of rendering based on the VBO and the target index set to obtain a first rendering result, the method further includes: changing the data state of the vertex data in the VBO from a valid state to an invalid state in response to a triggering condition, wherein the triggering condition includes the deletion or hiding of the primitives corresponding to the vertex data; deleting vertex data in the invalid storage regions when the number of invalid storage regions exceeds a threshold, wherein an invalid storage region is a vertex storage region that stores vertex data in an invalid state but does not store vertex data in a valid state. It can be seen that by actively cleaning up invalid storage regions that are interspersed with valid vertex storage regions, fragmented video memory space can be reclaimed, and discontinuous available vertex storage regions can be merged into a larger contiguous space. This can solve the problem of new large blocks of vertex data being unable to be allocated due to the accumulation of video memory fragmentation, improve the internal space reuse efficiency and allocation success rate of the VBO, thereby improving the stability and rendering performance in long-running or multi-round editing and rendering scenarios.

[0014] In conjunction with the first aspect, in one possible embodiment, the Vertex Buffer Object (VBO) includes multiple vertex storage areas for storing vertex data. Before the step of resizing the VBO, the method further includes deleting vertex data from invalid storage areas. It can be seen that by actively cleaning up vertex data in invalid storage areas before the resizing operation, the system can attempt to release video memory space by reclaiming invalid data before performing the costly resizing operation. If the space released after GC is sufficient to meet the requirements, unnecessary resizing operations can be reduced, thereby reducing the number of video memory reallocations and the associated overhead, reducing performance fluctuations caused by frequent resizing, and further improving the system's operating efficiency and stability.

[0015] Secondly, this application provides an image rendering apparatus, comprising: a determining unit, configured to determine a target index set from multiple index information in an index buffer object (EBO) of a rendering object based on user interaction operations and a rendering window, wherein the interaction operations include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window, the rendering window being an area for displaying rendering results, the rendering object being a model to be rendered, the index buffer object (EBO) storing index information of multiple vertex data of the rendering object, and the target index set being composed of multiple index information corresponding to multiple vertex data located in the rendering window; and a rendering unit, configured to perform rendering based on a vertex buffer object (VBO) and the target index set to obtain a first rendering result, wherein the vertex buffer object (VBO) stores multiple vertex data of the rendering object.

[0016] Thirdly, this application provides an electronic device including a processor, a memory, a communication interface, and one or more programs, the one or more programs being stored in the memory and configured to be executed by the processor, the programs including instructions for performing some or all of the steps in the method provided in the first aspect.

[0017] Fourthly, this application provides a computer-readable storage medium that stores a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the methods provided in the first aspect.

[0018] Fifthly, this application provides a computer program product that, when run, causes some or all of the method provided in the first aspect to be implemented.

[0019] It is understood that the beneficial effects of the embodiments of the second to fifth aspects can be referred to the beneficial effects of the method of the first aspect, and will not be repeated here. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 A flowchart illustrating an image rendering method provided in this application; Figure 3 A schematic diagram of a rendering window provided in an embodiment of this application; Figure 4 A schematic diagram illustrating access to a VBO and an EBO provided for an embodiment of this application; Figure 5 A schematic diagram of the initial data flow provided in an embodiment of this application; Figure 6 A flowchart illustrating an image rendering method provided in an embodiment of this application; Figure 7 This is a schematic diagram of an off-screen rendering process provided in an embodiment of this application; Figure 8 A schematic flowchart illustrating another image rendering method provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a vertex storage region provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a vertex storage area after invalid data deletion, provided in an embodiment of this application. Figure 11 This is a schematic diagram of the data flow processing of an image rendering method provided in an embodiment of this application; Figure 12 A schematic diagram of the structure of an image rendering apparatus provided in this application; Figure 13 This is a schematic structural diagram of an electronic device provided in this application.

[0022] Explanation of reference numerals in the attached figures: 10-Application Scenarios; 101 - Rendering device; 102 - Display device; 120 - Image rendering device; 1201 - Determining unit; 1202 - Rendering unit; 130 - Electronic devices; 1301 - Processor; 1302 - Memory; 1303 - Transceiver. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0024] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] The following describes the application scenarios involved in the embodiments of this application.

[0027] Please see Figure 1 , Figure 1 This is a schematic diagram of an application scenario provided in an embodiment of this application, wherein application scenario 10 includes a rendering device 101 and a display device 102.

[0028] The rendering device 101 is an electronic device equipped with a graphics processing unit (GPU) and a central processing unit (CPU), such as a personal computer, workstation, or cloud server.

[0029] The rendering device 101 is used to run printed circuit board (PCB) design software and execute the image rendering method provided in the embodiments of this application. Specifically, the rendering device 101 acquires the PCB data to be rendered (such as Gerber or ODB++ format files), parses the PCB data, stores the parsed vertex data in a vertex buffer object (VBO), and stores the corresponding index information in an element buffer object (EBO).

[0030] Users can use input devices (such as a mouse, keyboard, or touchscreen) to perform interactive operations such as panning, scaling, rotating, or changing the rendering window of the rendered object.

[0031] Translation of a rendering object refers to the user's interactive operation of moving the rendering object horizontally and / or vertically in the scene by dragging it with the mouse or using the keyboard arrow keys; scaling of a rendering object refers to the user's interactive operation of scaling the display size of the rendering object proportionally by scrolling the mouse wheel or clicking the scaling button; rotating a rendering object refers to the user's interactive operation of changing the orientation or angle of the rendering object in the scene by rotating it; changing the rendering window refers to the user's interactive operation of adjusting the size of the rendering window by dragging the border or corner of the rendering window with the mouse, or changing the size of the rendering window by switching to full-screen mode. All of the above interactive operations will cause changes in the size, posture, or position of the rendering object relative to the rendering window, thus affecting the rendering result. The rendering device 101, based on the first transformation matrix corresponding to the interactive operation, uses the compute shader to perform coordinate transformation on the vertex data in the VBO and updates the vertex data, specifically updating the coordinate information of the vertex data. It further filters out the visible vertices located within the rendering window and determines the target index set corresponding to these visible vertices from the EBO. Subsequently, the rendering device 101 renders only the vertex data indicated by this target index set to obtain the first rendering result.

[0032] Display device 102 is an output device with display function, such as a liquid crystal display, an organic light-emitting diode display, or a projector.

[0033] Display device 102 is used to receive the first rendering result generated by rendering device 101 and present the first rendering result to the user on the screen.

[0034] In PCB design scenarios, the display device 102 can display the rendered image of the PCB layout in real time, including the overlay display of multiple layers such as routing layer, silkscreen layer, and solder mask layer, as well as interactive feedback information such as highlighting and net name labeling, enabling users to clearly and smoothly perform circuit board layout, routing inspection and design rule verification.

[0035] The application scenario 10 provided in this application embodiment can be widely used in the field of electronic design automation, such as large-scale PCB design verification systems, automatic optical inspection defect detection systems, and surface mount technology production guidance systems.

[0036] In these systems, the rendering device 101 utilizes the rendering method of this application to significantly reduce the synchronization overhead between the CPU and GPU under large data volumes, reduce the number of rendering instruction calls, thereby achieving a smooth interactive experience with high frame rate and low latency on the display device 102, and effectively alleviating stuttering in operations such as scaling and highlighting.

[0037] The prior art involved in the embodiments of this application is described below.

[0038] In printed circuit board (PCB) design software, the CPU acquires the complete PCB model data to be rendered, then the GPU renders all the vertex data of the model, generating an intermediate rendering result of the complete scene. This intermediate rendering result contains all primitive information of the model across its entire coordinate range. Subsequently, based on the position and size of the current rendering window (i.e., the display area determined by the user through interactive operations such as panning and zooming), the CPU or GPU performs a cropping operation on the intermediate rendering result, capturing the portion of the image within the rendering window, and outputting the cropped image as the final rendering result to the display device.

[0039] While the implementation logic of this solution is simple, it suffers from several drawbacks. After each interactive operation (such as zooming or panning), the system must re-render all vertex data of the model. Since only a small portion of the entire PCB layout is often displayed in the window, a significant amount of rendering computation is wasted on invisible primitives outside the window. The rendering results of these invisible primitives are discarded during subsequent clipping, resulting in a substantial waste of GPU computing power and memory bandwidth, leading to low rendering efficiency. As the PCB design size and the number of primitives increase, the rendering time of this solution increases dramatically, making it difficult to support a smooth, real-time interactive experience.

[0040] Based on this, this application provides an image rendering method. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This application provides a flowchart illustrating an image rendering method, which can be based on... Figure 1 Application scenario 10 shown is implemented as follows: Figure 2 As shown, steps S201-S202 are included: S201: Based on the user's interactive operations and the rendering window, determine the target index set from multiple index information in the index buffer object EBO of the rendering object. The interactive operations include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window. The rendering window is the area used to display the rendering results. The rendering object is the model to be rendered. The index buffer object EBO stores the index information of multiple vertex data of the rendering object. The target index set consists of multiple index information corresponding to multiple vertex data located in the rendering window.

[0041] Specifically, the interactive operations here include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window. For detailed explanations of the above interactive operations, please refer to the relevant content above, which will not be repeated here.

[0042] The rendering window is the area used to display the rendering results, specifically the rectangular viewport on the screen used to present the PCB layout. In this application, only the elements within the rendering window (such as traces, pads, vias, silkscreen characters, etc.) need to be rendered; elements outside the rendering window do not require rendering, thus reducing the amount of data rendered. Optionally, the graphical user interface of the rendering software includes a function area for displaying menus and functions, and a rendering window for displaying visible objects. The rendering window can be located above the function area. Triggering full-screen or non-full-screen operations on the rendering software may affect the display boundaries of the function area and the rendering window. Actively adjusting the boundaries of the rendering software using the mouse can also change the boundaries of the rendering window.

[0043] To facilitate understanding of the technical solution of this application, some of the terms involved in this application will be explained below.

[0044] Vertex data refers to the geometric information of each primitive (such as traces, pads, vias, etc.) that constitutes the rendering object. Each vertex data includes at least the three-dimensional spatial coordinates of the vertex, and optionally includes attribute information such as color value, texture coordinates, transparency, and normal direction.

[0045] A Vertex Buffer Object (VBO) is a buffer storage area located in the GPU's video memory used to store the vertex data of a rendered object. Data in a VBO can be directly read and modified by the GPU without requiring data transfer between the CPU and GPU.

[0046] An Index Buffer Object (EBO) is another buffer storage area located in GPU memory, used to store index information. The index information is a unique identifier pointing to the storage location of the corresponding vertex data within the VBO; each identifier uniquely corresponds to a vertex data point in the VBO. Using the index information stored in the EBO, the GPU can combine vertex data from the VBO in a specified order to construct complete primitives (such as triangles, line segments, etc.).

[0047] For example, the Vertex Buffer Object (VBO) stores vertex data P0, P1, P2, P3, P4, and P5 in the storage order, with corresponding vertex indices of 0, 1, 2, 3, 4, and 5, respectively. The Index Buffer Object (EBO) stores the index values ​​of these vertices. For example, an index might be recorded as: 0, 1, 2, 0, 2, 3, 0, 4, 5, where each index value corresponds to one vertex data. When the GPU executes a drawing command, it looks up the corresponding vertex data in the VBO based on the index values ​​in the EBO, and combines the vertices in the order specified by the index to construct and draw the corresponding complete primitive. For example, if every three vertices constitute the three vertices of a primitive, then 0, 1, and 2 in the Vertex Buffer Object correspond to one primitive, 0, 2, and 3 in the Vertex Buffer Object correspond to one primitive, and 0, 4, and 5 in the Vertex Buffer Object correspond to one primitive.

[0048] Please see Figure 3 , Figure 3 This is a schematic diagram of a rendering window provided in an embodiment of this application. The rendering window is an area used to display the rendering results, that is, a rectangular viewport on the display screen used to present the PCB layout. In this application, only the graphic elements included inside the rendering window, such as traces, pads, vias, silkscreen characters, etc., need to be rendered. It is not necessary to render the graphic elements outside the rendering window, thus reducing the amount of data to be rendered.

[0049] The Index Buffer Object (EBO) stores index information of multiple vertex data of the rendered object. The EBO is a buffer object located in the GPU memory of the graphics processor. It records the index information required to constitute each primitive in advance in the form of a key-value pair mapping set. The index information is the number value pointing to the storage location of the corresponding vertex data in the Vertex Buffer Object (VBO).

[0050] Determining the target index set from multiple index information in the Index Buffer Object (EBO) of the rendering object specifically includes: determining the boundary range of the current rendering window in the scene coordinate system based on interactive operations; then traversing the vertex indices corresponding to each primitive stored in the EBO; determining whether each primitive intersects with the boundary of the rendering window or is contained within the window; and collecting the vertex indices corresponding to all primitives that meet the conditions into the target index set.

[0051] Optionally, based on the user's interactive operation and the rendering window, the target index set is determined from multiple index information in the index buffer object (EBO) of the rendering object, including: determining the first transformation matrix corresponding to the interactive operation based on the interactive operation; using a compute shader to transform multiple vertex data in the vertex buffer object (VBO) based on the first transformation matrix to update the multiple vertex data in the vertex buffer object; determining multiple vertex data that are still located in the rendering window after transformation based on the updated multiple vertex data and the rendering window; and determining the target index set in the index buffer object (EBO) based on the multiple vertex data located in the rendering window.

[0052] Specifically, the first transformation matrix is ​​a model-view projection matrix calculated based on the type and magnitude of the user's interactive operations on the rendering window (such as the translation component of translating the rendered object, the scaling component of scaling the rendered object, and the rotation component of rotating the rendered object). This matrix is ​​used to transform vertex data from model space coordinates to clip space coordinates. In clip space, the boundary range of vertex coordinates corresponds to the boundary of the rendering window; therefore, by comparing whether the vertex coordinates fall within this range, it can be quickly determined whether a vertex is within the rendering window.

[0053] For example, the first transformation matrix includes one or more of translation, scaling, or rotation components. When a user performs a translation operation on the rendered object, the corresponding translation component in the first transformation matrix is ​​updated according to the translation distance and direction; when the user performs a scaling operation on the rendered object, the scaling component in the first transformation matrix is ​​adjusted proportionally according to the scaling factor. After the first transformation matrix is ​​calculated, it is transmitted to the GPU side for use by the compute shader.

[0054] The rendering device 101 uses a compute shader to transform multiple vertex data in a vertex buffer object (VBO) based on a first transformation matrix to update the multiple vertex data in the VBO. The compute shader is a programmable shader that runs on the GPU and has large-scale parallel computing capabilities.

[0055] In its implementation, the computation shader reads the vertex data stored in the VBO, performs a calculation on the position coordinates of each vertex with the first transformation matrix, and obtains the new coordinates of that vertex in space. It should be noted that vertex data typically includes multiple attributes, such as the vertex's 3D coordinates, color value, and texture. The first transformation matrix operates on the vertex coordinates; that is, the computation shader performs matrix multiplication on the coordinate components of each vertex according to the first transformation matrix to obtain the updated coordinate values, and writes the updated coordinates back to the corresponding vertex storage location in the VBO. Through this parallel computation process, the computation shader can process all vertices in the VBO at once, achieving coordinate updates for all vertex data.

[0056] Based on the updated vertex data and the rendering window, the vertex data that remains within the rendering window after transformation is determined. After the vertex data coordinates are updated, the rendering device 101 performs a viewport clipping test on the updated vertex data in the VBO according to the boundary range of the rendering window. This test determines whether the updated coordinates of each vertex are within the clipping space boundary range corresponding to the rendering window. For example, it checks whether the x, y, and z components of the vertex coordinates are all within the [-1, 1] interval of the normalized device coordinates. Through this test, all visible vertices that remain within the rendering window after transformation can be identified. Further user interaction operations include scaling, panning, and dragging operations on the rendering window boundary. Before determining the vertex data that remains within the rendering window after transformation based on the updated vertex data and the rendering window, the rendering window also needs to be updated based on the interaction operations.

[0057] After identifying all visible vertices within the rendering window, the rendering device 101 iterates through the index information of each primitive stored in the EBO (Executable Object Box) based on the vertex numbers corresponding to these visible vertices. It then filters out the index information corresponding to primitives whose vertices are all located in the visible vertex list and merges these index information into a target index set. Each index in the target index set points to a visible vertex in the VBO, and these indexes are organized into a complete primitive form for direct use by subsequent rendering pipelines. Furthermore, the target index set can further remove primitive indexes that are completely occluded by other primitives to further reduce the amount of rendering data.

[0058] As can be seen, in this embodiment of the application, vertex data located within the rendering window is pre-filtered in the computation shader based on the first transformation matrix corresponding to the interactive operation, and a target index set is determined from the EBO based on the index information of the vertex data still located within the rendering window. Since the target index set does not include the index information of vertex data outside the rendering window, vertex data that is completely invisible in the rendering window can be eliminated when rendering based on the vertex buffer object and the target index set, reducing the amount of data submitted to the subsequent rendering pipeline, thus reducing the amount of GPU vertex processing and improving rendering efficiency.

[0059] Optionally, before the step of determining the target index set from multiple index information in the index buffer object EBO of the rendering object based on the user's interactive operation and the rendering window, the method further includes: obtaining and parsing the rendering object to obtain multiple initial vertex data corresponding to the rendering object, and multiple initial index information corresponding to the multiple initial vertex data, wherein the multiple initial vertex data is part or all of the multiple vertex data; writing the multiple initial vertex data into the vertex buffer object VBO, and writing the multiple initial index information into the index buffer object EBO, wherein the multiple initial index information and the multiple index information have at least partially the same index information.

[0060] Specifically, before determining the target index set based on user interaction and the rendering window, it is necessary to first acquire and preprocess the rendering object data.

[0061] Rendering device 101 acquires the rendering object to be rendered. This rendering object can be a printed circuit board design model containing multiple primitives (such as traces, pads, vias, silkscreen characters), and its data format can be Gerber file, ODB++ file, or other EDA industry standard format. The acquisition method can be reading from local storage or downloading from a network server or cloud storage. After acquiring the original data file of the rendering object, rendering device 101 parses the file. The parsing process includes identifying the types of various primitives in the file (such as line segments, arcs, polygons, rectangles, circular pads, etc.), extracting the geometric description parameters of each primitive (such as endpoint coordinates, center coordinates, radius, width, corner point sequence, etc.), and calculating the vertex position coordinates, color, transparency, fill, etc. of each primitive in the model space based on these geometric parameters, thereby obtaining multiple initial vertex data corresponding to the rendering object; that is, each vertex data includes information such as the vertex's position, color, transparency, and fill.

[0062] Simultaneously, during the parsing process, the rendering device 101 also constructs multiple initial index information corresponding to the initial vertex data based on the geometric topological relationships of each primitive. The initial index information records the vertex indices required to constitute each primitive in the form of a key-value pair mapping set. For example, for a rectangular trace segment in a PCB layout, it can be divided into two triangles, and it can be recorded that triangle 1 is composed of vertices V0, V1, and V2, and triangle 2 is composed of vertices V0, V2, and V3. The multiple initial vertex data are part or all of the multiple vertex data stored in the VBO in subsequent steps. That is, in some cases, the initial vertex data can be directly used as all vertex data; in other cases, the initial vertex data can be further refined or supplemented in subsequent processing, thereby generating more vertex data and index information.

[0063] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the access of VBO and EBO according to an embodiment of this application. The CPU of the rendering device 101 allocates storage areas for VBO and EBO in the GPU memory by calling the graphics library interface. After allocation, the CPU of the rendering device 101 writes the parsed initial vertex data into the storage area corresponding to the VBO in the GPU memory; simultaneously, the CPU of the rendering device 101 writes the parsed initial index information into the storage area corresponding to the EBO in the GPU memory.

[0064] After writing is complete, the VBO stores the geometric data of the rendered object (such as vertex position coordinates, texture coordinates, normal directions, etc.), while the EBO stores the topological structure data of the rendered object (i.e., the connection relationships between vertices). By storing the VBO and EBO separately, subsequent rendering processes and compute shaders can directly read data from GPU memory without repeatedly transferring it from CPU memory.

[0065] Furthermore, it should be noted that the initial index information and the index information used in subsequent steps share at least some of the same index information. This is because the initial index information is the basic topology directly constructed from the parsed initial vertex data. In subsequent processes of this application, the primitives may undergo further subdivision processing (e.g., refining large polygons into more small triangles) or other processing methods. This processing adds additional vertices and corresponding index information to the original index, but the index information corresponding to the original primitives is still retained and remains valid. Therefore, the index information of the same primitives is the same between the multiple initial index information and the multiple index information ultimately used for rendering.

[0066] As can be seen, by writing the parsed initial vertex data into the VBO and the initial index information into the EBO, the vertex data and index information of the rendering object are stored separately in the GPU-dedicated buffer object. When multiple primitives share a vertex in the rendering object, vertex data can be reused through index, without having to repeatedly store the vertex data corresponding to the vertex shared by multiple primitives. At the same time, it provides direct data structure support for subsequent index-based rendering.

[0067] Optionally, after writing multiple initial vertex data into a vertex buffer object (VBO) and multiple initial index information into an index buffer object (EBO), the method further includes: using a computation shader to perform an initial subdivision of the primitives corresponding to the multiple initial vertex data to obtain multiple vertex data and the index information corresponding to the multiple vertex data.

[0068] Specifically, after writing the initial vertex data into the VBO and the initial index information into the EBO, the rendering device 101 calls the compute shader to perform the initial subdivision operation on the primitives corresponding to the multiple initial vertex data.

[0069] The computation shader is a programmable parallel computing unit running on the GPU. During the partitioning process, the CPU of the rendering device 101 first determines the number of sub-primitives to be partitioned into for each initial primitive, the position coordinates of the new vertex, and the connection relationship between the new vertex and the original vertex, based on the type of each primitive obtained by parsing (such as line segment, rectangle, polygon, circular pad, etc.) and the preset partitioning strategy (such as partitioning accuracy, maximum triangle size, etc.).

[0070] Please see Figure 5 , Figure 5 This is a schematic diagram of the initial partitioning data flow provided in an embodiment of this application. The CPU writes these partitioning mapping relationships (including the correspondence between initial vertices and newly added vertices, the storage location of newly added vertices in the VBO, the order of the newly added indices, etc.) into a Shader Storage Buffer Object (SSBO). The SSBO is a read-write buffer object in the GPU memory, and its contents can be read by the compute shader during runtime.

[0071] Subsequently, the CPU of rendering device 101 sends a scheduling instruction to the GPU, triggering the execution of the compute shader. The compute shader reads the partitioning mapping relationship pre-written by the CPU from the SSBO, and then reads the initial vertex data from the VBO and the initial index information from the EBO to perform the actual partitioning calculation.

[0072] For each initial primitive, the compute shader generates multiple new vertex data based on the mapping relationship, writes these new vertex data to the specified storage location in the VBO (e.g., appends to the original vertices or overwrites the reserved space), and at the same time generates corresponding new index information based on the mapping relationship, updating the index information in the EBO.

[0073] After partitioning, the VBO stores the refined vertex data, and the EBO stores the corresponding refined index information, which are used for subsequent viewport clipping and rendering steps. It should be noted that during the partitioning process, the CPU and GPU only exchange partitioning mapping relationships once via SSBO before initiating scheduling. The actual calculation of partitioning and the writing of new data are all completed within the GPU's video memory.

[0074] As can be seen, although calling the compute shader still requires the use of the CPU, the initial partitioning of primitives is performed by the compute shader on the GPU side. Therefore, the data synchronized between the CPU and the GPU is the data before partitioning, resulting in high communication efficiency. In addition, the partitioning process performed by the compute shader frees the CPU from the task of partitioning primitives, releasing the CPU's computing resources. Since the GPU's computing resources are relatively redundant, transferring the task of primitive partitioning from the CPU to the GPU can also improve the overall efficiency of primitive partitioning.

[0075] Optionally, before the step of performing initial subdivision of primitives corresponding to multiple initial vertex data using a compute shader, the method further includes: obtaining a first edit operation by the user on a first target primitive in the rendering object, wherein the first edit operation is used to modify the geometric properties of the first target primitive, the geometric properties including shape and / or size; according to the first edit operation, using a compute shader to write a first mapping relationship between the modified vertex data and the corresponding index information corresponding to the first target primitive to a shader buffer object SSBO, wherein the position information of the modified vertex data corresponding to the first target primitive is different from the vertex data of the first target primitive in a vertex buffer object VBO; using a compute shader based on the first mapping relationship, replacing the vertex data corresponding to the first target primitive in the vertex buffer object VBO with the modified vertex data, and updating the index information in an index buffer object EBO.

[0076] Specifically, before performing the initial subdivision of the primitives corresponding to the initial vertex data using the computational shader, the rendering device 101 first acquires the first editing operation performed by the user on the first target primitive in the rendering object. The first editing operation is used to modify the geometric properties of the first target primitive, including shape and / or size. For example, the user can drag the edge of a pad with the mouse to change it from a rectangle to a circle, or change the width and length of a trace segment by inputting parameters, or change the overall size of the polygon primitive by scaling.

[0077] The first target element can be any element in the PCB layout, such as traces, pads, vias, polygonal copper areas, or silkscreen characters. The rendering device 101 captures the first editing operation through a user interface (such as a toolbar, property panel, or direct drag-and-drop interaction in a graphical user interface) and determines the identifier of the first target element and the specific parameters of the editing operation.

[0078] According to the first editing operation, the rendering device 101 uses the compute shader to write a first mapping relationship between the modified vertex data and the corresponding index information of the first target primitive to the SSBO. The first mapping relationship is a set of key-value pairs written to the SSBO in response to the first editing operation (such as modifying the shape and size of the primitive), which describes the correspondence between the modified vertex data and the original vertex position of the vertex in the VBO.

[0079] The computation shader calculates the new vertex coordinates corresponding to the modified geometry of the first target primitive based on the type and parameters of the first editing operation. If the user changes a rectangular pad to a circular pad, the computation shader calculates the coordinates of a series of sampling points on the circular boundary as the modified vertex data based on the circular equation and the center position and radius parameters of the pad. If the user changes the trace width from 0.2mm to 0.3mm, the computation shader recalculates the vertex coordinates of both sides of the trace boundary based on the new width value.

[0080] After calculating the modified vertex data, the compute shader constructs a first mapping relationship and writes it into the SSBO. This first mapping relationship is stored in the form of a set of key-value pairs, which describes the correspondence between each modified vertex data and the original vertex storage position in the VBO before the modification. That is, the key represents the modified vertex data and the value represents the storage position index information that the vertex should be written to in the VBO, or the key represents the original vertex storage position in the VBO and the value represents the modified vertex data.

[0081] It should be noted that the location information of the modified vertex data corresponding to the first target primitive (i.e., the storage location of these new vertices in the VBO) differs from the location information of the original vertex data of the first target primitive in the VBO. This is because the number of modified vertices may differ from the original number of vertices, or the modified vertex coordinates may need to overwrite the newly allocated VBO area, rather than simply overwriting the original positions. Attribute modifications specifically include scaling, color modification, and fill pattern modification, but in this step, the first editing operation targets the modification of geometric attributes, i.e., changes in shape and / or size.

[0082] After the first mapping relationship between the modified vertex data and the corresponding index information corresponding to the first target primitive is written into the SSBO, the rendering device 101 sends a scheduling instruction to the GPU, triggering the execution of the compute shader. The compute shader reads the first mapping relationship pre-written by the CPU from the SSBO, and writes the modified vertex data into the corresponding vertex storage area in the VBO according to the storage location indicated in the mapping relationship, replacing the original vertex data of the first target primitive.

[0083] Meanwhile, since the vertex data changes (e.g., the number of vertices increases or decreases, or the vertex arrangement order changes), the computation shader also needs to recalculate the index information corresponding to the first target primitive based on the modified vertex data, and write the updated index information to the corresponding position in the EBO.

[0084] After the replacement and update are completed, the VBO stores the vertex data after the geometric attributes have been modified, and the EBO stores the corresponding updated index information for use in subsequent initial subdivision or other processing steps.

[0085] As can be seen, in related technologies, the modification of geometric attributes and the subdivision of vertex data are both performed on the CPU side, which consumes a large amount of computing power for the CPU. In contrast, in this embodiment, the mapping relationship between the modified vertex data and the corresponding index information is written into the SSBO through the compute shader on the CPU side, and the vertex buffer object and index buffer object are updated based on the SSBO. This process is performed on the GPU side. Since the GPU generally has higher computing power and multi-core concurrency advantages than the CPU, the processing efficiency can be improved.

[0086] Optionally, after the step of performing initial subdivision of primitives corresponding to multiple initial vertex data using a computational shader, the method further includes: obtaining a second editing operation by the user on a second target primitive of the rendering object, wherein the second editing operation is used to modify the target attributes of the second target primitive, the target attributes being attributes other than geometric attributes, and the geometric attributes including shape and / or size; according to the second editing operation, using the computational shader to write a second mapping relationship between the modified vertex data and the corresponding index information corresponding to the second target primitive to a shader buffer object SSBO, wherein the target attributes of the modified vertex data corresponding to the second target primitive are different from the vertex data of the second target primitive in a vertex buffer object VBO; using the computational shader based on the second mapping relationship, replacing the vertex data corresponding to the second target primitive in the vertex buffer object VBO with the modified vertex data, and updating the index information in an index buffer object EBO.

[0087] Specifically, after the primitives corresponding to the initial vertex data are initially partitioned using a computational shader, the rendering device 101 obtains the second editing operation performed by the user on the second target primitive in the rendering object.

[0088] The second editing operation is used to modify the target attributes of the second target primitive. These target attributes are attributes other than geometric attributes, which include shape and / or size. Target attributes include modifying the graphic scale, fill color, fill pattern, etc.

[0089] For example, users can modify the fill color of trace segments (e.g., from red to blue), modify the fill pattern of polygonal copper areas (e.g., from solid fill to grid fill), or adjust the overall display ratio of pads (e.g., from 100% to 80%) through the properties panel. The second target element can be any element in the PCB layout, and can be the same element or a different element from the first target element. The rendering device 101 captures this second editing operation through the user interface and determines the identifier of the second target element and the specific parameters of the editing operation.

[0090] According to the second editing operation, the rendering device 101 uses the compute shader to write a second mapping relationship between the modified vertex data and the corresponding index information of the second target primitive to the SSBO. The second mapping relationship is a set of key-value pairs written to the SSBO in response to the second editing operation (such as modification of graphics scale, modification of fill color, modification of fill pattern), which describes the correspondence between the modified vertex data and the original vertex position of the vertex in the VBO.

[0091] The CPU of the rendering device 101 calculates the vertex data changes required to modify the target attributes based on the type and parameters of the second editing operation, and organizes these changes into a second mapping relationship.

[0092] The difference between the second mapping and the first mapping is that the write operation of the second mapping is performed by the compute shader, rather than by the CPU directly. The CPU of the rendering device 101 first sends a scheduling instruction to the GPU, triggering the compute shader to run, and the compute shader writes the second mapping into the SSBO.

[0093] The second mapping relationship is stored as a set of key-value pairs, describing the correspondence between the modified vertex data and the original vertex storage locations in the VBO. It should be noted that the target attributes (such as color value, fill type identifier, scale factor, etc.) of the modified vertex data corresponding to the second target primitive are different from the target attributes of the existing vertex data of the second target primitive in the VBO, to reflect the attribute changes caused by user editing operations. For example, if the user changes the fill color from red to blue, the color attribute value in the modified vertex data changes from RGB(255,0,0) to RGB(0,0,255).

[0094] The compute shader, based on the second mapping relationship, replaces the vertex data corresponding to the second target primitive in the VBO with the modified vertex data and updates the index information in the EBO. Specifically, the CPU of the rendering device 101 sends a scheduling instruction to the GPU, triggering the compute shader to execute. The compute shader reads the previously written second mapping relationship from the SSBO, and according to the storage location indicated in the mapping relationship, writes the modified vertex data (containing new target attribute values) into the corresponding vertex storage area in the VBO, replacing the original vertex data of the second target primitive.

[0095] Simultaneously, if modifications to the target attributes result in changes to the number of vertices or alterations to the index order (e.g., changes to the fill pattern leading to a change in the number of vertices), the compute shader also needs to update the index information in the EBO accordingly. After the replacement and update are complete, the VBO stores the vertex data modified by the target attributes, and the EBO stores the corresponding updated index information for use in subsequent rendering steps.

[0096] As can be seen, in related technologies, the modification of vertex data attributes is performed on the CPU side, which consumes a large amount of computing power for the CPU. In contrast, in this embodiment, the mapping relationship between the vertex data with the target attribute modification and the corresponding index information is written into the SSBO through the compute shader on the CPU side, and the vertex buffer object and index buffer object are updated based on the SSBO. This process is performed on the GPU side. Since the GPU generally has higher computing power and multi-core concurrency advantages than the CPU, the processing efficiency can be improved.

[0097] S202: Render based on the vertex buffer object (VBO) and the target index set to obtain the first rendering result, wherein the vertex buffer object (VBO) stores the vertex data of the rendering object.

[0098] A Vertex Buffer Object (VBO) stores the vertex data of a rendering object. This VBO is a buffer object located in GPU memory, storing the geometric attributes of each vertex (such as 3D position coordinates, texture coordinates, and normal direction). During rendering, the GPU's rendering pipeline reads the vertex data from the VBO indicated by the target index set, ignoring vertex data outside the target index set. It then performs vertex shading, rasterization, fragment shading, and other operations on these selected vertices, ultimately generating the rendered image within the current rendering window.

[0099] As can be seen, in related technologies, all vertex data of the rendering object are rendered first to obtain intermediate rendering results, and then the intermediate rendering results are clipped through the rendering window to obtain the final rendering result. In contrast, this application determines the target index set based on the rendering window. In subsequent rendering steps, only the vertex data corresponding to the index information in the target index set needs to be rendered to obtain the first rendering result of the rendering object in the rendering window. This application reduces the number of vertex data to be rendered, that is, reduces the amount of data rendered by the GPU, which can improve rendering efficiency.

[0100] Example 2: Based on the description of the above-described embodiments, this application also provides a more detailed image rendering method with a more detailed rendering process. Please refer to [link to relevant documentation]. Figure 6 , Figure 6 This application provides a flowchart illustrating an image rendering method, including steps S601-S605: S601: Based on the user's interactive operations and the rendering window, determine the target index set from multiple index information in the index buffer object EBO of the rendering object. The interactive operations include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window. The rendering window is the area used to display the rendering results. The rendering object is the model to be rendered. The index buffer object EBO stores the index information of multiple vertex data of the rendering object. The target index set consists of multiple index information corresponding to multiple vertex data located in the rendering window.

[0101] For a detailed explanation of step S601, please refer to the relevant content in Embodiment 1, which will not be repeated here.

[0102] S602: Determine the layout index and the foreground index, wherein the layout index is the set of index information corresponding to the vertex data of the layout, and the foreground index is the set of index information corresponding to the vertex data of the foreground.

[0103] Specifically, the layout index is the index corresponding to the vertex data of the board layout, that is, the index information corresponding to the storage location of the board layout data (such as the vertex data corresponding to the trace layer, pad layer, via layer, etc. of the PCB board) in the VBO; the foreground index is the index corresponding to the vertex data of the foreground, that is, the index information corresponding to the storage location of the foreground data (such as the vertex data corresponding to interactive elements that need to be superimposed on the board layout, such as foreground annotations, netname text, and highlights) in the VBO. This part of the data determines which part of the vertex data is the layout and which part of the vertex data is the foreground by the CPU in the rendering task.

[0104] The CPU divides the vertex data stored in the VBO according to its rendering level based on preset data classification rules, and generates a layout index and a foreground index respectively. The layout index and the foreground index can be in the form of an index range (such as the starting position and length) or an index list, pointing to the storage area of ​​the corresponding vertex data in the VBO.

[0105] For example, a layout index can indicate that vertices 0 to 10000 in a VBO are layout data, and a foreground index can indicate that vertices 10001 to 10200 in a VBO are foreground data. Those skilled in the art will understand that layout data and foreground data can also be interleaved and stored in VBOs, in which case the layout index and foreground index can be independent index lists pointing to various scattered vertices. For example, if the rendering device 101 creates multiple VBOs in the GPU memory and stores the layout data and foreground data in different VBOs, then the layout index is an identifier pointing to the layout VBO, and the foreground index is an identifier pointing to the foreground VBO.

[0106] S603: Obtain the corresponding layout data from the vertex buffer object (VBO) based on the layout index, perform layout rendering, and obtain the layout rendering layer.

[0107] Specifically, after determining the layout index and foreground index, the GPU's rendering pipeline reads layout data (including vertex position coordinates, texture coordinates, color, and other attributes) from the VBO according to the storage location indicated by the layout index. It then performs operations such as vertex shading, rasterization, and fragment shading, drawing the layout onto an off-screen framebuffer object or a viewport framebuffer object to generate the layout rendering layer. The layout rendering layer contains the main graphic information of the PCB board, such as traces, pads, vias, solder mask layers, and silkscreen layers.

[0108] S604: Obtain the corresponding foreground data from the vertex buffer object VBO based on the foreground index, perform foreground rendering, and obtain the foreground rendering layer.

[0109] Specifically, the GPU's rendering pipeline reads foreground data from the VBO based on the storage location indicated by the foreground index, performs rendering operations, and draws the foreground onto the off-screen framebuffer object or the viewport framebuffer object, generating a foreground rendering layer. The foreground rendering layer contains interactive elements that need to be overlaid and displayed on the layout, such as highlighted net traces, component reference labels, net name labels, measurement dimension labels, design rule check marks, etc.

[0110] S605: Obtain the first rendering result based on the map rendering layer and the foreground rendering layer.

[0111] Specifically, the rendering device 101 can overlay and synthesize the layout rendering layer and the foreground rendering layer, that is, to cover the layout rendering layer with the foreground rendering layer to form a final rendered image containing complete information.

[0112] As can be seen, because the layout index and foreground index are determined based on the rendering window, and the layout index and foreground index respectively indicate the storage location of the corresponding layout data and foreground data in the VBO, layout rendering and foreground rendering can be performed separately according to different indices. The rendering work can be separated according to logical levels, and the geometric data that needs to be rendered in the VBO can be quickly located by just the index value. Therefore, it is beneficial for subsequent overlay of special effects, dynamic annotation or interactive highlighting, which enhances the flexibility and real-time response capability of rendering.

[0113] Optionally, the steps of obtaining the corresponding layout data from the vertex buffer object (VBO) according to the layout index for layout rendering to obtain the layout rendering layer and obtaining the corresponding foreground data from the vertex buffer object (VBO) according to the foreground index for foreground rendering to obtain the foreground rendering layer are performed in the off-screen frame buffer object. Based on the layout rendering layer and the foreground rendering layer, the first rendering result is obtained, including: copying the layout rendering layer and the foreground rendering layer from the frame buffer in the off-screen frame buffer object to the viewport frame buffer object to obtain the first rendering result.

[0114] Specifically, when rendering the layout and foreground, the rendering device 101 first renders the layout data and foreground data into an off-screen frame buffer object. The off-screen frame buffer object is an invisible rendering target allocated in the GPU's video memory. Its contents are not directly displayed on the screen, but are used as an intermediate cache for subsequent processing.

[0115] Please see Figure 7 , Figure 7 This is a schematic diagram of an off-screen rendering process provided in an embodiment of this application. The rendering device 101 first creates an off-screen frame buffer object. During the rendering process, the rendering device 101 binds the rendering target to this off-screen frame buffer object, then retrieves the corresponding layout data from the VBO according to the layout index, performs layout rendering, and writes the layout rendering layer into the off-screen frame buffer object. Subsequently, it retrieves the corresponding foreground data from the VBO according to the foreground index, performs foreground rendering, and writes the foreground rendering layer into the off-screen frame buffer object. After the off-screen rendering is completed, the off-screen frame buffer object stores the complete composited first rendering result (including the layout rendering layer and the foreground rendering layer).

[0116] After completing off-screen rendering, the rendering device 101 copies the layout rendering layer and the foreground rendering layer (in practical applications, the rendering can be further subdivided into more layers, such as background rendering layer, highlight rendering layer, and network name rendering layer) from the off-screen framebuffer object to the viewport framebuffer object to obtain the first rendering result. The viewport framebuffer object is the default framebuffer provided by the window system, and its contents directly correspond to the rendering window area on the display screen.

[0117] The rendering device 101 efficiently copies pixel data from a specified region (i.e., the pixel region corresponding to the rendering window) in the off-screen framebuffer object to the corresponding position in the viewport framebuffer object, thereby presenting the first rendering result after off-screen rendering on the screen. The framebuffer copying process is performed by the GPU without the involvement of the CPU, reducing the data transfer overhead between the CPU and GPU. During framebuffer copying, the rendering device 101 can copy only the pixel region corresponding to the rendering window in the off-screen framebuffer object, based on the size and position of the rendering window, further reducing the amount of data copied.

[0118] As can be seen, in related technologies, if rendering is performed directly on the viewport framebuffer object, the GPU's rendering operation must be synchronized with the screen refresh rate. Before the vertical synchronization signal arrives, even if the GPU has completed rendering, it can only wait and cannot process the rendering task of the next frame in advance, resulting in the GPU being idle during the waiting period and having low utilization. However, this application decouples the rendering operation from the screen refresh process by pre-completing the rendering in the off-screen framebuffer object. The GPU can process the off-screen rendering task of subsequent frames in advance during the gap of waiting for the screen refresh. The framebuffer copy operation itself is efficiently executed by the GPU's dedicated copy engine in the video memory, which hardly occupies the GPU's rendering computing resources. This allows the GPU's rendering computing unit to continuously process rendering tasks without frequently waiting for the screen refresh, thus significantly improving GPU utilization and rendering efficiency.

[0119] Example 3: Based on the description of the above embodiments, this application also provides a more detailed image rendering method that takes into account video memory management. In this application embodiment, the video memory of the graphics processor includes at least three vertex buffer objects (VBOs), and the number of vertex buffer objects (VBOs) is less than 10. One or more of the at least three vertex buffer objects (VBOs) are used to store vertex data, one of the multiple vertex buffer objects is used to store a second transformation matrix, and one of the multiple vertex buffer objects (VBOs) is used to store rendering instructions. The second transformation matrix is ​​used to convert the local coordinates of the vertex data into world coordinates during the rendering process.

[0120] Specifically, the graphics processing unit (GPU) of the rendering device 101 allocates and maintains at least three vertex buffer objects (VBOs) in video memory, and the total number of VBOs is less than 10.

[0121] These VBOs each have different storage responsibilities, covering all data storage needs for rendering with a streamlined buffer object structure. At least three VBOs are used to store the following: One or more VBOs are used to store vertex data (e.g., vertex data of borderless line (i.e., dashed line type primitives), vertex data of sector and triangle type primitives, vertex data of border type primitives, and vertex data of line fill type primitives). A VBO is used to store a second transformation matrix, which is used to convert the local coordinates of vertex data into world coordinates during the rendering process, so that all models can participate in subsequent rendering calculations in a unified world coordinate system. The local coordinates correspond to the position coordinates of the vertex relative to the origin of its own model (e.g., the design origin of the PCB board), while the world coordinates correspond to the absolute position coordinates of the vertex in the entire 3D scene.

[0122] A VBO is used to store rendering instructions, which instruct the GPU what drawing operation to perform (such as drawing triangles, lines, point sets, etc.) and the parameter configuration used during drawing.

[0123] For example, if the rendering device 101 is configured with 6 VBOs, they are used to store: vertex data of borderless lines (dashed lines), vertex data of sectors and triangles, vertex data of borders, vertex data of line fills, a second transformation matrix, and rendering instructions, respectively. Each VBO is independent of the others, and the GPU reads the corresponding type of data from the corresponding VBO according to the needs of the current rendering task during rendering. It should be noted that the number of VBOs is limited to less than 10, and a minimum of 3 is sufficient to cover basic rendering requirements.

[0124] As can be seen, because it only requires configuring the VBO corresponding to the vertex data, the VBO corresponding to the second transformation matrix, and the VBO corresponding to the instruction, the number of VBOs is reduced compared to related technologies, simplifying the storage structure of the second geometry data. The GPU does not need to search for the corresponding vertex data from a large number of VBOs during the rendering process, and can quickly locate the required vertex data, thus improving rendering efficiency.

[0125] Please see Figure 8 , Figure 8 A flowchart illustrating another image rendering method provided in this application embodiment includes steps S801-S806: S801: Based on the user's interactive operations and the rendering window, determine the target index set from multiple index information in the index buffer object EBO of the rendering object. The interactive operations include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window. The rendering window is the area used to display the rendering results. The rendering object is the model to be rendered. The index buffer object EBO stores the index information of multiple vertex data of the rendering object. The target index set consists of multiple index information corresponding to multiple vertex data located in the rendering window.

[0126] S802: Render based on the vertex buffer object (VBO) and the target index set to obtain the first rendering result, wherein the vertex buffer object (VBO) stores the vertex data of the rendering object.

[0127] For a detailed explanation of steps S801 and S802, please refer to the relevant content in Embodiment 1 and Embodiment 2 of the above application, which will not be repeated here.

[0128] S803: Get the first video memory occupied by the vertex data that is in a valid state in the vertex buffer object (VBO).

[0129] Specifically, the rendering device 101 monitors video memory usage after the rendering process to dynamically adjust the storage capacity of the VBO.

[0130] Rendering device 101 first acquires the first video memory occupied by the vertex data in the VBO that is in a valid state. Valid vertex data refers to vertex data in the render object that has not been deleted or hidden; it is vertex data that may be reused in the next rendering process, such as vertex data used in the current rendering frame that may continue to appear in the rendering window in the next interactive operation (such as panning or zooming). Conversely, invalid vertex data refers to vertex data in the render object that has been deleted or hidden. The first video memory refers to the total video memory space occupied by all valid vertex data in the VBO.

[0131] S804: Get the second video memory currently occupied by the program used to render the rendered object on the graphics processor GPU.

[0132] Specifically, the rendering device 101 simultaneously obtains the second video memory currently occupied by the program used to render the rendered object. The second video memory refers to the total amount of video memory currently accessed by the PCB design software program running on the rendering device 101, including the video memory space occupied by all GPU buffer objects such as VBO, SSBO, EBO, and VAO. The second video memory reflects the overall memory usage of the program on the GPU and is an important reference for determining whether an expansion operation can be performed.

[0133] S805: Determine the percentage of video memory used based on the ratio of the first video memory to the second video memory.

[0134] Specifically, the rendering device 101 determines the percentage of used video memory based on the ratio of the first video memory to the second video memory. For example, the percentage of used video memory = (first video memory / second video memory) × 100%. This percentage reflects the proportion of effective vertex data occupying the GPU video memory currently used by the program. A high percentage indicates that the VBO (Video Box Optimizer) is densely populated with effective data and has limited remaining available space.

[0135] S806: If the percentage of video memory already used is greater than or equal to the first preset threshold, and the ratio of the second video memory to the total video memory of the graphics processor (GPU) is less than or equal to the second preset threshold, then the vertex buffer object (VBO) is expanded.

[0136] Specifically, if the percentage of video memory already used is greater than or equal to the first preset threshold, and the ratio of the second video memory to the total video memory of the GPU is less than or equal to the second preset threshold, then the rendering device 101 will expand the VBO.

[0137] The first preset threshold is used to determine whether the effective data in the VBO is close to the upper limit of the current VBO capacity, for example, it is set to 80% or 90%; the second preset threshold is used to determine whether the overall video memory usage of the current program has not yet reached the bottleneck of the total video memory of the GPU, for example, it is set to 70% or 80%.

[0138] When both of the above conditions are met simultaneously, it indicates that the current capacity of the VBO is insufficient to efficiently accommodate valid vertex data (it is about to face space shortage), and the GPU still has sufficient remaining video memory available for allocation (video memory overflow will not occur due to expansion). In this case, the rendering device 101 performs an expansion operation on the VBO, for example, by calling the graphics library interface to reallocate a larger video memory space and migrate the original valid data to the newly allocated space. The timing of the expansion operation is dynamically determined by the rendering device 101 based on the above conditions, without user intervention.

[0139] As can be seen, by obtaining the first video memory occupied by the effective data in the VBO and the second video memory currently being called by the GPU, the percentage of video memory used can be calculated. This allows the system to determine when there is still video memory available but the percentage of effective data in the VBO is close to a preset threshold. This expands the storage capacity of the VBO, solving the problem of excessive GPU video memory usage and the frequent discarding of effective data or video memory overflow errors due to insufficient VBO space. It also dynamically balances video memory utilization and rendering stability, thereby improving the rendering stability in long-running or complex model editing scenarios.

[0140] Optionally, the Vertex Buffer Object (VBO) includes multiple vertex storage areas for storing vertex data. After the step of rendering based on the Vertex Buffer Object (VBO) and the target index set to obtain a first rendering result, the method further includes: changing the data state of the vertex data in the Vertex Buffer Object (VBO) from a valid state to an invalid state in response to a triggering condition, wherein the triggering condition includes the deletion or hiding of the primitives corresponding to the vertex data; and deleting the vertex data in the invalid storage areas when the number of invalid storage areas exceeds a threshold, wherein an invalid storage area is a vertex storage area that stores vertex data in an invalid state and does not store vertex data in a valid state.

[0141] Specifically, the VBO allocated in the GPU memory by the rendering device 101 is divided into multiple vertex storage areas, each of which stores one or more vertex data. To facilitate efficient state management of the vertex data stored in the vertex buffer object (VBO), this embodiment of the application sets a state flag field in the data structure of the vertex data.

[0142] For example, in the initial state, such as when vertex data is first written to the VBO, the state flag field is initialized to a valid state (e.g., ValidFlag = true or ValidFlag = 1), indicating that the data is available for normal reading and use by subsequent rendering pipelines.

[0143] When a vertex data meets the triggering condition (for example, the primitive corresponding to the vertex data is deleted or hidden), the rendering device 101 modifies the status flag field of the vertex data from a valid state to an invalid state (for example, ValidFlag = false or ValidFlag = 0), thereby marking the data as invalid. When new vertex data needs to be written to the VBO, the invalid vertex data can be directly overwritten without physically erasing or removing the vertex data from the buffer object.

[0144] It should be noted that you should refer to [link / reference]. Figure 9 , Figure 9 This is a schematic diagram of a vertex storage region provided in an embodiment of this application. Each rectangle represents a vertex storage region. The number "1" in the rectangle indicates that the corresponding vertex storage region stores vertex data with a valid state, and the number "0" in the rectangle indicates that the corresponding vertex storage region stores vertex data without a valid state.

[0145] When new vertex data needs to be written to the VBO, the rendering device 101 will determine the data storage space size based on the new vertex data. Figure 9 The diagram shows the determination of a contiguous space sufficient to accommodate new vertex data. Specifically, this contiguous space can be a contiguous storage space in the VBO that does not store vertex data; or a contiguous storage space in the VBO that stores vertex data in an invalid state, and the size of this contiguous storage space is sufficient to accommodate new vertex data.

[0146] When the rendering device 101 determines that the new vertex data will be stored in an invalid storage area that is large enough to accommodate the new vertex data, the rendering device 101 will overwrite the old vertex data in the invalid storage area with the new vertex data to complete the storage of the new vertex data.

[0147] Because invalid and valid storage areas are interleaved, a large amount of data will be identified as invalid data during the operation of the rendering device 101. At this time, the available space in the VBO is divided into many discontinuous small blocks, which means that even if the total size of new vertex data does not exceed the total amount of remaining space (including unused vertex storage areas and invalid storage areas), the allocation may fail because a contiguous vertex storage area cannot be found.

[0148] Therefore, when the number of invalid storage regions exceeds a threshold, it will lead to fragmentation of the storage space in the VBO. Even if the total space occupied by the invalid storage regions is large, it will not be able to meet the space requirements of new vertex data. Therefore, when the number of invalid storage regions exceeds the threshold, the rendering device 101 will execute a vertex data deletion procedure in the invalid storage regions. The threshold can be a preset fixed value (e.g., 100 storage regions) or a value calculated proportionally based on the total number of storage regions in the VBO (e.g., 10% of the total number of storage regions). The rendering device 101 counts the number of invalid storage regions in real time. When the number exceeds the preset threshold, it triggers a deletion operation, erasing the vertex data in the invalid storage regions from the VBO, releasing the video memory space they occupy into contiguous usable space for subsequent writing of new vertex data.

[0149] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a vertex storage area after invalid data deletion, provided in an embodiment of this application. Figure 10 The vertex storage area shown is for Figure 9 The vertex storage area shown is obtained after deleting invalid data. The rectangles without numbers indicate that the corresponding vertex storage area does not store vertex data.

[0150] It can be seen that by actively cleaning up invalid storage areas that are interspersed with effective vertex storage areas, fragmented video memory space can be reclaimed, and discontinuous available vertex storage areas can be merged into larger contiguous spaces. This can solve the problem of new large blocks of vertex data being unable to be allocated due to the accumulation of video memory fragments, improve the efficiency of VBO internal space reuse and allocation success rate, thereby improving the stability and rendering performance in long-running or multi-round editing and rendering scenarios.

[0151] Optionally, the vertex buffer object (VBO) includes multiple vertex storage areas for storing vertex data. Before the step of expanding the size of the vertex buffer object (VBO), the method further includes deleting vertex data in invalid storage areas.

[0152] Specifically, the VBO allocated in the GPU memory by the rendering device 101 is divided into multiple vertex storage areas, each of which is used to store one or more vertex data. An invalid storage area refers to a vertex storage area that stores vertex data in an invalid state but does not store vertex data in a valid state. The invalid vertex data refers to vertex data that has been used after rendering and will not be used again.

[0153] This embodiment combines memory reclamation and expansion processing. Before the rendering device 101 determines that VBO expansion is necessary, an invalid data cleanup operation is performed first. This involves deleting vertex data from all invalid storage areas in the VBO, releasing the video memory space occupied by these vertex storage areas, and making them usable. By prioritizing the cleanup operation before the expansion operation, the video memory space occupied by invalid data is reclaimed to further meet the new vertex data storage requirements. This reduces the frequency of costly expansion operations, lowers the overall overhead of video memory management, and improves the system's operating efficiency and stability. If the video memory space released after cleanup is still insufficient to meet the requirements, subsequent expansion processing steps are then executed.

[0154] As can be seen, by actively cleaning up vertex data in invalid storage areas before the expansion operation, the system can try to free up video memory space by reclaiming invalid data before performing the expensive expansion operation. If the space released after GC is sufficient to meet the needs, unnecessary expansion operations can be reduced, thereby reducing the number of video memory reallocations and overhead, reducing performance fluctuations caused by frequent expansion, and further improving the system's operating efficiency and stability.

[0155] Based on the description in the above application embodiments, please refer to the following example: Figure 11 , Figure 11 This is a schematic diagram of the data flow processing of an image rendering method provided in an embodiment of this application, as shown below. Figure 11 As shown, the image rendering method runs in software on the rendering device 101.

[0156] The parsing module of the rendering device 101 first obtains the original data of the rendering object, parses it to obtain multiple initial vertex data and corresponding initial index information, writes the initial vertex data into the vertex buffer object VBO, and writes the initial index information into the index buffer object EBO.

[0157] Subsequently, the determination module determines the target index set from the EBO's index information based on the user's interactive operations (such as panning, zooming, or dragging) and the rendering window.

[0158] Finally, the rendering module renders the VBO and the target index set to obtain the first rendering result. Throughout the data stream processing, the CPU and GPU of the rendering device 101 work together, achieving efficient rendering of the rendering object through the separate storage of VBO and EBO and the filtering of the target index set.

[0159] Example 4: Based on the above embodiments, this embodiment provides an image rendering apparatus 120, which can operate in... Figure 1A computer program (including program code) in the rendering device 101 shown, and used to perform such as Figure 2 , Figure 6 and Figure 8 The method shown. Please refer to [link / reference]. Figure 12 , Figure 12 This application provides a schematic diagram of the structure of an image rendering apparatus 120, which includes: The determining unit 1201 is used to determine a target index set from multiple index information in the index buffer object EBO of the rendering object based on the user's interactive operation and the rendering window. The interactive operation includes translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window. The rendering window is the area used to display the rendering result. The rendering object is the model to be rendered. The index buffer object EBO stores the index information of multiple vertex data of the rendering object. The target index set is composed of multiple index information corresponding to multiple vertex data located in the rendering window.

[0160] The rendering unit 1202 is used to render based on the vertex buffer object VBO and the target index set to obtain the first rendering result, wherein the vertex buffer object VBO stores multiple vertex data of the rendering object.

[0161] In one possible embodiment, in determining the target index set from multiple index information in the index buffer object (EBO) of the rendering object based on the user's interaction operation and the rendering window, the determining unit 1201 is further specifically configured to: determine a first transformation matrix corresponding to the interaction operation based on the interaction operation; use a compute shader to transform multiple vertex data in the vertex buffer object (VBO) based on the first transformation matrix to update the multiple vertex data in the vertex buffer object; determine multiple vertex data that are still located in the rendering window after transformation based on the updated multiple vertex data and the rendering window; and determine the target index set in the index buffer object (EBO) based on the multiple vertex data located in the rendering window.

[0162] In one possible embodiment, before the step of determining the target index set from multiple index information in the index buffer object EBO of the rendering object based on the user's interactive operation and the rendering window, the determining unit 1201 is further specifically used to: obtain and parse the rendering object to obtain multiple initial vertex data corresponding to the rendering object, and multiple initial index information corresponding to the multiple initial vertex data, wherein the multiple initial vertex data is part or all of the multiple vertex data; write the multiple initial vertex data into the vertex buffer object VBO, and write the multiple initial index information into the index buffer object EBO, wherein the multiple initial index information and the multiple index information have at least partially the same index information.

[0163] In one possible embodiment, after writing multiple initial vertex data into a vertex buffer object (VBO) and multiple initial index information into an index buffer object (EBO), the determining unit 1201 is further specifically used to: perform initial subdivision of the primitives corresponding to the multiple initial vertex data using a computational shader to obtain multiple vertex data and index information corresponding to the multiple vertex data.

[0164] In one possible embodiment, before the step of initially subdividing the primitives corresponding to multiple initial vertex data using a computational shader, the determining unit 1201 is further specifically configured to: obtain a first editing operation by the user on a first target primitive in the rendering object, wherein the first editing operation is used to modify the geometric attributes of the first target primitive, the geometric attributes including shape and / or size; according to the first editing operation, use the computational shader to write a first mapping relationship between the modified vertex data and the corresponding index information corresponding to the first target primitive to a shader buffer object SSBO, wherein the position information of the modified vertex data corresponding to the first target primitive is different from the vertex data of the first target primitive in a vertex buffer object VBO; use the computational shader based on the first mapping relationship to replace the vertex data corresponding to the first target primitive in the vertex buffer object VBO with the modified vertex data, and update the index information in an index buffer object EBO.

[0165] In one possible embodiment, after the step of initially subdividing the primitives corresponding to multiple initial vertex data using a computational shader, the determining unit 1201 is further specifically configured to: obtain a second editing operation by the user on the second target primitive of the rendering object, wherein the second editing operation is used to modify the target attribute of the second target primitive, the target attribute being an attribute other than geometric attributes, the geometric attributes including shape and / or size; according to the second editing operation, using the computational shader to write a second mapping relationship between the modified vertex data and the corresponding index information corresponding to the second target primitive to the shader buffer object SSBO, wherein the target attribute of the modified vertex data corresponding to the second target primitive is different from the vertex data of the second target primitive in the vertex buffer object VBO; using the computational shader based on the second mapping relationship, replacing the vertex data corresponding to the second target primitive in the vertex buffer object VBO with the modified vertex data, and updating the index information in the index buffer object EBO.

[0166] In one possible embodiment, in obtaining a first rendering result by rendering based on the vertex buffer object (VBO) and the target index set, the rendering unit 1202 is further specifically configured to: determine the layout index and the foreground index, wherein the layout index is a set of index information corresponding to the vertex data of the layout, and the foreground index is a set of index information corresponding to the vertex data of the foreground; obtain the corresponding layout data from the vertex buffer object (VBO) based on the layout index and perform layout rendering to obtain a layout rendering layer; obtain the corresponding foreground data from the vertex buffer object (VBO) based on the foreground index and perform foreground rendering to obtain a foreground rendering layer; and obtain the first rendering result based on the layout rendering layer and the foreground rendering layer.

[0167] In one possible embodiment, the step of obtaining the corresponding layout data from the vertex buffer object (VBO) according to the layout index and performing layout rendering to obtain the layout rendering layer, and obtaining the corresponding foreground data from the vertex buffer object (VBO) according to the foreground index and performing foreground rendering to obtain the foreground rendering layer, is performed in the off-screen frame buffer object. In terms of obtaining the first rendering result based on the layout rendering layer and the foreground rendering layer, the rendering unit 1202 is further specifically used to: copy the layout rendering layer and the foreground rendering layer from the frame buffer in the off-screen frame buffer object to the view frame buffer object to obtain the first rendering result.

[0168] In one possible embodiment, the graphics processor's video memory includes at least three vertex buffer objects (VBOs), with the number of VBOs being less than 10; one or more of the at least three VBOs are used to store vertex data, one of the multiple VBOs is used to store a second transformation matrix, and one of the multiple VBOs is used to store rendering instructions, wherein the second transformation matrix is ​​used to convert the local coordinates of the vertex data into world coordinates during the rendering process.

[0169] In one possible embodiment, after the step of rendering based on the vertex buffer object (VBO) and the target index set to obtain the first rendering result, the rendering unit 1202 is further specifically configured to: obtain the first video memory occupied by the vertex data in the vertex buffer object (VBO) that is in a valid state; obtain the second video memory currently occupied by the graphics processor (GPU) used by the program for rendering the rendering object; determine the percentage of video memory used based on the ratio of the first video memory to the second video memory; if the percentage of video memory used is greater than or equal to a first preset threshold, and the ratio of the second video memory to the total video memory of the graphics processor (GPU) is less than or equal to a second preset threshold, then the vertex buffer object (VBO) is expanded.

[0170] In one possible embodiment, the vertex buffer object (VBO) includes multiple vertex storage areas for storing vertex data. After the step of rendering based on the vertex buffer object (VBO) and the target index set to obtain a first rendering result, the rendering unit 1202 is further configured to: change the data state of the vertex data in the vertex buffer object (VBO) from a valid state to an invalid state in response to a triggering condition, wherein the triggering condition includes the deletion or hiding of the primitives corresponding to the vertex data; and delete the vertex data in the invalid storage areas when the number of invalid storage areas is greater than a threshold, wherein an invalid storage area is a vertex storage area that stores vertex data in an invalid state and does not store vertex data in a valid state.

[0171] In one possible embodiment, the vertex buffer object (VBO) includes multiple vertex storage areas for storing vertex data. Before the step of expanding the vertex buffer object (VBO), the rendering unit 1202 is further specifically used to delete vertex data in invalid storage areas.

[0172] Example 5: Please see Figure 13 , Figure 13 This is a schematic structural diagram of an electronic device provided in this application. The electronic device 130 includes a processor 1301, which is coupled to a memory 1302. The memory 1302 is used to store computer programs or instructions and / or data. The processor 1301 is used to execute the computer programs or instructions stored in the memory 1302, or to read the data stored in the memory 1302, in order to execute the methods in the above-described method embodiments.

[0173] Optionally, there may be one or more processors 1301.

[0174] Optionally, the memory 1302 may be one or more.

[0175] Alternatively, the memory 1302 can be integrated with the processor 1301, or it can be set separately.

[0176] Optionally, such as Figure 13 As shown, the electronic device 130 also includes a transceiver 1303, which is used for receiving and / or transmitting signals. For example, the processor 1301 is used to control the transceiver 1303 to receive and / or transmit signals.

[0177] In addition, this application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the methods in the various method embodiments of this application to be performed.

[0178] This application also provides a computer program product, which includes computer program code or instructions, such that when the computer program code or instructions are run on a computer, the methods in the various method embodiments of this application are executed.

[0179] Furthermore, this application also provides a chip including a processor. A memory for storing a computer program is provided independently of the chip, and the processor is used to execute the computer program stored in the memory to perform the methods in the various method embodiments of this application.

[0180] Furthermore, the chip may also include a communication interface. The communication interface may be an input / output interface or an interface circuit, etc. Furthermore, the chip may also include a memory.

[0181] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with the ability to process signals. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware encoding processor, or implemented by a combination of hardware and software modules in the encoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0182] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), and synchronous link dynamic memory (SLDRAM).

[0183] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory can be integrated into the processor.

[0184] It should also be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0185] Each of the above modules or units can be implemented through software, hardware, or a combination of both. For example, the coarse-grained segmentation module performs coarse-grained segmentation of the knowledge document to obtain target long and short paragraphs, and the fine-grained segmentation module performs fine-grained segmentation of the target long paragraph to obtain multiple first paragraphs and multiple summary texts corresponding to the multiple first paragraphs. Both of these can be implemented based on software.

[0186] In this application, "implemented through software" means that the processor reads and executes program instructions stored in memory to implement the functions corresponding to the aforementioned modules or units. Here, the processor refers to a processing circuit capable of executing program instructions, including but not limited to at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., and other processing circuits capable of running program instructions. In other embodiments, the processor may also include circuits with other processing functions (such as hardware circuits for hardware acceleration, bus and interface circuits, etc.). The processor can be presented as an integrated chip, for example, as an integrated chip whose processing function only includes executing software instructions, or it can also be presented as a SoC (system on a chip), that is, on a single chip, in addition to the processing circuit capable of running program instructions (usually referred to as the "core"), it also includes other hardware circuits for implementing specific functions (of course, these hardware circuits can also be implemented separately based on ASIC or FPGA). Correspondingly, the processing functions, in addition to executing software instructions, may also include various hardware acceleration functions (such as AI calculation, encoding / decoding, compression / decompression, etc.).

[0187] In this application, "implemented in hardware" means that the functions of the above-mentioned modules or units are implemented through hardware processing circuits that do not have program instruction processing capabilities. These hardware processing circuits can be composed of discrete hardware components or integrated circuits. To reduce power consumption and size, integrated circuits are typically used. Hardware processing circuits can include ASICs (application-specific integrated circuits) or PLDs (programmable logic devices); PLDs can include FPGAs (field-programmable gate arrays), CPLDs (complex programmable logic devices), and so on. These hardware processing circuits can be a single packaged semiconductor chip (e.g., packaged as an ASIC); or they can be integrated with other circuits (e.g., CPUs, DSPs) and packaged into a single semiconductor chip. For example, multiple hardware circuits and a CPU can be formed on a silicon substrate and packaged into a single chip; this type of chip is also called a SoC. Alternatively, circuits for implementing FPGA functions and a CPU can be formed on a silicon substrate and encapsulated into a single chip; this type of chip is also called a SoPC (system on a programmable chip).

[0188] It should be noted that when this application is implemented through software, hardware, or a combination of both, different software or hardware can be used, and it is not limited to using only one type of software or hardware. For example, one module or unit can be implemented using a CPU, while another module or unit can be implemented using a DSP. Similarly, when implemented using hardware, one module or unit can be implemented using an ASIC, while another module or unit can be implemented using an FPGA. Of course, it is not limited to using the same software (e.g., all through a CPU) or the same hardware (e.g., all through an ASIC) to implement some or all modules or units. Furthermore, those skilled in the art will understand that software is generally more flexible but less performant than hardware, while hardware is the opposite. Therefore, those skilled in the art can choose software, hardware, or a combination of both based on actual needs.

Claims

1. An image rendering method, characterized in that, The method includes: Based on user interaction, vertex data in a vertex buffer object is transformed to update multiple vertex data in the vertex buffer object; based on the updated multiple vertex data and the rendering window, multiple vertex data that remain in the rendering window after transformation are determined; and based on the multiple vertex data located in the rendering window, a target index set is determined in the index buffer object of the rendering object; wherein, the interaction includes translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window, the rendering window is an area used to display the rendering result, the rendering object is the model to be rendered, the index buffer object stores the index information of multiple vertex data of the rendering object, and the target index set consists of multiple index information corresponding to the multiple vertex data located in the rendering window; and... Rendering is performed based on the vertex buffer object and the target index set to obtain a first rendering result, wherein the vertex buffer object stores multiple vertex data of the rendering object.

2. The method according to claim 1, characterized in that, Based on the user's interactive operations, the vertex data in the vertex buffer object is transformed to update multiple vertex data in the vertex buffer object; Based on the updated vertex data and the rendering window, determine the vertex data that are still located in the rendering window after the transformation; And, based on the multiple vertex data located in the rendering window, determining the target index set in the index buffer object of the rendering object includes: Based on the interaction operation, determine the first transformation matrix corresponding to the interaction operation; Using a compute shader, multiple vertex data in a vertex buffer object are transformed based on the first transformation matrix to update the multiple vertex data in the vertex buffer object; Based on the updated vertex data and the rendering window, determine the vertex data that remain within the rendering window after the transformation; and, The target index set is determined in the index buffer object based on the multiple vertex data located in the rendering window.

3. The method according to claim 1 or 2, characterized in that, Based on the user's interactive operations, the vertex data in the vertex buffer object is transformed to update multiple vertex data in the vertex buffer object; Based on the updated vertex data and the rendering window, determine the vertex data that are still located in the rendering window after the transformation; Furthermore, prior to the step of determining the target index set in the index buffer object of the rendering object based on the multiple vertex data located in the rendering window, the method further includes: The rendering object is obtained and parsed to obtain multiple initial vertex data corresponding to the rendering object, and multiple initial index information corresponding to the multiple initial vertex data, wherein the multiple initial vertex data is part or all of the multiple vertex data; The plurality of initial vertex data are written to a vertex buffer object, and the plurality of initial index information are written to an index buffer object, wherein the plurality of initial index information and the plurality of index information have at least partially the same index information.

4. The method according to claim 3, characterized in that, After the steps of writing the plurality of initial vertex data to a vertex buffer object and writing the plurality of initial index information to an index buffer object, the method further includes: The primitives corresponding to the multiple initial vertex data are initially partitioned using a computational shader to obtain the multiple vertex data and the index information corresponding to the multiple vertex data.

5. The method according to claim 4, characterized in that, Before the step of performing initial partitioning of the primitives corresponding to the plurality of initial vertex data using a computational shader, the method further includes: Obtain a user's first editing operation on a first target primitive in the rendered object, wherein the first editing operation is used to modify the geometric properties of the first target primitive, the geometric properties including shape and / or size; According to the first editing operation, the compute shader writes the first mapping relationship between the modified vertex data and the corresponding index information of the first target primitive to the shader buffer object, wherein the position information of the modified vertex data of the first target primitive is different from the vertex data of the first target primitive in the vertex buffer object. Using a compute shader based on the first mapping relationship, the modified vertex data replaces the vertex data corresponding to the first target primitive in the vertex buffer object, and the index information in the index buffer object is updated.

6. The method according to claim 4, characterized in that, After the step of performing initial partitioning of the primitives corresponding to the plurality of initial vertex data using a computational shader, the method further includes: Obtain a second editing operation by the user on the second target primitive of the rendered object, wherein the second editing operation is used to modify the target attribute of the second target primitive, the target attribute being an attribute other than geometric attributes, the geometric attributes including shape and / or size; According to the second editing operation, the compute shader writes a second mapping relationship between the modified vertex data and the corresponding index information corresponding to the second target primitive to the shader buffer object, wherein the target attribute of the modified vertex data corresponding to the second target primitive is different from the vertex data of the second target primitive in the vertex buffer object; Using a compute shader based on the second mapping relationship, the modified vertex data replaces the vertex data corresponding to the second target primitive in the vertex buffer object, and the index information in the index buffer object is updated.

7. The method according to claim 1 or 2, characterized in that, Rendering is performed based on the vertex buffer object and the target index set to obtain a first rendering result, including: Determine the layout index and the foreground index, wherein the layout index is a set of index information corresponding to the vertex data of the layout, and the foreground index is a set of index information corresponding to the vertex data of the foreground; Based on the layout index, the corresponding vertex data is obtained from the vertex buffer object for layout rendering to obtain the layout rendering layer; Based on the foreground index, the corresponding vertex data is obtained from the vertex buffer object for foreground rendering to obtain the foreground rendering layer; and The first rendering result is obtained based on the map rendering layer and the foreground rendering layer.

8. The method according to claim 1 or 2, characterized in that, The graphics processor's video memory includes at least three vertex buffer objects, and the number of vertex buffer objects is less than 10. One or more of the at least three vertex buffer objects are used to store the vertex data, one of the plurality of vertex buffer objects is used to store the second transformation matrix, one of the plurality of vertex buffer objects is used to store rendering instructions, and the second transformation matrix is ​​used to convert the local coordinates of the vertex data into world coordinates during the rendering process.

9. The method according to claim 1 or 2, characterized in that, After the step of rendering based on the vertex buffer object and the target index set to obtain a first rendering result, the method further includes: Obtain the first video memory occupied by the vertex data that is in a valid state in the vertex buffer object; Obtain the second video memory currently occupied by the graphics processor used by the program to render the rendered object; The percentage of video memory already used is determined based on the ratio of the first video memory to the second video memory. If the percentage of used video memory is greater than or equal to a first preset threshold, and the ratio of the second video memory to the total video memory of the graphics processor is less than or equal to a second preset threshold, then the vertex buffer object is expanded.

10. The method according to claim 1 or 2, characterized in that, The vertex buffer object includes multiple vertex storage areas for storing vertex data. After the step of rendering based on the vertex buffer object and the target index set to obtain a first rendering result, the method further includes: In response to a triggering condition, the data state of the vertex data of one or more third target primitives in the vertex buffer object is changed from a valid state to an invalid state, wherein the triggering condition includes the deletion or hiding of the one or more third target primitives; When the number of invalid storage areas exceeds a threshold, the vertex data in the invalid storage areas is deleted. The invalid storage area is a vertex storage area that stores vertex data in the invalid state but does not store vertex data in the valid state.

11. An image rendering apparatus, characterized in that, The device includes: A determining unit is configured to: transform vertex data in a vertex buffer object based on user interaction operations to update multiple vertex data in the vertex buffer object; determine multiple vertex data that remain in the rendering window after transformation based on the updated multiple vertex data and the rendering window; and determine a target index set in an index buffer object of a rendering object based on the multiple vertex data located in the rendering window. The interaction operations include translating the rendering object, scaling the rendering object, rotating the rendering object, or changing the rendering window. The rendering window is an area for displaying rendering results. The rendering object is a model to be rendered. The index buffer object stores index information of multiple vertex data of the rendering object. The index information is a number value pointing to the storage location of the corresponding vertex data in the vertex buffer object. The target index set consists of multiple index information corresponding to the multiple vertex data located in the rendering window. A rendering unit is used to render based on a vertex buffer object and the target index set to obtain a first rendering result, wherein the vertex buffer object stores multiple vertex data of the rendering object.

12. An electronic device, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, said one or more programs being stored in the memory and configured to be executed by the processor, said programs including instructions for performing the steps of the method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program for electronic data interchange, wherein the computer program causes a computer to perform the method as described in any one of claims 1-10.

14. A computer program product, characterized in that, When the computer program product is run, the method as described in any one of claims 1-10 is implemented.

Images