Resource Loading Method, Terminal and Storage Medium

Abstract

The present invention provides a resource loading method, a terminal, and a storage medium. Aiming at the problems of waste of picture resources and time waste in loading picture resources by a graphics processor on an existing terminal, the picture file to be loaded corresponding to an application program is decompressed into a texture format file; it is judged whether the graphics processor supports a preset compressed texture algorithm; if so, the texture format file is compressed by using the preset compressed texture algorithm to obtain a compressed texture file, and the compressed texture file is processed by the graphics processor. Thus, it is pre-judged whether the graphics processor supports the corresponding compressed texture algorithm before compression, and the preset texture algorithm compression is only performed on the premise that the graphics processor supports it, avoiding waste of storage space, improving the picture processing efficiency of the graphics processor, and saving processing time.

Description

Technical Field

[0001] The present invention relates to the technical field of terminals, and more specifically, to a resource loading method, a terminal, and a storage medium. Background Art

[0002] Currently, various applications inevitably need to load corresponding picture files for display during use. When using picture resources, the graphics processing unit (GPU) is used for rendering. The process is to load image files in a file format (such as jpg, png, tga, etc.). These file formats cannot be directly recognized by the graphics processing unit. Usually, the central processing unit (CPU) is required to decompress them into a texture format that the graphics processing unit can recognize (such as R5G6B5, R8G8B8, A8R8G8B8, etc.). Then, this texture format is compressed through a compressed texture algorithm to obtain a compressed texture file, which is then loaded into the graphics processing unit for processing. However, in this process, if the graphics processing unit does not support this compressed texture algorithm, the compressed texture file will be decompressed into an RGBA texture again, resulting in two texture images existing in memory simultaneously, causing resource waste and time waste. Summary of the Invention

[0003] The technical problem to be solved by the present invention is the problem of resource waste and time waste caused by the graphics processing unit loading pictures in the related art. To solve this technical problem, a resource loading method, a terminal, and a storage medium are provided.

[0004] To solve the above technical problem, the present invention provides a resource loading method, which includes:

[0005] Decompressing the picture file to be loaded corresponding to the application program into a texture format file;

[0006] Judging whether the graphics processing unit supports a preset compressed texture algorithm;

[0007] If so, compressing the texture format file with the preset compressed texture algorithm to obtain a compressed texture file, and processing the compressed texture file through the graphics processing unit.

[0008] Optionally, before decompressing the picture file to be loaded corresponding to the application program into a texture format file, it further includes:

[0009] Detecting the picture format of the picture file.

[0010] Optionally, when the picture format of the picture file includes a lossless transparent format, it further includes:

[0011] Determine whether there is transparency in the picture file;

[0012] If not, mark the picture file.

[0013] Optionally, determining whether there is transparency in the picture file includes:

[0014] Traverse and retrieve the pixel points in the picture file to determine whether each pixel point has transparency.

[0015] Optionally, decompressing the picture file to be loaded corresponding to the application program into a texture format file includes:

[0016] Convert the marked picture file into a lossy opaque picture format;

[0017] Decompress the converted picture file into the texture format file.

[0018] Optionally, processing the compressed texture file by the graphics processor includes:

[0019] The graphics processor parses and renders the compressed texture file.

[0020] Optionally, the graphics processor parsing and rendering the compressed texture file includes:

[0021] The graphics processor rasterizes the compressed texture file, periodically issues a vertical synchronization signal, triggers the rendering of the application interface, and projects it onto the display screen of the terminal.

[0022] Optionally, after determining whether the graphics processor supports a preset compressed texture algorithm, it further includes:

[0023] If not, directly send the texture format file to the graphics processor for processing.

[0024] The present invention also provides a terminal, which includes a processor, a memory, and a communication bus;

[0025] The communication bus is used to realize the connection and communication between the processor and the memory;

[0026] The processor is used to execute one or more programs stored in the memory to implement the steps of the above resource loading method.

[0027] The present invention also provides a computer-readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the above resource loading method.

[0028] Beneficial effects

[0029] The present invention provides a resource loading method, a terminal, and a storage medium. Aiming at the problems of waste of picture resources and time waste in loading picture resources by a graphics processor on an existing terminal, the picture files to be loaded corresponding to an application are decompressed into texture format files; it is judged whether the graphics processor supports a preset compressed texture algorithm; if so, the texture format files are compressed by using the preset compressed texture algorithm to obtain compressed texture files, and the compressed texture files are processed by the graphics processor. Thus, it is pre-judged whether the graphics processor supports the corresponding compressed texture algorithm before compression, and the preset texture algorithm compression is only performed on the premise that the graphics processor supports it, avoiding waste of storage space, improving the picture processing efficiency of the graphics processor, and saving processing time. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The present invention will be further described below in conjunction with the drawings and embodiments. In the drawings:

[0031] Figure 1 It is a schematic hardware structure diagram of an optional mobile terminal for implementing various embodiments of the present invention.

[0032] Figure 2 As Figure 1 shown, it is a schematic diagram of a wireless communication system of the mobile terminal;

[0033] Figure 3 It is a basic flowchart of the resource loading method provided by an embodiment of the present invention;

[0034] Figure 4 It is a schematic diagram of the process of the resource loading method provided by an embodiment of the present invention;

[0035] Figure 5 It is a schematic diagram of the structure of the terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0036] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0037] In subsequent descriptions, suffixes such as "module", "component", or "unit" used to represent elements are only for the convenience of description of the present invention, and they have no specific meaning themselves. Therefore, "module", "component", or "unit" can be used interchangeably.

[0038] The terminal can be implemented in various forms. For example, the terminal described in the present invention may include mobile terminals such as mobile phones, tablet computers, laptop computers, palmtop computers, personal digital assistants (PDAs), portable media players (PMPs), navigation devices, wearable devices, smart bracelets, pedometers, etc., as well as fixed terminals such as digital TVs, desktop computers, etc.

[0039] In the following description, a mobile terminal will be taken as an example for illustration. Those skilled in the art will understand that, except for the components specifically for mobile purposes, the structure according to the embodiments of the present invention can also be applied to fixed-type terminals.

[0040] Please refer to Figure 1 , which is a schematic diagram of the hardware structure of a mobile terminal for implementing various embodiments of the present invention. The mobile terminal 100 may include: an RF (Radio Frequency) unit 101, a WiFi module 102, an audio output unit 103, an A / V (audio / video) input unit 104, a sensor 105, a display unit 106, a user input unit 107, an interface unit 108, a memory 109, a processor 110, and a power supply 111, etc. Those skilled in the art can understand that Figure 1 the mobile terminal structure shown in does not constitute a limitation on the mobile terminal. The mobile terminal may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0041] Next, in combination with Figure 1 each component of the mobile terminal will be specifically introduced:

[0042] The radio frequency unit 101 can be used for receiving and transmitting information or signals during a call. Specifically, after receiving the downlink information from the base station, it is sent to the processor 110 for processing. Additionally, it sends the uplink data to the base station. Generally, the radio frequency unit 101 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc. Moreover, the radio frequency unit 101 can also communicate with the network and other devices via wireless communication. The above wireless communication can use any communication standard or protocol, including but not limited to GSM (Global System of Mobile communication), GPRS (General Packet Radio Service), CDMA2000 (Code Division Multiple Access 2000), WCDMA (Wideband Code Division Multiple Access), TD-SCDMA (Time Division-Synchronous Code Division Multiple Access), FDD-LTE (Frequency Division Duplexing-Long Term Evolution), and TDD-LTE (Time Division Duplexing-Long Term Evolution), etc.

[0043] WiFi belongs to short-range wireless transmission technology. The mobile terminal can help users send and receive emails, browse the web, and access streaming media, etc. through the WiFi module 102. It provides users with wireless broadband Internet access. Although Figure 1 the WiFi module 102 is shown, it can be understood that it is not an essential component of the mobile terminal and can be omitted entirely within the scope of not changing the essence of the invention according to needs.

[0044] The audio output unit 103 can convert the audio data received by the radio frequency unit 101 or the WiFi module 102 or stored in the memory 109 into an audio signal and output it as sound when the mobile terminal 100 is in call signal reception mode, call mode, recording mode, voice recognition mode, broadcast reception mode, etc. Moreover, the audio output unit 103 can also provide audio output related to specific functions executed by the mobile terminal 100 (such as call signal reception sound, message reception sound, etc.). The audio output unit 103 can include a speaker, a buzzer, etc.

[0045] The A / V input unit 104 is used to receive audio or video signals. The A / V input unit 104 may include a Graphics Processing Unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes the image data of still pictures or videos obtained by an image capture device (such as a camera) in the video capture mode or the image capture mode. The processed image frames can be displayed on the display unit 106. The image frames processed by the GPU 1041 can be stored in the memory 109 (or other storage media) or transmitted via the radio frequency unit 101 or the WiFi module 102. The microphone 1042 can receive sounds (audio data) via the microphone 1042 in operating modes such as the phone call mode, the recording mode, the voice recognition mode, etc., and can process such sounds into audio data. The processed audio (voice) data can be output in a format that can be transmitted to a mobile communication base station via the radio frequency unit 101 in the case of the phone call mode. The microphone 1042 can implement various types of noise cancellation (or suppression) algorithms to cancel (or suppress) the noise or interference generated during the reception and transmission of audio signals.

[0046] The mobile terminal 100 further includes at least one sensor 105, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. Among them, the ambient light sensor can adjust the brightness of the display panel 1061 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 1061 and / or the backlight when the mobile terminal 100 is moved to the ear. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes), and can detect the magnitude and direction of gravity when stationary, and can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that the mobile phone can also be configured with, such as fingerprint sensors, pressure sensors, iris sensors, molecular sensors, gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be elaborated here.

[0047] The display unit 106 is used to display the information input by the user or the information provided to the user. The display unit 106 may include a display panel 1061, and the display panel 1061 can be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), etc.

[0048] The user input unit 107 can be used to receive input digital or character information and generate key signal inputs related to the user settings and function control of the mobile terminal. Specifically, the user input unit 107 can include a touch panel 1071 and other input devices 1072. The touch panel 1071, also known as a touch screen, can collect touch operations of the user on or near it (such as operations of the user using any suitable object or accessory such as a finger or a stylus on or near the touch panel 1071), and drive the corresponding connection device according to a preset program. The touch panel 1071 can include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the touch position of the user and detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 110, and can receive and execute the commands sent by the processor 110. In addition, the touch panel 1071 can be implemented in multiple types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1071, the user input unit 107 can also include other input devices 1072. Specifically, the other input devices 1072 can include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, etc., and specific details are not limited here.

[0049] Further, the touch panel 1071 can cover the display panel 1061. After the touch panel 1071 detects a touch operation on or near it, it transmits the operation to the processor 110 to determine the type of touch event. Subsequently, the processor 110 provides a corresponding visual output on the display panel 1061 according to the type of touch event. Although in Figure 1 the touch panel 1071 and the display panel 1061 are implemented as two independent components to realize the input and output functions of the mobile terminal, in some embodiments, the touch panel 1071 and the display panel 1061 can be integrated to realize the input and output functions of the mobile terminal, and specific details are not limited here.

[0050] The interface unit 108 serves as an interface through which at least one external device can be connected to the mobile terminal 100. For example, the external device can include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headset port, and so on. The interface unit 108 can be used to receive inputs from external devices (such as data information, power, etc.) and transmit the received inputs to one or more components within the mobile terminal 100 or can be used to transmit data between the mobile terminal 100 and external devices.

[0051] The memory 109 can be used to store software programs and various data. The memory 109 mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.); the data storage area can store data created according to the use of the mobile phone (such as audio data, phone book, etc.). In addition, the memory 109 can include high-speed random access memory, and can also include non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0052] The processor 110 is the control center of the mobile terminal, connecting various parts of the entire mobile terminal through various interfaces and circuits. By running or executing software programs and / or modules stored in the memory 109, and calling data stored in the memory 109, it executes various functions of the mobile terminal and processes data, thereby monitoring the mobile terminal as a whole. The processor 110 can include one or more processing units; preferably, the processor 110 can integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, and application programs, etc., and the modem processor mainly processes wireless communication. It can be understood that the above-mentioned modem processor may not be integrated into the processor 110.

[0053] The mobile terminal 100 can also include a power supply 111 (such as a battery) for supplying power to each component. Preferably, the power supply 111 can be logically connected to the processor 110 through a power management system, so as to realize functions such as management of charging, discharging, and power consumption management through the power management system.

[0054] Although Figure 1 not shown, the mobile terminal 100 can also include a Bluetooth module, etc., which will not be elaborated here.

[0055] To facilitate the understanding of the embodiments of the present invention, the communication network system on which the mobile terminal of the present invention is based will be described below.

[0056] Please refer to Figure 2 , Figure 2 which is an architecture diagram of a communication network system provided by an embodiment of the present invention. This communication network system is an LTE system of the general mobile communication technology. This LTE system includes a UE (User Equipment) 201, an E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) 202, an EPC (Evolved Packet Core) 203, and an operator's IP service 204 that are communicatively connected in sequence.

[0057] Specifically, the UE 201 may be the above-mentioned terminal 100, which will not be elaborated here.

[0058] The E-UTRAN 202 includes an eNodeB 2021 and other eNodeBs 2022, etc. Among them, the eNodeB 2021 can be connected to other eNodeBs 2022 through a backhaul (such as an X2 interface), the eNodeB 2021 is connected to the EPC 203, and the eNodeB 2021 can provide access for the UE 201 to the EPC 203.

[0059] The EPC 203 may include an MME (Mobility Management Entity) 2031, an HSS (Home Subscriber Server) 2032, other MMEs 2033, an SGW (Serving Gate Way) 2034, a PGW (PDN Gate Way) 2035, a PCRF (Policy and Charging Rules Function) 2036, etc. Among them, the MME 2031 is a control node that processes the signaling between the UE 201 and the EPC 203 and provides bearer and connection management. The HSS 2032 is used to provide some registers to manage functions such as a home location register (not shown in the figure) and stores some user-specific information such as service characteristics and data rates. All user data can be sent through the SGW 2034. The PGW 2035 can provide IP address allocation for the UE 201 and other functions. The PCRF 2036 is a policy and charging control policy decision point for service data flows and IP bearer resources, and it selects and provides available policy and charging control decisions for a policy and charging enforcement function unit (not shown in the figure).

[0060] The IP service 204 may include the Internet, an intranet, an IMS (IP Multimedia Subsystem), or other IP services, etc.

[0061] Although the above has been described by taking the LTE system as an example, those skilled in the art should be aware that the present invention is not only applicable to the LTE system, but also applicable to other wireless communication systems, such as GSM, CDMA2000, WCDMA, TD-SCDMA, and future new network systems, etc., which are not limited here.

[0062] Based on the above mobile terminal hardware structure and communication network system, various embodiments of the method of the present invention are proposed.

[0063] The First Embodiment

[0064] Figure 3 The basic flowchart of the resource loading method provided in this embodiment is as follows. The resource loading method includes:

[0065] S301. Unzip the image file to be loaded corresponding to the application into a texture format file;

[0066] S302. Determine whether the graphics processing unit supports a preset compressed texture algorithm;

[0067] S303. If so, compress the texture format file with the preset compressed texture algorithm to obtain a compressed texture file, and process the compressed texture file through the graphics processing unit.

[0068] During the process of the application loading images through the graphics processing unit, its pre - processing process is basically as follows:

[0069] First, search for the image resources corresponding to the application; the image resources are stored in the storage space of the terminal in various image file formats, and the image formats can be jpg, png, tga, etc.

[0070] Then, the central processing unit loads the image file and unzips it into the corresponding texture format file; during this process, the file size of the corresponding image file in its image format is larger than that of the unzipped texture format file, occupying more memory space. Based on such considerations, in order to save the subsequent processing time of the graphics processing unit and reduce system occupancy, usually, the texture format file is compressed with a preset compressed texture algorithm to obtain a compressed texture file; the size of the compressed texture file is smaller than that of the texture format file and occupies less memory, so that the graphics processing unit can process it.

[0071] Among them, in some optional embodiments of the embodiments of the present invention, the preset compressed texture algorithm may include:

[0072] DXT Compressed Texture Algorithm: The basic idea is to compress a 4x4 pixel block into a 64 - or 128 - bit data block, which is a lossy compression method. DXT1 - DXT5 are five variations of the S3TC (S3 Texture Compression) algorithm and are used for various Windows devices.

[0073] Among them, the DXT1 format is mainly applicable to textures without transparency or textures with only one - bit Alpha. Regarding every 4×4 pixel block as a compression unit, the compressed 4×4 pixel block occupies 64 bits, including 2 16 - bit RGB colors and 16 2 - bit indices.

[0074] DXT2 and DXT3 can represent textures with more complex transparency information. These two formats use explicit Alpha representation. In DXT1, 64-bit data is used to describe the color information of a 4x4 pixel block. In DXT2 and DXT3, this part of the color information remains unchanged, but additional 64-bit data, that is, 4 bits per pixel, is used to represent their Alpha transparency information. Usually, this 4-bit Alpha information can be represented using direct encoding.

[0075] DXT4 and DXT5 are also used to represent textures with complex transparency information. Different from DXT2 and DXT3, the Alpha information of DXT4 and DXT5 is obtained through linear interpolation calculation, similar to the color information of DXT1. Similarly, the transparency information of each 4x4 pixel block occupies 64 bits. The difference is that among the 64 bits, 2 8-bit alpha values and 16 3-bit index values are used. Since each pixel's index occupies 3 bits, 8 different transparency states can be represented.

[0076] ETC (Ericsson Texture Compression) compression texture algorithm: Widely used in mobile platforms. It is a lossy algorithm designed for perceptual quality, based on the fact that the human eye is more sensitive to changes in brightness than in chrominance. Similar to DXT, ETC also compresses a 4x4 pixel block into a 64- or 128-bit data block, and it is also lossy compression.

[0077] Among them, ETC1 compresses a 4x4 pixel unit group into a 64-bit data block. The 4x4 pixel group is first horizontally or vertically divided into 2 4x2 groups. Each half-group has 1 base color (in RGB444 / RGB444 or RGB555 / RGB333 format), 1 4-bit brightness index, and 8 2-bit pixel indexes. The color of each pixel is equal to the base color plus the brightness range pointed to by the index.

[0078] ETC2 is an extension of ETC1, backward compatible with ETC1, with better compression quality for RGB and supports the transparency channel.

[0079] PVRTC (PowerVR Texture Compression) compression texture algorithm: Uses 2 bilinearly magnified low-resolution maps, which are fused together according to the precision and the weight of each pixel to present the texture, and both 2-bpp (bits per pixel) and 4-bpp support ARGB data. The PVRTC format has a high compression ratio and is also lossy compression.

[0080] Among them, PVRTC 2-bpp means 2 bits per pixel. With 2 bits for each pixel, the quality is relatively poor. An 8×4 pixel unit group is compressed into a 64-bit data block. Six variables are stored in each data block.

[0081] PVRTC 4-bpp means 4 bits per pixel. With 4 bits for each pixel, a 4×4 pixel unit group is compressed into a 64-bit data block. Six variables are stored in each data block.

[0082] The above various compressed texture algorithms can all be used as the preset compressed texture algorithms in the embodiments of the present invention. Among them, for the preset compressed texture algorithms supported by the graphics processor, the graphics processor can support zero to multiple of the above preset compressed texture algorithms.

[0083] After determining whether the graphics processor supports the corresponding preset compressed texture algorithm, if the result of the determination is yes, indicating that the graphics processor supports the corresponding preset compressed texture algorithm, then the compressed texture file in the corresponding format can be processed by the graphics processor. In this case, the texture format file can be compressed to obtain the required compressed texture file and handed over to the graphics processor for processing.

[0084] Specifically, the process of the graphics processor processing the compressed texture file, that is, the process of the graphics processor processing the compressed texture file can specifically include:

[0085] The graphics processor parses and renders the compressed texture file. And the graphics processor parsing and rendering the compressed texture file can further include:

[0086] The graphics processor rasterizes the compressed texture file, periodically issues a vertical synchronization signal, triggers the rendering of the application interface, and projects it onto the display screen of the terminal. Among them, for the periodic vertical synchronization signal, its period can be 16 ms, 8 ms, 32 ms, etc., and the embodiments of the present invention do not limit it.

[0087] In some alternative embodiments, before decompressing the picture file to be loaded corresponding to the application program into a texture format file, it may further include:

[0088] Detect the picture format of the picture file. Detecting the format of the picture file can determine the compression situation of the file format of the picture file to be loaded, and can determine whether it is lossy compression or lossless compression, and whether it is compression with transparency or without transparency.

[0089] In some alternative embodiments, when the picture format of the picture file includes a lossless transparent format, it may further include:

[0090] Determine whether there is transparency in the image file;

[0091] If not, mark the image file. Image files in lossless transparent formats (usually png) have a large amount of image content and also occupy a large amount of space. However, not all image files in lossless transparent formats have transparency applied properly. Some are just image files compressed in lossless transparent formats but without corresponding transparency. In this case, the image files are actually a waste of storage resources and also a waste of the loaded memory resources during the processing. Therefore, for such image files, they can be pre-detected and marked so that in subsequent processing, the marked image files can be further processed.

[0092] In some alternative embodiments, the specific way to determine whether there is transparency in the image file may include:

[0093] Traverse and retrieve the pixel points in the image file to determine whether each pixel point has transparency.

[0094] In some alternative embodiments, decompressing the image file to be loaded corresponding to the application into a texture format file may specifically include:

[0095] Convert the marked image file into a lossy opaque image format;

[0096] Decompress the converted image file into a texture format file. To save storage space and at the same time save memory resources, the marked image file can be converted into a lossy opaque image format (such as jpg). Since the marked image file is a lossless transparent file without transparency, there is no need to present it in a lossless transparent format. Converting it into a lossy opaque image format can further reduce the occupation of storage space. And in subsequent processing, when loading and processing the lossy opaque image file, compared with the lossless transparent image file, it will occupy less memory space, thus reducing the waste of memory resources.

[0097] In some alternative embodiments, after determining whether the graphics processor supports a preset compressed texture algorithm, it may further include:

[0098] If not, directly send the texture format file to the graphics processor for processing. If the graphics processor does not support the corresponding preset compressed texture algorithm, then the texture format file can be directly sent to the graphics processor for processing without going through the texture compression process, thereby reducing the intermediate process and also reducing the generation of intermediate files, improving the processing efficiency.

[0099] This embodiment provides a resource loading method. Aiming at the problems of waste of graphics processor in loading picture resources and waste of time on existing terminals, the picture files to be loaded corresponding to the application are decompressed into texture format files; it is determined whether the graphics processor supports a preset compressed texture algorithm; if so, the texture format files are compressed by the preset compressed texture algorithm to obtain compressed texture files, and the graphics processor processes the compressed texture files. Thus, it is pre-judged whether the graphics processor supports the corresponding compressed texture algorithm before compression, and the preset texture algorithm compression is only performed on the premise that the graphics processor supports it, avoiding waste of storage space, improving the picture processing efficiency of the graphics processor, and saving processing time.

[0100] The second embodiment

[0101] This embodiment provides a resource loading method. Please refer to Figure 4 , the resource loading method in this embodiment is as follows:

[0102] S401. The central processing unit loads the local picture file and retrieves the pixel points in the picture file;

[0103] S402. Determine whether there is transparency among the pixel points in the picture file; if so, go to S404, if not, go to S403;

[0104] S403. Mark the picture file and convert the marked picture file into a lossy non-transparent file;

[0105] S405. Decompress the picture file into a texture format file;

[0106] S406. Determine whether the graphics processor supports a preset compressed texture algorithm; if so, go to S407; if not, go to S408;

[0107] S407. Compress the texture format file by the preset compressed texture algorithm to obtain a compressed texture file;

[0108] S408. The graphics processor renders and processes the compressed texture file or the texture format file and displays it in the application interface.

[0109] The third embodiment

[0110] This embodiment also provides a terminal. As shown in Figure 5 , it includes a processor 51, a memory 52 and a communication bus 53, where:

[0111] The communication bus 53 is used to realize the connection and communication between the processor 51 and the memory 52;

[0112] The processor 51 is configured to execute one or more programs stored in the memory 52 to implement the steps of the resource loading method in the above embodiments, which will not be elaborated here.

[0113] This embodiment also provides a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the steps of the resource loading method in the above embodiments, which will not be elaborated here.

[0114] It should be noted that in this document, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the presence of additional identical elements in the process, method, article or device comprising such element.

[0115] The serial numbers of the above embodiments of the present invention are only for description and do not represent the superiority or inferiority of the embodiments.

[0116] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation. Based on such understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc) and includes several instructions for causing a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0117] The above embodiments of the present invention have been described in conjunction with the accompanying drawings. However, the present invention is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Under the inspiration of the present invention, those of ordinary skill in the art can also make many forms without departing from the purpose of the present invention and the scope protected by the claims. All of these are within the protection scope of the present invention.

Claims

1. A resource loading method, characterized in that, the resource loading method includes: uncompressing the image file to be loaded corresponding to the application program into a texture format file, including: converting the marked image file into a lossy opaque image format; uncompressing the converted image file into the texture format file; judging whether the graphics processor supports a preset compressed texture algorithm; if so, compressing the texture format file with the preset compressed texture algorithm to obtain a compressed texture file, and processing the compressed texture file through the graphics processor.

2. The resource loading method according to claim 1, characterized in that, before the step of uncompressing the image file to be loaded corresponding to the application program into a texture format file, it further includes: detecting the image format of the image file.

3. The resource loading method according to claim 2, characterized in that, when the image format of the image file includes a lossless transparent format, it further includes: determining whether there is transparency in the image file; if not, marking the image file.

4. The resource loading method according to claim 3, characterized in that, the step of determining whether there is transparency in the image file includes: traversing and retrieving the pixel points in the image file to determine whether each pixel point has transparency.

5. The resource loading method according to any one of claims 1-4, characterized in that, the step of processing the compressed texture file through the graphics processor includes: the graphics processor parses and renders the compressed texture file.

6. The resource loading method according to claim 5, characterized in that, the step of the graphics processor parsing and rendering the compressed texture file includes: the graphics processor rasterizes the compressed texture file, periodically issues a vertical synchronization signal, triggers the rendering of the application interface, and projects it onto the display screen of the terminal.

7. The resource loading method according to any one of claims 1-4, characterized in that, after the step of judging whether the graphics processor supports a preset compressed texture algorithm, it further includes: if not, directly sending the texture format file to the graphics processor for processing.

8. A terminal, characterized in that, the terminal includes a processor, a memory and a communication bus; the communication bus is used to realize the connection and communication between the processor and the memory; the processor is used to execute one or more programs stored in the memory to realize the steps of the resource loading method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, the computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to realize the steps of the resource loading method according to any one of claims 1-7.

Images