WO2025227968A1 - Application texture rendering method and apparatus, and electronic device, computer-readable storage medium and computer program product - Google Patents

Abstract

Provided in the present application are an application texture rendering method and apparatus, and an electronic device, a computer-readable storage medium and a computer program product. The method comprises: acquiring a target application texture resource and placeholder data of a target application, and sending the placeholder data to a second electronic device; according to a plurality of candidate compression formats, respectively compressing the target application texture resource into a plurality of candidate compressed texture resources; receiving a resource request sent by the second electronic device, wherein the resource request is sent by the second electronic device after acquiring the placeholder data, and the resource request is used for requesting a target compressed texture resource, the target compressed texture resource being obtained by using a target compression format to compress the target application texture resource; and if the target compression format is one of the plurality of candidate compression formats, acquiring the target compressed texture resource from among the plurality of candidate compressed texture resources, and sending the target compressed texture resource to the second electronic device.

Description

Applications of texture rendering methods, apparatuses, electronic devices, computer-readable storage media, and computer program products

Cross-references to related applications

This application is based on Chinese Patent Application No. 202410517067.6, filed on April 28, 2024, and claims priority to that Chinese Patent Application, the entire contents of which are incorporated herein by reference.

Technical Field

This application relates to the field of image rendering, and in particular to an applied texture rendering method, apparatus, electronic device, computer-readable storage medium, and computer program product.

Background Technology

Currently, in applications such as video games, as users progress through different stages of the application, texture rendering is required based on the textures of the displayed objects at each stage to obtain the displayed application screen. Texture reflects the surface structure and arrangement properties of an object, exhibiting slow or periodic changes. Simply put, texture is the pattern of the displayed object, such as the skin of a game character or the pattern on a sword.

Different devices use different texture compression formats. If the compression format of the application's textures is set at the factory to be different from the compression format supported by the device, the compressed textures of the application will not be rendered well, and problems will occur. If compressed textures based on various compression formats are sent to the device in advance, it will occupy the device's storage space.

Summary of the Invention

This application provides an application texture rendering method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the universality of application texture rendering on terminals that support different compression formats and reduce the occupation of terminal storage space.

According to one aspect of the embodiments of this application, an application texture rendering method is provided, the method being executed by a first electronic device, the method comprising:

Obtain the target application texture resources and placeholder data of the target application, and send the placeholder data to the second electronic device;

The target application texture resources are compressed into multiple candidate compressed texture resources according to multiple candidate compression formats;

The system receives a resource request sent by the second electronic device. The resource request is sent by the second electronic device after it obtains the placeholder data. The request is for requesting a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format.

If the target compression format belongs to the plurality of candidate compression formats, the target compressed texture resource is obtained from the plurality of candidate compressed texture resources, and the target compressed texture resource is sent to the second electronic device;

The target compressed texture resource is used for rendering the target application by the second electronic device.

According to one aspect of the embodiments of this application, an application texture rendering apparatus is provided, the apparatus comprising:

The first sending unit is configured to acquire the target application texture resources and placeholder data of the target application, and send the placeholder data to the second electronic device;

The compression unit is configured to compress the target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats;

The second sending unit is configured to receive a resource request sent by the second electronic device. The resource request is sent by the second electronic device after obtaining the placeholder data, and is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format. If the target compression format belongs to the plurality of candidate compression formats, the unit obtains the target compressed texture resource from the plurality of candidate compressed texture resources and sends the target compressed texture resource to the second electronic device. The target compressed texture resource is used by the second electronic device to render the target application.

According to one aspect of the embodiments of this application, an application texture rendering method is provided, the method being executed by a second electronic device, the method comprising:

In response to receiving placeholder data of the target application sent from the first electronic device, the target compression format supported by the second electronic device is determined;

Send a resource request to the first electronic device. The resource request is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format.

Receive the target compressed texture resource from the first electronic device, and render the target application based on the target compressed texture resource;

When the first electronic device sends the placeholder data of the target application, it also compresses the acquired target application texture resources into multiple candidate compressed texture resources according to multiple candidate compression formats; the multiple candidate compression formats include the target compression format, and the multiple candidate compressed texture resources include the target compressed texture resource.

According to one aspect of the embodiments of this application, an application texture rendering apparatus is provided, the apparatus comprising:

The determining unit is configured to determine the target compression format supported by the second electronic device in response to receiving placeholder data of the target application sent from the first electronic device;

The third sending unit is configured to send a resource request to the first electronic device. The resource request is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing a target application texture resource using a target compression format.

The second receiving unit is configured to receive the target compressed texture resource from the first electronic device and render the target application based on the target compressed texture resource; wherein, when the first electronic device sends the placeholder data of the target application, it also compresses the acquired target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats; the multiple candidate compression formats include the target compression format, and the multiple candidate compressed texture resources include the target compressed texture resource.

According to one aspect of the embodiments of this application, an electronic device is provided, including:

Memory, configured to store computer-executable instructions or computer programs;

When a processor is configured to execute computer-executable instructions or computer programs stored in the memory, it implements the application texture rendering method as described above.

According to one aspect of the embodiments of this application, the computer program product includes computer-executable instructions or a computer program, and the processor executes the computer-executable instructions or the computer program to implement the application texture rendering method as described above.

According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer executable instructions or a computer program, wherein a processor executes the computer executable instructions or computer program, causing the computer device to perform the application texture rendering method as described above.

In this embodiment, during factory configuration of the first electronic device, the target application texture resources and placeholder data of the target application are acquired, and the target application texture resources are compressed into multiple candidate compressed texture resources according to multiple candidate compression formats and stored. Then, the placeholder data is sent to the user's second electronic device. Thus, the second electronic device does not receive any compressed texture resources of any compression format. When the second electronic device actually renders the application, it can acquire the placeholder data, determine the target compression format it supports, and send a resource request to the first electronic device. Based on the resource request, it requests the target compressed texture resources obtained by compressing the target application texture resources using the target compression format. Since the first electronic device has pre-stored candidate compressed texture resources of various candidate compression formats, upon receiving the resource request, it can obtain the target compressed texture resources from the candidate compressed texture resources and send them to the second electronic device, thereby enabling the second electronic device to render the target application using the target compressed texture resources. In this process, regardless of the compression format supported by the second electronic device, since it has not received the actual compressed texture resource, after obtaining the placeholder data, it requests the target compressed texture resource of the target compression format from the first electronic device to obtain the target compressed texture resource for rendering. This improves the universality of application texture rendering on terminals supporting different compression formats and increases the rendering efficiency of application textures. Simultaneously, because the placeholder data is much smaller than the original compressed texture resource, it significantly reduces the amount of storage space occupied on the terminal, minimizing wasted space resources.

Other features and advantages of the embodiments of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by means of the embodiments of this application. The objects and other advantages of the embodiments of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims, and drawings.

Attached Figure Description

The accompanying drawings are used to provide a further understanding of the technical solutions of the embodiments of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of the embodiments of this application.

Figure 1 is a system architecture diagram of the application texture rendering method provided in the embodiments of this application;

Figure 2 is a schematic diagram of a terminal replacement scenario provided in an embodiment of this application;

Figure 3 is a flowchart illustrating the application texture rendering method provided in an embodiment of this application;

Figure 4 is a flowchart of the application texture rendering method provided in an embodiment of this application;

Figure 5 is a schematic diagram of the initial resources and updated resource packages provided in the embodiments of this application;

Figure 6 is a schematic diagram of the process for storing multiple candidate compressed texture resources provided in an embodiment of this application;

Figure 7 is a schematic diagram of the compression process provided in an embodiment of this application;

Figure 8 is a flowchart illustrating the application texture rendering method provided in an embodiment of this application;

Figure 9 is a schematic diagram of a resource request provided in an embodiment of this application;

Figure 10 is a schematic diagram of the process of sending a resource request provided in an embodiment of this application;

Figure 11 is a flowchart illustrating the application texture rendering method provided in an embodiment of this application;

Figure 12 is a schematic diagram of the process for determining the target compressed texture resource provided in an embodiment of this application;

Figure 13 is a flowchart illustrating the application texture rendering method provided in an embodiment of this application;

Figure 14 is a flowchart illustrating the application texture rendering method provided in an embodiment of this application;

Figure 15 is a schematic diagram of the structure of an application texture rendering device 1500 for a first electronic device provided in an embodiment of this application;

Figure 16 is a schematic diagram of the structure of an application texture rendering device 1600 for a second electronic device provided in an embodiment of this application;

Figure 17 is a partial structural block diagram of the second electronic device using the texture rendering method provided in an embodiment of this application;

Figure 18 is a structural block diagram of a portion of the first electronic device for applying the texture rendering method provided in an embodiment of this application.

Detailed Implementation

To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this 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 only used to explain the embodiments of this application and are not intended to limit the embodiments of this application.

Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

Application: This typically refers to a software program or system used to perform a specific task or provide a specific function. Applications can be of various types, including mobile applications, desktop applications, web applications, etc. Web applications include WebGL games.

WebGL games are games developed using WebGL (Web Graphics Library) technology. They refer to games that run on a canvas element and conform to HTML5 standards, with rendering technology based on WebGL. Texture resources are often required for rendering WebGL games.

Texture resources, also known as material mapping resources, refer to bitmap resources that can be wrapped around the surface of 3D models or sprites. Common texture resources are primarily in PNG and JPEG formats. Texture compression can be used to reduce the storage size of texture resources.

Texture compression: An image compression technique specifically designed for storing texture map resources in computer graphics rendering systems. This compression algorithm optimizes storage size and random access. Common texture compression formats include Ericsson Texture Compression (ETC or Ericsson Texture Compression 2, ETC2), Adaptive Scalable Texture Compression (ASTC), PowerVR Texture Compression (PVRTC), DXT1, and DXT5.

Unity Mini-Games: Specifically refers to games developed using the Unity platform and run on mini-game platforms. The Unity platform can be used to develop various types of games and can output them in WebGL format, thus creating WebGL games.

AB package: full name AssetBundle, refers to the game resource archive file provided by the Unity platform, which can store non-code resources (such as models, textures, prefabs, scenes and media files) needed for game runtime.

First package resources: Specifically refers to the resource files stored in the first scene when exporting WebGL game resources from the Unity platform. They end with the unityweb suffix by default and are the resource files that are loaded first when the Unity mini-game starts. The first package resources include the resource content of the first scene and the resources of the attached AB packages.

Unity resource packs: a collective term for resources in AB packs and the first pack.

In related technologies, the Unity platform already provides game developers with texture resource compression capabilities. Typically, Unity mini-games are released independently for each device, meaning separate game clients are exported for iOS, Android, and Windows. By configuring the texture resource formats supported by each device differently, when exporting game resources to the Unity asset package, the texture resources are converted according to the format types supported by the device. The resulting compressed texture resources, already in the corresponding compressed texture format, are then written into the Unity asset package. This allows for efficient texture rendering during game runtime.

Currently, there is a lack of technology that enables applications (such as the aforementioned Unity game) to render correctly on various terminals that support different compression formats. If compressed textures based on various compression formats are pre-loaded into the asset package, it will consume terminal storage space.

The embodiments of this application can improve the universality of application texture rendering on terminals that support different compression formats and improve the rendering efficiency of application textures; at the same time, it reduces the occupation of terminal storage space and reduces the waste of space resources.

System architecture and scenario description used in the embodiments of this application

Figure 1 is a system architecture diagram of the texture rendering method provided in the embodiments of this application. It includes: terminals 110-1, 110-2 and 110-3, Internet 120, gateway 130, and server 140.

Terminals 110-1, 110-2, and 110-3 are devices used by the objects to render target applications (such as the WebGL game and Unity mini-game mentioned above). They include various forms such as desktop computers, laptops, personal digital assistants (PDAs), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. For example, multiple devices can be connected via a local area network, sharing a single display device to work collaboratively, forming a single terminal. Terminals 110-1, 110-2, and 110-3 can also communicate with the Internet 120 via wired or wireless means to exchange data.

Gateway 130, also known as an internetwork connector or protocol converter, is a computer system or device that enables network interconnection at the transport layer and acts as a translator. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateway 130 also provides filtering and security functions. Messages sent from terminals 110-1, 110-2, and 110-3 to server 140 are forwarded to the corresponding server 140 via gateway 130. Similarly, messages sent from server 140 to terminals 110-1, 110-2, and 110-3 are also forwarded to the corresponding terminals 110-1, 110-2, and 110-3 via gateway 130.

Server 140 refers to a computer system capable of providing certain services to terminals 110-1, 110-2, and 110-3 (such as providing application containers for target applications, providing compressed texture resources of various formats to terminals 110-1, 110-2, and 110-3, etc.). Compared to terminals 110-1, 110-2, and 110-3, server 140 has higher requirements in terms of stability, security, and performance. Server 140 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Server 140 can also communicate with the Internet 120 via wired or wireless means to exchange data.

The embodiments of this application can be applied in various scenarios, such as Figure 2, which is a schematic diagram of a scenario of replacing a terminal provided by the embodiments of this application.

Based on Figure 2, after an object has used a certain terminal (referred to as the first terminal) for an extended period, it may need to be switched to a new terminal (referred to as the second terminal). When switching terminals, it is often necessary to import the data of various applications from the first terminal (such as application containers, object registration information, application runtime data, etc.) to the second terminal to preserve the usage records of each application. Because the first and second terminals differ in terminal type, they support different texture compression formats. Consequently, when running applications on the second terminal, compressed texture resources cannot be parsed, affecting the rendering of application texture resources. Therefore, there is a need to ensure that the rendering of application texture resources is not affected when the object switches from the first terminal to the second terminal.

As shown in Figure 2, the server stores texture compression resources for different applications under various texture compression formats. Application A includes candidate compressed texture resources W1 (for candidate compression format Y1), W2 (for candidate compression format Y2), and W3 (for candidate compression format Y3). Application B is similar to Application A, also including texture compression resources under various compression formats, which will not be elaborated further. On the first terminal, the application container does not contain specific texture resources, but rather placeholder data. When the object runs Application A using the first terminal, since the first terminal supports the target compression format Y1, upon recognizing the placeholder data, the first terminal can request candidate compressed texture resources corresponding to the target compression format Y1 from the server. Thus, the first terminal uses candidate compressed texture resource Y1 to render the target application. After the object changes the first terminal to a second terminal, the second terminal has the same resource package as the first terminal. When the object runs application A using a second terminal, since the second terminal supports the target compression format Y2, when the second terminal identifies the placeholder data in the resource package, it can request candidate compressed texture resources corresponding to the target compression format Y2 from the server. Thus, the second terminal uses the candidate compressed texture resource Y2 to render the target application. Therefore, when the object changes from the first terminal to the second terminal, it does not need to re-download the application container corresponding to the application on the second terminal or re-download the resource package (if the second terminal re-downloads, it may cause the loss of the usage records generated by the first terminal), nor will it cause rendering failure due to the compression format supported by the second terminal being different from that supported by the first terminal. The second terminal can adaptively download the required compressed texture resources when rendering the application, ensuring normal texture resource rendering while avoiding the loss of application usage records.

Thus, since the server pre-stores candidate compressed texture resources in various compression formats, it can retrieve the target compressed texture resource from these and send it to the terminal for rendering of the target application. In this process, regardless of the compression format supported by the terminal, since the resource package does not contain a specific compressed texture resource but uses placeholder data, the target compressed texture resource can be obtained by requesting it from the server, thus enabling rendering. This improves the universality of application texture rendering on terminals supporting different compression formats and increases the rendering efficiency of application textures. Simultaneously, because the placeholder data is much smaller than the original compressed texture resource, it significantly reduces the amount of storage space occupied on the terminal, minimizing wasted space resources.

General Description of Embodiments in this Application

According to one embodiment of this application, an application texture rendering method is provided.

The application texture rendering method refers to a method for rendering texture resources required for running an application. The application texture rendering method in the embodiments of this application is executed on a terminal and/or a server.

As shown in Figure 3, Figure 3 is a flowchart illustrating the application texture rendering method provided in this embodiment of the application. Based on Figure 3, the application texture rendering method (executed by a first electronic device such as a server) provided in this embodiment of the application includes:

Step 310: Obtain the target application texture resources and placeholder data of the target application, and send the placeholder data to the second electronic device;

Step 320: Compress the target application texture resources into multiple candidate compressed texture resources according to multiple candidate compression formats;

Step 330: Receive a resource request sent by the second electronic device. The resource request is sent by the second electronic device after obtaining the placeholder data, and is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format. If the target compression format belongs to multiple candidate compression formats, obtain the target compressed texture resource from the multiple candidate compressed texture resources and send the target compressed texture resource to the second electronic device. The target compressed texture resource is used by the second electronic device for rendering the target application.

The advantage of the embodiment of steps 310-330 is that the target application texture resource is compressed into multiple candidate compressed texture resources and stored, and placeholder data is sent to the second electronic device. In this way, the second electronic device, if the terminal does not receive any compressed texture resources of any compressed format, can retrieve the target compressed texture resource from the candidate compressed texture resources of various compressed formats when the second electronic device sends a request to the first electronic device for the target compressed texture resource in the target compressed format, since the first electronic device has pre-stored candidate compressed texture resources of various compressed formats. This target compressed texture resource can then be sent to the second electronic device for rendering of the target application. Thus, this embodiment of the application can improve the universality of application texture rendering on terminals supporting different compression formats and improve the rendering efficiency of application textures; at the same time, since the placeholder data is much smaller than the original compressed texture resource, it can greatly reduce the occupation of terminal storage space and reduce the waste of space resources.

The following describes in detail steps 310 to 330, the steps between steps 310 and 330, and the steps following step 330.

Detailed description of step 310

In some embodiments, in step 310, the process of obtaining the target application texture resources of the target application is to obtain the initial resource package of the target application, which includes the initial compressed texture resources of the target application in the initial compressed format; and to decompress the initial compressed texture resources to obtain the target application texture resources.

In this context, the target application refers to an application capable of performing a specific task or providing a specific function. For example, referring to the above, applications include web applications, and web applications include WebGL games; therefore, the target application could refer to a WebGL game. The initial compressed texture resource refers to the target application's texture resource after compression. The target application texture resource refers to the texture resource used to render the application. For instance, when running the target application on a terminal, the initial compressed texture resource needs to be decompressed into the target application texture resource, and then the target application texture resource is used to render the target application.

It's important to note that developers need to design an application container when designing an application. The application container is used to store data related to the application's operation. It includes an application package and an initial resource package. The application package controls the application's execution process. The initial resource package provides resources used for rendering during application execution. The initial resource package may include target application texture resources. To reduce the storage size of the initial resource package, the target application texture resources can be compressed using a compression algorithm corresponding to the initial compression format to obtain initially compressed texture resources, thus ensuring that the initial resource package includes initially compressed texture resources in the target application's initial compression format. In some embodiments, when the application runs on the terminal, corresponding operations can be performed through the application package, and the initial resource package can be invoked for rendering.

In some embodiments, the initial resource package of the target application is obtained in ways including but not limited to the following:

(1) In response to the developer designing and publishing the target application on the Unity platform, the first electronic device obtains the initial application container of the target application from the Unity platform, the initial application container including the initial resource package.

(2) In response to an object request, the first electronic device transmits the target application in the first terminal to the second terminal and obtains the initial application container of the target application from the first terminal. The initial application container includes an initial resource package.

By applying the above embodiments, the target application's texture resources are obtained by decompressing the initial resource package of the target application. In this way, by packaging and compressing the target application's texture resources, the size of the application installation package is reduced, memory usage is optimized, and resource management is also facilitated.

In some embodiments, as described above, the process of obtaining the target application texture resources of the target application is to obtain the initial resource package of the target application, which includes the initial compressed texture resources of the target application in the initial compression format; and to decompress the initial compressed texture resources to obtain the target application texture resources.

Based on this, referring to Figure 4, which is a flowchart of the application texture rendering method provided in the embodiment of this application, step 310 can be divided into: step 3101, obtaining the initial resource package of the target application, the initial resource package including the initial compressed texture resource of the target application; step 3102, decompressing the initial compressed texture resource to obtain the texture resource of the target application; step 3103, replacing the initial compressed texture resource in the initial resource package with placeholder data to obtain the updated resource package; step 3104, sending the updated resource package to the second electronic device.

In step 3102 of some embodiments, the first electronic device can decompress the initial compressed texture resource based on the compression algorithm corresponding to the compression format name to obtain the target application texture resource. The initial resource package includes not only the initial compressed texture resource but also the initial compression format name, and the first electronic device stores compression algorithms corresponding to various texture compression format names.

For example, continuing to refer to Figure 4, based on Figure 4, step 3102 includes: step 31021, obtaining the initial compression algorithm corresponding to the initial compression format name; step 31022, decompressing the initial compressed texture resource into the target application texture resource based on the initial compression algorithm.

It should be noted that the first electronic device stores a mapping table between format names and compression algorithms. Step 31021 includes: looking up the mapping table between format names and compression algorithms based on the initial compression format name to obtain the initial compression algorithm. Below is an example of a mapping table between format names and compression algorithms.

Table 1

Referring to Table 1, if the initial compression format name is ETC, the server will use the ETC algorithm as the initial compression algorithm. If the initial compression format name is ASTC, the server will use the ASTC algorithm as the initial compression algorithm. If the initial compression format name is PVRTC, the server will use the PVRTC algorithm as the initial compression algorithm. If the initial compression format name is DXT, the server will use the DXT algorithm as the initial compression algorithm.

In practice, in addition to looking up tables, other methods can be used to obtain the initial compression algorithm, and this embodiment does not impose specific limitations on this.

In step 31022 of some embodiments, the initial compressed texture resource can be decompressed based on the decompression function or decompression tool corresponding to the initial compression algorithm to obtain the target application texture resource. Specifically, when decompressing the initial compressed texture resource, the decompression process depends on the compression algorithm and format used. For example, the following are some common texture compression formats and decompression methods: (1) ETC (Ericsson Texture Compression): ETC is a commonly used texture compression format, often used in mobile terminals. Decompressing ETC texture resources can be done using the corresponding functions provided by graphics APIs (such as OpenGL ES). (2) ASTC (Adaptive Scalable Texture Compression): ASTC is an advanced texture compression format developed by ARM, supporting multiple compression ratios and bit depths. Decompressing ASTC texture resources usually requires decoding using the corresponding functions provided by graphics APIs or libraries that support the ASTC format. (3) PVRTC (PowerVR Texture Compression): PVRTC is a texture compression format developed by Imagination Technologies, often used in iOS devices. Decompressing PVRTC texture resources requires using tools such as PVRTexTool for decoding.

By applying the above embodiments, the initial compression algorithm is first determined based on the initial compression format name, and then decompression is performed based on the initial compression algorithm, thereby improving decompression efficiency.

In step 3103 of some embodiments, the first electronic device replaces the initial compressed texture resource in the initial resource packet with placeholder data to obtain an updated resource packet. Placeholder data is typically temporary data used to replace the actual data in the data packet and does not affect the parsing of the data packet. In this embodiment, using placeholder data to replace the initial compressed texture resource allows for the obtaining of an updated resource packet, and the parsing of the updated resource packet is not affected even without the initial compressed texture resource. The placeholder data can be a texture resource name.

It should be noted that different texture resource names can be classified according to their purpose and characteristics. For example, the following are some common texture resource names: (1) Diffuse Map: used to describe the color and lighting information of an object's surface. (2) Normal Map: used to simulate the bumps and dents of an object's surface, enhance lighting effects, and improve visual realism. (3) Specular Map: used to control the intensity and position of specular reflections on an object's surface, affecting the glossiness of the material. (4) Emission Map: used to describe the luminous parts of an object's surface, enabling self-illumination effects. (5) Roughness Map: describes the roughness of an object's surface, affecting the scattering and reflection effects of light. (6) Metallic Map: describes the metallic properties of an object's surface, affecting the way light is reflected and its color. (7) Ambient Occlusion Map: describes the shadows and occlusion information of an object's surface, enhancing the realism and three-dimensionality of the scene. (8) Height Map: Describes the height information of an object's surface and is usually used to create bumpy terrain effects.

It should be noted that the methods for obtaining placeholder data include, but are not limited to, the following: (1) If the initial resource package also includes the name of the initial compressed texture resource, the name of the initial compressed texture resource can be obtained from the initial resource package to obtain the texture resource name, and the texture resource name can be determined as placeholder data. (2) If the initial resource package does not include the name of the initial compressed texture resource, the name can be identified based on the description function of the initial compressed texture resource to obtain the texture resource name, and the texture resource name can be determined as placeholder data. Among them, the description function refers to the functions mentioned above that describe the color and lighting of the object surface, the details of the concavity and convexity, the intensity and position of the specular reflection, the luminous part, the roughness, the metallic properties, the shadow and occlusion information, and the height information.

In practice, after determining the placeholder data, the process of replacing the initial compressed texture resources in the initial resource package with the placeholder data to obtain the updated resource package can include: 1. Backing up the initial compressed texture resources; 2. Copying the placeholder data into the initial resource package, overwriting the initial compressed texture resources; 3. Updating the path or link relationship between the remaining resources in the initial resource package and the placeholder data; 4. Testing the placeholder data in the initial resource package. If it can be loaded and displayed correctly, the backup is deleted, and the initial resource package is used as the updated resource package.

In some embodiments, as shown in FIG5, which is a schematic diagram of the initial resource and updated resource package provided in the embodiments of this application, the initial resource package stores multiple initial compressed texture resources, including initial compressed texture resource 01, initial compressed texture resource 02, and initial compressed texture resource 03, etc. Assuming the texture resource name of initial compressed texture resource 01 is diffuse map, the placeholder data is diffuse map. Replacing "initial compressed texture resource 01" with "diffuse map" in the initial resource package yields the updated resource package. The updated resource package stores diffuse map, initial compressed texture resource 02, and initial compressed texture resource 03. Other initial compressed texture resources, such as initial compressed texture resource 02 and initial compressed texture resource 03, can also be replaced. Since the process is similar to replacing initial compressed texture resource 01, it will not be described in detail here.

In step 3204 of some embodiments, the first electronic device sends an update resource package to the second electronic device. Specifically, if the terminal has not downloaded the target application, the first electronic device, in response to a download request for the target application sent by the second electronic device, sends the application container of the target application to the terminal; the application container includes application code and an update resource package. If the second electronic device has already downloaded the target application, the first electronic device, in response to a request to obtain the resource package of the target application sent by the second electronic device, sends the update resource package to the second electronic device.

In one embodiment, before executing step 3204, step 32041 can be executed to change the texture resource compression format field of the updated resource package to the anchor compression format, thereby obtaining a new updated resource package; then step 3204 is executed, in which case step 3204 is implemented by step 32042, that is, the new updated resource package is sent to the second electronic device. The texture resource compression format field is a field that indicates the compression format of the texture resource.

It should be noted that before the first electronic device performs data replacement, the initial resource package includes the initial compressed texture resource. In this case, the texture resource compression format field in the initial resource package is the compression format of the initial compressed texture resource (e.g., ETC format). After the first electronic device performs data replacement, the updated resource package no longer includes the initial compressed texture resource, but instead includes placeholder data, and the texture resource compression format field is updated to the anchor compression format. The anchor compression format is a specific compression format that indicates the terminal should request texture resources from the first electronic device. Since the second electronic device may not support the anchor compression format, if the second electronic device recognizes that the texture resource compression format field is the anchor compression format, it can add a mandatory constraint to the texture processing script. This mandatory constraint indicates support for the anchor compression format. The specific process of how the second electronic device adds mandatory constraints will be described below and will not be repeated here.

Understandably, if some second electronic devices do not impose mandatory constraints, they may be unable to request texture resources from the first electronic device after discovering that the updated resource package contains placeholder data instead of texture resources, thus causing texture resource rendering to fail.

By applying the above embodiments, the texture resource compression format field is changed to the anchor compression format, thereby imposing a mandatory constraint on the second electronic device. In this way, the second electronic device can support the function of requesting texture resources from the first electronic device when it recognizes the anchor compression format, so that even if there are no specific texture resources in the updated resource package, the second electronic device can still obtain texture resources from the first electronic device.

Detailed description of step 320

Referring to Figure 3, for step 320, the target application texture resource is compressed into multiple candidate compressed texture resources according to multiple candidate compression formats.

It should be noted that a candidate compression format is a data compression format used to reduce file size. A candidate compression format generally corresponds to a compression algorithm. Referring to the above, candidate compression formats can include ETC, ASTC, PVRTC, DXT, etc.

In step 320 of some embodiments, a compression algorithm corresponding to the candidate compression format can be invoked to compress the target application texture resource to obtain a candidate compressed texture resource corresponding to the candidate compression format. For example, if the candidate compression format is ETC, the ETC algorithm can be invoked to compress the target application texture resource to obtain a candidate compressed texture resource in ETC format.

In actual implementation, after executing step 320, step 3201 can also be executed to store multiple candidate compressed texture resources.

It should be noted that in step 3201 of some embodiments, a sequence number can be set for each candidate compressed texture resource, and the candidate compressed texture resource can be stored according to the candidate storage address corresponding to the sequence number and the candidate compression format. For example, a sequence number can be set for each candidate compressed texture resource according to the order of compression time. However, the sequence number cannot reflect the relevant information of the candidate compressed texture resource (such as the purpose of the candidate compressed texture resource), making it very cumbersome to find the candidate compressed texture resource (for example, when it is necessary to read a texture resource for a specific purpose, the candidate compressed texture resource must be read in order to determine whether it meets the requirements). Therefore, in one embodiment, the placeholder data that replaces the initial compressed texture resource in the aforementioned steps is used to determine the candidate storage address, and then the candidate compressed texture resource is stored. The placeholder data is the texture resource name.

In some embodiments, referring to FIG6, FIG6 is a schematic flowchart of storing multiple candidate compressed texture resources provided in the embodiments of this application. Based on FIG6, step 3201 includes: step 32011, for each candidate compression format, storing the candidate compressed texture resource according to the candidate storage address corresponding to the texture resource name and the candidate compression format.

Among them, the candidate storage address is used to characterize the storage location of the candidate compressed texture resource corresponding to the candidate compression format.

In actual implementation, step 32011 includes: obtaining a first correspondence table, which indicates the correspondence between texture resource names, candidate compression formats, and candidate storage addresses; and storing candidate compressed texture resources based on the first correspondence table. The following is an example of a first correspondence table:

Table 2

Referring to Table 2, if the texture resource name is diffuse map and the candidate compression format is ETC, then the candidate storage address is XX:XX\MEh1. The same applies to other texture resource names and candidate compression formats, and will not be elaborated further.

Thus, the advantages of using a lookup table to determine candidate storage addresses are that it is not only simple and easy to implement, but also has low processing overhead.

In actual implementation, step 32011 also includes: performing target operations on the texture resource name and candidate compression format to obtain candidate storage addresses; and storing candidate compressed texture resources according to the candidate storage addresses.

It's important to note that the target operation is a set formula or function, such as a hash function. The texture resource name and candidate compression format are input into the target operation, and the output is the candidate storage address. In one example, the texture resource name and candidate compression format are taken as input, a hash function generates a unique identifier, and this identifier is combined with the storage path to obtain the candidate storage address. This ensures that each candidate compressed texture resource has a unique storage address, and that candidate compressed texture resources can be retrieved based on their texture resource name and candidate compression format.

Thus, the method of determining candidate storage addresses through target operations is not only highly accurate, but also highly flexible as the target operations can be adjusted as needed.

In some embodiments, the texture resource name is assumed to be a diffuse map. The target application texture resource is compressed according to ETC format to obtain candidate compressed texture resource h1, with a candidate storage address of "XX:XX\MEh1"; the target application texture resource is compressed according to ASTC format to obtain candidate compressed texture resource MAh2, with a candidate storage address of "XX:XX\h2"; the target application texture resource is compressed according to PVRTC format to obtain candidate compressed texture resource h3, with a candidate storage address of "XX:XX\MPh3"; and the target application texture resource is compressed according to DXT format to obtain candidate compressed texture resource h4, with a candidate storage address of "XX:XX\MDh4". As shown in Figure 7, which is a schematic diagram of the compression process provided in this embodiment, based on Figure 7, the first electronic device stores candidate compressed texture resource h1 according to "XX:XX\MEh1"; candidate compressed texture resource h2 according to "XX:XX\MAh2"; candidate compressed texture resource h3 according to "XX:XX\MPh3"; and candidate compressed texture resource h4 according to "XX:XX\MDh4".

By applying the above embodiments and utilizing placeholder data to store candidate compressed texture resources, the efficiency of reading candidate compressed texture resources required by the second electronic device can be improved, while ensuring the storage of these resources is completed. For example, referring to the following, after the second electronic device identifies the placeholder data in the updated resource package, it can request candidate compressed texture resources from the first electronic device based on the placeholder data. Since the first electronic device happens to store these resources based on the placeholder data, the resource reading efficiency can be improved.

It should be noted that although the first electronic device stores candidate compressed texture resources of multiple candidate compression formats, if the target compression format supported by the second electronic device may not belong to any of the multiple candidate compression formats, the first electronic device will be unable to send suitable candidate compressed texture resources to the terminal.

Based on this, in one embodiment, referring to FIG6, step 3201 may further include: step 32012, storing multiple candidate compressed texture resources and target application texture resources. Thus, when the terminal subsequently requests texture resources from the server, even if the target compression format supported by the terminal is not among the multiple candidate compression formats, the server can still send the target application texture resources to the terminal, ensuring that the terminal can render the target application normally.

A detailed description of the steps performed by the second electronic device, such as a terminal, after step 320.

As shown in Figure 3, according to one embodiment of this application, the texture rendering method (executed by a second electronic device) includes:

Step 410: In response to obtaining placeholder data of the target application sent from the first electronic device, determine the target compression format supported by the second electronic device;

Step 420: Send a resource request to the first electronic device. The resource request is used to request the target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using the target compression format.

Step 430: Receive target compressed texture resources from the first electronic device and render the target application based on the target compressed texture resources.

In steps 410 to 430 above, regardless of the compression format supported by the second electronic device, since the second electronic device does not receive the specific compressed texture resource but uses placeholder data instead, it obtains the target compressed texture resource by requesting the target compressed texture resource of the target compression format from the first electronic device, and then performs rendering. In this way, the universality of application texture rendering on terminals that support different compression formats can be improved, and the rendering efficiency of application textures can be improved. At the same time, since the placeholder data is much smaller than the original compressed texture resource, the occupation of terminal storage space can be greatly reduced, and the waste of space resources can be reduced.

In some embodiments, step 410 specifically includes receiving an application container of a target application from a first electronic device, the application container including an updated resource package, wherein the updated resource package is obtained by the first electronic device replacing the initial compressed texture resources in the initial resource package of the target application with placeholder data; in response to identifying that the updated resource package contains placeholder data, determining a target compression format supported by a second electronic device.

It should be noted that the first electronic device stores application containers for multiple candidate applications. The second electronic device, in response to a download operation of the target application, sends a resource download request to the first electronic device to download the resource package of the target application. The multiple candidate applications include the target application. Based on the download request from the second electronic device, the first electronic device sends the application container of the target application to the second electronic device.

It should be noted that, on the first electronic device side, the application container of the target application may include the initial resource package, but after the first electronic device executes step 3101, the initial resource package has been replaced with the updated resource package, that is, the application container of the target application sent by the first electronic device to the second electronic device includes the updated resource package.

The updated resource package is obtained by the first electronic device replacing the initial compressed texture resources in the target application's initial resource package with placeholder data. As discussed above, the first electronic device can send an application container containing only the updated resource package to the second electronic device, or it can send an application container containing both the application package and the updated resource package to the second electronic device.

In step 410 of some embodiments, the second electronic device may need to call texture resources for rendering when running the target application. The second electronic device then parses the updated resource package to extract texture resources. Since the updated resource package no longer contains actual texture resources but only placeholder data, the second electronic device cannot extract texture resources from it. Therefore, in response to recognizing the placeholder data in the resource package, the second electronic device determines the target compression format it supports, and requests compressed texture resources that the first electronic device needs to render the target application and that the second electronic device can parse, based on the target compression format.

In some embodiments, referring to FIG8, which is a flowchart of the application texture rendering method provided in the embodiments of this application, step 410 includes: step 4101, running the application package through the main logic, and in response to identifying that the application package contains placeholder data during the running process, querying the target compression format supported by the second electronic device through the texture processing script.

The main logic refers to the process/thread on the terminal that runs the target application. Texture processing scripts refer to the scripts used to render the target application. In one example, the rendering of the target application (WebGL game) exported from the Unity platform is all based on the WebGL API. Since the WebGL API is called using JavaScript, the application package exported from the Unity platform ultimately needs to implement basic calls using JavaScript.

Thus, this embodiment identifies placeholder data during operation through the main logic and queries the texture processing script for the target compression format through the main logic, thereby improving query efficiency.

It should be noted that the target application's runtime main logic can query the JavaScript script layer for a list of compression formats supported by the current terminal (GPU) to determine the target compression format. Because the server performs data replacement processing on the initial resource package, the "placeholder data" is not guaranteed to be supported on all terminals. Therefore, in one embodiment, when querying the list of supported compression formats, a mandatory constraint is added to the texture processing script to ensure that the "placeholder data" is always rendered by the current terminal.

In a specific implementation of this embodiment, referring to Figure 8, step 4101 includes:

Step 41011: Run the application package through the main logic. In response to the identification during the running process that the application package contains placeholder data and the texture resource compression format field in the application package is anchor compression format, add a mandatory constraint to the texture processing script. The mandatory constraint indicates that the anchor compression format is supported.

Step 41012: Send a query request to the texture processing script; wherein, the query request is used for the texture processing script to verify support for the anchor compression format based on the mandatory constraint, and to query the target compression formats supported by the second electronic device other than the anchor compression format.

In step 41011, the anchor compression format is a specific compression format that indicates the second electronic device should request texture resources from the first electronic device. Since the second electronic device may not support the anchor compression format, this embodiment adds a mandatory constraint to the texture processing script through the main logic, and this mandatory constraint indicates support for the anchor compression format. The mandatory constraint is a processing script that requires support for the anchor compression format.

In step 41012, since mandatory constraints have been added to the texture processing script, when the second electronic device sends a query request to the texture processing script, it can verify the support for the anchor compression format and obtain the supported target compression formats other than the anchor compression format.

Thus, the advantage of the above embodiment of adding mandatory constraints to the texture processing script is that it can ensure that any terminal can support the anchor compression format, thereby improving the effectiveness of texture resource rendering.

In step 420 of some embodiments, a resource request, namely a request for a target compressed texture resource in a target compression format, is sent to a first electronic device. This resource request may include the source address of the second electronic device, the destination address of the first electronic device, the texture resource name, and the target compression format. In one example, as shown in FIG9, which is a schematic diagram of a resource request provided in an embodiment of this application, the resource request for a target compressed texture resource in a target compression format includes the target compression format, the texture resource name, the source address, and the destination address, causing the first electronic device to send the target compressed texture resource to the second electronic device according to the target compression format and texture resource name in the resource request. The resource request may also include the source address of the second electronic device, the destination address of the first electronic device, and a target storage address corresponding to the texture resource name and the target compression format, causing the first electronic device to send the target compressed texture resource to the second electronic device according to the target storage address in the request.

In one embodiment, referring to FIG10, which is a schematic flowchart of sending a resource request provided in an embodiment of this application, step 420 includes:

Step 4201: Insert a hijacking statement before the rendering function used to render the target application;

Step 4202: Execute the hijacking statement, which is used to replace the placeholder data in the application package with the target compression format and send a resource request to the first electronic device based on the target compression format in the application package.

It should be noted that hijacking statements refer to modifying the control flow of a computer program to execute additional operations or code. Hijacking statements are typically implemented by injecting code or modifying the program's instruction flow. Common hijacking statements include jump instructions, function calls, and variable modifications. This embodiment mainly utilizes hijacking statements to control the second electronic device to request target compressed texture resources from the first electronic device before executing the rendering function.

In practical implementation, hijacking statements can be inserted before the rendering function used to render the target application in the following ways: (1) Modify the rendering loop: Add custom code directly to the rendering loop so that this code is executed before each rendering; (2) Use rendering pipeline hooks: Insert hooks at specific stages of the rendering pipeline, such as using the ID3D11 Device Context hook in DirectX or the framebuffer object hook in OpenGL; (3) Wrap the rendering function: Create a new rendering function in which custom code is executed before or after the original rendering function is called; (4) Use middleware or frameworks: Utilize the interfaces provided by existing middleware or frameworks, where the interfaces allow the insertion of custom code into the rendering process, etc. This application does not limit the scope of these methods.

Since the aforementioned steps have already added mandatory constraints to the texture processing script, the format within the updated resource package will definitely be "supported" by the current second electronic device. Therefore, when the target application uses texture resources for rendering, the rendering function for the target application will be executed. For example, assuming the target application is a WebGL game, the WebGLRenderingContext.compressedTexSubImage2D rendering function will ultimately be executed. By inserting a hijacking statement before the rendering function for the target application and then executing the hijacking, placeholder data in the resource package can be replaced with the target compression format, and a request for the target compressed texture resource can be sent to the first electronic device based on the target compression format in the resource package. After the second electronic device reads the target compressed texture resource from the first electronic device into its runtime memory space, it can upload the target compressed texture resource to the GPU of the second electronic device to complete the rendering of the desired texture resource. After successful upload to the GPU, the second electronic device will immediately release the runtime memory space occupied by the target compressed texture resource.

Thus, by using hijacking statements before the execution of the rendering function, the second electronic device can obtain the target compressed texture resources from the first electronic device, thereby improving the effectiveness of the target application rendering.

In actual implementation, in step 420, the second electronic device sends a request for the target compressed texture resource to the first electronic device. Therefore, in step 330, after receiving the request for the target compressed texture resource in the target compressed format from the second electronic device, the first electronic device can send the target compressed texture resource to the second electronic device. Then, in step 430, the second electronic device receives the target compressed texture resource from the first electronic device for rendering the target application. Therefore, step 330 will be described in detail first, followed by a detailed description of step 430.

Detailed description of step 330

Referring to Figure 3, step 330 is divided into: step 3301, receiving a resource request sent by the second electronic device, the resource request being sent by the second electronic device after obtaining the placeholder data, for requesting a target compressed texture resource, the target compressed texture resource being obtained by compressing the target application texture resource using a target compression format; step 3302, if the target compression format belongs to the plurality of candidate compression formats, obtaining the target compressed texture resource from the plurality of candidate compressed texture resources; step 3303, sending the target compressed texture resource to the second electronic device; wherein, the target compressed texture resource is used for the second electronic device to render the target application.

It should be noted that the resource request sent by the second electronic device to the first electronic device may include the texture resource name and the target compression format. The first electronic device then determines the target storage address based on the texture resource name and the target compression format in the resource request, and then obtains the target compressed texture resource based on the target storage address.

Alternatively, the resource request sent by the second electronic device to the first electronic device may directly include the target storage address (i.e., the target storage address is determined in advance by the second electronic device based on the texture resource name and the target compression format), so that the first electronic device can obtain the target compressed texture resource based on the target storage address.

In some embodiments, referring to FIG11, FIG11 is a flowchart of the application texture rendering method provided in the embodiments of this application. Based on FIG11, when the resource request sent by the second electronic device to the first electronic device includes a texture resource name and a target compression format, step 3302 includes: step 33021a, if the target compression format belongs to multiple candidate compression formats, the target compressed texture resource is obtained according to the target storage address corresponding to the texture resource name and the target compression format, wherein the target storage address belongs to multiple candidate storage addresses.

In this way, the first electronic device, such as a server, can determine the target storage address based on the texture resource name and the target compression format, which can reduce the computational burden on the second electronic device, such as a terminal.

In actual implementation, as mentioned above, for each of the candidate compression formats, the process of storing candidate compressed texture resources according to the candidate storage address corresponding to the texture resource name and the candidate compression format can be as follows: obtaining a first correspondence table, which indicates the correspondence between the texture resource name, the candidate compression format, and the candidate storage address; and storing the candidate compressed texture resources based on the first correspondence table.

Based on this, the target storage address can be obtained by the first electronic device by looking up the first correspondence table based on the texture resource name and the target compression format. That is, before step 33021a, if the target compression format belongs to multiple candidate compression formats, the first correspondence table can be looked up based on the texture resource name and the target compression format to obtain the target storage address; thereby, the target compressed texture resource can be obtained based on the obtained target storage address.

Based on the above, candidate compression formats include ETC, ASTC, PVRTC, and DXT formats. The first correspondence table can be found in Table 2 above. In one example, assuming the target compression format is ETC and the texture resource name is a diffuse map, the first electronic device, such as a server, searches the first correspondence table based on the ETC format and the diffuse map to obtain the target storage address XX:XX\MEh1. The server then determines the candidate compressed texture resource h1 as the target compressed texture resource based on XX:XX\MEh1 and sends it to the second electronic device, such as a terminal. In another example, assuming the target compression format is DXT and the texture resource name is a diffuse map, the server searches the first correspondence table based on the DXT format and the diffuse map to obtain the target storage address XX:XX\MDh4. The server then determines the candidate compressed texture resource h4 as the target compressed texture resource based on XX:XX\MDh4 and sends it to the terminal.

Thus, using table lookup to determine the target storage address is not only simple and easy to implement, but also has low processing overhead.

In actual implementation, as mentioned above, the process of storing candidate compressed texture resources according to the candidate storage address corresponding to the texture resource name and the candidate compression format for each candidate compression format can also be as follows: perform target operation on the texture resource name and the candidate compression format to obtain the candidate storage address; and store the candidate compressed texture resources according to the candidate storage address.

Based on this, the target storage address can be obtained by the first electronic device by performing a target operation based on the texture resource name and the target compression format. That is, before step 33021a, a target operation can also be performed on the texture resource name and the target compression format to obtain the target storage address; thereby, the target compressed texture resource can be obtained based on the obtained target storage address.

It's important to note that the target operation is a set formula or function, such as a hash function. The texture resource name and target compression format are input into the target operation, and the output is the target storage address. In one example, the texture resource name and target compression format are used as input, a hash function generates a unique identifier, and this identifier is combined with the storage path to obtain the target storage address. The target storage address belongs to multiple candidate storage addresses, and each candidate storage address corresponds to a candidate compressed texture resource. This allows the target compressed texture resource to be retrieved based on the target storage address.

Thus, determining the target storage address through target operations is not only highly accurate, but also highly flexible as the target operations can be adjusted as needed.

In some other embodiments, continuing to refer to FIG11, based on FIG11, when the resource request sent by the second electronic device to the first electronic device includes a target storage address, step 3302 includes: step 33021b, if the target compression format belongs to multiple candidate compression formats, obtain the target compressed texture resource according to the target storage address in the resource request, wherein the target storage address belongs to multiple candidate storage addresses.

It should be noted that the target storage address can be obtained by the second electronic device by looking up the first correspondence table based on the texture resource name and the target compression format, or by the second electronic device by applying a target operation to the texture resource name and the target compression format. The specific implementation process of the second electronic device looking up the first correspondence table or applying the target operation can be referred to the implementation process of the first electronic device determining the target storage address above, and will not be repeated here.

In this way, the second electronic device, such as a terminal, can determine the target storage address based on the texture resource name and the target compression format, which can reduce the computational burden on the first electronic device, such as a server.

In one embodiment, the second electronic device can detect the remaining computing power of the first electronic device. If the remaining computing power is less than a predetermined computing power threshold, the second electronic device determines the target storage address based on the texture resource name and the target compression format. If the remaining computing power is greater than or equal to the predetermined computing power threshold, the second electronic device sends the texture resource name and the target compression format to the first electronic device, which then determines the target storage address based on the texture resource name and the target compression format. This balances the computing load between the second and first electronic devices.

It should be noted that in step 33021a or 33021b above, there is one target compression format, so the target storage address determined based on the texture resource name and the target compression format is also one. However, in some embodiments, there are multiple target compression formats, so there are multiple target storage addresses determined based on the texture resource name and multiple target compression formats, which in turn creates the need to determine the target compressed texture resource based on the target storage address corresponding to each target compression format.

The process of determining the target compressed texture resource based on the target storage address corresponding to each target compression format is described below using various embodiments.

In the first embodiment, the process of obtaining the target compressed texture resource according to the target storage address in step 33021a or step 33021b includes: if there are multiple target compression formats, obtaining the compression loss rate of each target compression format; based on the compression loss rate of each target compression format, selecting the target storage address corresponding to the target compression format with the smallest compression loss rate from the target storage addresses corresponding to each target compression format; and obtaining the target compressed texture resource based on the selected target storage address.

It's important to note that compression loss rate refers to the ratio of the amount of information lost during data compression to the total amount of original data. In lossy compression algorithms, some data is discarded to reduce file size, resulting in compression loss. The compression loss rate can be expressed by the following formula: Compression Loss Rate = (Size of Target Application Texture Resource - Size of Candidate Compressible Texture Resource) / Size of Target Application Texture Resource. Compression loss rate is usually expressed as a percentage and helps measure the impact of the compression algorithm on the data. A lower compression loss rate means that the compression algorithm achieves better compression results while preserving data quality.

By applying the above embodiments, the target compressed texture resource can be determined based on the target storage address corresponding to the minimum compression loss rate, thereby obtaining target compressed texture resources with relatively high data quality and improving rendering accuracy.

In the second embodiment, the process of obtaining the target compressed texture resource according to the target storage address in step 33021a or step 33021b includes: if there are multiple target compression formats, obtaining the compression rate of each target compression format; based on the compression rate of each target compression format, selecting the target storage address corresponding to the target compression format with the largest compression rate from the target storage addresses corresponding to each target compression format; and obtaining the target compressed texture resource based on the selected target storage address.

Compression rate refers to the ratio of the compressed data size to the original data size. It represents the relative size of the data after compression, usually expressed as a ratio or percentage. Compression rate can be expressed by the following formula: Compression rate = Size of candidate compressed texture resource / Size of target applied texture resource. A higher compression rate indicates better compression, meaning the data is effectively compressed. Generally, a higher compression rate results in a smaller compressed file size and less storage space. Compression rate is a crucial indicator of compression algorithm performance and is particularly important for scenarios requiring the storage of large amounts of data within limited storage space.

In practical applications, the target compressed texture resource can be determined based on the target storage address corresponding to the maximum compression rate. This allows for the acquisition of target compressed texture resources with relatively small storage space, reducing the storage space occupied on the terminal. This is very suitable for terminals with limited storage space and can also improve rendering efficiency.

In the third embodiment, referring to Figure 12, which is a flowchart illustrating the process of determining the target compressed texture resource provided in an embodiment of this application, step 33021a includes:

Step 330211: If there are multiple target compression formats, obtain the compression loss rate and compression rate of each target compression format;

Step 330212: Obtain the compression gain function. The compression gain function is determined based on the proportion of compressed texture resources in multiple target compression formats, the compression loss rate of each target compression format, and the compression rate.

Step 330213: When the compression gain function is maximized, determine the proportion of target compressed texture resources for each target compression format;

Step 330214: Based on the texture resource name and the target storage address corresponding to each target compression format, obtain the compressed texture resource corresponding to each target compression format, and based on the proportion of the target compressed texture resource in each target compression format and the compressed texture resource corresponding to each target compression format, obtain the compressed texture resource component corresponding to each target compression format.

Step 330215: Integrate the obtained compressed texture resource components of each target compression format into a target compressed texture resource.

Unlike the embodiments described above that determine the target texture resource based on compression loss rate or compression rate, this embodiment determines the target compressed texture resource based on both compression loss rate and compression rate. Furthermore, this embodiment does not simply determine the target compressed texture resource at a specific target storage address as the final target compressed texture resource; instead, it integrates the compressed texture resource components corresponding to multiple target compression formats to obtain the final target compressed texture resource.

It should be noted that the compression loss rate and compression rate in step 330211 have already been explained above and will not be repeated here. The compression gain function is used to evaluate the average performance of compression algorithms corresponding to multiple target compression formats. The compression gain function is determined based on the proportion of compressed texture resources in multiple target compression formats, the compression loss rate of each target compression format, and the compression rate. The proportion of compressed texture resources refers to the proportion of texture resources corresponding to each target compression format. The sum of the proportions of compressed texture resources of all target compression formats is 1.

In some embodiments, step 330212 includes: obtaining compression gain sub-functions for each target compression format, wherein the compression gain sub-functions are determined based on the compression loss rate and compression rate of the target compression format; using the proportion of compressed texture resources of each target compression format as the weight of the compression gain sub-function of each target compression format, and performing a weighted summation of each compression gain sub-function based on the weight to obtain a compression gain function.

For each target compression format, the compression loss rate and compression rate can be calculated based on the initial compressed texture resources and the target application texture resources corresponding to the target compression format. The specific calculation formulas for the compression loss rate and compression rate are described above and will not be repeated here. The compression gain sub-function is directly proportional to the compression loss rate and inversely proportional to the compression rate.

In one example, the compression gain subfunction is calculated using the following formula:

In formula (1), G _{_t} is the compression gain subfunction of the t-th target compression format, R_{_t} is the compression rate of the t-th target compression format, and L_{_t} is the compression loss rate of the t-th target compression format. Formula (1) shows that the compression gain subfunction increases with the increase of the compression rate, that is, the higher the compression rate, the higher the compression gain coefficient. Formula (1) also shows that the compression gain subfunction decreases with the increase of the compression loss rate, that is, the higher the compression loss rate, the lower the compression gain coefficient.

The compressed texture resource proportion indicates the proportion of texture resources in each target compression format. The compression rate and compression loss rate for each target compression format are known quantities, also called constants, but the compressed texture resource proportion for each target compression format is an unknown quantity, also called a variable. Therefore, the compression gain function is a function that takes the compressed texture resource proportion of each target compression format as a variable.

In one example, the compression gain function is calculated using the following formula:

In formula (2), G refers to the compression gain function, T refers to the number of target compression formats, _{a_t} is the proportion of compressed texture resources in the t-th target compression format, and _{G_t} is the compression gain sub-function of the t-th target compression format.

After determining the compression gain function, it needs to be solved to obtain the target compressed texture resource proportions for each target compression format. The solved target compressed texture resource proportions are known quantities, also called constants, and can be used for resource integration in subsequent steps. Therefore, in step 330213, when the compression gain function is maximized, the target compressed texture resource proportions for multiple target compression formats are determined.

Then, in step 330214, based on the texture resource name and the target storage address corresponding to each target compression format, the compressed texture resource corresponding to each target compression format is obtained, and based on the proportion of the target compressed texture resource in each target compression format and the compressed texture resource corresponding to each target compression format, the compressed texture resource component corresponding to each target compression format is obtained.

In one example, assume T = 3, meaning there are 3 target compression formats, and assume _G1 = 1, _G2 = 2, and _G3 = 3. We need to maximize the compression gain function G = _a1G1 + _a2G2 + _a3G3 = _a1 *1 + _a2 *2 + _a3 *3, with the constraint that _a1 + _a2 + _a3 = ₁ , and _a1 , _a2 , and _a3 are all greater than or equal to 0. When _G = ₃ , we get { _a1 = 0, _a2 = 0, _a3 = 1}. Therefore, in this example, the target compressed texture resource ratio for the target compression format at t = 1 is 0, the target compressed texture resource ratio for the target compression format at t = 2 is 0, and the target compressed texture resource ratio for the target compression format at t = 3 is 1. Based on the target compressed texture resource ratio of { _a1 = 0, _a2 = 0, _a3 = 1}, we can obtain that the compressed texture resource component of the target compressed format at t=1 is 0, the compressed texture resource component of the target compressed format at t=2 is also 0, and the compressed texture resource component of the target compressed format at t=3 is 1.

Finally, in step 330215, the compressed texture resource components of each target compression format are integrated into a target compressed texture resource.

Following the example above, the three compressed texture resource components of the target compression format are integrated into a target compressed texture resource.

The advantage of the above embodiment, which uses the maximization of the compression gain function to determine the proportion of target compressed texture resources for each target compression format, is that it can improve the accuracy and flexibility of determining the proportion of target compressed texture resources.

The advantage of the above embodiment, which integrates compressed texture resources of various target compression formats using the target compressed texture resource ratio, is that it can improve the compression gain of the determined target compressed texture resources and improve the resource rendering quality.

Detailed description of step 430

Referring to Figure 3, step 430 is divided into: step 4301, receiving target compressed texture resources from the first electronic device; and step 4302, rendering the target application based on the target compressed texture resources.

In practice, the first electronic device sends the target compressed texture resource to the second electronic device by executing step 3303, and the second electronic device receives the target compressed texture resource from the first electronic device by executing step 4301. After receiving the target compressed texture resource, the second electronic device can immediately execute step 4302, or it can verify the target compressed texture resource before executing step 4302. Adding a verification process can verify the validity and accuracy of the target compressed texture resource, reducing the waste of processing resources by the second electronic device due to running invalid or erroneous target compressed texture resources.

In one embodiment, step 4302 includes: storing the target compressed texture resource in the target storage space and sending the target compressed texture resource to the rendering processing unit; after receiving a message from the rendering processing unit that the rendering was successful based on the target compressed texture resource, deleting the target compressed texture resource from the target storage space.

It should be noted that the target storage space refers to the storage area on the second electronic device used to store data related to the target application. The target storage space stores the application container. Referring to the above, the application container includes the application package and the update resource package. If the second electronic device can store the target compressed texture resource into the update resource package, then after successful storage, the update resource package will include the target compressed texture resource. The second electronic device can also store the target compressed texture resource in a space within the target storage space other than the application container. The rendering processing unit is a processing unit configured to perform resource rendering, typically referring to the GPU.

Using the above embodiments, after the second electronic device receives the target compressed texture resource from the first electronic device, it reads it into the target storage space of the target application and uploads it to the GPU to complete the rendering of the texture resource. After the rendering is successful, the second electronic device will immediately release the storage space occupied by the target compressed texture resource, thereby reducing space occupation while realizing rendering.

In one example, the process of rendering a target application based on a target compressed texture resource by the second electronic device includes: (1) Loading the target compressed texture resource: The second electronic device needs to decompress the target compressed texture resource into a target application texture resource according to the supported target compression format. This can be an image file (such as PNG, JPEG, etc.) or other types of texture data. This data contains the texture's color information and other attributes. (2) Creating a texture object: The second electronic device will convert the loaded texture data into a texture object, usually created in the rendering processing unit (such as the GPU) for subsequent rendering operations. (3) Binding the texture object: Before rendering, the terminal needs to bind the required texture object to a specific texture unit of the rendering pipeline for use during the rendering process. (4) Using the texture in the shader: In the vertex shader and fragment shader, the corresponding texture color value can be obtained from the bound texture object through texture coordinates and texture samplers. (5) Rendering the object: When rendering the object, the second electronic device mixes the texture color into the final pixel color according to the required texture information and texture coordinates to achieve the texture mapping effect. In summary, the process of rendering using target compressed texture resources by the second electronic device involves steps such as loading texture resources, creating texture objects, binding texture objects, using textures in shaders, and rendering objects. These steps need to be performed in the rendering processing unit to achieve the texture mapping effect.

The application of texture resource rendering methods also includes a detailed description of the steps.

It should be noted that in the above embodiments, the premise for the first electronic device to send the target compressed texture resource to the terminal is that the target compression format belongs to multiple candidate compression formats. However, in some embodiments, the target compression format may not belong to multiple candidate compression formats, causing the first electronic device to be unable to determine the target compressed texture resource from the candidate compressed texture resources and send it to the terminal. Therefore, as mentioned above, based on Figure 6, in step 32012, not only are multiple candidate compressed texture resources stored, but also the target application texture resource is stored so that the target application texture resource can be directly sent to the second electronic device.

Based on this, referring to Figure 13, which is a flowchart illustrating the application texture rendering method provided in this embodiment, the application texture rendering method further includes: step 340 (executed by the first electronic device) and step 440 (executed by the second electronic device). Step 340 can be divided into: step 3401, receiving a resource request from the second electronic device, the resource request being used to request a target compressed texture resource, the target compressed texture resource being obtained by compressing the target application texture resource using a target compression format; step 3402, if the target compression format does not belong to multiple candidate compression formats, obtaining the stored target application texture resource; step 3403, sending the target application texture resource to the second electronic device; wherein, the target compressed texture resource is used by the second electronic device to render the target application using the target application texture resource. Step 440 can be divided into: step 4401, receiving the target application texture resource from the first electronic device; step 4402, rendering the target application using the target application texture resource.

In step 3401, the resource request sent by the second electronic device to the first electronic device may include a texture resource name and a target compression format. The first electronic device then determines the target storage address based on the texture resource name and target compression format in the request, and then obtains the target compressed texture resource based on the target storage address.

Alternatively, the resource request sent by the second electronic device to the first electronic device may directly include the target storage address (i.e., the target storage address is determined in advance by the second electronic device based on the texture resource name and the target compression format), so that the first electronic device can obtain the target compressed texture resource based on the target storage address.

In step 3402, since the target compression format does not belong to the multiple candidate compression formats, the target storage address does not belong to the multiple candidate storage addresses, which causes the first electronic device to be unable to obtain the target compressed texture resource based on the target storage address. Therefore, the first electronic device obtains the stored target application texture resource.

Then, in step 3403, the first electronic device sends the target application texture resource to the second electronic device.

In step 4401, unlike step 4301 where the target compressed texture resource is received, the target compression format supported by the second electronic device does not belong to multiple candidate compression formats. Even if the target compressed texture resource is obtained, it cannot be parsed normally. Therefore, the second electronic device receives the target application texture resource, which can complete the resource rendering without terminal parsing, thus improving the effectiveness of resource rendering.

The advantage of the embodiments of steps 340 and 440 described above is that even if the target compression format supported by the second electronic device does not belong to multiple candidate compression formats, the second electronic device will still receive the target application texture resource sent by the server, enabling the second electronic device to perform normal rendering and improving the effectiveness of application texture resource rendering.

A schematic diagram illustrating the overall implementation of the texture rendering method in this application embodiment.

Referring to Figure 14, which is a flowchart illustrating the application texture rendering method provided in an embodiment of this application, the implementation details of the application texture rendering method in the following exemplary description will be provided in detail.

(1) The server (first electronic device) obtains the initial resource package of the target application, which includes the initial compressed texture resources of the target application in the initial compressed format.

For example, assuming the initial compression format is ETC format and the initial compressed texture resource is an initial compressed diffuse map resource, then the initial resource package includes an initial compressed diffuse map resource in ETC format, and the texture resource compression format field in the initial resource package is ETC format.

(2) The server decompresses the initial compressed texture resources into the target application texture resources, replaces the initial compressed texture resources in the initial resource package with placeholder data to obtain the updated resource package, changes the texture resource compression format field of the updated resource package to the anchor compression format, and sends the updated resource package to the terminal.

For example, the server decompresses the initial compressed diffuse map resource into the target application's diffuse map resource, replaces the initial compressed diffuse map resource in the initial resource package with placeholder data (the placeholder data is specifically "diffuse map"), and the server also changes the texture resource compression format field from ETC format to anchor compression format, and sends the updated resource package to the terminal.

(3) The server compresses the target application texture resources into multiple candidate compressed texture resources according to multiple candidate compression formats.

For example, candidate compression formats can be ETC, ASTC, PVRTC, and DXT formats. The corresponding candidate compressed texture resource is h1 for ETC format, h2 for ASTC format, h3 for PVRTC format, and h4 for DXT format.

(4) The server stores multiple candidate compressed texture resources according to the candidate storage address corresponding to the texture resource name and candidate compression format, as well as the target application texture resources.

The specific process by which the server determines the candidate storage address based on the texture resource name and candidate compression format has been described above and will not be repeated here. For example, multiple candidate storage addresses include: XX:XX\MEh1 for ETC format, XX:XX\MAh2 for ASTC format, XX:XX\MPh3 for PVRTC format, and XX:XX\MDh4 for DXT format, etc.

(5) The terminal (second electronic device) receives the application container of the target application from the server. The application container includes an application package and an update resource package. Referring to step (1), the update resource package includes placeholder data and a texture resource compression format field.

(6) The terminal runs the application package through the main logic. In response to the identification during the operation that the updated resource package contains placeholder data and the texture resource compression format field in the updated resource package is the anchor compression format, a mandatory constraint is added to the texture processing script. The mandatory constraint indicates that the anchor compression format is supported.

(7) The terminal sends a query request to the texture processing script so that the texture processing script can verify support for the anchor compression format based on mandatory constraints and query the target compression formats supported by the terminal other than the anchor compression format. For example, the target compression format supported by the terminal is the ASTC format.

(8) The terminal inserts a hijacking statement before the rendering function used to render the target application; then the terminal executes the hijacking statement to replace the placeholder data in the update resource package with the target compression format.

(9) The terminal sends a request for the target compressed texture resource to the server based on the target compression format in the resource package. The request may include the texture resource name and the target compression format.

For example, the terminal replaces placeholder data in the update resource pack with ASTC format, and the request sent by the terminal to the server includes diffuse texture and ASTC format.

(10) When the server receives a request from the terminal for a target compressed texture resource in a target compression format supported by the terminal, if the target compression format belongs to multiple candidate compression formats, the server retrieves the target compressed texture resource according to the target storage address corresponding to the texture resource name and the target compression format, and sends it to the terminal. Alternatively, when the server receives a request from the terminal for a target compressed texture resource in a target compression format supported by the terminal, if the target compression format does not belong to multiple candidate compression formats, the server retrieves the stored target application texture resource and sends it to the terminal.

For example, since the ASTC format supported by the terminal is one of the multiple candidate compression formats, the server can determine the target storage address as XX:XX\MAh2 from multiple candidate storage addresses based on the diffuse map and the ASTC format, and obtain the target compressed texture resource based on XX:XX\MAh2.

(11) The terminal receives the target compressed texture resource from the server to render the target application; or, the terminal receives the target application texture resource from the server to render the target application.

This application effectively solves the problem of fixed compression formats in personalized resource packages for target applications (such as WebGL games) distributed by the Unity platform on different terminals. This allows the target application to fully utilize the rendering performance improvements brought by GPU computing and storage across different terminals/devices. From an application operation perspective, because the texture resources in this application are truly loaded on demand—that is, only loaded into memory when rendering is required—and the texture resource file is used as the smallest granularity, the granularity is finer than the Unity resource package solution provided by the Unity platform, avoiding additional memory consumption caused by other idle resources within the AB package. It also eliminates the problem of redundant disk and memory space usage caused by the same resource being repeatedly packaged in multiple Unity resource packages. From the application developer's perspective, this application only processes the exported application container, so no modification or editing of the application package's code is required. The conversion can be completed simply through the panel, making it easy to use widely. This application has high universality and reduces the memory space occupied on the terminal.

Description of apparatus and devices in embodiments of this application

It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in the embodiments of this application, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

It should be noted that in various specific embodiments of this application, when processing data related to object characteristics, such as object attribute information or sets of attribute information, is required, the object's permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining object attribute information, separate permission or consent from the object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the object's separate permission or consent will the necessary object-related data for the proper functioning of these embodiments be acquired.

Figure 15 is a structural schematic diagram of an application texture rendering apparatus 1500 applied to a first electronic device according to an embodiment of this application. Based on Figure 15, the application texture rendering apparatus 1500 specifically includes:

The first sending unit 1510 is configured to acquire the target application texture resources and placeholder data of the target application, and send the placeholder data to the second electronic device.

Compression unit 1520 is configured to compress the target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats;

The second sending unit 1530 is configured to receive a resource request sent by the second electronic device. The resource request is sent by the second electronic device after obtaining the placeholder data, and is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format. If the target compression format belongs to the plurality of candidate compression formats, the target compressed texture resource is obtained from the plurality of candidate compressed texture resources, and the target compressed texture resource is sent to the second electronic device. The target compressed texture resource is used by the second electronic device to render the target application.

In one embodiment, the first transmitting unit 1510 is further configured to:

Obtain the initial resource package of the target application, the initial resource package including the initial compressed texture resources of the target application in the initial compression format;

The initial compressed texture resource is decompressed to obtain the target application texture resource.

In one embodiment, the initial resource packet further includes an initial compression format name; the first sending unit 1510 is also configured to:

Obtain the initial compression algorithm corresponding to the initial compression format name;

Based on the initial compression algorithm, the initially compressed texture resources are decompressed into the target application texture resources.

In one embodiment, the apparatus further includes a first acquisition unit, configured to:

Obtain the initial resource package of the target application, wherein the initial resource package includes the initial compressed texture resources of the target application;

Replace the initial compressed texture resources in the initial resource package with placeholder data to obtain the updated resource package;

The first transmitting unit 1510 is also configured as follows:

Send the updated resource package to the second electronic device.

In one embodiment, the apparatus further includes an updating unit, configured to:

Change the texture resource compression format field of the updated resource package to the anchor compression format to obtain a new updated resource package;

The first transmitting unit 1510 is also configured as follows:

Send the new update resource package to the second electronic device;

When the second electronic device identifies the texture resource compression format field as the anchor compression format, it adds a mandatory constraint to the texture processing script, the mandatory constraint indicating support for the anchor compression format.

In one embodiment, the placeholder data is a texture resource name, and the resource request includes the texture resource name and the target compression format; the apparatus further includes a storage unit configured as follows:

For each of the candidate compression formats, the candidate compressed texture resources are stored according to the candidate storage address corresponding to the texture resource name and the candidate compression format;

The second sending unit 1530 is further configured to: if the target compression format belongs to the plurality of candidate compression formats, obtain the target compressed texture resource according to the target storage address corresponding to the texture resource name and the target compression format, wherein the target storage address belongs to the plurality of candidate storage addresses.

In one embodiment, the storage unit is further configured as follows:

Perform a target operation on the texture resource name and the candidate compression format to obtain the candidate storage address;

Store the candidate compressed texture resources according to the candidate storage addresses;

The second transmitting unit 1530 is also configured as follows:

If the target compression format belongs to the plurality of candidate compression formats, the target operation is performed on the texture resource name and the target compression format to obtain the target storage address.

In one embodiment, the storage unit is further configured as follows:

Obtain a first correspondence table, which indicates the correspondence between the texture resource name, the candidate compression format, and the candidate storage address;

Based on the first correspondence table, the candidate compressed texture resources are stored;

The second transmitting unit 1530 is also configured as follows:

If the target compression format belongs to the plurality of candidate compression formats, the first correspondence table is searched based on the texture resource name and the target compression format to obtain the target storage address.

In one embodiment, the placeholder data is a texture resource name, the resource request includes a target storage address, the target storage address is determined by the second electronic device based on the texture resource name and the target compression format; the storage unit is further configured as follows:

For each of the candidate compression formats, the candidate compressed texture resources are stored according to the candidate storage address corresponding to the texture resource name and the candidate compression format;

The second transmitting unit 1530 is also configured as follows:

If the target compression format belongs to the plurality of candidate compression formats, the target compressed texture resource is obtained according to the target storage address in the resource request, wherein the target storage address belongs to the plurality of candidate storage addresses.

In one embodiment, the second transmitting unit 1530 is further configured to:

If there are multiple target compression formats, obtain the compression loss rate for each target compression format;

Based on the compression loss rate of each target compression format, the target storage address corresponding to the target compression format with the smallest compression loss rate is selected from the target storage addresses corresponding to each target compression format.

Based on the selected target storage address, the target compressed texture resource is obtained.

In one embodiment, the number of target compression formats is multiple;

The second transmitting unit 1530 is also configured as follows:

If there are multiple target compression formats, obtain the compression loss rate and compression rate for each target compression format;

Obtain the compression gain function, which is determined based on the proportion of compressed texture resources in multiple target compression formats, the compression loss rate of each target compression format, and the compression rate.

When the compression gain function is maximized, the proportion of target compressed texture resources for each target compression format is determined.

Based on the texture resource name and the target storage address corresponding to each target compression format, obtain the compressed texture resources corresponding to each target compression format. Based on the proportion of the target compressed texture resources in each target compression format and the compressed texture resources corresponding to each target compression format, obtain the compressed texture resource components corresponding to each target compression format. Integrate the obtained compressed texture resource components of each target compression format into a target compressed texture resource.

In one embodiment, the second transmitting unit 1530 is further configured to:

Obtain the compression gain sub-function for each target compression format. The compression gain sub-function is determined based on the compression loss rate and compression rate of the target compression format.

The proportion of compressed texture resources in each target compression format is used as the weight of the compression gain sub-function of each target compression format. Based on this weight, the compression gain sub-functions are weighted and summed to obtain the compression gain function.

In one embodiment, the second transmitting unit 1530 is further configured to:

If there are multiple target compression formats, obtain the compression rate of each target compression format;

Based on the compression rate of each target compression format, the target storage address corresponding to the target compression format with the highest compression rate is selected from the target storage addresses corresponding to each target compression format;

Based on the selected target storage address, the target compressed texture resource is obtained.

In one embodiment, the second transmitting unit 1530 is further configured to:

Store the plurality of candidate compressed texture resources and the target application texture resource;

If the target compression format does not belong to the plurality of candidate compression formats, the stored target application texture resource is obtained and sent to the second electronic device.

It should be noted that the specific implementation of the above-mentioned texture resource rendering device is basically the same as the specific implementation of the above-mentioned texture resource rendering method, and will not be repeated here.

Figure 16 is a schematic diagram of an application texture rendering apparatus 1600 for a second electronic device provided in an embodiment of this application. The application texture rendering apparatus 1600 specifically includes:

The determining unit 1610 is configured to determine a target compression format supported by the second electronic device in response to receiving placeholder data of a target application sent from the first electronic device.

The third sending unit 1620 is configured to send a resource request to the first electronic device. The resource request is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing a target application texture resource using a target compression format.

The first receiving unit 1630 is configured to receive the target compressed texture resource from the first electronic device and render the target application based on the target compressed texture resource; wherein, when the first electronic device sends the placeholder data of the target application, it also compresses the acquired target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats; the multiple candidate compression formats include the target compression format, and the multiple candidate compressed texture resources include the target compressed texture resource.

In one embodiment, placeholder data exists in the application package; the determining unit 1610 is configured to: run the application package through the main logic, and in response to identifying that the application package contains placeholder data during the operation, query the target compression format supported by the second electronic device through a texture processing script.

In one embodiment, the determining unit 1610 is further configured to:

The application package is run by the main logic. In response to the identification during the operation that the application package contains placeholder data and that the texture resource compression format field in the application package is an anchor compression format, a mandatory constraint is added to the texture processing script. The mandatory constraint indicates support for the anchor compression format.

A query request is sent to the texture processing script; wherein the query request is used for the texture processing script to verify support for the anchor compression format based on the mandatory constraints, and to query the target compression formats supported by the second electronic device other than the anchor compression format.

In one embodiment, the third transmitting unit 1620 is configured as follows:

Insert hijacking statements before the rendering function used to render the target application;

The hijacking statement is executed to replace the placeholder data in the application package with the target compression format and to send the resource request to the first electronic device based on the target compression format in the application package.

In one embodiment, the first receiving unit 1630 is configured as follows:

The target compressed texture resource is stored in the target storage space, and the target compressed texture resource is sent to the rendering processing unit;

After receiving a message from the rendering processing unit that the target compressed texture resource has been successfully rendered, the target compressed texture resource is deleted from the target storage space.

It should be noted that the specific implementation of the above-mentioned texture resource rendering device is basically the same as the specific implementation of the above-mentioned texture resource rendering method, and will not be repeated here.

Referring to Figure 17, which is a partial structural block diagram of the second electronic device using the texture rendering method provided in this embodiment of the application, the second electronic device may be a terminal, including: a radio frequency (RF) circuit 1710, a memory 1715, an input unit 1730, a display unit 1740, a sensor 1750, an audio circuit 1760, a wireless fidelity (WiFi) module 1770, a processor 1780, and a power supply 1790, etc. Those skilled in the art will understand that the electronic device structure shown in Figure 17 does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

The RF circuit 1710 can be configured to receive and transmit signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with the processor 1780; in addition, it transmits uplink data designed to be sent to the base station.

The memory 1715 can be configured to store software programs and modules, and the processor 1780 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 1715.

The input unit 1730 can be configured to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the content terminal. The input unit 1730 may include a touch panel 1731 and other input devices 1732.

Display unit 1740 can be configured to display input or provided information, as well as various menus of the content terminal. Display unit 1740 may include display panel 1741.

Audio circuitry 1760, speaker 1761, and microphone 1762 provide an audio interface.

In this embodiment, the processor 1780 included in the terminal can execute the application texture rendering method of the previous embodiment.

The terminals in this application embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to content distribution scenarios, gaming scenarios, and resource processing.

Figure 18 is a partial structural block diagram of a first electronic device using the texture rendering method provided in an embodiment of this application. The first electronic device, such as a server, can vary significantly depending on its configuration or performance. It may include one or more central processing units (CPUs) 1822 (e.g., one or more processors) and a memory 1832, and one or more storage media 1830 (e.g., one or more mass storage devices) storing application programs 1842 or data 1844. The memory 1832 and storage media 1830 may be temporary or persistent storage. The program stored in the storage media 1830 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the server. Furthermore, the CPU 1822 may be configured to communicate with the storage media 1830 and execute the series of instruction operations in the storage media 1830 on the server.

The server may also include one or more power supplies 1826, one or more wired or wireless network interfaces 1850, one or more input/output interfaces 1858, and/or one or more operating systems 1841, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

The central processing unit 1822 in the server can be configured to execute the application texture rendering method of the embodiments of this application.

This application provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor will execute the application texture rendering method provided in this application.

This application provides a computer program product including computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the computer device to perform the application texture rendering method described above.

The terms "first," "second," "third," "fourth," etc. (if present) in the specification and accompanying drawings of the embodiments of this application are used to distinguish similar content and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "including," 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 necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

It should be understood that in the embodiments of this application, "at least one (item)" refers to one or more, and "more than one" refers to two or more. "And/or" is used to describe the relationship between related content, indicating that three relationships can exist. For example, "A and/or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character "/" generally indicates that the preceding and following related content are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server 130, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

The above is a detailed description of the implementation methods of the embodiments of this application. However, the embodiments of this application are not limited to the above implementation methods. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims (22)

An application texture rendering method, performed by a first electronic device, the method comprising: Obtain the target application texture resources and placeholder data of the target application, and send the placeholder data to the second electronic device; The target application texture resources are compressed into multiple candidate compressed texture resources according to multiple candidate compression formats; The system receives a resource request sent by the second electronic device. The resource request is sent by the second electronic device after it obtains the placeholder data. The request is for requesting a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format. If the target compression format belongs to the plurality of candidate compression formats, the target compressed texture resource is obtained from the plurality of candidate compressed texture resources, and the target compressed texture resource is sent to the second electronic device; The target compressed texture resource is used for rendering the target application by the second electronic device. According to claim 1, the application texture rendering method, wherein obtaining the target application texture resource of the target application includes: Obtain the initial resource package of the target application, the initial resource package including the initial compressed texture resources of the target application in the initial compression format; The initial compressed texture resource is decompressed to obtain the target application texture resource. According to claim 2, the application texture rendering method further includes an initial compression format name; The step of decompressing the initial compressed texture resource to obtain the target application texture resource includes: Obtain the initial compression algorithm corresponding to the initial compression format name; Based on the initial compression algorithm, the initially compressed texture resource is decompressed into the target application texture resource. The application texture rendering method according to any one of claims 1 to 3, wherein, before sending the placeholder data to the second electronic device, the method further includes: Obtain the initial resource package of the target application, wherein the initial resource package includes the initial compressed texture resources of the target application; Replace the initial compressed texture resources in the initial resource package with placeholder data to obtain the updated resource package; Sending the placeholder data to the second electronic device includes: Send the updated resource package to the second electronic device. According to claim 4, the application texture rendering method, before sending the updated resource package to the second electronic device, the method further includes: Change the texture resource compression format field of the updated resource package to the anchor compression format to obtain a new updated resource package; Sending the updated resource package to the second electronic device includes: Send the new update resource package to the second electronic device; When the second electronic device identifies the texture resource compression format field as the anchor compression format, it adds a mandatory constraint to the texture processing script, the mandatory constraint indicating support for the anchor compression format. The application texture rendering method according to any one of claims 1 to 5, wherein the placeholder data is a texture resource name, and the resource request includes the texture resource name and the target compression format; After compressing the target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats, the method further includes: For each of the candidate compression formats, the candidate compressed texture resources are stored according to the candidate storage address corresponding to the texture resource name and the candidate compression format; If the target compression format belongs to the plurality of candidate compression formats, obtaining the target compressed texture resource from the plurality of candidate compressed texture resources includes: If the target compression format belongs to the plurality of candidate compression formats, the target compressed texture resource is obtained according to the target storage address corresponding to the texture resource name and the target compression format, wherein the target storage address belongs to the plurality of candidate storage addresses. According to the application texture rendering method of claim 6, the step of storing the candidate compressed texture resource according to the candidate storage address corresponding to the texture resource name and the candidate compression format includes: Perform a target operation on the texture resource name and the candidate compression format to obtain the candidate storage address; Store the candidate compressed texture resources according to the candidate storage addresses; Before obtaining the target compressed texture resource according to the target storage address corresponding to the texture resource name and the target compression format, the method further includes: If the target compression format belongs to the plurality of candidate compression formats, the target operation is performed on the texture resource name and the target compression format to obtain the target storage address. According to the application texture rendering method of claim 6, the step of storing the candidate compressed texture resource according to the candidate storage address corresponding to the texture resource name and the candidate compression format includes: Obtain a first correspondence table, which indicates the correspondence between the texture resource name, the candidate compression format, and the candidate storage address; Based on the first correspondence table, the candidate compressed texture resources are stored; Before obtaining the target compressed texture resource according to the target storage address corresponding to the texture resource name and the target compression format, the method further includes: If the target compression format belongs to the plurality of candidate compression formats, the first correspondence table is searched based on the texture resource name and the target compression format to obtain the target storage address. The application texture rendering method according to any one of claims 1 to 5, wherein the placeholder data is a texture resource name, the resource request includes a target storage address, and the target storage address is determined by the second electronic device based on the texture resource name and the target compression format; After compressing the target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats, the method further includes: For each of the candidate compression formats, the candidate compressed texture resources are stored according to the candidate storage address corresponding to the texture resource name and the candidate compression format; If the target compression format belongs to the plurality of candidate compression formats, obtaining the target compressed texture resource from the plurality of candidate compressed texture resources includes: If the target compression format belongs to the plurality of candidate compression formats, the target compressed texture resource is obtained according to the target storage address in the resource request, wherein the target storage address belongs to the plurality of candidate storage addresses. The application texture rendering method according to any one of claims 6 to 9, wherein obtaining the target compressed texture resource according to the target storage address in the resource request includes: If there are multiple target compression formats, obtain the compression loss rate for each target compression format; Based on the compression loss rate of each target compression format, the target storage address corresponding to the target compression format with the smallest compression loss rate is selected from the target storage addresses corresponding to each target compression format. Based on the selected target storage address, the target compressed texture resource is obtained. The application texture rendering method according to any one of claims 6 to 9, wherein obtaining the target compressed texture resource according to the target storage address in the resource request includes: If there are multiple target compression formats, obtain the compression rate of each target compression format; Based on the compression rate of each target compression format, the target storage address corresponding to the target compression format with the highest compression rate is selected from the target storage addresses corresponding to each target compression format; Based on the selected target storage address, the target compressed texture resource is obtained. The application texture rendering method according to any one of claims 1 to 11, wherein, after compressing the target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats, the method further includes: Store the plurality of candidate compressed texture resources and the target application texture resource; If the target compression format does not belong to the plurality of candidate compression formats, the stored target application texture resource is obtained and sent to the second electronic device. An application texture rendering method, performed by a second electronic device, the method comprising: In response to receiving placeholder data of the target application sent from the first electronic device, the target compression format supported by the second electronic device is determined; Send a resource request to the first electronic device. The resource request is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format. Receive the target compressed texture resource from the first electronic device, and render the target application based on the target compressed texture resource; When the first electronic device sends the placeholder data of the target application, it also compresses the acquired target application texture resources into multiple candidate compressed texture resources according to multiple candidate compression formats; the multiple candidate compression formats include the target compression format, and the multiple candidate compressed texture resources include the target compressed texture resource. The application texture rendering method according to claim 13, wherein the placeholder data exists in the application package; The step of determining the target compression format supported by the second electronic device in response to receiving placeholder data of the target application sent from the first electronic device includes: The application package is run by the main logic, and in response to the identification of placeholder data in the application package during the operation, the target compression format supported by the second electronic device is queried through the texture processing script. According to the application texture rendering method of claim 14, the step of running the application package through the main logic, in response to identifying that the application package contains placeholder data during the running process, and querying the target compression format supported by the second electronic device through the texture processing script, includes: The application package is run by the main logic. In response to the identification during the operation that the application package contains placeholder data and that the texture resource compression format field in the application package is an anchor compression format, a mandatory constraint is added to the texture processing script. The mandatory constraint indicates that the anchor compression format is supported. A query request is sent to the texture processing script; wherein the query request is used for the texture processing script to verify support for the anchor compression format based on the mandatory constraints, and to query the target compression formats supported by the second electronic device other than the anchor compression format. The application texture rendering method according to any one of claims 13 to 15, wherein sending a resource request to the first electronic device includes: Insert hijacking statements before the rendering function used to render the target application; The hijacking statement is executed to replace the placeholder data in the application package with the target compression format and to send the resource request to the first electronic device based on the target compression format in the application package. The application texture rendering method according to any one of claims 13 to 16, wherein rendering the target application based on the target compressed texture resource includes: The target compressed texture resource is stored in the target storage space, and the target compressed texture resource is sent to the rendering processing unit; After receiving a message from the rendering processing unit that the target compressed texture resource has been successfully rendered, the target compressed texture resource is deleted from the target storage space. An application texture rendering apparatus, the apparatus comprising: The first sending unit is configured to acquire the target application texture resources and placeholder data of the target application, and send the placeholder data to the second electronic device; The compression unit is configured to compress the target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats; The second sending unit is configured to receive a resource request sent by the second electronic device. The resource request is sent by the second electronic device after obtaining the placeholder data, and is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing the target application texture resource using a target compression format. If the target compression format belongs to the plurality of candidate compression formats, the unit obtains the target compressed texture resource from the plurality of candidate compressed texture resources and sends the target compressed texture resource to the second electronic device. The target compressed texture resource is used by the second electronic device to render the target application. An application texture rendering apparatus, the apparatus comprising: The determining unit is configured to determine the target compression format supported by the second electronic device in response to receiving placeholder data of the target application sent from the first electronic device; The third sending unit is configured to send a resource request to the first electronic device. The resource request is used to request a target compressed texture resource. The target compressed texture resource is obtained by compressing a target application texture resource using a target compression format. The second receiving unit is configured to receive the target compressed texture resource from the first electronic device and render the target application based on the target compressed texture resource; wherein, when the first electronic device sends the placeholder data of the target application, it also compresses the acquired target application texture resource into multiple candidate compressed texture resources according to multiple candidate compression formats; the multiple candidate compression formats include the target compression format, and the multiple candidate compressed texture resources include the target compressed texture resource. An electronic device, comprising: Memory, configured to store computer-executable instructions or computer programs; When a processor is configured to execute computer-executable instructions or computer programs stored in the memory, it implements the application texture rendering method according to any one of claims 1 to 17. A computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, implement the application texture rendering method according to any one of claims 1 to 17. A computer program product comprising computer-executable instructions or a computer program, wherein when executed by a processor, the computer-executable instructions or the computer program implement the application texture rendering method according to any one of claims 1 to 17.