Rendering method and system, electronic equipment and storage medium

Abstract

The invention discloses a rendering method and system, electronic equipment and a storage medium, which are applied to a user-defined user mode graphics library set for a Linux operating system, and comprise the following steps: responding to a detected calling request of a target application running in the Linux operating system for a first target interface in the user-defined user mode graphics library; obtaining calling information of the first target interface; the calling information of the first target interface is sent to a target service running in an Android operating system, so that the target service calls the first target interface in a native user mode graphics library according to the calling information of the first target interface, and hardware rendering is carried out through a GPU, the native user mode graphics library is a graphics library which is set for an Android operating system and is subjected to hardware rendering through a GPU (Graphics Processing Unit). The purpose of carrying out hardware rendering by utilizing the GPU in the Linux operating system is achieved.

Description

Technical Field

[0001] The present application relates to the field of rendering technology, and in particular to a rendering method, system, electronic device, and storage medium. Background Art

[0002] Chip manufacturers (such as mobile phone chip manufacturers) typically only provide native user-mode graphics libraries based on the Android operating system. Therefore, if you want to run the Linux operating system directly on this chip, you will not be able to use the GPU (Graphics Processing Unit) for hardware rendering in the Linux operating system due to the lack of the native user-mode graphics libraries provided by the manufacturer.

[0003] In view of this, this application is hereby filed. Summary of the Invention

[0004] The following is a brief summary of one or more aspects to provide a basic understanding of these aspects. This summary is not an exhaustive overview of all conceivable aspects and is neither intended to identify key or critical elements of all aspects nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that will be provided later.

[0005] The present application provides a rendering method, system, electronic device and storage medium, which achieve the purpose of hardware rendering using GPU in Linux operating system.

[0006] In a first aspect, the present application provides a rendering method, which is applied to a custom user-mode graphics library set for a Linux operating system, comprising the following steps:

[0007] In response to detecting a call request from a target application running in a Linux operating system to a first target interface in the custom user-mode graphics library, acquiring call information of the first target interface, wherein the call request is sent when the target application has an image rendering requirement;

[0008] The calling information of the first target interface is sent to the target service running in the Android operating system, so that the target service calls the first target interface in the native user-mode graphics library according to the calling information of the first target interface to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system for hardware rendering through the GPU.

[0009] Furthermore, it also includes:

[0010] Receive a return value obtained when calling the first target interface, as fed back by the target service;

[0011] The return value is sent to the target application.

[0012] Furthermore, the target application includes a graphics application and / or a window compositor.

[0013] In a second aspect, the present application further provides a rendering method, which is applied to a target service running on an Android operating system, comprising:

[0014] detecting whether call information of a first target interface sent by a custom user-state graphics library is received, wherein the custom user-state graphics library is set for a Linux operating system, and when a target application running in the Linux operating system has an image rendering requirement, the target application sends a call request for the first target interface in the custom user-state graphics library. Upon detecting the call request for the first target interface in the custom user-state graphics library, the custom user-state graphics library obtains the call information of the first target interface and sends the call information of the first target interface to the target service;

[0015] In response to receiving the call information of the first target interface sent by the custom user-mode graphics library, the first target interface in the native user-mode graphics library is called according to the call information to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system for hardware rendering through the GPU.

[0016] Furthermore, the return value obtained when the first target interface is called is fed back to the custom user-state graphics library. When the custom user-state graphics library receives the return value, it sends the return value to the target application.

[0017] Furthermore, the target application includes a graphics application and / or a window compositor.

[0018] In a third aspect, the present application further provides a rendering system, comprising: a Linux operating system, a target application running in the Linux operating system, a custom user-mode graphics library set for the Linux operating system, an Android operating system, a target service running in the Android operating system, and a native user-mode graphics library set for the Android operating system for hardware rendering via a GPU;

[0019] When the target application has an image rendering requirement, the target application sends a call request for a first target interface in the custom user-mode graphics library;

[0020] When the custom user-mode graphics library detects a call request of the first target interface, obtaining call information of the first target interface and sending the call information of the first target interface to the target service;

[0021] The target service calls the first target interface in the native user-mode graphics library according to the calling information of the first target interface, so as to perform hardware rendering through the GPU.

[0022] Furthermore, the target application includes a graphics application and / or a window compositor.

[0023] In a fourth aspect, the present application further provides an electronic device, comprising:

[0024] one or more processors;

[0025] a storage device for storing one or more programs;

[0026] When the one or more programs are executed by the one or more processors, the one or more processors implement the rendering method described above.

[0027] In a fifth aspect, the present application also provides a computer-readable storage medium having a computer program stored thereon, which implements the rendering method described above when executed by a processor.

[0028] The rendering method disclosed in the present application sets a custom user-mode graphics library for the Linux operating system, so that the target application running on the Linux operating system can call the interface in the custom user-mode graphics library, thereby solving the problem of the lack of a native user-mode graphics library based on the Linux operating system. In response to detecting a call request for a first target interface in the custom user-mode graphics library from a target application running on the Linux operating system, the call information of the first target interface is obtained, and further, the call information of the first target interface is sent to a target service running on the Android operating system, so that the target service calls the first target interface in the native user-mode graphics library according to the call information of the first target interface, so as to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system for hardware rendering through the GPU, thereby achieving the purpose of using the GPU for hardware rendering in the Linux operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0030] Figure 1 A flowchart of a rendering method provided in an embodiment of the present application;

[0031] Figure 2 A flowchart of another rendering method provided in an embodiment of the present application;

[0032] Figure 3 A schematic diagram of the structure of a rendering system provided in an embodiment of the present application;

[0033] Figure 4 This is a structural diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0034] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0035] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0036] Figure 1 This is a flow chart of a rendering method proposed in this application. The method is applicable to the Linux operating system, and the Linux operating system is installed on the target chip. The manufacturer of the target chip does not provide a native user-mode graphics library based on the Linux operating system (i.e., a graphics library that performs hardware rendering through the GPU), but only provides a native user-mode graphics library based on the Android operating system. Due to the different root file systems of the Linux operating system and the Android operating system, the C libraries they use are different, and the dynamic linkers they use are different. These differences make it impossible for the native user-mode graphics library adapted to the Android operating system provided by the manufacturer to be used directly in the Linux operating system. Therefore, it will not be possible to use the GPU for hardware rendering in the Linux operating system.

[0037] To address the above issues, this embodiment provides a custom user-mode graphics library specifically for the Linux operating system. This custom user-mode graphics library only needs to be callable by the target application or window compositor in the Linux operating system, without requiring the GPU to perform hardware rendering. Actual GPU hardware rendering functionality still relies on the native user-mode graphics library of the Android operating system. This facilitates the development and design of the custom user-mode graphics library.

[0038] Specifically, the interface in the custom user-mode graphics library is implemented by passing API call information to a target service running in the Android environment. Within the Android runtime environment, the target service calls the manufacturer's native user-mode graphics library, generated based on the Android runtime environment, using the same call information to execute these calls. This approach enables hardware rendering using the GPU within the Linux operating system.

[0039] Specifically, when a process in the Linux operating system (including the target application and the window compositor) calls the custom user-mode graphics library provided by this application, the custom user-mode graphics library passes the call (including parameters) to the graphics library API such as EGL or GLES to the service running in the Android runtime environment. The service calls the native user-mode graphics library provided by the manufacturer and generated based on the Android runtime environment in the Android runtime environment, executes these calls using the same parameters, and returns the results to the process in the Linux operating system. In this way, the function of hardware rendering using the GPU in the Linux operating system is realized.

[0040] like Figure 1 As shown, the rendering method applied to the customized user-mode graphics library set for the Linux operating system includes the following steps:

[0041] S110. In response to detecting a call request from a target application running in a Linux operating system to a first target interface in the custom user-mode graphics library, obtain call information of the first target interface, wherein the call request is sent when the target application has an image rendering requirement.

[0042] The calling information of the first target interface includes the image rendering related information output by the target application and the numbering information of the first target interface. The numbering information of the first target interface is used to identify the first target interface to facilitate rapid location of the first target interface, and the image rendering related information output by the target application is used as an input parameter of the first target interface.

[0043] The image rendering-related information output by the target application can be obtained by parsing the call request. The number information of the first target interface can be obtained by searching the corresponding relationship between the name and number of the first target interface using the name of the first target interface as a search input. The name of the first target interface is obtained by parsing the call request.

[0044] S120. Send the calling information of the first target interface to the target service running in the Android operating system, so that the target service calls the first target interface in the native user-mode graphics library according to the calling information of the first target interface to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system to perform hardware rendering through the GPU.

[0045] In other words, the custom user-mode graphics library configured for the Linux operating system has the same API (i.e., interface) as the native user-mode graphics library. The custom user-mode graphics library configured for the Linux operating system is only used to provide call options for target applications running in the Linux operating system; actual functionality is implemented through the native user-mode graphics library.

[0046] In some embodiments, it also includes: receiving the return value obtained when calling the first target interface as feedback from the target service; sending the return value to the target application, so that the target application performs relevant processing based on the return value and obtains rendering-related information, such as processing vertex data according to the return value (including multiplication of the model view matrix and the projection matrix, converting the vertex from the model space to the screen space, so as to determine the position of the vertex in the final rendered image, etc.), texture data accuracy, etc. It can be understood that after the target application prepares these data, it needs to pass these data to the relevant interface in the native user-mode graphics library through an interface call method (such as the interface call method described in steps S110 and S120), and finally realize hardware rendering through the GPU.

[0047] The rendering method disclosed in this embodiment sets a custom user-mode graphics library for the Linux operating system, so that the target application running on the Linux operating system can call the interface in the custom user-mode graphics library, thereby solving the problem of the lack of a native user-mode graphics library based on the Linux operating system. In response to detecting a call request from the target application running on the Linux operating system to the first target interface in the custom user-mode graphics library, the call information of the first target interface is obtained, and further, the call information of the first target interface is sent to the target service running on the Android operating system, so that the target service calls the first target interface in the native user-mode graphics library according to the call information of the first target interface, so as to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system for hardware rendering through the GPU, thereby achieving the purpose of using the GPU for hardware rendering in the Linux operating system.

[0048] Based on the above embodiments, Figure 2 The flowchart of a rendering method applied to a target service running on an Android operating system is shown, which specifically includes the following steps:

[0049] S210. Detect whether call information of a first target interface sent by a custom user-state graphics library is received, wherein the custom user-state graphics library is set for a Linux operating system. When a target application running in the Linux operating system has an image rendering requirement, the target application sends a call request for the first target interface in the custom user-state graphics library. When the custom user-state graphics library detects the call request for the first target interface in the custom user-state graphics library, it obtains the call information of the first target interface and sends the call information of the first target interface to the target service.

[0050] S220. In response to receiving the call information of the first target interface sent by the custom user-mode graphics library, calling the first target interface in the native user-mode graphics library according to the call information to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system to perform hardware rendering through the GPU.

[0051] Furthermore, the method further includes: feeding back a return value obtained when calling the first target interface to the custom user-state graphics library, and when the custom user-state graphics library receives the return value, sending the return value to the target application.

[0052] Exemplarily, the target application includes a graphics application and / or a window compositor. A graphics application refers to a general application that requires image display. A window compositor is a component responsible for combining multiple different windows or graphic elements into a complete image that is ultimately displayed on the screen. This involves window hierarchy processing, window layout, and window cropping. When a graphics application requires multiple windows to be displayed simultaneously, it needs to interact with the window compositor so that the window compositor can handle the layout of the multiple windows.

[0053] Based on the above embodiments, Figure 3 A structural diagram of a rendering system is shown, comprising a Linux operating system 310, a target application 311 running in the Linux operating system, a custom user-mode graphics library 312 set for the Linux operating system, an Android operating system 320, a target service 321 running in the Android operating system, and a native user-mode graphics library 322 set for the Android operating system for hardware rendering via a GPU.

[0054] When the target application 311 has an image rendering requirement, the target application 311 sends a call request for the first target interface in the custom user-mode graphics library 312. When the custom user-mode graphics library 312 detects the call request for the first target interface, it obtains call information of the first target interface and sends the call information of the first target interface to the target service 321. The target service 321 calls the first target interface in the native user-mode graphics library 322 based on the call information of the first target interface to perform hardware rendering through the GPU.

[0055] The target application 311 includes a graphics application and / or a window compositor.

[0056] The graphics application and window compositor both run in a Linux environment and can call API functions from a custom user-mode graphics library (libEGL.so and libGLESv2.so) provided in the Linux system. The API functions in this custom user-mode graphics library are implemented by passing the API call number and parameters (i.e., call information) to a target service 321 running in the Android environment. Target service 321 then calls the manufacturer's native user-mode graphics library for the Android environment, executing these calls with the same parameters, thereby using the GPU hardware to render into the video memory.

[0057] The primary difference between the Linux and Android environments mentioned above lies in the C library: glibc in Linux, and bionic in Android. Therefore, the native user-mode graphics library provided by the manufacturer for the Android environment cannot be used directly in the Linux environment. This application's solution effectively establishes a transmission channel for hardware rendering commands from the Linux environment to the GPU hardware.

[0058] In this application, the video memory after GPU hardware rendering can be obtained by the window compositor in the Linux environment and sent to the display (that is, the return value of the relevant interface is fed back to the caller). Therefore, this solution is transparent and imperceptible to the window compositor and graphics applications running in the Linux environment, just like the window compositor and graphics applications in the Linux environment can directly use the native user-mode graphics library based on the Android environment.

[0059] Specifically, an application in Linux calls an API in the custom user-mode graphics library (libEGL.so or libGLESv2.so) provided in this embodiment. The custom user-mode graphics library passes the number and parameters agreed upon by this API call to the target service running in the Android runtime environment. The target service calls the native user-mode graphics library based on the Android runtime environment provided by the manufacturer, and uses the same parameters to execute the above API call. Check whether the API call has a return value or output parameters. If not, end the call; if so, return the return value and output parameters of the API to the application that called the API in Linux.

[0060] In some embodiments, the solution of this embodiment can be applied to the display of the instrument panel in the 8650 container environment. The environment uses the Android 14 operating environment as the base, on which a container is started, and the Linux operating system is run in the container. The graphics application (i.e., the instrument panel) and the window compositor (weston) run in the container. The custom user-mode graphics library (libEGL.so and libGLESv2.so) provided in this embodiment is also deployed in the container. The service (render_proxy) in this embodiment runs in the Android environment. The service calls the native user-mode graphics library based on the Android environment provided by the manufacturer (the service is designed to call the native user-mode graphics library of different manufacturers according to changes in the base). The service is also responsible for acquiring and managing video memory.

[0061] In some embodiments, the EGL extensions EGL_PLATFORM_WAYLAND_KHR and EGL_WL_bind_wayland_display are implemented for the custom userland graphics library libEGL.so so that it can interact with the window compositor (weston).

[0062] When a graphics application calls libEGL.so provided in this embodiment to obtain a drawing surface, the service returns the video memory information corresponding to the surface to libEGL.so. libEGL.so then passes this video memory information to the window compositor (weston) via the window protocol (wayland). The window compositor then obtains the video memory information, uses it to perform window synthesis, and then displays the final screen image obtained by synthesizing multiple windows.

[0063] There are two modes for display delivery: single SIM and dual SIM. In single SIM mode, Weston uses Android's SurfaceFlinger as the backend, specifying that the screen output be sent to the instrument cluster. In dual SIM mode, Weston uses the Linux DRM library to send the display content to the instrument cluster, which has the advantage of not requiring SurfaceFlinger to participate.

[0064] The render_proxy service in this embodiment runs in an Android environment and automatically adapts to the native user-mode graphics library (GPU) provided by various manufacturers for the Android environment, shielding upper-layer applications from hardware differences. This design greatly simplifies the container deployment and porting process, providing great convenience.

[0065] Figure 4 This is a schematic diagram of the structure of an electronic device in the embodiment of the present disclosure. Figure 4 , which shows a structural diagram of an electronic device 500 suitable for implementing the embodiments of the present disclosure. Figure 4 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0066] like Figure 4As shown, the electronic device 500 may include a processing device (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes to implement the method of the embodiment as described in the present disclosure according to the program stored in the read-only memory (ROM) or the program loaded from the storage device 508 into the random access memory (RAM). In the RAM 503, various programs and data required for the operation of the electronic device 500 are also stored. The processing device 501, the ROM 502 and the RAM 503 are connected to each other via a bus 504. The I / O interface 505 is also connected to the bus 504. The input device 506, the output device 507, the storage device 508 and the communication device 509 are all connected to the I / O interface 505.

[0067] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart, thereby implementing the rendering method as described above. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0068] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. In the present disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0069] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device performs the method steps of the present application.

[0070] Optionally, when the above one or more programs are executed by the electronic device, the electronic device may also execute other steps described in the above embodiments.

[0071] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0072] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0073] This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. The above is only the preferred implementation method of this application. It should be pointed out that due to the limitations of textual expression, there are objectively infinite specific structures. For ordinary technicians in this technical field, without departing from the principles of this application, they can also make several improvements, modifications or changes, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes or combinations, or the direct application of the inventive concept and technical solution to other occasions without improvement, should be regarded as the scope of protection of this application.

Claims

1. A rendering method, applied to a custom user-mode graphics library set for a Linux operating system, characterized in that: include: In response to detecting a call request from a target application running in a Linux operating system to a first target interface in the custom user-mode graphics library, acquiring call information of the first target interface, wherein the call request is sent when the target application has an image rendering requirement; The calling information of the first target interface is sent to the target service running in the Android operating system, so that the target service calls the first target interface in the native user-mode graphics library according to the calling information of the first target interface to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system for hardware rendering through the GPU.

2. The rendering method according to claim 1, wherein: Also includes: Receive a return value obtained when calling the first target interface, as fed back by the target service; The return value is sent to the target application.

3. The rendering method according to claim 1, wherein: The target application includes a graphics application and / or a window compositor.

4. A rendering method, applied to a target service running on an Android operating system, characterized in that: include: detecting whether call information of a first target interface sent by a custom user-state graphics library is received, wherein the custom user-state graphics library is set for a Linux operating system, and when a target application running in the Linux operating system has an image rendering requirement, the target application sends a call request for the first target interface in the custom user-state graphics library. Upon detecting the call request for the first target interface in the custom user-state graphics library, the custom user-state graphics library obtains the call information of the first target interface and sends the call information of the first target interface to the target service; In response to receiving the call information of the first target interface sent by the custom user-mode graphics library, the first target interface in the native user-mode graphics library is called according to the call information to perform hardware rendering through the GPU, wherein the native user-mode graphics library is a graphics library set for the Android operating system for hardware rendering through the GPU.

5. The rendering method according to claim 4, characterized in that: Also includes: The return value obtained when the first target interface is called is fed back to the custom user-state graphics library. When the custom user-state graphics library receives the return value, it sends the return value to the target application.

6. The rendering method according to claim 4, characterized in that: The target application includes a graphics application and / or a window compositor.

7. A rendering system, characterized in that: include: Linux operating system, target application running in the Linux operating system, a custom user-mode graphics library configured for the Linux operating system, Android operating system, target service running in the Android operating system, and a native user-mode graphics library configured for the Android operating system that performs hardware rendering via a GPU; When the target application has an image rendering requirement, the target application sends a call request for a first target interface in the custom user-mode graphics library; When the custom user-mode graphics library detects a call request of the first target interface, obtaining call information of the first target interface and sending the call information of the first target interface to the target service; The target service calls the first target interface in the native user-mode graphics library according to the calling information of the first target interface, so as to perform hardware rendering through the GPU.

8. The rendering system according to claim 7, wherein: The target application includes a graphics application and / or a window compositor.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; a storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the rendering method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the rendering method according to any one of claims 1 to 6 is implemented.

Images