Texture resource management method and device, storage medium and electronic equipment

Abstract

The invention provides a texture resource management method and device, a storage medium and electronic equipment, and relates to the field of computers. The electronic device determines an invisible object leaving the visual area in response to an update operation of a user on the visual area; a target texture corresponding to the invisible object in the video memory is determined, if no target visible object is left in the visible area, video memory resources occupied by the target texture are recycled, and the target visible object is a display object depending on the target texture in the visible area. In this way, the texture resources which are not quoted by the visual object are recognized and released in time, and therefore the risk of excessive consumption of the video memory is relieved.

Description

Texture resource management methods, devices, storage media and electronic devices Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method, apparatus, storage medium, and electronic device for texture resource management. Background Technology

[0002] When rendering images, graphics cards need to upload texture data from system memory to their dedicated video memory so that the Graphics Processing Unit (GPU) can access and perform drawing operations at high speed. In practical applications, when an application requests to display a display object in the visible area, it first needs to create a texture object in memory, and then call the corresponding interface to submit the texture data to the graphics card driver. The driver is responsible for transferring the data to the video memory for subsequent shader programs to use for rendering.

[0003] However, in most current client applications, there is a lack of effective management of textures uploaded to video memory. Specifically, textures are retained in video memory for an extended period after initial loading until the application exits, at which point the system automatically reclaims them. Therefore, as application runtime increases, the loaded textures may cause video memory exhaustion. Summary of the Invention

[0004] To overcome at least one deficiency in the prior art, this application provides a texture resource management method, apparatus, storage medium, and electronic device, comprising: Firstly, this application provides a texture resource management method, the method comprising: in response to a user's update operation on a visible area, determining an invisible object that has left the visible area; determining a target texture in video memory corresponding to the invisible object; if no target visible object remains in the visible area, reclaiming the video memory resources occupied by the target texture, wherein the target visible object is a display object within the visible area that depends on the target texture.

[0005] Secondly, this application provides a texture resource management device, the device comprising: an operation interaction module, configured to determine an invisible object leaving the visible area in response to a user's update operation on the visible area; a texture management module, configured to determine a target texture in the video memory corresponding to the invisible object; and if there is no remaining target visible object in the visible area, to reclaim the video memory resources occupied by the target texture, wherein the target visible object is a display object in the visible area that depends on the target texture.

[0006] Thirdly, this application provides a storage medium storing a computer program that, when executed by a processor, implements the texture resource management method described above.

[0007] Fourthly, this application provides an electronic device, which includes a processor and a memory, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the texture resource management method.

[0008] Compared to existing technologies, this application offers the following advantages: In the texture resource management method, apparatus, storage medium, and electronic device provided by this application, the electronic device, in response to a user's update operation on the visible area, identifies invisible objects that have left the visible area; it identifies the target texture in video memory corresponding to the invisible object; and if no target visible object remains in the visible area, it reclaims the video memory resources occupied by the target texture. The target visible object is a display object within the visible area that depends on the target texture. Thus, by promptly identifying and releasing texture resources not referenced by visible objects, the risk of excessive video memory consumption is mitigated. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 is a flowchart illustrating the texture resource management method provided in an embodiment of this application; Figure 2 is a schematic diagram illustrating the relationship between the visible area and the VR environment provided in an embodiment of this application; Figure 3 is an example flowchart illustrating the texture resource management method provided in an embodiment of this application; Figure 4 is a structural schematic diagram illustrating the texture resource management device provided in an embodiment of this application; Figure 5 is a structural schematic diagram illustrating the electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application (hereinafter referred to as "the embodiments") clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0012] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0014] In the description of this application, it should be noted that the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0015] Based on the above statement, it should be understood that the current management method for texture resources in video memory is rather crude. Specifically, textures are retained in video memory for an extended period after initial loading until the application exits, at which point the system automatically reclaims them. This approach may lead to video memory exhaustion.

[0016] It should be noted that the defects in the solutions in the prior art are the result of practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the embodiments of this application in the following text should be regarded as contributions to this application in the process of invention and creation, and should not be understood as technical content known to those skilled in the art.

[0017] Based on the discovery of the above-mentioned technical problems, this embodiment provides a texture resource management method. As shown in Figure 1, the method includes: S1, in response to the user's update operation on the visible area, determining invisible objects that have left the visible area.

[0018] S2, determine the target texture in video memory corresponding to the invisible object.

[0019] S3. If there are no remaining target visible objects in the visible area, then reclaim the video memory resources occupied by the target texture.

[0020] The target visible object is the display object within the visible area that depends on the target texture.

[0021] In this way, by promptly identifying and releasing texture resources that are not referenced by visual objects, the risk of excessive consumption of video memory is mitigated.

[0022] It should be noted that the texture resource management method provided in this embodiment can run on electronic devices with graphics processing capabilities and support dynamic resource loading. Specifically, such electronic devices include, but are not limited to, smartphones, tablets, personal computers, game consoles, augmented reality (AR) / virtual reality (VR) devices, and smart TVs. These devices all have the ability to run graphics applications and can support the creation, use, and release of texture resources in video memory through the access interface provided by the operating system.

[0023] To make the solution provided in this embodiment clearer, a VR device is used as an example below, and the steps of the method are described in detail with reference to Figure 1. However, it should be understood that the operations in the flowchart may not be implemented in sequence, and steps without logical contextual relationships may be reversed in order or implemented simultaneously. Furthermore, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowchart, or remove one or more operations from the flowchart. Continuing to refer to Figure 1, the method includes: S1, in response to a user's update operation on the visible area, determining invisible objects that have left the visible area.

[0024] It should be understood that user actions updating the visible area can refer to interactive operations such as swiping, scrolling, page turning, or clicking within the visible area. Taking VR devices as an example, VR devices can present the application interface in three-dimensional space. Users can interact with the interface through head movements or controller movements, thereby updating the visible area. In this scenario, the visible area refers to the display area generated by the application in the VR environment that is currently directly observable by the user. In practical applications, when a user rotates their head or uses a specific button on the controller to swipe, the VR device recognizes this interaction as an update operation to the visible area, thus updating the displayed content of the current visible area. If this update operation causes a displayed object to leave the display area, that object is determined to be invisible.

[0025] For example, as shown in Figure 2, when using a live streaming program through a VR device, a visible area 12 of the live streaming program is displayed in the VR environment 11. Multiple preview covers 13 of live streaming rooms are displayed horizontally within this visible area 12 for the user to select from. When the user uses a controller to swipe down on the displayed content within the visible area to view more recommended content, some of the preview covers 13 that were originally in the visible area 12 gradually move out of the visible area, and these covers are recognized as invisible objects by the VR device.

[0026] Based on the above description of the visible area and the invisible object, referring to Figure 1, we will continue to explain step S2 in Figure 1: S2, determine the target texture in the video memory corresponding to the invisible object.

[0027] In practical applications, for invisible objects that leave the visible area due to update operations, VR devices need to know which texture was used to display these invisible objects. In this embodiment, an invisible object can be an avatar or a background image. Before leaving the visible area, the VR device maintains the target texture that the invisible object depends on in the background. Therefore, the VR device can find the target texture that the invisible object depends on based on its internal identifier or resource link information.

[0028] S3. If there are no remaining target visible objects in the visible area, then reclaim the video memory resources occupied by the target texture.

[0029] As an optional implementation, the target texture is configured with a reference count, which represents the number of target visible objects before the update operation. Furthermore, before step S3, the VR device can update the reference count based on the number of invisible objects and the number of the first newly added objects, where the first newly added objects represent the target visible objects that enter the visible area during the update operation; if the updated reference count is 0, it is determined that no visible objects remain in the visible area.

[0030] This embodiment can be understood as follows: by setting a reference count for each target texture, it can accurately determine whether the texture is still being used by the currently visible object.

[0031] First, it's important to understand that during graphics rendering, multiple display objects may share the same texture resource to save on video memory. For example, multiple user avatar cards or video covers might reference the same downloaded web texture. In practice, VR devices can manage the state of each texture resource uniformly through a structure called WebTextureInfo, which includes a field called refCount, specifically used to record how many display objects within the visible area are currently referencing the texture. In other words, the reference count of the target texture represents the number of target visible objects before the update operation.

[0032] Therefore, during the above steps, when a visual object that was originally located in the visible area leaves the visible area due to an update operation and becomes an invisible object, the VR device searches for the texture resource associated with the invisible object, determines the target texture in the video memory corresponding to the invisible object, and decrements the reference count of that target texture. Simultaneously, new display objects may also enter the visible area during the update operation. Some of these newly arrived display objects may also use the same target texture; these objects are called the first newly added objects. Therefore, when updating the reference count, not only the impact of the number of departing objects must be subtracted, but also the number of first newly added objects must be considered. In other words, the VR device calculates and updates the reference count of the target texture based on a comprehensive calculation of the number of departing invisible objects and the number of newly added first newly added objects.

[0033] When the reference count becomes zero after being updated, it indicates that no display object in the current visible area depends on the target texture, and the VR device can then perform subsequent texture destruction and memory reclamation actions.

[0034] For example, if multiple preview covers in the live streaming program shown in Figure 2 share the same texture of the streamer's avatar, when the last of the multiple preview covers leaves the visible area and completes the decrement of the reference count, and no new preview cover uses the streamer's avatar as the target texture, the VR device will perform memory reclamation. This effectively prevents other display abnormalities caused by the exit of individual objects and also alleviates the risk of excessive consumption.

[0035] Based on the above implementation methods, the study also found that users typically exhibit a continuous unidirectional scrolling habit when operating on the visible area. For example, when browsing candidate video covers or audience avatar walls in a live streaming program, users often scroll continuously in one direction to view new content. In this scenario, if the video memory resources occupied by the target texture are reclaimed immediately after its reference count reaches zero, then when subsequent new display objects need to use the same texture due to entering the visible area, the loading, decoding, and uploading process must be re-executed, resulting in unnecessary performance overhead. Therefore, when performing step S3 to reclaim the video memory resources occupied by the target texture, the method specifically includes: S3-1, obtaining the update direction of the update operation.

[0036] The update direction can be any of the four directions: up, down, left, or right, determined by the interaction logic provided by the application itself. For example, in a vertically arranged list of live stream recommendations displayed on a VR device, when a user slides or pushes vertically using the touchpad or joystick on the VR device's remote control, this action is recognized as vertical scrolling, driving the list to scroll up and down to browse more options; while if the live stream recommendation list is designed for horizontal browsing, the user's horizontal input will drive the list to scroll left and right to browse more options.

[0037] S3-2, If there are potential display objects that depend on the target texture for rendering in the update direction, determine the waiting time required before recycling the target texture.

[0038] Among them, potential display objects refer to display objects located in the update direction that have not yet entered the visible area.

[0039] The above steps can be understood as follows: this embodiment dynamically determines whether to delay the timing of video memory reclamation by judging whether there are potential display objects in the current update direction that may require the target texture to be rendered in the future. Specifically, when the VR device detects such potential usage needs, it does not immediately release the video memory resources occupied by the target texture, but introduces a waiting time mechanism to temporarily retain the target texture in video memory. During this period, if a potential display object enters the visible area and becomes visible, causing the target texture to be referenced again, the existing texture can be reused directly, avoiding repeated loading and decoding; if no potential display object enters the visible area after the set waiting time, the video memory reclamation operation is finally performed.

[0040] To determine the required waiting time before reclaiming the target texture, as an optional implementation, the VR device can determine the required waiting time before reclaiming the target texture based on the update speed in the update direction.

[0041] This can be understood as follows: during the user's update operation on the visible area, the scrolling behavior not only has directionality but also includes speed information, which reflects the pace at which the user browses the content. In this embodiment, when the VR device determines that the video memory resources occupied by the target texture need to be reclaimed, it dynamically adjusts the timing of reclamation based on the update speed of the visible area.

[0042] Specifically, VR devices can determine the physical distance between potential display objects and the current visible area based on the interface layout. This physical distance refers to the spatial offset along the scroll axis between the initial position of the potential display object and the distance it needs to travel to enter the visible area. For example, in a vertically scrolling list, if a potential display object is located at the Nth item below the current visible window, and each item has a height of H, then this distance can be represented as N×H. Based on this distance information and the acquired update rate, the VR device can estimate the waiting time required for the potential display object to enter the visible area.

[0043] It should be noted that the predicted waiting time mentioned above is only based on the current update operation. In practical applications, if the user stops scrolling or changes the update direction midway, potential display objects in the original predicted path may not enter the visible area. In this case, the VR device does not need to continue retaining the corresponding target texture in the video memory and should reclaim it.

[0044] S3-3: If the potential display object does not enter the visible area after the waiting period, the video memory resources occupied by the target texture will be reclaimed.

[0045] In practical applications, VR devices can continuously track the reference count changes of the target texture. If the reference count of the target texture is still zero when the waiting period ends, it indicates that the potential display object has not entered the visible area, meaning that no new visible object depends on the target texture for rendering, i.e., there is no actual usage requirement. Therefore, the VR device performs a video memory resource reclamation operation, removing the target texture from the video memory, thereby freeing up the graphics processor memory space it occupies.

[0046] The study also found that, under the action of the update operation, if a display object that does not depend on the target texture enters the visible area, the VR device needs to initiate a network request to a remote server based on its corresponding Uniform Resource Locator (URL) to download the required texture data. In related technologies, developers usually encapsulate a download function, passing in a URL and a callback function. When multiple requests are initiated, this download function is called independently, and if the URLs are the same, it will lead to duplicate downloads. For example, if two different UI components need to display the same player avatar, they will each call the download function. Since the download is asynchronous, the second request may have been initiated before the first download is completed, resulting in the same image being downloaded twice. Therefore, related technologies lack effective management of texture resources. In view of this, this embodiment also provides the following optional implementation: S4, determine the second newly added object that enters the visible area with the update operation.

[0047] The second newly added object refers to a display object that does not depend on the target texture for display. In other words, the GPU's video memory does not contain the texture resources that the display of the second newly added object depends on, and these resources need to be reloaded.

[0048] S5. If a reusable texture matching the second newly added object is cached in the texture pool, the reusable texture is loaded from the texture pool into the video memory, and the second newly added object is rendered.

[0049] In practical applications, assume the live streaming program is implemented based on a 3D engine and provides a texture pool named Texture2DPool in memory for centralized management of reusable Texture2D objects. Texture2D is the core graphics resource class defined by this 3D engine, specifically designed for representing and processing two-dimensional textures. When the VR device detects a second newly added object entering the visible area and confirms that a reusable texture matching the second newly added object is cached in the texture pool, it does not need to download the corresponding compressed image data from the server again, nor does it need to dynamically create a new Texture2D instance through the `new` operation. Instead, it directly obtains a pre-created Texture2D object that is currently in an available state from Texture2DPool.

[0050] Therefore, during the above steps, if the VR device detects a reusable texture that matches the second newly added object from the texture pool, it writes the previously decoded texture data into the reusable Texture2D object and uploads it to the graphics processor's video memory, thereby completing the rendering of the newly added object.

[0051] It should also be understood that the texture pool is responsible for resource reclamation. When a Texture2D object is no longer referenced by any new object, the VR device does not immediately destroy the object. Instead, it calls the RecycleTexture method to return it to the Texture2DPool and checks whether the number of cached objects in the pool has reached a preset limit. If it is not full, the Texture2D object is retained for reuse in subsequent requests; if it is full, the object is actively destroyed to prevent excessive memory consumption.

[0052] In this way, by providing a texture pool to manage and reuse texture resources, repeated network requests and high-overhead object initialization processes are avoided, significantly reducing memory allocation frequency and garbage collection pressure, thereby improving rendering efficiency and running smoothness.

[0053] In practice, it was also found that during the operation of the graphics rendering system, when multiple new objects successively enter the visible area, if the reusable textures they depend on are not cached in the pre-configured texture pool, the corresponding resources need to be obtained from a remote server via network requests. In related technologies, whenever a texture is detected as missing, the VR device immediately initiates a download task, that is, each request triggers an independent network operation. However, this method is prone to network congestion. In view of this, the texture resource management method provided in this embodiment further includes: S6, if the texture pool does not cache a reusable texture that matches the second newly added object, a download task for the reusable texture is generated and added to the task queue as a task to be scheduled; S7, if the current number of concurrent tasks is less than the preset maximum number of concurrent tasks, the target task is selected from the task queue and started for execution.

[0054] Here, the task concurrency number represents the number of active tasks, and an active task represents a download task that is in the execution state.

[0055] The above steps can be understood as follows: after determining that the texture corresponding to the second newly added object does not exist in the texture pool, the network download is not started directly. Instead, a corresponding download task is generated and added to the task queue as a task to be scheduled. In this embodiment, this task queue is called m_ProcessingWebTextureList, and each element stored inside it is called WebTextureInfo, representing a texture download request to be processed.

[0056] Therefore, during the execution of the above steps, the VR device detects the current concurrent task count, that is, the number of active tasks in the execution state. This value is maintained in real time by a variable called m_CurrentProcessingCount, which tracks the total number of download tasks that have started but not yet completed. The VR device is also configured with an upper limit threshold called MAX_COUNT to control the number of download tasks that can be executed simultaneously. Only when m_CurrentProcessingCount is less than MAX_COUNT will the VR device select the next target task from the m_ProcessingWebTextureList queue, for example, by taking it from the head of the queue in first-in-first-out order or according to a priority strategy, and trigger the network request corresponding to that task.

[0057] In this way, the actual number of download tasks running in parallel is always limited to the threshold specified by MAX_COUNT, effectively preventing the impact of a large number of instantaneous requests on the network channel and server.

[0058] In practice, it was also found that in scenarios with unstable network environments or abnormal server responses, download tasks may fail due to connection timeouts, data transmission interruptions, or incorrect response codes. If a download failure message is directly returned, subsequent requests for the same texture resource will still need to be re-initiated, which will actually increase latency. Therefore, the texture resource management method provided in this embodiment further includes: S8, if the active task fails, a retry task with the same task objective as the active task is generated.

[0059] S9 adds the retry task as a task to be scheduled to the task queue.

[0060] Specifically, when a VR device detects that an activity task has failed to execute, that is, the task has failed to successfully complete the download operation of texture resources, the VR device will generate a new retry task based on the failed task, and the task objective of the retry task is completely consistent with the original activity task.

[0061] For example, continuing with the WebTextureInfo object mentioned above, it includes a cached status identification mechanism to record the current status of each download request. When a download attempt fails, the corresponding WebTextureInfo object's status is marked as DownloadFailed. At this time, the VR device will not directly return a failure result, but will determine the status and trigger retry logic, that is, resubmit the WebTextureInfo object to the download queue m_ProcessingWebTextureList, waiting for processing again.

[0062] This ensures that failed requests can be automatically recovered, improving the success rate and robustness of texture loading.

[0063] It should also be noted that the texture resources in this embodiment are typically stored on a remote server as compressed image files, such as JPEG, PNG, or WebP formats. These compressed images have a smaller data size during transmission, which helps reduce network bandwidth consumption and speeds up downloads. However, compressed images themselves cannot be used directly for rendering; they must undergo a decoding process to be converted into a texture data structure that the GPU can recognize, thus enabling texture reuse. Therefore, the data downloaded by the download task is actually an encoded compressed image, which cannot be directly used for rendering.

[0064] Therefore, as an optional implementation, the VR device will also decode the compressed image into a reusable texture and cache it in the texture pool; based on the reusable texture, rendering information for the reusable texture will be generated. The rendering information consists of metadata used for rendering control.

[0065] This can be understood as follows: when a second newly added object requires texture support but the corresponding texture is not cached, the VR device will generate a download task. The goal of this download task is to obtain the compressed image corresponding to the reusable texture, that is, a binary data stream stored in standard image compression formats such as JPEG, PNG or WebP.

[0066] Therefore, during the above steps, after receiving the compressed image, the VR device does not directly upload it to the video memory for rendering. Instead, it first performs a decoding operation to convert the compressed image into a reusable texture that can be used by the graphics rendering system, such as a Texture2D object in a 3D engine. After decoding, the generated reusable texture is cached in a pre-configured texture pool so that subsequent requests for the same resource can be quickly hit and reused, avoiding the additional overhead caused by repeated downloading and decoding.

[0067] Furthermore, to support more refined rendering control logic, VR devices also create corresponding rendering information based on the generated reusable textures. This rendering information refers to metadata used for rendering control, defining how textures are correctly mapped onto geometric primitives. Its specific content includes, but is not limited to, parameter information required for interaction with the rendering pipeline, such as texture size, position, and pixel format.

[0068] In actual rendering, when a texture needs to be applied to a specific display object in the visible area (such as a user avatar, icon, or interface control), some 3D engines do not directly use the decoded reusable texture. Instead, they combine it with the corresponding rendering information and encapsulate it into a renderable primitive entity. Therefore, to improve operational efficiency and avoid repeatedly constructing such primitive entities every time they need to be displayed, VR devices can introduce a caching mechanism. For example, a separately maintained cache structure can be used to store constructed primitive entities on demand. This cache uses the unique identifier of the texture resource as the lookup key to achieve fast retrieval and reuse of frequently used primitive entities.

[0069] In this way, when the same display object enters the visible area again, the corresponding primitive entity can be directly obtained from the cache, skipping high-overhead processes such as texture loading, decoding and object assembly, thereby significantly reducing the CPU processing burden and improving the overall rendering response speed.

[0070] This can be understood as limiting the downloaded content to compressed images rather than decoded textures, and then decoding them locally into reusable textures and generating texture information, thereby reducing the amount of data transmitted over the network and avoiding the additional overhead caused by repeated downloading and decoding.

[0071] In the above embodiments, each step of the texture resource management method provided in this embodiment has been described. The method will be fully described below with reference to Figure 3.

[0072] As shown in Figure 3, when a VR device initiates an image request, it uses the image's unique identifier (e.g., URL) as an index to query whether the corresponding image binary data exists in the memory cache. Here, image binary data refers to images stored in compressed formats such as JPEG, PNG, or WebP.

[0073] If the image's binary data exists in the memory cache, it is directly retrieved and the process proceeds to the next step. If it does not exist, the process further checks if a corresponding file exists in the disk cache. If the disk cache is hit, the file is read into memory; if not, the image's binary data is downloaded from the network and saved to the memory cache after downloading.

[0074] Before writing the downloaded compressed image to the memory cache, the VR device determines whether the cache has reached its preset capacity limit. If the limit has been reached, the device uses algorithms such as LRU (Least Recently Used) to write the binary data of images that are accessed less frequently to the disk cache and remove them from the memory cache to free up space.

[0075] When a new object needs to be displayed (i.e., it enters the visible area), the VR device decodes the binary data of the image in memory on demand, generates a reusable texture (e.g., Texture2D), uploads the texture to the GPU memory, performs rendering operations, and displays the image on the screen.

[0076] When a VR device detects that the displayed image has left the visible area due to the user scrolling, it determines that the image is no longer visible and can destroy the corresponding target texture in the video memory, releasing the GPU video memory and temporary memory resources it occupies.

[0077] It is worth noting that although the target texture is destroyed, the reusable texture it decodes is cached in the texture pool so that it can be used directly in the next rendering, instead of being decoded repeatedly in an unordered manner.

[0078] Based on the same inventive concept as the texture resource management method provided in this embodiment, this embodiment also provides a texture resource management device, which includes at least one software functional module that can be stored in memory or embedded in an electronic device. The processor in the electronic device is used to execute the executable module stored in memory. For example, the software functional module and computer program included in the device. Referring to Figure 4, functionally, the device may include: an operation interaction module 21, used to determine invisible objects that have left the visible area in response to a user's update operation on the visible area; a texture management module 22, used to determine the target texture in the video memory corresponding to the invisible object; the texture management module 22 is also used to reclaim the video memory resources occupied by the target texture if no target visible object remains in the visible area, wherein the target visible object is a display object in the visible area that depends on the target texture.

[0079] In this embodiment, the operation interaction module 21 is used to implement step S1 in FIG1, and the texture management module 22 is used to implement steps S2 and S3 in FIG1. ​​Therefore, for a detailed description of each of the above modules, please refer to the specific implementation of the corresponding steps.

[0080] Since it shares the same inventive concept as the texture resource management method provided in this embodiment, the texture resource management device can implement other steps or sub-steps of the method through the above-described modules.

[0081] Optionally, the target texture is configured with a reference count, which represents the number of target visible objects before the update operation. Before reclaiming the video memory resources occupied by the target texture, the texture management module 22 is further configured to: update the reference count based on the number of invisible objects and the number of the first newly added objects, wherein the first newly added objects represent the target visible objects that enter the visible area with the update operation; if the updated reference count is 0, it is determined that there are no visible objects remaining in the visible area.

[0082] Optionally, when reclaiming the video memory resources occupied by the target texture, the texture management module 22 is further specifically used to: obtain the update direction of the update operation; if there is a potential display object that depends on the target texture for rendering in the update direction, determine the waiting time required before reclaiming the target texture, wherein the potential display object refers to a display object located in the update direction that has not yet entered the visible area; if the potential display object has not entered the visible area after the waiting time, then the video memory resources occupied by the target texture are reclaimed.

[0083] Optionally, the texture management module 22 is also specifically used to: determine the waiting time required before recycling the target texture based on the update speed in the update direction.

[0084] Optionally, the operation interaction module 21 is further configured to: determine the second newly added object that enters the visible area with the update operation, wherein the second newly added object represents a display object that does not depend on the target texture for display; the texture management module 22 is further configured to: if there is a reusable texture in the texture pool that matches the second newly added object, load the reusable texture from the texture pool into the video memory and render the second newly added object.

[0085] Optionally, the texture management module 22 is further configured to: if there is no reusable texture in the texture pool that matches the second newly added object, generate a download task for the reusable texture and add it to the task queue as a task to be scheduled; if the current task concurrency is less than the preset maximum concurrency, select the target task from the task queue and start its execution, wherein the task concurrency represents the number of active tasks and the active task represents a download task in the execution state.

[0086] Optionally, the texture management module 22 is also used to: generate a retry task with the same task objective as the active task if the active task fails to execute; and add the retry task as a task to be scheduled to the task queue.

[0087] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0088] It should also be understood that if the above embodiments are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, 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, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0089] Therefore, this embodiment also provides a storage medium, which is a computer-readable storage medium. The storage medium stores a computer program, which, when executed by a processor, implements the texture resource management method provided in this embodiment. The storage medium can be any medium capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0090] This embodiment provides an electronic device for implementing a texture resource management method. As shown in FIG5, the electronic device may include a processor 32 and a memory 31. The memory 31 stores a computer program, and the processor implements the texture resource management method provided in this embodiment by reading and executing the computer program corresponding to the above embodiments stored in the memory 31.

[0091] Referring again to Figure 5, the electronic device also includes a communication unit 33. The memory 31, processor 32, and communication unit 33 are electrically connected to each other directly or indirectly via a system bus 34 to achieve data transmission or interaction.

[0092] The memory 31 can be an information recording device based on any electronic, magnetic, optical, or other physical principles, used to record execution instructions, data, etc. In some embodiments, the memory 31 can be, but is not limited to, volatile memory, non-volatile memory, memory drive, etc.

[0093] In some embodiments, the volatile memory may be random access memory (RAM); in some embodiments, the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc.; in some embodiments, the storage drive may be a disk drive, solid-state drive, any type of storage disk (such as optical disc, DVD, etc.), or similar storage media, or a combination thereof.

[0094] The communication unit 33 is used to send and receive data via a network. In some embodiments, the network may include a wired network, a wireless network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, a ZigBee network, or a near field communication (NFC) network, or any combination thereof. In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations and / or network switching nodes, through which one or more components of an electronic device can connect to the network to exchange data and / or information.

[0095] The processor 32 may be an integrated circuit chip with signal processing capabilities, and may include one or more processing cores (e.g., a single-core processor or a multi-core processor). By way of example only, the processor described above may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an Application Specific Instruction-set Processor (ASIP), a Graphics Processing Unit (GPU), a Physics Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computing (RISC) computer, or a microprocessor, or any combination thereof.

[0096] For clarity, the structure shown in Figure 5 is for illustrative purposes only. Electronic devices may have more or fewer components than those shown in Figure 5, or may have different configurations. The components shown in Figure 5 may be implemented using hardware, software, or a combination thereof.

[0097] It should be understood that the apparatus and methods disclosed in the above embodiments can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0098] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A texture resource management method, characterized in that, The method includes: in response to a user's update operation on the visible area, determining an invisible object that has left the visible area; determining a target texture in video memory corresponding to the invisible object; and if there is no target visible object remaining in the visible area, reclaiming the video memory resources occupied by the target texture, wherein the target visible object is a display object in the visible area that depends on the target texture.

2. The texture resource management method according to claim 1, characterized in that, The target texture is configured with a reference count, which represents the number of target visible objects before the update operation. Before reclaiming the video memory resources occupied by the target texture, the method further includes: updating the reference count based on the number of invisible objects and the number of first newly added objects, wherein the first newly added objects represent target visible objects that enter the visible area with the update operation; if the updated reference count is 0, it is determined that there are no remaining visible objects in the visible area.

3. The texture resource management method according to claim 1, characterized in that, When reclaiming the video memory resources occupied by the target texture, the method further includes: obtaining the update direction of the update operation; if there is a potential display object that depends on the target texture for rendering in the update direction, determining the waiting time required before reclaiming the target texture, wherein the potential display object refers to a display object located in the update direction that has not yet entered the visible area; if the potential display object has not entered the visible area after the waiting time, then the video memory resources occupied by the target texture are reclaimed.

4. The texture resource management method according to claim 3, characterized in that, Determining the required waiting time before recycling the target texture includes: determining the required waiting time before recycling the target texture based on the update rate in the update direction.

5. The texture resource management method according to any one of claims 1-4, characterized in that, The method further includes: determining a second newly added object that enters the visible area with the update operation, wherein the second newly added object represents a display object that does not depend on the target texture for display; if a reusable texture matching the second newly added object is cached in the texture pool, then the reusable texture is loaded from the texture pool into the video memory, and the second newly added object is rendered.

6. The texture resource management method according to claim 5, characterized in that, The method further includes: if the texture pool does not cache a reusable texture that matches the second newly added object, then a download task for the reusable texture is generated and added to the task queue as a task to be scheduled; if the current task concurrency is less than the preset maximum concurrency, then a target task is selected from the task queue and started to execute, wherein the task concurrency represents the number of active tasks, and the active task represents a download task in the execution state.

7. The texture resource management method according to claim 6, characterized in that, The method further includes: if the activity task fails to execute, generating a retry task with the same task objective as the activity task; and adding the retry task as a task to be scheduled to the task queue.

8. A texture resource management device, characterized in that, The device includes: an operation interaction module, configured to respond to a user's update operation on the visible area and determine an invisible object that has left the visible area; a texture management module, configured to determine a target texture in the video memory corresponding to the invisible object; and if there is no target visible object remaining in the visible area, to reclaim the video memory resources occupied by the target texture, wherein the target visible object is a display object in the visible area that depends on the target texture.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the texture resource management method according to any one of claims 1-7.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program that, when executed by the processor, implements the texture resource management method according to any one of claims 1-7.

Images