Rendering method, apparatus, device, readable storage medium and program product

Abstract

Embodiments of the present application provide a rendering method and device, equipment, readable storage medium and program product, relating to the fields of picture rendering. The method comprises: determining, based on a plurality of rendering states corresponding to a target object, a structure corresponding to a target shared memory through a C++ layer, the structure being used to represent a data structure of the target shared memory; generating, based on the structure, offset values of each of the plurality of rendering states through a preset script, the offset value of each rendering state being used to represent a position of each rendering state in the target shared memory; and obtaining, based on the offset value of each rendering state, state values of each of the rendering states from the target shared memory through a JS layer, the state value of each rendering state being used for picture rendering.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a rendering method, apparatus, device, readable storage medium, and program product. Background Technology

[0002] In existing technologies, rendering game visuals requires the JavaScript layer to call the rendering capabilities of the driver layer. If the JavaScript layer needs to call the driver layer's rendering capabilities, it must first call the relevant binding functions and then call the driver layer's API (Application Programming Interface). If the JavaScript layer needs to obtain relevant rendering states, it also needs to go through the above calling steps. This process is cumbersome, especially when the call frequency is high, often leading to low rendering efficiency for the game visuals. Summary of the Invention

[0003] This application addresses the shortcomings of existing methods by proposing a rendering method, apparatus, device, computer-readable storage medium, and computer program product to solve the problem of how to improve the rendering efficiency of game graphics.

[0004] Firstly, this application provides a rendering method, including:

[0005] Based on the multiple rendering states corresponding to the target object, the structure corresponding to the target shared memory is determined through the C++ layer. The structure is used to represent the data structure of the target shared memory.

[0006] Based on the structure, an offset value for each rendering state is generated through a preset script. The offset value of each rendering state is used to characterize the location of each rendering state in the target shared memory.

[0007] Based on the offset value of each rendering state, the state value of each rendering state is obtained from the target shared memory through the JS layer, and the state value of each rendering state is used for screen rendering.

[0008] In one embodiment, based on the first application programming interface in the JS layer, a target shared memory and its name are created through the C++ layer, and the name of the target shared memory is passed to the JS layer; the first application programming interface is the WebGL application programming interface; the target shared memory is used to store the state values ​​of multiple rendering states corresponding to the target object.

[0009] In one embodiment, based on the second application programming interface in the JS layer, the update state value of at least one of the multiple rendering states is set to the target shared memory via the C++ layer.

[0010] In one embodiment, based on the second application programming interface in the JS layer, and through the C++ layer, the update state value of at least one of multiple rendering states is set to the target shared memory, including:

[0011] The starting address of the target shared memory and the update state value of at least one of the multiple rendering states are passed to the C++ layer through the second application interface in the JS layer.

[0012] Based on the starting address of the target shared memory, the starting address of the target shared memory is converted into a structure through the C++ layer, and the state value of at least one rendering state in the structure is updated to the updated state value.

[0013] In one embodiment, the target object is a WebGL object, the object set is a WebGL object set, and the second application interface is a WebGL application interface.

[0014] In one embodiment, after setting the update state value of at least one of the multiple rendering states to the target shared memory, the method further includes:

[0015] The C++ layer sends the update state value of at least one of the multiple rendering states to the driver layer.

[0016] The driver layer performs image rendering based on updated state values.

[0017] Secondly, this application provides a rendering apparatus, comprising:

[0018] The first processing module is used to determine the structure corresponding to the target shared memory through the C++ layer based on the multiple rendering states corresponding to the target object. The structure is used to represent the data structure of the target shared memory.

[0019] The second processing module is used to generate an offset value for each of the multiple rendering states based on the structure and through a preset script. The offset value of each rendering state is used to characterize the position of each rendering state in the target shared memory.

[0020] The third processing module is used to obtain the state value of each rendering state from the target shared memory through the JS layer based on the offset value of each rendering state. The state value of each rendering state is used for screen rendering.

[0021] Thirdly, this application provides an electronic device, including: a processor, a memory, and a bus;

[0022] A bus is used to connect the processor and memory;

[0023] Memory, used to store operation instructions;

[0024] A processor is used to execute the rendering method of the first aspect of this application by invoking operation instructions.

[0025] Fourthly, this application provides a computer-readable storage medium storing a computer program that is used to execute the rendering method of the first aspect of this application.

[0026] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the rendering method in the first aspect of this application.

[0027] The technical solution provided in this application has at least the following beneficial effects:

[0028] Based on multiple rendering states corresponding to the target object, a C++ layer determines the structure corresponding to the target shared memory. This structure represents the data structure of the target shared memory. Based on the structure, a preset script generates the offset value of each rendering state. This offset value represents the position of each rendering state in the target shared memory. Based on the offset value of each rendering state, a JS layer retrieves the state value of each rendering state from the target shared memory. This state value is used for rendering. In this way, the JS layer retrieves the state value of the rendering state from the shared memory, improving the efficiency of the JS layer in obtaining the rendering state of the target object (e.g., a WebGL object), thereby improving the rendering efficiency of the screen (e.g., game screen). Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

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

[0031] Figure 2 A flowchart illustrating a rendering method provided in an embodiment of this application;

[0032] Figure 3 This is a schematic diagram of the structure of a rendering device provided in an embodiment of this application;

[0033] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0035] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” indicates implementation as “A,” or implementation as “B,” or implementation as “A and B.”

[0036] It is understood that in the specific implementation of this application, rendering-related data is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0037] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0038] To better understand and explain the solutions of the embodiments of this application, some technical terms involved in the embodiments of this application will be briefly explained below.

[0039] WebGL: (1) WebGL (Web Graphics Library, 3D drawing protocol) is a drawing technology standard that combines JavaScript and OpenGL ES 2.0. By adding a JavaScript binding to OpenGL ES 2.0, WebGL can provide hardware 3D accelerated rendering for HTML5 Canvas. In this way, 3D scenes and models can be displayed more smoothly in the browser with the help of the system graphics card, and complex navigation and data visualization can also be created. WebGL can be used to create website pages with complex 3D structures, design 3D web games, etc. (2) The specifications defined in the WebGL standard include: all states that need to be defined to implement a WebGL state machine; the structure name is WebGLState, which includes binding state, Rasterization state, and Pixel state. Among them, binding state includes array buffer binding, read framebufferbinding, draw framebuffer binding, program binding, etc. Rasterization includes viewport, cullFaceMode, frontFace, etc. Pixel includes blend, depthTest, dither, etc.

[0040] JS: JavaScript is an object-based, dynamic, weakly typed scripting language. JS is an interpreted language, meaning it does not need to be compiled into intermediate code and can be run directly in a browser. The JS execution process can be divided into two stages: compilation and execution.

[0041] WebGLRenderingContext: WebGLRenderingContext provides a drawing context based on OpenGL ES 2.0 for drawing within HTML elements.

[0042] WebGLBuffer: WebGLBuffer is part of the WebGL API. WebGLBuffer represents an opaque buffer object that stores data such as vertices or shaders.

[0043] WebGLFramebuffer: A WebGLFramebuffer is an independent rendering target, meaning that the entire scene can be drawn into the same WebGLFramebuffer.

[0044] WebGL Program: WebGL Program is part of the WebGL API. WebGL Program consists of two WebGL Shaders: a vertex shader and a fragment shader.

[0045] WebGLBufferState: WebGLBufferState is a structure used to store the state values ​​of WebGLBuffer related rendering states, including size, usage, everBeenBound, etc.

[0046] WebGLFramebufferState: WebGLFramebufferState is a structure used to store the state values ​​of the rendering state related to WebGLFramebuffer, including color attachments, depth attachments, draw buffers, etc.

[0047] WebGLProgramState: WebGLProgramState is a structure used to store the state values ​​of WebGLProgram related rendering states, including vertex shader, fragment shader, link status, etc.

[0048] The solutions provided in this application relate to rendering technology. The technical solutions of this application will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0049] See Figure 1 , Figure 1 This illustration shows a flowchart of a rendering method provided in an embodiment of this application. This method can be executed by any electronic device, such as a terminal. As an optional implementation, the method can be executed by a terminal. For ease of description, the following descriptions of some optional embodiments will use a terminal as the executing entity of the method. Figure 1 As shown, the rendering method provided in this application embodiment includes the following steps:

[0050] S201, based on multiple rendering states corresponding to the target object, determines the structure corresponding to the target shared memory through the C++ layer. The structure is used to represent the data structure of the target shared memory.

[0051] Specifically, the JS layer is the JS runtime environment; the target shared memory is created by the C++ layer, and it is the memory that the JS and C++ layers can share and access; the target object is a WebGL object, such as WebGLRenderingContext, WebGLBuffer, WebGLFramebuffer, WebGLProgram, etc. The WebGL state machine is a collection of multiple rendering states corresponding to WebGLRenderingContext. One target object corresponds to one target shared memory; for example, WebGLRenderingContext corresponds to target shared memory A, WebGLBuffer corresponds to target shared memory B, WebGLFramebuffer corresponds to target shared memory C, and WebGLProgram corresponds to target shared memory D. The C++ layer is the C++ runtime environment; the structures corresponding to the target shared memory include WebGLBufferState, WebGLFramebufferState, WebGLProgramState, etc.

[0052] It should be noted that terminals include, but are not limited to, smartphones (such as Android phones, iOS phones, etc.), mobile phone emulators, tablets, laptops, digital broadcast receivers, MIDs (Mobile Internet Devices), PDAs (Personal Digital Assistants), smart voice interaction devices, smart home appliances, and in-vehicle terminals.

[0053] S202, based on a structure, generates an offset value for each of the multiple rendering states through a preset script. The offset value of each rendering state is used to characterize the location of each rendering state in the target shared memory.

[0054] Specifically, the offset value of each rendering state is a constant, such as 5. This constant can be directly declared in the JS layer code file, and the JS layer can directly access this constant. The offset value of each rendering state is used to represent the position of the state value of each rendering state in the target shared memory, that is, the order of the state values ​​of each rendering state in the target shared memory. For example, the offset value of rendering state A is 1, the offset value of rendering state B is 2, and the offset value of rendering state C is 3. That is, the state values ​​of rendering state A, rendering state B, and rendering state C are stored in the target shared memory in the order of their respective states.

[0055] S203, based on the offset value of each rendering state, obtains the state value of each rendering state from the target shared memory through the JS layer, and the state value of each rendering state is used for screen rendering.

[0056] Specifically, for example, a WebGL state machine has two rendering states, ArrayBufferBinding and ProgramBinding. The state values ​​of these two rendering states are both int type values. An int type value can be 8 bytes. The target shared memory corresponding to this WebGL state machine needs a length of 16 bytes to store the state values ​​of these two rendering states.

[0057] In this embodiment, based on multiple rendering states corresponding to the target object, a structure corresponding to the target shared memory is determined through a C++ layer. The structure is used to represent the data structure of the target shared memory. Based on the structure, an offset value for each rendering state is generated through a preset script. The offset value for each rendering state is used to represent the position of each rendering state in the target shared memory. Based on the offset value for each rendering state, the state value of each rendering state is obtained from the target shared memory through a JS layer. The state value of each rendering state is used for screen rendering. In this way, the JS layer obtains the state value of the rendering state from the shared memory, which improves the efficiency of the JS layer in obtaining the rendering state of the target object (e.g., a WebGL object), thereby improving the rendering efficiency of the screen (e.g., game screen).

[0058] In one embodiment, based on the first application interface in the JS layer, a target shared memory and its name are created through the C++ layer, and the name of the target shared memory is passed to the JS layer; the first application interface is the WebGL application interface; the target shared memory is used to store the state values ​​of multiple rendering states corresponding to the target object.

[0059] Specifically, the first application programming interface (API) is the WebGL API. The JS layer calls the WebGL API to the C++ layer. The C++ layer creates a WebGL object, such as WebGLRenderingContext, based on the WebGL API. The C++ layer creates a target shared memory for the WebGLRenderingContext and a name for the target shared memory (e.g., ArrayBuffer). The C++ layer returns the WebGLRenderingContext and the name of the target shared memory to the JS layer so that the JS layer can access the target shared memory.

[0060] In one embodiment, when the JS layer creates WebGL objects such as WebGLBuffer and WebGLProgram, the JS layer establishes a mapping relationship between shared memory (target shared memory) and the WebGL object; in this way, the name of the shared memory (e.g., ArrayBuffer) and the address of the shared memory in the C++ layer can be obtained through the WebGL object.

[0061] In one embodiment, when it is necessary to modify the rendering state in the WebGL state machine, the address of the shared memory corresponding to the WebGL state machine in the C++ layer is passed to the JSB layer (the mapping function corresponding to the WebGL API) in the C++ layer; then the rendering state of the WebGL state machine is modified through the C++ layer.

[0062] In one embodiment, when it is necessary to obtain the state value of the rendering state in the WebGL state machine, the name of the shared memory (target shared memory) is obtained; based on the name of the shared memory, the offset value of the rendering state is obtained from the code file of the JS layer; and based on the offset value of the rendering state, the state value of the rendering state is obtained from the shared memory through the JS layer.

[0063] In one embodiment, the structure corresponding to the shared memory is the C++ layer's representation of the shared memory between the JS and C++ layers. This structure is not created directly; it only exists after the shared memory is created when the JS layer requests the creation of a WebGL object. When the JS layer needs to create a WebGL object (e.g., WebGLRenderingContext), it calls the JSB layer. The JSB layer can determine the shared memory space based on the structure corresponding to the WebGL object to be created; it then calls the ArrayBuffer creation method provided by the JS virtual machine in the C++ layer, leveraging the ArrayBuffer's ability to be shared between the JS and C++ layers to use the ArrayBuffer as shared memory between them.

[0064] Shared memory can be reused. After a WebGL object is released, the shared memory corresponding to the WebGL object is in an unused state. At this time, the shared memory can be saved to the reuse pool. When a WebGL object is created again, it can be checked whether there is reusable shared memory in the reuse pool. If it is determined that there is reusable shared memory in the reuse pool, it can be used directly.

[0065] After creating an ArrayBuffer as shared memory in the C++ layer, the ArrayBuffer instance (the identifier of the shared memory created in the C++ layer), the starting address of the ArrayBuffer in the C++ layer, and the WebGL object to be created this time are returned to the JS layer; in this way, the JS layer can access the shared memory.

[0066] After the C++ layer calls the WebGL API, it converts the starting address of the shared memory passed from the JS layer into a structure defined in the C++ layer. The C++ layer then obtains a pointer to the structure and can easily manipulate the data it needs.

[0067] In one embodiment, based on the second application programming interface in the JS layer, the update state value of at least one of the multiple rendering states is set to the target shared memory via the C++ layer.

[0068] Specifically, the second application programming interface is the WebGL API.

[0069] According to the WebGL standard, the structure corresponding to the shared memory of WebGL objects is defined in the C++ layer, such as the structure corresponding to the shared memory of the WebGL state machine.

[0070] In the C++ layer, when creating WebGL objects such as WebGLRenderingContext, WebGLBuffer, WebGLFramebuffer, and WebGLProgram, the total length required to store the values ​​of all rendering states corresponding to that WebGL object is determined based on the structure corresponding to the shared memory for that WebGL object. The C++ layer then creates shared memory that meets this total length requirement. For example, a WebGL state machine may have multiple rendering states, two of which are ArrayBufferBinding and ProgramBinding. The state values ​​of these two states are both int types, and an int value can be 8 bytes. The shared memory corresponding to this WebGL state machine needs to be 16 bytes long to store the state values ​​of these two rendering states; that is, the total length required to store the state values ​​of these two rendering states is 16 bytes. The C++ layer creates shared memory that meets this total length requirement. The C++ layer not only creates the shared memory but also creates a name for the shared memory used by the JS layer. After the WebGL object is created, the C++ layer directly returns the identifier of the shared memory created by the C++ layer, the starting address of the shared memory in the C++ layer, and the WebGL object created by the C++ layer to the JS layer.

[0071] After the JSB (JavaScript binding) layer in the C++ layer receives the call from the WebGL API in the JS layer: (1) The C++ layer converts the starting address of the shared memory passed by the WebGL API in the JS layer into the corresponding structure defined by the C++ layer (the structure corresponding to the shared memory); one WebGL object corresponds to one shared memory. If a WebGL API is called in the JS layer, the pointer of the shared memory corresponding to the WebGL object stored in the JS layer needs to be obtained in the JS layer and sent to the C++ layer. In this way, the C++ layer can determine that the current operation is on a WebGL object among multiple WebGL objects; among them, the WebGL API is, for example, bindBuffer (WebGLBuffer buffer), and the WebGLBuffer buffer is a WebGL object; (2) The C++ layer receives the update state value of the rendering state passed by the WebGL API in the JS layer and updates the value of the rendering state in the shared memory to the update state value.

[0072] It's important to note that when the WebGL state machine updates its state values, it sends the updated rendering state value—pointed to the shared memory address by a pointer stored in the C++ layer—to the backend implemented using OpenGL ES, Metal, Vulkan, etc. The backend then uses this updated state value to call some low-level graphics APIs, updating the driver layer accordingly. The driver layer then renders the image based on the updated state value. By using the C++ layer to set state values ​​in shared memory, the JS layer can detect errors in WebGL API calls earlier, without relying on the driver layer.

[0073] In one embodiment, based on the second application programming interface in the JS layer, and through the C++ layer, the update state value of at least one of multiple rendering states is set to the target shared memory, including:

[0074] The starting address of the target shared memory and the update state value of at least one of the multiple rendering states are passed to the C++ layer through the second application interface in the JS layer.

[0075] Based on the starting address of the target shared memory, the starting address of the target shared memory is converted into a structure through the C++ layer, and the state value of at least one rendering state in the structure is updated to the updated state value.

[0076] Specifically, after the JSB (JavaScript binding) layer in the C++ layer receives the call from the WebGL API in the JS layer: (1) The C++ layer converts the starting address of the shared memory passed by the WebGL API in the JS layer into the corresponding structure defined by the C++ layer (the structure corresponding to the shared memory); one WebGL object corresponds to one shared memory. If a WebGL API is called in the JS layer, the pointer of the shared memory corresponding to the WebGL object stored in the JS layer needs to be obtained in the JS layer and sent to the C++ layer. In this way, the C++ layer can determine that the current operation is on a WebGL object among multiple WebGL objects; among them, the WebGL API is, for example, bindBuffer (WebGLBufferbuffer), and the WebGLBuffer buffer is a WebGL object; (2) The C++ layer receives the update state value of the rendering state passed by the WebGL API in the JS layer, and the C++ layer updates the value of the rendering state in the shared memory to the update state value.

[0077] In one embodiment, the target object is a WebGL object, the object set is a WebGL object set, and the second application interface is a WebGL application interface.

[0078] Specifically, the WebGL application programming interface is the WebGL API. Within the JS layer, the WebGL API can be divided into two categories: the first category consists of APIs whose logic can be implemented directly within the JS layer; the second category requires calling the JSB layer, where WebGL objects can be created.

[0079] In one embodiment, when creating a WebGLRenderingContext, the C++ layer returns a shared memory ArrayBuffer corresponding to the WebGL state machine, and the JS layer needs to create a TypedArray based on the ArrayBuffer.

[0080] When a WebGL object is created, the C++ layer returns: an ArrayBuffer, the address of the ArrayBuffer in the C++ layer, and the WebGL object. For the shared-memory ArrayBuffer corresponding to the WebGL object, a TypedArray is created to facilitate data reading.

[0081] After creating the TypedArray, a mapping is established between the WebGL object and its C++ address (the C++ address is the address of the TypedArray in the C++ layer). For example, a global JS WeakMap object is created in the JS layer, with the WebGL object as the key and the C++ address as the value; in this way, the address of the TypedArray in the C++ layer can be obtained through the WebGL object.

[0082] When the JS layer calls a function (WebGL API) that modifies the state values ​​of certain rendering states in the WebGL state machine, if the function involves passing a WebGL object, the C++ address stored in the WeakMap can be obtained from the WebGL object, and this address can be passed to the JSB layer. The C++ layer can then obtain the structure corresponding to the WebGL object (e.g., the structure corresponding to the shared memory ArrayBuffer) based on the C++ address.

[0083] When the JS layer calls a function to get the rendering state in the WebGL state machine, it does not need to call the JSB layer. It only needs to get the TypedArray corresponding to the WebGL object in WeakMap based on the WebGL object.

[0084] In one embodiment, after setting the update state value of at least one of the multiple rendering states to the target shared memory, the method further includes:

[0085] The C++ layer sends the update state value of at least one of the multiple rendering states to the driver layer.

[0086] The driver layer performs image rendering based on updated state values.

[0087] Specifically, the updated state value of the rendering state in the shared memory pointed to by the pointer (which points to the starting address of the shared memory) stored in the C++ layer is sent to the backend based on OpenGL ES, Metal, Vulkan, etc.; the backend calls the underlying graphics API according to the updated state value to update the updated state value in the driver layer; and the driver layer performs image rendering based on the updated state value.

[0088] For example, after the JSB layer receives a Draw Call command (such as drawArrays, drawElements, etc., which need to trigger the drawing pipeline), the WebGL state machine and updated state values ​​are sent to the backend through the C++ layer.

[0089] Applying the embodiments of this application has at least the following beneficial effects:

[0090] The JS layer obtains the rendering state values ​​from shared memory, improving the efficiency of the JS layer in obtaining the rendering state of WebGL objects. The JS layer sets the state values ​​in shared memory through the C++ layer, enabling earlier detection of errors in WebGL API calls without relying on the driver layer. This reduces the number of layers traversed when obtaining rendering state values, avoids some context switching and secondary parameter encapsulation, and improves the performance of WebGL API calls. Thus, the rendering efficiency of the image is improved.

[0091] To better understand the methods provided in the embodiments of this application, the solutions of the embodiments of this application will be further explained below with reference to specific application scenarios.

[0092] In a specific application scenario, such as a game rendering scenario, see [link to example]. Figure 2 This illustrates the processing flow of a rendering method, such as... Figure 2 As shown, the rendering method provided in this application includes the following steps:

[0093] S301: The terminal uses the WebGL API in the JS layer to create shared memory and its name through the C++ layer, and then passes the name of the shared memory to the JS layer.

[0094] S302, the terminal passes the starting address of the shared memory and the update value of the rendering state to the C++ layer through the WebGL API in the JS layer.

[0095] S303, the terminal determines the target WebGL object from the WebGL object collection through the C++ layer based on the starting address of the shared memory, and updates the state value of the rendering state in the shared memory corresponding to the target WebGL object to the updated state value.

[0096] Specifically, the C++ layer converts the starting address of the shared memory passed from the WebGL API in the JS layer into a corresponding C++-defined structure (the structure corresponding to the shared memory). One WebGL object corresponds to one shared memory. If a WebGL API is called in the JS layer, the pointer to the shared memory corresponding to the WebGL object stored in the JS layer needs to be obtained in the JS layer and sent to the C++ layer. In this way, the C++ layer can determine that the WebGL object being operated on is the target WebGL object in the WebGL object collection. Among them, the WebGL API is, for example, bindBuffer(WebGLBuffer buffer), and the WebGLBuffer buffer is the target WebGL object. The C++ layer receives the update status value of the rendering state passed from the WebGL API in the JS layer and updates the value of the rendering state in the shared memory to the update status value.

[0097] S304: The terminal sends the updated status value in shared memory to the backend through the C++ layer.

[0098] Specifically, the backend can be implemented based on OpenGL ES, Metal, Vulkan, etc.

[0099] S305: Based on the updated status value, the backend updates the status value in the driver layer by calling the underlying graphics API.

[0100] S306: The terminal renders the game screen based on the updated state value through the driver layer, obtains the rendered game screen, and displays the rendered game screen.

[0101] Specifically, the driver layer renders game visuals using hardware (such as a GPU, Graphics Processing Unit) based on updated state values.

[0102] Applying the embodiments of this application has at least the following beneficial effects:

[0103] The C++ layer obtains the updated rendering state value from shared memory, which improves the efficiency of obtaining the updated rendering state value, reduces the number of layers traversed when obtaining the updated rendering state value, avoids some context switching and secondary encapsulation of parameters, improves the performance of WebGL API calls, and thus improves the rendering efficiency of game screens.

[0104] This application also provides a rendering apparatus, the structural schematic diagram of which is shown below. Figure 3As shown, the rendering device 40 includes a first processing module 401, a second processing module 402, and a third processing module 403.

[0105] The first processing module 401 is used to determine the structure corresponding to the target shared memory through the C++ layer based on the multiple rendering states corresponding to the target object. The structure is used to represent the data structure of the target shared memory.

[0106] The second processing module 402 is used to generate an offset value for each of the multiple rendering states based on the structure and through a preset script. The offset value of each rendering state is used to characterize the position of each rendering state in the target shared memory.

[0107] The third processing module 403 is used to obtain the state value of each rendering state from the target shared memory through the JS layer based on the offset value of each rendering state. The state value of each rendering state is used for screen rendering.

[0108] In one embodiment, the first processing module 401 is further configured to:

[0109] Based on the first application programming interface (API) in the JS layer, a target shared memory and its name are created through the C++ layer, and the name of the target shared memory is passed to the JS layer; the first API is the WebGL API; the target shared memory is used to store the state values ​​of multiple rendering states corresponding to the target object.

[0110] In one embodiment, the second processing module 402 is further configured to:

[0111] Based on the second application interface in the JS layer, the update state value of at least one of the multiple rendering states is set to the target shared memory through the C++ layer.

[0112] In one embodiment, the second processing module 402 is specifically used for:

[0113] The starting address of the target shared memory and the update state value of at least one of the multiple rendering states are passed to the C++ layer through the second application interface in the JS layer.

[0114] Based on the starting address of the target shared memory, the starting address of the target shared memory is converted into a structure through the C++ layer, and the state value of at least one rendering state in the structure is updated to the updated state value.

[0115] In one embodiment, the target object is a WebGL object, the object set is a WebGL object set, and the second application interface is a WebGL application interface.

[0116] In one embodiment, the second processing module 402 is further configured to:

[0117] The C++ layer sends the update state value of at least one of the multiple rendering states to the driver layer.

[0118] The driver layer performs image rendering based on updated state values.

[0119] Applying the embodiments of this application has at least the following beneficial effects:

[0120] Based on multiple rendering states corresponding to the target object, a C++ layer determines the structure corresponding to the target shared memory. This structure represents the data structure of the target shared memory. Based on the structure, a preset script generates the offset value of each rendering state. This offset value represents the position of each rendering state in the target shared memory. Based on the offset value of each rendering state, a JS layer retrieves the state value of each rendering state from the target shared memory. This state value is used for rendering. In this way, the JS layer retrieves the state value of the rendering state from the shared memory, improving the efficiency of the JS layer in obtaining the rendering state of the target object (e.g., a WebGL object), thereby improving the rendering efficiency of the screen (e.g., game screen).

[0121] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 4 As shown, Figure 4 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0122] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0123] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0124] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0125] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0126] Electronic devices include, but are not limited to, terminals.

[0127] Applying the embodiments of this application has at least the following beneficial effects:

[0128] Based on multiple rendering states corresponding to the target object, a C++ layer determines the structure corresponding to the target shared memory. This structure represents the data structure of the target shared memory. Based on the structure, a preset script generates the offset value of each rendering state. This offset value represents the position of each rendering state in the target shared memory. Based on the offset value of each rendering state, a JS layer retrieves the state value of each rendering state from the target shared memory. This state value is used for rendering. In this way, the JS layer retrieves the state value of the rendering state from the shared memory, improving the efficiency of the JS layer in obtaining the rendering state of the target object (e.g., a WebGL object), thereby improving the rendering efficiency of the screen (e.g., game screen).

[0129] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0131] Based on the same principles as the methods provided in the embodiments of this application, the embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in any of the optional embodiments of this application described above.

[0132] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0133] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A rendering method, characterized in that, include: Based on multiple rendering states corresponding to the target object, the structure corresponding to the target shared memory is determined through the C++ layer. The structure is used to represent the data structure of the target shared memory. Based on the structure, an offset value for each of the multiple rendering states is generated using a preset script. The offset value for each rendering state is used to characterize the position of each rendering state in the target shared memory. Based on the offset value of each rendering state, the state value of each rendering state is obtained from the target shared memory through the JS layer, and the state value of each rendering state is used for screen rendering; Based on the second application interface in the JS layer, the update state value of at least one of the multiple rendering states is set to the target shared memory through the C++ layer; The step of setting the update state value of at least one of the multiple rendering states to the target shared memory through the C++ layer, based on the second application programming interface in the JS layer, includes: The starting address of the target shared memory and the update status value of at least one of the multiple rendering states are passed to the C++ layer through the second application interface in the JS layer. Based on the starting address of the target shared memory, the starting address of the target shared memory is converted into a structure through the C++ layer, and the state value of at least one rendering state in the structure is updated to the updated state value.

2. The method according to claim 1, characterized in that, Also includes: Based on the first application programming interface (API) in the JS layer, the target shared memory and its name are created through the C++ layer, and the name of the target shared memory is passed to the JS layer; the first API is a WebGL API; the target shared memory is used to store the state values ​​of multiple rendering states corresponding to the target object.

3. The method according to claim 1, characterized in that, The target object is a WebGL object, the set of target objects is a set of WebGL objects, and the second application interface is a WebGL application interface.

4. The method according to claim 1, characterized in that, After setting the update state value of at least one of the plurality of rendering states into the target shared memory, the method further includes: The C++ layer sends the update status value of at least one of the multiple rendering states to the driver layer. The driver layer performs image rendering based on the updated state value.

5. A rendering apparatus, characterized in that, include: The first processing module is used to determine the structure corresponding to the target shared memory through the C++ layer based on multiple rendering states corresponding to the target object. The structure is used to represent the data structure of the target shared memory. The second processing module is used to generate an offset value for each of the multiple rendering states based on the structure and through a preset script. The offset value of each rendering state is used to characterize the position of each rendering state in the target shared memory. The third processing module is used to obtain the state value of each rendering state from the target shared memory through the JS layer based on the offset value of each rendering state, and the state value of each rendering state is used for screen rendering. The second processing module is further configured to: Based on the second application interface in the JS layer, the update state value of at least one of the multiple rendering states is set to the target shared memory through the C++ layer; The second processing module is specifically used for: The starting address of the target shared memory and the update status value of at least one of the multiple rendering states are passed to the C++ layer through the second application interface in the JS layer. Based on the starting address of the target shared memory, the starting address of the target shared memory is converted into a structure through the C++ layer, and the state value of at least one rendering state in the structure is updated to the updated state value.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-4.

Images