Method, apparatus and device for texture display

Abstract

The application provides a texture display processing method and device and a vehicle. The method comprises the following steps: in response to a received texture loading request, rendering a target texture; the target texture is a texture to be displayed pointed by the texture loading request; in the case that the target texture meets a first condition, rendering a backup texture which is successfully pre-loaded to display the backup texture; the first condition is used to represent that the target texture cannot be successfully rendered normally. The scheme uses the backup texture to bottom out, avoids the problem of black screen, and improves the display effect.

Description

Technical Field

[0001] This application relates to vehicle control technology, and more particularly to processing methods, apparatus and devices for texture display. Background Technology

[0002] In mobile application development, graphics rendering is one of the core technologies for achieving visual interaction, especially in scenarios that require dynamically displaying complex image content, such as in-vehicle infotainment systems, where higher demands are placed on the efficient and stable loading and display of textures. The GLSurfaceView component, a commonly used OpenGL ES rendering view component on the Android platform, is widely used to visualize 3D graphics and dynamic textures.

[0003] In related technologies, texture resources are typically loaded using utility classes such as texture loaders and rendered through the rendering pipeline. However, due to the complexity of the scene, rendering failures may occur, resulting in a black screen, which is difficult to meet actual needs. Summary of the Invention

[0004] To address the aforementioned issues, this application provides at least one processing method, apparatus, and device for texture display. This solution uses a backup texture to avoid the black screen problem and improves the display effect.

[0005] The technical solution of this application is implemented as follows: In a first aspect, this application provides a method for processing texture display, the method comprising: in response to a received texture loading request, rendering a target texture; the target texture being the texture to be displayed as pointed to by the texture loading request; and rendering a pre-loaded backup texture to display the backup texture if the target texture satisfies a first condition; the first condition being used to characterize that the target texture cannot be rendered successfully.

[0006] Secondly, this application provides a texture display processing apparatus, the apparatus comprising: a first rendering unit, configured to render a target texture in response to a received texture loading request; the target texture being the texture to be displayed as pointed to by the texture loading request; and a second rendering unit, configured to render a pre-loaded backup texture to display the backup texture if the target texture satisfies a first condition; the first condition being used to characterize that the target texture cannot be rendered successfully.

[0007] Thirdly, this application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program or instructions, and when the computer program or instructions are executed by the processor, the method provided in the first aspect is implemented.

[0008] Fourthly, this application also provides a storage medium storing a computer program or instructions that, when executed by a processor, implement any of the methods provided in the first aspect above.

[0009] Fifthly, this application also provides a computer program product comprising a computer program or instructions that, when executed by a processor, implement any of the methods provided in the first aspect above.

[0010] In this solution, in response to a received texture loading request, the system first attempts to render the target texture. If the target texture fails to render normally due to loading failure, parsing failure, or rendering failure, the first condition is triggered, and a pre-loaded, successfully loaded backup texture is then rendered for display. By automatically switching to the backup texture when the target texture fails to render normally, the black screen phenomenon caused by texture loading anomalies is avoided, improving the stability and integrity of the interface display. This solution is particularly suitable for scenarios such as in-vehicle systems and industrial control systems where high display continuity is required. Attached Figure Description

[0011] Figure 1 This is a schematic flowchart of an optional texture display processing method provided in an embodiment of this application. Figure 2 A schematic diagram of an optional texture loading process provided in an embodiment of this application; Figure 3 This is a schematic diagram of an optional structure of the verification module provided in an embodiment of this application; Figure 4 This is an optional schematic diagram illustrating the collaborative relationship of the thread synchronization loading module provided in the embodiments of this application; Figure 5 A schematic diagram of an optional fallback handling process for loading failure provided in an embodiment of this application; Figure 6 This is a schematic diagram of an optional structure of the texture display processing apparatus provided in an embodiment of this application.

[0012] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of the application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0014] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0015] In the following description, the terms "first," "second," and "third" are used only to distinguish different objects and do not represent a specific order of objects or have any chronological limitation. It is understood that "first," "second," and "third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0017] This application provides a method, apparatus, device, storage medium, and program product for texture display. The following describes various embodiments of the texture display processing method, apparatus, device, storage medium, and program product provided in this application.

[0018] In a first aspect, embodiments of this application provide a method for processing texture display. This method can be executed by a texture display processing device, which can be deployed in an electronic device and implemented through a program stored in a memory by a processor.

[0019] To facilitate understanding, some technical terms will be explained first.

[0020] GL Surface View: An OpenGL ES-based view component in the Android platform, used to render 2D / 3D graphics, dynamic textures, and other content in application interfaces. It is commonly used in scenarios requiring high-performance graphics rendering, such as games, AR / VR, and in-vehicle UIs. Internally, it contains an independent rendering thread (GL Thread) responsible for executing OpenGL drawing instructions.

[0021] Texture: In graphics rendering, texture refers to image data used to be applied to the surface of a 3D model or a 2D plane, typically stored in formats such as JPG, PNG, and ETC2. Texture loading refers to the process of parsing these image files into OpenGL-recognizable texture IDs and binding them to the rendering pipeline; it is a fundamental step in achieving visual effects.

[0022] The first condition is a criterion used to determine if a target texture cannot be rendered successfully. It covers various scenarios, including loading failure (e.g., incorrect path, file not found), parsing failure (e.g., unsupported format, corrupted data), and rendering failure (e.g., OpenGL API call error, memory overflow). When any of these scenarios occurs, the first condition is deemed met, triggering the subsequent fallback processing flow.

[0023] Fallback Texture: A pre-loaded and cached texture resource used to replace the target texture when loading fails. It typically includes a transparent texture (to maintain background transparency) or a default icon texture (to indicate loading failure to the user). Fallback textures are loaded during application initialization to ensure they are immediately available when needed, thus avoiding a black screen.

[0024] Anomaly monitoring and feedback: This refers to capturing exceptions through a try-catch mechanism at each key stage of texture loading (such as verification, loading, and rendering), recording exception type, trigger time, device parameters, stack information, etc., and generating corresponding optimization suggestions based on the exception type (such as checking the texture path, changing the texture format, and releasing unused resources), providing developers with accurate troubleshooting basis and optimization direction.

[0025] Thread synchronization mechanism: To avoid conflicts caused by multi-threaded operations on the OpenGL context, this solution adopts a collaborative mode of main thread scheduling, asynchronous thread loading, and GL Thread rendering. It uses Count Down Latch to achieve synchronous waiting between asynchronous thread and GL Thread, and uses the synchronized keyword to ensure the safety of texture ID transmission. It ensures that the rendering operation is only performed after loading is complete, thereby ensuring the stability of the rendering process.

[0026] Pre-load verification module: This module performs comprehensive verification of the loading requirements before texture loading, including path validity verification (whether the local / network path is accessible), format compatibility verification (whether it is supported by the current device's OpenGL version), memory sufficiency verification (whether the remaining memory is sufficient for texture loading), and device compatibility verification (whether the OpenGL version and rendering configuration match). It aims to filter invalid loading requests from the source and reduce the probability of loading failure.

[0027] The following section uses an electronic device as an example to explain the processing method for this texture display.

[0028] In some embodiments, reference Figure 1 The process may include, but is not limited to, S101 and S102 described below.

[0029] S101, The electronic device responds to the received texture loading request and renders the target texture.

[0030] The target texture is the texture to be displayed as pointed to by the texture loading request.

[0031] In this step, a texture loading request refers to an instruction triggered by the application layer or user interaction that requires the electronic device to load and display a specific texture resource.

[0032] Texture loading requests typically contain texture identification information, such as a local file path (e.g., / res / drawable / icon.png), a network URL (e.g., https: / / example.com / textures / background.jpg), or a unique ID in a memory cache.

[0033] Upon receiving a texture loading request, the electronic device needs to initiate the texture loading process. The core objective of the texture loading request is to parse the image data pointed to by the request into a texture object that can be recognized by the graphics rendering engine (such as OpenGL ES) and bind it to the rendering pipeline for visualization. The target texture refers to the specific texture resource specified by the texture loading request. The target texture may be an icon, background image, 3D model texture, etc. in the user interface, and its final presentation effect directly affects the user experience.

[0034] For example, when a user clicks the "Switch Theme" button on the vehicle's navigation interface, the electronic device generates a texture loading request pointing to the new theme background image, theme_background.png. The texture file is stored in the device's local resource directory. Another example is in AR applications, where the user captures a real-world scene using a camera. The electronic device dynamically loads the corresponding virtual texture (such as virtual_marker.png) based on the recognition results to overlay it onto the real-world image. In this case, the texture pointed to by the texture loading request is the target texture.

[0035] The execution entity is the application running on the Android electronic device, specifically executed by the component responsible for graphics rendering (such as GLSurfaceView) and its associated rendering thread (GLThread). The application can be a dashboard UI application in an in-vehicle electronic device, industrial control panel software, mobile game clients, etc., all of which rely on OpenGL ES for graphics rendering.

[0036] In practice, the electronic device first captures the texture loading request, parses the texture identification information within it, and then calls the texture loading module to begin processing. The technical advantage lies in ensuring real-time interaction between user actions and visual feedback by proactively responding to texture loading requests and initiating the rendering process, thus avoiding stuttering caused by delays or lack of response. As the starting point of the entire process, it provides clear triggering conditions for subsequent pre-verification, thread synchronization, and fallback mechanisms, laying the foundation for closed-loop management throughout the entire process.

[0037] S102. If the target texture meets the first condition, the electronic device renders the pre-loaded backup texture to display the backup texture.

[0038] The first condition is used to characterize the target texture as failing to render successfully.

[0039] The first condition refers to any situation that occurs during texture loading, parsing, or rendering that prevents the target texture from being successfully displayed. These situations include, but are not limited to: invalid texture path (e.g., file does not exist, network address is unreachable), incompatible texture format (e.g., the current device does not support ETC2 compression format), insufficient memory (remaining memory is less than 1.2 times the redundancy threshold of the memory required for loading), device OpenGL version is too low (e.g., only supports OpenGL ES 1.1, while the texture requires 2.0 or higher), asynchronous loading process throws IO exception or null pointer exception, OpenGL API call failure (e.g., glGenTextures returns 0), texture binding and rendering failure (e.g., glGetError returns a non-zero error code), etc. When any of the above situations occur, the first condition is determined to be met, and the electronic device will automatically enter the fallback processing flow.

[0040] For example, in a car's infotainment system, if an attempt is made to load `map_icon.png` located in the ` / storage / emulated / 0 / texture_cache / ` directory, but the file has been deleted, the path verification fails, thus satisfying the first condition. Similarly, on a low-end phone, if a 1024×1024 RGBA8888 format texture is loaded, and the available memory is only 3MB while the texture requires 4MB, the memory sufficiency check fails, also satisfying the first condition. Furthermore, a network request timeout causing the texture file download to fail, triggering an I / O exception, also falls under the first condition category.

[0041] Alternate textures are texture resources that are pre-loaded and cached during application initialization to replace the target texture in case of loading failure. The main purpose of alternate textures is to avoid black screen issues and ensure the basic integrity of the interface. Alternate textures are generally divided into two categories: transparent textures, suitable for scenarios that require maintaining background transparency (such as floating windows and semi-transparent controls) to prevent abrupt black screens; and default icon textures, such as loading_fail.png or default_image.png, used to clearly inform the user of loading failure, improving the user experience. Alternate textures use basic formats (such as PNG) to ensure successful loading on various devices.

[0042] For example, in automotive dashboard applications, the default backup texture is a PNG image with a pure white transparent background, used to replace the display when map texture loading fails. In industrial control panel software, the backup texture is a red icon with a loading failure message. When the target monitoring screen texture fails to load, the red icon with the loading failure message will be rendered to help the operator quickly identify the problem.

[0043] In practical implementation, upon detecting that the first condition is met, the electronic device immediately abandons further processing of the target texture and instead retrieves the texture ID of a backup texture from the cache, binding the backup texture to the rendering pipeline. The technical advantage lies in completely eliminating the black screen issue caused by loading failure by introducing a backup texture fallback mechanism, significantly improving the stability and fault tolerance of the interface display. Simultaneously, since the backup texture is loaded when the application starts, it can be rendered instantly upon triggering, ensuring the continuity and smoothness of the user interface, making it particularly suitable for applications with extremely high stability requirements, such as automotive systems and industrial control systems.

[0044] In summary, the texture display processing method provided in this application embodiment achieves closed-loop control over the GLSurfaceView texture loading process by constructing a complete flow of responding to texture loading requests → rendering the target texture → judging the first condition → rendering the backup texture. The texture display processing method provided in this application embodiment not only reduces the probability of loading failure from the source through pre-verification and thread synchronization mechanisms, but also completely solves the technical defects of black screen caused by loading failure in related technologies by introducing a backup texture strategy, significantly improving the fault tolerance, display stability, and user experience of electronic devices. Simultaneously, through the anomaly monitoring and feedback module, the entire loading process is traceable, troubleshootable, and optimizable, making it particularly suitable for application scenarios with extremely high requirements for interface stability, such as in-vehicle systems and industrial control.

[0045] The following describes the process of rendering the target texture in S101.

[0046] This process may include, but is not limited to, S201 to S203 below.

[0047] S201. The electronic device loads the texture file corresponding to the target texture.

[0048] Upon receiving a texture loading request, the electronic device reads and retrieves the texture file corresponding to the target texture based on the path (local resource path, network URL, or memory cache path) specified in the request. The loading process is executed via the File class or a network request tool, ensuring that the texture file corresponding to the target texture is accessible and valid.

[0049] For example, in in-vehicle infotainment systems, when a user switches interfaces, the device triggers a request to load the background texture of the new interface. This initiates S201, which reads the texture file data corresponding to the target texture from local storage or a network server. S201 is a prerequisite for subsequent parsing and rendering; if loading the texture file corresponding to the target texture fails, the subsequent process cannot continue.

[0050] In practice, the electronic device first verifies the validity of the path to the texture file corresponding to the target texture. If the path does not exist or is unreadable, it directly determines that loading the texture file corresponding to the target texture has failed and enters the fallback strategy. For network resources, the electronic device also needs to determine the network connection status and the network address reachability of the texture file corresponding to the network resource.

[0051] This allows for the early identification of invalid paths or missing resources in the texture files corresponding to the target texture, thereby avoiding resource waste and subsequent operational anomalies caused by loading invalid texture files, and ultimately improving overall loading efficiency and electronic device stability.

[0052] S202. The electronic device parses the texture file to obtain pixel data.

[0053] The process of converting a successfully loaded target texture file (such as JPG, PNG, ETC2, etc.) into pixel data (usually a Bitmap object or byte array) that OpenGLES can process. During the parsing process, the electronic device reads the header information of the target texture file to determine its format, and then decodes it pixel by pixel according to the format specification to generate a two-dimensional pixel matrix containing color values. For example, a target texture file in RGBA8888 format (1024×1024) will generate an array containing 4MB of raw pixel data after parsing.

[0054] In practice, the parsing process may involve operations such as decompressing image compression formats (e.g., ETC2, ASTC) and color space conversion (e.g., sRGB to linear space). Electronic devices complete the parsing by calling Android's native BitmapFactory.decodeResource() or similar APIs. If problems such as format incompatibility or data corruption occur during parsing, the parsing of the texture file corresponding to the target texture is considered a failure.

[0055] In this way, the texture files corresponding to non-standard target textures can be converted into a unified pixel data structure, which can then be used by the subsequent rendering pipeline, thereby ensuring consistent processing and compatibility of texture files corresponding to target textures from different sources.

[0056] S203. The electronic device renders the pixel data to obtain the rendered target texture.

[0057] The process involves binding the pixel data parsed in the previous step to GPU texture units via OpenGL ES APIs (such as glGenTextures, glBindTexture, and glTexImage2D), and mapping it onto the rendering canvas of GLSurfaceView, ultimately presenting it as the rendered target texture. Rendering occurs in the default rendering thread (GLThread) of GLSurfaceView, typically executed within the onDrawFrame callback method. For example, in a car's dashboard interface, the electronic device renders the texture file corresponding to the parsed dashboard background target texture to a specified area to achieve a dynamic display effect.

[0058] In practice, the electronic device first generates a texture ID, binds it to a texture target (such as GL_TEXTURE_2D), then uploads the pixel data to the video memory and sets texture parameters (such as filtering mode and wrapping mode). If an OpenGL error occurs during rendering (such as glGetError returning a non-zero value), it is determined that rendering that pixel data has failed.

[0059] This method can transform abstract pixel data into graphical content visible to end users, thereby enabling dynamic updates and interactive displays of interface elements, and ultimately improving the visual experience and the functional integrity of the application.

[0060] The first condition includes at least one of the following: loading failure, parsing failure, and rendering failure; the loading failure is used to indicate that loading the texture file corresponding to the target texture failed, the parsing failure is used to indicate that parsing the texture file corresponding to the target texture failed, and the rendering failure is used to indicate that rendering the pixel data corresponding to the target texture failed.

[0061] Loading failure refers to a situation where the target texture file cannot be successfully read due to reasons such as an invalid path (e.g., file not existing, insufficient permissions, unreachable network), a corrupted texture file, or device incompatibility. For example, if the path to the target texture file points to a deleted local file, or if the network address of the target texture file returns a 404 error, loading the target texture file will fail. Failures to load the target texture file are typically caught by a pre-checking module to prevent invalid loading from consuming electronic device resources.

[0062] Parsing failure refers to a situation where the texture file corresponding to the target texture cannot be correctly converted into pixel data due to reasons such as the target texture's format not being supported by the current device's OpenGL ES version (e.g., an incompatible compressed texture format), corrupted texture file data, or decoder malfunction. For example, if the device only supports the ETC1 format, attempting to parse a texture file corresponding to an ETC2 format target texture will result in parsing failure. Parsing failures can be identified by checking the OpenGL extension list or catching parsing exceptions.

[0063] Rendering failure refers to a situation where pixel data cannot be successfully rendered onto a GLSurfaceView due to reasons such as OpenGL context conflicts, the size of the texture file corresponding to the target texture exceeding device limits, insufficient video memory, or API call errors (such as glTexImage2D returning an error code). For example, when the size of the texture file corresponding to the target texture is too large (e.g., 4096×4096) while the device's maximum texture size is 2048×2048, rendering pixel data will fail.

[0064] The aforementioned first condition constitutes the anomaly monitoring point in the entire texture loading process. Electronic devices can adopt preset fallback strategies (such as loading transparent textures or default icons) based on the specific texture loading failure type to avoid black screen phenomena. Simultaneously, recording the reasons for failure facilitates subsequent electronic device optimization and troubleshooting.

[0065] In this embodiment, the texture loading process is clearly divided into three stages: loading, parsing, and rendering, and specific conditions (loading failure, parsing failure, rendering failure) are defined for each stage. This allows for fine-grained control and anomaly localization throughout the texture loading process, enabling timely triggering of fallback strategies to prevent black screens and thus ensuring the stability of the GLSurfaceView interface and the user experience.

[0066] In one possible implementation, the implementation of S201-S203 may include, but is not limited to, the following S301 to S303.

[0067] S301. The electronic device loads the texture file corresponding to the target texture through the first thread.

[0068] The first thread refers to the initial thread responsible for initiating and executing the texture loading task. In this scheme, it is usually the main thread or a dedicated scheduling thread. The main function of the first thread is to trigger the loading process, calling the pre-verification module to check conditions such as texture path, format, memory, and device compatibility to ensure that the loading environment meets the requirements. If the verification passes, the loading task is submitted to the subsequent processing thread; if the verification fails, the fallback strategy is triggered directly to avoid unnecessary resource consumption. As the entry point of the loading process, the first thread undertakes the functions of task distribution and preliminary exception judgment, ensuring the orderliness and security of the loading process.

[0069] In practical applications, such as in Android in-vehicle electronic devices, when a user clicks on a UI control that requires loading a background texture, the main thread receives the user's click event and immediately calls the texture loading interface, starting a texture loading verification thread to execute the verification logic. If an incorrect texture path or an unsupported format is found, the texture loading verification thread immediately returns a failure status and notifies the user interface to display a preset backup texture, thereby avoiding a black screen due to texture loading failure.

[0070] S302. The electronic device parses the texture file through a second thread to obtain pixel data.

[0071] The second thread is an asynchronous thread dedicated to reading and parsing texture files. Its core function is to convert raw texture files (such as JPG and PNG) into OpenGL-recognizable pixel data (such as Bitmap objects). The second thread runs independently of the main thread and the GLSurfaceView's rendering thread, avoiding UI lag caused by consuming the main thread and preventing context conflicts with the third thread. During parsing, the second thread calls electronic device APIs (such as BitmapFactory.decodeResource or Glide.load) to decode the file and passes the results to the third thread. Because the second thread only handles data processing and does not involve rendering operations, it effectively improves overall loading efficiency and the responsiveness of electronic devices.

[0072] In practical implementation, such as when loading map textures in an in-vehicle navigation interface, the second thread reads a high-resolution map image file from local storage or network cache, parses the map image file into ARGB8888 format pixel data, and safely passes the data to the third thread through a Handler or CountDownLatch mechanism. This texture loading process can handle multiple texture loading tasks in parallel, significantly improving performance in multi-image loading scenarios.

[0073] S303: The electronic device renders the pixel data through a third thread to obtain the rendered target texture.

[0074] The first thread, the second thread, and the third thread are different threads.

[0075] The default rendering thread of GLSurfaceView (GLThread) is responsible for binding pixel data passed from the image processing thread to the OpenGL rendering pipeline and performing the final texture rendering operation. This rendering thread has its own independent OpenGL context, dedicated to graphics drawing and texture mapping, ensuring the stability and efficiency of the rendering process. In the onDrawFrame callback method, this rendering thread receives the texture ID and calls APIs such as glBindTexture and glTexImage2D to complete texture binding and rendering. If a valid texture ID is not received (e.g., the image processing thread fails to resolve it), it automatically switches to a fallback strategy, binding the preset backup texture to replace the black screen display.

[0076] In real-world scenarios, such as dynamically loading vehicle status icon textures on a car dashboard, the third thread continuously monitors data from the second thread. Once a valid texture ID is received, it immediately renders that valid texture ID to the specified location in the current frame, achieving seamless updates. Simultaneously, if a rendering failure is detected (e.g., glGetError returns a non-zero value), a fallback mechanism is immediately triggered to ensure that content is always displayed on the interface.

[0077] The first thread, the second thread, and the third thread are different threads.

[0078] The first thread, second thread, and third thread are three independent thread entities, each with its own responsibilities, corresponding to the task scheduling, data processing, and graphics rendering stages, respectively. The first thread is typically the main thread or scheduling thread, responsible for initializing loading requests and performing pre-verification. The second thread is an asynchronous worker thread, responsible for reading and parsing texture files. The third thread is the rendering thread (GLThread) of GLSurfaceView, responsible for the final texture binding and rendering. These three threads coordinate and communicate through synchronization mechanisms such as Handler and CountDownLatch to ensure the security of data transmission and the correctness of the operation order.

[0079] As a higher-level concept, "thread" can refer to various specific implementation forms, such as: ① Main thread, suitable for UI interaction and task distribution, and suitable for executing lightweight validation and control logic; ② Asynchronous thread, suitable for time-consuming calculations and I / O operations, and suitable for executing heavy-load tasks such as texture parsing; ③ GLThread (OpenGLRendering Thread), dedicated to graphics rendering, with an independent OpenGL context, suitable for performing texture binding and rendering operations. Different threads are adapted to different scenarios: the main thread is suitable for short-term, high-priority tasks; the asynchronous thread is suitable for long-term, non-UI-related tasks; and the GLThread is suitable for graphics-intensive tasks. This multi-threaded architecture has a clear division of labor, effectively avoiding context conflicts and resource contention caused by the architecture, and improving the concurrent processing capabilities and stability of electronic devices.

[0080] In this embodiment, texture loading, parsing, and rendering operations are performed by a first thread, a second thread, and a third thread, respectively. This allows for parallel processing of tasks, reducing performance bottlenecks caused by single-thread blocking, thereby improving the overall efficiency and response speed of texture loading. This effectively avoids black screen issues caused by loading delays or context conflicts, ensuring stable display of the GLSurfaceView interface.

[0081] The texture display processing methods provided in the embodiments of this application can be executed by an application on an electronic device. This application can be integrated into scenarios such as vehicle systems, industrial control software, or mobile game clients, and achieves graphics rendering through the GLSurfaceView component.

[0082] In some implementations, thread management is also required.

[0083] Manage the processes of the first thread, the second thread, and the third thread; so that after the first thread finishes executing and loading the texture file corresponding to the target texture, the second thread is activated; after the second thread finishes executing and parses the texture file to obtain pixel data, the third thread is activated.

[0084] Here, the first thread refers to the asynchronous thread (such as a custom AsyncLoadThread) used to load the texture file corresponding to the target texture. Its main responsibility is to read the texture file content from local resources, network addresses, or memory caches, ensuring that the file data is obtained completely. The second thread refers to the parsing thread (such as ParseThread) used to parse the texture file and generate pixel data. Its core function is to convert the loaded raw texture data (such as JPG or PNG format) into Bitmap objects or pixel arrays that can be recognized by OpenGL ES. The third thread refers to the rendering thread of GLSurfaceView (i.e., GLThread), which is responsible for binding the parsed pixel data to OpenGL texture IDs and performing texture drawing operations in the rendering pipeline. In this embodiment, the process management of the three threads is implemented through a thread scheduler (ThreadScheduler), which creates and maintains the lifecycle of the three threads during the application initialization phase. When a texture loading request is received, the scheduler first starts the first thread to execute the texture file loading task; after the first thread completes loading, it notifies the scheduler through a callback mechanism, and the scheduler then activates the second thread to start texture parsing; after the second thread completes pixel data extraction, it notifies the scheduler again, and the scheduler activates the third thread (GLThread) to prepare for texture rendering.

[0085] This phased, ordered process management model effectively avoids resource contention and context conflicts caused by multi-threaded concurrent execution, ensuring that each phase is handled by only a designated thread for a specific task, thus improving system stability and predictability. Furthermore, task delivery and synchronization are achieved through inter-thread communication mechanisms (such as Handler and CountDownLatch), guaranteeing the continuity and integrity of the data flow. For example, in a car navigation application, when a user clicks the "Switch Map Theme" button, a texture loading request is triggered. The electronic device starts the first thread, loading the texture file from the local path ` / storage / emulated / 0 / maps / theme_map.png`. After the first thread finishes loading, it calls the `onLoadComplete()` method of the scheduler to activate the second thread. The second thread receives the file data and uses `BitmapFactory.decodeStream` to parse it into a Bitmap object. After parsing, it calls the `onParseComplete()` method to activate the third thread (GLThread). GLThread calls APIs such as `glGenTextures` and `glTexImage2D` in `onDrawFrame` to bind the Bitmap as a texture ID and render it. The entire process is precisely controlled by the thread scheduler, achieving an efficient and safe texture loading process. The technical advantage lies in its fine-grained management of the first, second, and third threads, constructing a three-stage pipeline architecture of "loading → parsing → rendering." This ensures that each stage's tasks are executed independently by a dedicated thread, avoiding resource conflicts and data corruption caused by thread chaos, and significantly improving the stability and efficiency of the texture loading process. Furthermore, this mechanism supports dynamic expansion, facilitating the addition of intermediate steps such as preprocessing and compression, thus enhancing the system's scalability.

[0086] After the first thread finishes loading the texture file, it needs to send a completion signal to the thread scheduler controller. This signal can be implemented through a callback interface, message queue, or event bus. Upon receiving this signal, the thread scheduler controller immediately wakes up the second thread that is in a waiting state and passes the loaded raw texture data (such as a byte stream or a File object) as a parameter to the second thread for subsequent parsing operations.

[0087] In practice, the first thread continuously monitors the file reading progress during the loading process. If loading fails to complete within the set timeout period (e.g., 3000ms), it actively throws a loading timeout exception and notifies the scheduler controller to terminate the current loading process, triggering a fallback strategy (as in step 102). If loading is successful, the onLoadSuccess() method is called to encapsulate the file data into a DataPacket object, which is then sent to the processing queue of the second thread via a Handler or Message mechanism. After receiving the DataPacket, the second thread selects the corresponding decoder (such as ImageDecoder or BitmapFactory) based on the texture file format (such as JPG or PNG) to parse it and generate a Bitmap object containing pixel data. During parsing, a timeout mechanism (such as 5000ms) is also set to prevent indefinite blocking due to file corruption or format errors. If parsing is successful, the onParseSuccess() method is called, passing the Bitmap object to the scheduler to activate the third thread.

[0088] The technical advantage lies in the fact that by precisely activating the second thread after the first thread has finished loading, the task is serialized and processed in stages. This avoids incomplete data or null pointer exceptions caused by starting parsing before loading is complete, ensuring the correctness and consistency of the data stream. Simultaneously, timeout control and exception handling mechanisms enhance the system's responsiveness to abnormal situations, improving overall robustness.

[0089] After the second thread completes the pixel data extraction, it needs to pass the parsing result (i.e., the Bitmap object) to the thread scheduler controller and trigger the activation of the third thread (GLThread). After receiving the parsing completion signal, the thread scheduler controller checks whether the parsing result is valid (e.g., the Bitmap is not empty, and its width and height are greater than 0). If it is valid, it sends the Bitmap object to the rendering queue of GLThread through the Handler, and sets the CountDownLatch to wait for GLThread to complete the texture binding and rendering operations.

[0090] After receiving the Bitmap object, GLThread enters the onDrawFrame callback function. First, it calls glGenTextures to generate a texture ID, then binds the texture using glBindTexture, next calls glTexImage2D to upload the Bitmap data to the GPU, and finally calls glGetError to check for OpenGL errors. If no errors are found, texture rendering is completed; if errors are found, the first condition is met, and backup texture rendering is triggered.

[0091] The technical advantage lies in activating the third thread after the second thread completes parsing, ensuring that the rendering process only begins after all pixel data is fully prepared. This avoids rendering failures due to missing or incorrect data, further reducing the probability of black screens. It achieves fully controllable management of the entire process—"loading → parsing → rendering → fallback"—significantly improving the system's fault tolerance and user experience.

[0092] In summary, the texture display processing method provided in this application constructs a three-stage pipeline architecture of "loading-parsing-rendering" by introducing a process management mechanism for the first, second, and third threads, achieving orderly activation and collaborative execution of tasks in each thread. This solution not only solves the problems of context conflicts and data corruption caused by thread chaos in related technologies, but also improves the stability, efficiency, and maintainability of texture loading through fine-grained process control, making it particularly suitable for application scenarios with extremely high requirements for graphics rendering stability, such as automotive systems and industrial control.

[0093] In some embodiments, before executing S201, the electronic device may load the texture file corresponding to the target texture, and the following steps may be included but not limited to S401 to S404.

[0094] S401. The electronic device performs a first verification on the texture file and obtains the first verification result.

[0095] The first verification result is used to indicate whether the texture file is normal.

[0096] The first verification refers to the process of checking the integrity, path validity, and format compatibility of the texture file itself before loading it. The first verification includes four dimensions: path verification, format verification, memory sufficiency verification, and device compatibility verification. Path verification uses the File class or network request tools to determine if the texture file exists, is readable, or if the URL is accessible. Format verification obtains a list of supported texture formats by calling the OpenGL ES glGetString(GL_EXTENSIONS) method and compares it with the texture file's format to determine compatibility. Memory sufficiency verification obtains the remaining memory through ActivityManager, calculates the memory required to load the texture file, and reserves redundant space (e.g., 1.2 times) to determine sufficiency. Device compatibility verification checks whether the current device's OpenGL ES version meets the minimum requirements (e.g., OpenGL ES 2.0) and whether the GLSurfaceView rendering configuration used to render the texture file is compatible.

[0097] The first verification result is a Boolean value. If all verification items pass, the verification is successful; otherwise, it fails. This first verification mechanism effectively avoids loading failures caused by incorrect paths, unsupported formats, insufficient memory, or device incompatibility, thereby reducing the probability of black screens.

[0098] S402. The electronic device performs a second verification on the hardware and software resources of the electronic device running the texture file, and obtains the second verification result.

[0099] The second verification result is used to characterize whether the hardware and software resources can support the rendering of the target texture.

[0100] The second verification is a comprehensive assessment of the electronic device's operating environment, primarily targeting the hardware resources (such as GPU performance and video memory capacity) and software resources (such as Android system version, OpenGL ES version, and hardware acceleration status) used for rendering texture files. Hardware resource verification includes checking the GPU model, video memory size, and number of texture units to ensure the device's hardware resources meet the rendering requirements. Software resource verification checks the system API level, whether the OpenGL ES version supports the necessary functions for rendering texture files, and whether hardware acceleration is enabled.

[0101] The second verification result is also a Boolean value. If the device has the hardware capability to render texture files and the software environment for rendering texture files meets the requirements, the verification passes; otherwise, the verification fails. This verification can identify in advance situations where the device cannot support high-resolution or complex compressed texture files, avoiding crashes or black screens due to insufficient resources during loading and ensuring the feasibility of the rendering process.

[0102] S403. If both the first and second verification results are passed, the electronic device will load the texture file corresponding to the target texture.

[0103] This step is a decision-making and execution phase following dual verification. Only when both the first verification (the texture file itself is valid) and the second verification (device resource support) pass simultaneously is the actual texture file loading process allowed. This constitutes a safety gating mechanism, ensuring that resource-intensive loading operations are triggered only when all preconditions are met. This mechanism avoids invalid loading, reduces unnecessary I / O operations and memory usage, and improves system efficiency and stability. For example, in an in-vehicle infotainment system, if a texture file path is incorrect or the device's video memory is insufficient, the electronic device will skip loading directly, preventing interface lag or crashes due to resource waste or abnormalities.

[0104] S404. If the electronic device fails the first verification or the second verification, it is determined that the first condition is met.

[0105] When either the first or second verification fails, the conditions for triggering the backup plan are met. The conditions for triggering the backup plan refer to the criteria used to determine whether to initiate subsequent fallback strategies. That is, when either verification fails, the electronic device assumes that the texture file cannot be successfully loaded and should activate the backup plan to avoid a black screen. The conditions for triggering the backup plan are based on a fault-tolerant design philosophy, ensuring that the user interface maintains basic usability even in extreme environments (such as network outages, device aging, or format incompatibility). In practical applications, when either the first or second verification fails, the electronic device automatically marks that the conditions for triggering the backup plan are met and triggers preset fallback processing logic, such as loading a transparent texture or default icon to replace the original texture file, thereby maintaining interface integrity.

[0106] In this embodiment, before loading the texture file, a first verification is performed on the texture file itself, followed by a second verification of the hardware and software resources of the running device. Loading is only performed if both verifications pass; otherwise, the conditions for triggering a backup plan are met. This approach proactively avoids invalid loading scenarios, reducing loading failures caused by incorrect paths, unsupported formats, insufficient memory, or device incompatibility. This effectively lowers the black screen incidence rate, ensuring the integrity and stability of the GLSurfaceView interface used for rendering texture files, and improving user experience and system reliability.

[0107] The process of the electronic device performing a first verification on the texture file in S401 and obtaining a first verification result will be described below. This process may include, but is not limited to, S501 to S504 described below.

[0108] S501, The electronic device determines the storage path of the texture file.

[0109] The storage path of a texture file refers to the specific location of the texture file on the device or network, used to locate and access the texture file. The storage path can be a local file system path (e.g., / storage / emulated / 0 / texture / image.png), a network URL path (e.g., http: / / example.com / textures / icon.jpg), or a reference address in the memory cache. In Android applications, the storage path is typically dynamically generated by the resource loader based on the texture file's origin, ensuring the system can accurately read the corresponding data.

[0110] In actual implementation, when a texture file loading request is received, the electronic device first parses the texture file's source type (local, network, or cache) and calls the corresponding utility class (such as the File class, HttpURLConnection, or cache manager) to obtain the texture file's storage path. For example, in an in-vehicle infotainment system, if the texture file comes from the local resource directory, the resource ID is obtained through Context.getResources().getIdentifier() and then converted into the actual path; if it comes from the network, the URL returned by the HTTP request is used as the path. The accuracy of the path directly affects whether subsequent loading will succeed; therefore, this path acquisition step is the starting point of the entire verification process.

[0111] S502, the electronic device determines whether the storage path is valid, whether the access response of the storage path is normal, and whether the texture data under the storage path exists.

[0112] The validity of a texture file's storage path refers to whether the path points to a legitimate and accessible resource location. For local paths, validity includes a correctly formatted path string and the existence and readability of the file; for network paths, validity requires a correct URL syntax and server reachability. The normality of the access response to the texture file's storage path means that when attempting to access the texture file's storage path, the electronic device receives the expected response status code (such as HTTP 200) or the file is successfully read. The existence of the texture file at the texture file's storage path means that the location pointed to by the texture file's storage path actually contains the expected texture file content (a non-empty file, a non-corrupted file).

[0113] In practice, the electronic device executes corresponding verification logic for different path types: for local paths, it uses the `File.exists()` and `File.canRead()` methods to determine file existence and readability; for network paths, it initiates a HEAD or GET request to check the response status code and Content-Length; for memory cache paths, it queries the cache key-value pairs to see if a corresponding texture file data object exists. For example, when loading navigation icons in the vehicle system, if the texture file path points to a local resource but the file has been accidentally deleted, it is determined to be an invalid path; if a network path results in a 404 error due to server downtime, the access response is deemed abnormal. This verification step ensures that only truly usable paths can proceed to the subsequent loading process, avoiding invalid operations that waste system resources.

[0114] S503. If the electronic device has a valid storage path, a normal access response, and the texture data exists, the first verification result is determined to be a successful verification.

[0115] The first verification result is successful, indicating that the storage path of the current texture file meets all the prerequisites and is feasible for loading. This first verification result is a prerequisite for triggering the subsequent loading process, meaning the system can safely start an asynchronous thread to read and parse the texture file data without needing additional path-level verification. Technically, the above judgment uses triple AND logic, meaning all three conditions must be met simultaneously for the judgment to pass.

[0116] In real-world scenarios, such as in-vehicle entertainment systems, when a user switches to a specific interface requiring the loading of a particular UI icon, the electronic device first performs this loading step. If the texture file's storage path is valid, the network response is normal, and the texture file is complete, the texture file is marked as valid, and the main thread is notified to prepare for the loading task. This rigorous verification mechanism significantly reduces the probability of loading failures due to incorrect paths or missing data, improving the stability of the in-vehicle entertainment system.

[0117] S504. If the electronic device determines that the first verification result is a verification failure when the storage path is invalid, the access response is abnormal, or the texture data does not exist.

[0118] The first verification result is "verification failed," indicating that the current texture file's storage path has at least one defect and cannot support subsequent loading operations. This first verification result will trigger a fallback strategy in the texture file loading process. The electronic device will skip the loading step and directly bind a preset backup texture file to avoid a black screen issue with the GLSurfaceView.

[0119] In practical applications, such as in the graphical interface of an industrial control panel, if a dashboard background image fails to update, resulting in a local path invalidation, the electronic device immediately determines that the verification has failed and automatically renders the backup texture file. This mechanism not only ensures the integrity of the interface but also prevents the operation of the entire electronic device from being affected by the absence of a single resource. Furthermore, the electronic device records the reason for the verification failure (such as invalid path, network timeout, etc.), facilitating quick identification of the root cause of the problem by maintenance personnel later.

[0120] In this embodiment, a triple check is performed before loading the texture file: verifying the validity of the texture file's storage path, the normality of the access response to the texture file's storage path, and the existence of the texture file under the texture file's storage path. This filters out invalid or unreachable texture files in advance, thus avoiding loading failures due to incorrect paths, network anomalies, or missing data. This prevents black screen issues caused by texture file loading failures in GLSurfaceView, improving the stability of the interface display and the user experience.

[0121] The following describes the process by which the electronic device in S402 performs a second verification on the hardware and software resources of the electronic device running the texture file and obtains the second verification result.

[0122] This process may include, but is not limited to, S601 to S604 described below.

[0123] S601, the electronic device determines the memory requirements of the texture file and the minimum software version used to render the target texture.

[0124] First, metadata is extracted from the texture resource file itself. During the texture export or packaging stage, the development tools pre-calculate the theoretical size of the texture in GPU memory after decompression (e.g., based on pixel format, resolution, number of mipmap layers, number of array slices, etc.) and write this value as the "memory requirement" into the header of the texture file or the accompanying manifest file. Simultaneously, the toolchain determines a "minimum software version" based on the hardware characteristics used by the texture (e.g., compression format support, sampler type, shader model instructions, etc.). This version typically corresponds to a specific release number of the operating system's graphics API (e.g., Vulkan 1.2, OpenGLES 3.2) or driver. Before loading the texture, the application reads these two metadata items through the file parsing module as baseline values ​​for subsequent verification.

[0125] S602. The electronic device determines whether its memory meets the memory requirements and whether its software configuration meets the minimum software version.

[0126] When an electronic device is running, it obtains the total amount of currently available physical memory (or the maximum video memory that the graphics subsystem can allocate) through the system interface and compares it with the "memory requirements" declared in the texture file. Simultaneously, it retrieves the actual graphics driver version and system API version of the device by querying system properties (such as ro.build.version.sdk, driver version string) or the initialization return value of the graphics API. This step is typically performed by the engine's Hardware Abstraction Layer (HAL) or platform adaptation module, ensuring that the obtained values ​​are the specifications actually supported by the device, not theoretical values, and that the dynamic changes in available memory under multi-tasking environments are considered (usually taking the process's available heap memory or the remaining GPU video memory capacity).

[0127] S603. If the electronic device's memory meets the memory requirements and the electronic device's software configuration meets the minimum software version, the second verification result is determined to be a successful verification.

[0128] When the available memory detected by the device is greater than or equal to the texture file's "memory requirement," and the queried software version number is not lower than the "minimum software version," the verification engine determines the second verification result to be "passed." At this point, the application can safely allocate texture storage space and call the corresponding version of the graphics API to create texture resources without allocation failure due to insufficient memory or rendering anomalies due to missing API functionality. After passing, the texture will be loaded normally onto the GPU and participate in subsequent rendering pipelines. The engine may also record this verification result for performance logs or resource caching strategies.

[0129] S604. If the memory of the electronic device does not meet the memory requirements, or the software configuration of the electronic device does not meet the minimum software version, the second verification result shall be determined as verification failure.

[0130] If available memory is insufficient or the software version is below the minimum requirement, the second verification result will be "fail". In this case, the application must not directly load the texture, otherwise it may cause a crash or display error. In implementation, the engine will trigger a degradation strategy: attempt to load a low-resolution alternative texture (reducing memory requirements), use an older compression format (lowering version requirements), or completely skip loading the texture and replace it with a placeholder color. Simultaneously, the system will output explicit error logs to developers or users, indicating insufficient hardware or system version, and may guide users to update drivers or clear background processes to free up memory, thereby providing usable rendering results while ensuring stability.

[0131] The method provided in this application embodiment may further include a process for recording and adjusting abnormal information. This process may include, but is not limited to, S701 to S703 described below.

[0132] S701. If the first condition is met, the electronic device acquires abnormal information related to the rendering of the target texture.

[0133] Exception information related to target texture rendering refers to the recorded data of various errors or abnormal events that occur during the target texture rendering process, including but not limited to IO exceptions (such as file read failure, network request timeout), OpenGL API call failures (such as glGenTextures returning 0, glTexImage2D reporting an error), memory overflow exceptions, null pointer exceptions, and device incompatibility with specific texture formats. This exception information related to target texture rendering is captured at various stages of the texture loading and rendering process using a try-catch mechanism, recording the time of occurrence, triggering scenario, device parameters, target texture information, and a complete exception stack trace to facilitate subsequent problem localization and analysis. For example, if the file does not exist when reading the local resource path in an asynchronous thread, an IOException is caught; if OpenGL returns a non-zero error code when binding the target texture ID in GLThread, the corresponding OpenGL error is caught.

[0134] Acquiring anomaly information related to target texture rendering is fundamental to accurate fault diagnosis and dynamic optimization. By monitoring anomaly events throughout the entire loading process in real time, electronic devices can accurately identify the root cause of target texture loading failure, avoiding situations where the problem cannot be identified due to black screen phenomena. In practical applications, when target texture loading fails, the electronic device automatically triggers an anomaly capture mechanism, recording key information such as the anomaly type, location of occurrence, device model, and target texture size to a local log file. This information can also be selectively uploaded to a server for remote monitoring and unified management. This proactive anomaly monitoring mechanism significantly improves the maintainability and debugging efficiency of electronic devices, making it particularly suitable for scenarios with extremely high stability requirements, such as automotive systems and industrial control systems.

[0135] S702. The electronic device determines the target anomaly type corresponding to the anomaly information.

[0136] The target exception type is a standardized exception category obtained by classifying the captured exception information related to the rendering of the target texture, used to identify which specific problem the current exception belongs to. According to the technical solution of this embodiment, the target exception types mainly include the following categories: invalid path exception (such as local file not existing, network URL inaccessible), format incompatibility exception (such as texture format ETC2 not supported by the current device OpenGL ES version), insufficient memory exception (such as remaining memory less than 1.2 times the memory required by the target texture), device compatibility exception (such as OpenGL ES version lower than 2.0), IO operation exception (such as file read interruption, network connection timeout), OpenGL context conflict exception (such as binding failure caused by multi-threaded operation), and rendering failure exception (such as glGetError returning a non-zero value).

[0137] The process of determining the target exception type is based on a pre-defined exception classification rule library. The electronic device automatically categorizes exceptions related to target texture rendering into a specific type defined in the pre-defined rule library by performing pattern matching or rule engine judgment on key fields (such as exception class name, error code, and error description) of the exception information. For example, when the exception information related to target texture rendering contains "FileNotFoundException" or "File not found," the electronic device determines it as an invalid path exception; when the exception information related to target texture rendering contains "GL_INVALID_ENUM" and is associated with a glTexImage2D call, it is determined as a format incompatibility exception defined in the pre-defined exception classification rule library. This exception classification mechanism allows different types of exceptions to be handled specifically, avoiding a one-size-fits-all approach and improving the intelligent response capability of the electronic device.

[0138] S703: The electronic device determines target optimization suggestions based on the anomaly type, and adjusts the rendering of the target texture based on the target optimization suggestions.

[0139] Target optimization suggestions are actionable improvements or alternatives proposed for specific target anomaly types, aiming to resolve current target texture rendering failures or prevent the recurrence of similar target anomaly issues in the future. Different target anomaly types correspond to different target optimization suggestions. For example: for invalid path anomalies, it is recommended to check whether the target texture path is correct or replace it with a valid path; for format incompatibility anomalies, it is recommended to convert the target texture to a device-supported texture format, such as ETC1 or PNG; for insufficient memory anomalies, it is recommended to release unused resources, such as cached old target textures or unused image resources; for device compatibility anomalies, it is recommended to upgrade the device driver or adjust the GL Surface View rendering configuration; for IO operation anomalies, it is recommended to retry loading or use a local cache copy.

[0140] The aforementioned optimization suggestions not only guide developers in troubleshooting and code fixing, but can also be dynamically applied during runtime to the target texture loading process. For example, they can automatically attempt to replace the texture with a compatible format, reduce the target texture resolution to save memory, or switch to an alternative target texture source. In practical applications, when an electronic device detects a target texture loading failure and determines it's due to insufficient memory, it can automatically trigger resource release logic, prioritizing the clearing of low-priority cached resources, and then retry loading the target texture. If it still fails, a fallback strategy is activated, rendering a transparent or default icon target texture while simultaneously informing the user that optimization loading is in progress and asking them to wait. This improves user experience and the fault tolerance of electronic devices.

[0141] In this embodiment, when a first condition is met, abnormal information related to the rendering of the target texture is obtained, the target abnormality type corresponding to the abnormal information related to the rendering of the target texture is determined, and a target optimization suggestion is determined based on the target abnormality type, so as to adjust the rendering of the target texture based on the target optimization suggestion. In this way, abnormal monitoring and accurate diagnosis of the entire target texture loading process can be achieved, thereby clarifying the cause of failure and providing targeted target optimization suggestions, which can effectively avoid black screen phenomenon caused by loading failure and improve the stability of GLSurfaceView interface and user experience.

[0142] Below, through an example, In Android application development, GLSurfaceView, as a view component based on OpenGL ES, is widely used in scenarios requiring the rendering of complex 3D graphics and dynamic textures, such as in-vehicle infotainment systems, game graphics, video rendering, and AR / VR displays. In related technologies, GLSurfaceView typically uses the TextureLoader utility class for texture loading. This class reads texture files (such as JPG, PNG, ETC2, etc.) from local resources, network resources, or memory cache, parses them into OpenGL-recognizable texture IDs, and then uses the rendering pipeline to map the textures onto 3D models or 2D planes, achieving the visualization of the textures.

[0143] However, existing texture loading technologies have many defects, which can easily lead to texture loading failures in GLSurfaceView, resulting in a black screen and seriously affecting the user experience. This problem is even more prominent in scenarios such as in-vehicle systems and industrial control where interface stability is extremely important. The specific defects are as follows: First, no pre-verification is performed before texture loading, failing to check the validity of the texture file path, format compatibility, and device memory sufficiency. If there are path errors, unsupported texture formats (such as incompatible compressed texture formats), or insufficient device memory, loading will directly fail, OpenGL will be unable to obtain valid texture data, resulting in a black screen. Second, the texture loading process is executed synchronously in a single thread, without proper synchronization with the GLSurfaceView's rendering thread (GLThread), which can easily lead to OpenGL context conflicts, causing texture binding failure and resulting in a black screen. Third, there is no fallback mechanism after loading failure. When texture loading is abnormal, no backup display solution is set, and a black screen is directly displayed, failing to provide effective feedback to the user and failing to guarantee the basic integrity of the interface display. Fourth, no anomaly monitoring is performed during the loading process, making it impossible to accurately locate the cause of loading failure (such as IO anomalies, OpenGL version incompatibility, texture size exceeding device limits, etc.), which is not conducive to problem troubleshooting and subsequent optimization.

[0144] Therefore, the GLSurfaceView texture loading method in related technologies suffers from poor fault tolerance, insufficient stability, and lack of fallback strategies after failure, easily leading to texture loading failure and subsequent black screen, failing to meet the usage requirements of high-stability scenarios. This embodiment aims to solve the black screen problem caused by GLSurfaceView texture loading failure in related technologies, providing a solution that balances stability, fault tolerance, and maintainability.

[0145] In response to the technical defects of GLSurfaceView texture loading in related technologies, such as lack of pre-verification, thread asynchrony, lack of failure fallback mechanism, and lack of anomaly monitoring methods, which lead to texture loading failure and black screen of the interface, the core technical problem to be solved by this embodiment is: to improve the success rate of GLSurfaceView texture loading, avoid black screen phenomenon caused by loading failure, and at the same time realize the monitoring and troubleshooting of anomalies in the loading process, so as to ensure the integrity and stability of the interface display.

[0146] To address the technical challenges, the core technical solution adopted in this embodiment is to construct a full-process texture loading system that includes pre-verification, thread synchronization, exception fallback, and monitoring feedback. This system avoids invalid loading in advance through multiple pre-verification checks, avoids context conflicts through thread synchronization mechanisms, resolves display issues after loading failures through fallback strategies, and enables precise troubleshooting through exception monitoring. Ultimately, this effectively prevents black screen phenomena caused by texture loading failures.

[0147] The advantages and technical effects of this solution are explained as follows: First, the pre-verification module performs multiple checks on texture paths, formats, memory, and device compatibility to pre-filter invalid loading scenarios (such as incorrect paths, unsupported formats, and insufficient memory), reducing the probability of loading failures and the likelihood of black screens. Second, the thread synchronization mechanism, through the coordinated scheduling of GLThread and the main thread, avoids conflicts caused by multi-threaded operations on the OpenGL context, ensuring the smoothness of texture binding and rendering processes, and further improving loading stability. Third, the fail-safe module automatically loads preset backup textures (such as transparent textures and default icons) when texture loading is abnormal, replacing the black screen display, ensuring the basic integrity of the interface, and improving the user experience. Fourth, the anomaly monitoring module records anomaly information during the loading process in real time (such as anomaly type, triggering scenario, and device parameters), providing data support for later troubleshooting and technical optimization, and reducing maintenance costs.

[0148] Compared with related technologies, this solution does not require excessive consumption of electronic device resources, is lightweight and highly compatible, and can be adapted to different Android versions and different hardware devices. It is especially suitable for scenarios with extremely high requirements for interface stability, such as vehicle systems and industrial control, and effectively solves the pain points of frequent black screens, difficult troubleshooting and poor user experience in related technologies.

[0149] The technical solution created in this embodiment mainly includes four functional modules: texture loading pre-verification module, thread synchronization loading module, loading failure fallback handling module, and exception monitoring and feedback module. These modules work together to achieve stable loading of GLSurfaceView textures and avoid black screen phenomena.

[0150] The overall process of GLSurfaceView texture loading is as follows: pre-verification → thread-synchronized loading → loading status judgment → texture rendering if successful → fallback strategy if unsuccessful → exception recording and feedback. The entire process forms a closed loop, ensuring that each step has a fault tolerance mechanism and preventing black screens.

[0151] The following is a description of each functional module.

[0152] First, let's explain the pre-processing verification module for texture loading.

[0153] Step 11: Before texture loading begins, perform texture path validation to obtain the storage path of the texture file (local resource path, network URL, or memory cache path). Use the File class or network request tool to determine if the path is valid (whether the local file exists and is readable; whether the network URL is accessible and responds normally; and whether the corresponding texture data exists in the memory cache). If the path is invalid, the loading is directly determined to have failed, triggering a fallback strategy to avoid invalid loading consuming system resources.

[0154] Step 12: After the path verification passes, perform texture format verification. Read the texture file's format identifier and determine if it is a format supported by the current device's OpenGL ES version. Supported texture formats include basic formats (JPG, PNG, BMP) and compressed formats (ETC1, ETC2, ASTC). The system calls the OpenGL ES glGetString(GL_EXTENSIONS) method to obtain a list of supported texture formats and compares the texture file's format identifier with this list. If the texture file's format identifier is not in the supported list, loading is considered a failure, and the system triggers a fallback strategy.

[0155] Step 13: After the format verification passes, perform a memory adequacy check. Obtain the remaining memory of the current device (including Java heap memory and native memory) through Activity Manager, calculate the memory required for loading the current texture (calculated based on the texture size and format, such as a 1024×1024 RGBA8888 format texture, which requires approximately 4MB of memory). If the remaining memory is less than 1.2 times the required memory (a certain amount of redundancy is reserved to avoid memory overflow), it is determined to be insufficient memory. Texture loading is paused, and cached old textures and unused image resources are released first. After successful release, the system re-verifies the relationship between the remaining memory and the required memory. If it is still insufficient, a fallback strategy is triggered.

[0156] Step 14: After the memory check passes, perform a device compatibility check to determine whether the current device's OpenGL ES version meets the minimum requirements for texture resource loading (minimum support for OpenGL ES 2.0). At the same time, check whether the GLSurfaceView's rendering configuration (such as whether hardware acceleration and texture sampling mode are enabled) is compatible with texture resource loading. If they are not compatible, adjust the rendering configuration and try to load the texture resources again. If the adjustment fails, the system will trigger a fallback strategy.

[0157] The texture loading process can be referenced. Figure 2 The contents shown include, but are not limited to, S801 to S808 below.

[0158] S801, Start loading requests.

[0159] S802, Initialize the context.

[0160] S803. Determine whether the pre-verification passed.

[0161] S804, asynchronous loading.

[0162] S805, fallback solution.

[0163] S806. Determine if the rendering was successful.

[0164] S807, Exception Log.

[0165] S808, End closed loop.

[0166] The structure of the verification module can be referenced. Figure 3 The contents shown include path verification submodule 301, format verification submodule 302, memory verification submodule 303, and device verification submodule 304.

[0167] The following section explains the thread synchronization loading module.

[0168] In related technologies, texture loading is often performed on the main thread or an asynchronous thread, which can easily cause OpenGL context conflicts with the GLSurfaceView's rendering thread (GLThread), leading to texture binding failure. This module adopts a collaborative mechanism of "main thread scheduling, asynchronous thread loading, and GLThread rendering" to achieve thread synchronization. The specific implementation method is as follows: (1) Main thread: responsible for triggering texture loading requests, calling the pre-verification module for verification, and submitting the loading task to the asynchronous thread after the verification is passed. At the same time, it establishes communication with GLThread through Handler to pass the loading status.

[0169] (2) Asynchronous thread: responsible for reading and parsing texture files, parsing texture files into Bitmap objects, and then converting Bitmap objects into texture IDs through OpenGL ES APIs (such as glGenTextures, glBindTexture, glTexImage2D). No rendering operations are performed during this process to avoid occupying GLThread resources.

[0170] (3) GLThread: The default rendering thread of GLSurfaceView, responsible for texture binding and rendering. It receives the texture ID passed by the asynchronous thread through Handler, and binds the texture ID to the rendering pipeline in the onDrawFrame method to perform texture rendering operation; if a valid texture ID is not received (loading failure), the fallback strategy is triggered.

[0171] (4) Synchronization mechanism: CountDownLatch is used to synchronize asynchronous threads with GLThread to ensure that rendering operations are performed only after the texture is loaded; the synchronized keyword is used to lock the process of passing texture IDs to avoid exceptions caused by concurrent modification by multiple threads and to ensure the stability of texture binding.

[0172] The coordination relationship of thread-synchronized loading modules can be found in [reference]. Figure 4 The content shown includes, but is not limited to, the main thread 401, the asynchronous loading thread 402, the Handler 403, and the CountDownLatch 404.

[0173] The following section explains the fallback handling module for loading failures.

[0174] This module is the core of preventing black screens. When front-end verification fails, texture loading is abnormal (such as IO exception, OpenGL error), or rendering fails, a fallback strategy is automatically activated to ensure that the GLSurfaceView has displayable content. The specific implementation is as follows: (1) Preset spare textures: When the application is initialized, the preset spare textures are loaded in advance, including two types: one is transparent texture (used for scenarios that require transparent backgrounds to avoid abrupt black screens), and the other is default icon texture (used for scenarios that require clear feedback on loading failure, such as displaying the "loading failed" icon). The spare textures adopt the basic format supported by the device (such as PNG) to ensure the success rate of loading.

[0175] (2) Fallback trigger conditions: The fallback strategy is triggered when the following situations occur: ① any of the pre-checks fails; ② an IO exception or null pointer exception is thrown when the asynchronous thread loads the texture; ③ the OpenGL API call fails (e.g., glGenTextures returns 0, the texture ID is invalid); ④ the rendering fails after the texture is bound to the rendering pipeline (e.g., glGetError returns a non-zero error code).

[0176] (3) Fallback execution process: After the fallback strategy is triggered, GLThread (rendering thread) abandons the failed texture loading, automatically binds the preset backup texture, renders the backup texture in the onDrawFrame method, and replaces the black screen display; at the same time, according to the scene requirements, the user can be informed of "texture loading failed" through Toast or interface prompts to improve the user experience.

[0177] The following section explains the anomaly monitoring and feedback module.

[0178] This module is used to monitor the entire texture loading process in real time, record abnormal information, and provide support for later troubleshooting and optimization. The specific implementation method is as follows: (1) Exception capture: In each stage of pre-verification, asynchronous loading, thread synchronization and texture rendering, exceptions are captured by try-catch, including IO exceptions, NullPointerException, OpenGL error, memory overflow exception, etc., and the exception type and triggering scenario are clearly defined.

[0179] (2) Log recording: The captured abnormal information (abnormal type, trigger time, device parameters, texture information, abnormal stack) is written to the local log file. The log file is divided by date for easy query later. At the same time, key abnormal information can be uploaded to the server through the interface to realize remote monitoring.

[0180] (3) Anomaly feedback: For different types of anomalies, corresponding optimization suggestions are given (such as "Check texture path" for path error, "Change texture format" for unsupported format, and "Release useless resources" for insufficient memory), which makes it easier for developers to quickly troubleshoot problems and optimize texture loading schemes.

[0181] For a fallback handling process in case of loading failure, please refer to Figure 5The contents shown include, but are not limited to, S901 to S905.

[0182] S901, Loading failed.

[0183] S902, Exception handling.

[0184] S903, Alternate texture call.

[0185] S904, rendering catch-all.

[0186] S905, User Feedback.

[0187] The key technical parameters and implementation details are as follows: Texture loading threshold: In the memory sufficiency check, the reserved memory redundancy ratio is 20%, that is, the remaining memory must be greater than 1.2 times the memory required by the texture, which can be dynamically adjusted according to the device performance.

[0188] Thread synchronization timeout: The timeout for asynchronous thread to load textures is set to 3000ms. If the timeout occurs, the loading operation is considered to have failed and a fallback strategy is triggered.

[0189] Alternate texture size: The default alternate texture size is 256×256px, which is suitable for the rendering needs of most devices and can be adjusted according to the actual scene.

[0190] OpenGL version compatibility: Supports at least OpenGL ES 2.0, compatible with OpenGL ES 3.0 and above, and adapts to different hardware devices.

[0191] This technical solution can significantly reduce the occurrence rate of black screens: by using a pre-verification module to avoid invalid loading scenarios in advance, the probability of loading failure is reduced from the source; combined with a fallback strategy for loading failure, a backup texture is automatically rendered when loading is abnormal, completely eliminating black screen phenomena and ensuring the integrity of the interface display, which is especially suitable for scenarios with extremely high stability requirements such as in-vehicle systems and industrial control.

[0192] Meanwhile, this solution significantly improves texture loading stability: by adopting a thread synchronization mechanism, it solves the conflict problem caused by multi-threaded operation of the OpenGL context in related technologies, ensuring the smoothness of texture loading, binding, and rendering processes, reducing abnormal interruptions during loading, and improving overall loading stability.

[0193] In addition, this solution is lightweight and highly compatible: it does not require the introduction of additional third-party libraries, is implemented only through native APIs, consumes little system resources, can be adapted to Android 4.4 and above, different hardware devices, is compatible with multiple texture formats, does not require major modifications to the existing GLSurfaceView rendering logic, and is easy to integrate into existing projects.

[0194] The texture loading solution also facilitates troubleshooting and optimization: through the exception monitoring and feedback module, exception information during the loading process is recorded in real time, the cause of the exception and the triggering scenario are identified, and targeted optimization suggestions are given, reducing the troubleshooting cost for developers and facilitating iterative optimization of the texture loading solution in the later stages.

[0195] Finally, this solution effectively improves the user experience: when loading fails, a backup texture is used to replace the black screen, while providing clear feedback to avoid user confusion caused by the black screen, thus improving the application's user experience and reliability.

[0196] Furthermore, this embodiment also provides several alternatives to adapt to different application scenarios: An alternative to the pre-verification module: The memory adequacy verification step can be omitted, retaining only path and format verification. The advantage of this approach is that it simplifies the verification process and improves verification speed, making it suitable for devices with ample memory and powerful hardware (such as high-end mobile phones and flagship in-vehicle systems). The disadvantage is that in scenarios with insufficient memory, the system may still experience texture loading failures, slightly increasing the risk of a black screen.

[0197] An alternative to thread synchronization mechanisms is to use AsyncTask asynchronous tasks instead of custom asynchronous threads. The texture ID is passed to GLThread via the onPostExecute method of AsyncTask to achieve thread synchronization. The advantage of this alternative is its simplicity, eliminating the need for manual management of thread lifecycles. The disadvantage is that in complex scenarios (such as loading multiple textures simultaneously), AsyncTask's thread pool management is prone to congestion, making its stability slightly inferior to custom asynchronous thread synchronization mechanisms.

[0198] An alternative to the fallback strategy is to use a solid color fill instead of a backup texture. When loading fails, GLThread renders a preset solid color (such as white or light gray) instead of a black screen. The advantage of this approach is that it eliminates the need to pre-load backup textures, saving memory resources; the disadvantage is that the display effect is relatively simple, and it cannot provide users with clear feedback on loading failures, resulting in a slightly worse user experience.

[0199] An alternative to the anomaly monitoring module: Omit local logging and only display anomaly information via Toast, without uploading anomaly information to the server. The advantage of this alternative is simplified implementation logic and reduced system resource consumption; the disadvantage is the inability to retain anomaly logs, making later troubleshooting more difficult, and it is only suitable for simple application scenarios.

[0200] An alternative to texture loading is to use a texture caching pool mechanism. Frequently used textures are pre-cached, and when a texture loading fails, a similar texture is retrieved from the cache pool as a replacement, thus achieving fault tolerance in case of loading failure. The advantage of this approach is that it can improve texture loading speed and reduce repeated loading operations; the disadvantage is that the cache pool consumes certain memory resources, and the validity of the cached content needs continuous maintenance, resulting in higher overall implementation complexity.

[0201] Secondly, embodiments of this application provide a texture display processing apparatus, referring to... Figure 6 The texture display processing device 60 shown includes: The first rendering unit 601 is used to render a target texture in response to a received texture loading request; the target texture is the texture to be displayed as pointed to by the texture loading request; the second rendering unit 602 is used to render a pre-loaded backup texture to display the backup texture if the target texture meets a first condition; the first condition is used to indicate that the target texture cannot be rendered successfully.

[0202] In some embodiments, the first rendering unit 601 is further configured to: load a texture file corresponding to the target texture; parse the texture file to obtain pixel data; and render the pixel data to obtain the rendered target texture; wherein the first condition includes at least one of the following: loading failure, parsing failure, and rendering failure; loading failure is used to indicate that loading the texture file corresponding to the target texture failed, parsing failure is used to indicate that parsing the texture file failed, and rendering failure is used to indicate that rendering the pixel data failed.

[0203] In some embodiments, the first rendering unit 601 is further configured to: load a texture file corresponding to the target texture through a first thread; parse the texture file through a second thread to obtain pixel data; and render the pixel data through a third thread to obtain the rendered target texture; wherein the first thread, the second thread, and the third thread are different threads.

[0204] In some embodiments, the texture display processing apparatus may further include a management unit, which is configured to: manage the processes of the first thread, the second thread, and the third thread; activate the second thread after the first thread finishes executing and loading the texture file corresponding to the target texture; and activate the third thread after the second thread finishes executing and parses the texture file to obtain pixel data.

[0205] In some embodiments, the texture display processing apparatus may further include a verification unit, which is configured to: perform a first verification on the texture file to obtain a first verification result; the first verification result is used to characterize whether the texture file is normal; perform a second verification on the hardware and software resources of the electronic device running the texture file to obtain a second verification result; the second verification result is used to characterize whether the hardware and software resources can support the rendering of the target texture; if both the first verification result and the second verification result are successful, execute the loading of the texture file corresponding to the target texture; if either the first verification result or the second verification result is unsuccessful, determine that a first condition is met.

[0206] In some embodiments, the verification unit is further configured to: determine the storage path of the texture file; determine whether the storage path is valid, whether the access response of the storage path is normal, and whether the texture data under the storage path exists; if the storage path is valid, the access response is normal, and the texture data exists, determine that the first verification result is verification passed; if the storage path is invalid, the access response is abnormal, or the texture data does not exist, determine that the first verification result is verification failed.

[0207] In some embodiments, the verification unit is further configured to: determine the memory requirements of the texture file and the minimum software version for rendering the target texture; determine whether the memory of the electronic device meets the memory requirements and whether the software configuration of the electronic device meets the minimum software version; if the memory of the electronic device meets the memory requirements and the software configuration of the electronic device meets the minimum software version, determine that the second verification result is verification passed; if the memory of the electronic device does not meet the memory requirements or the software configuration of the electronic device does not meet the minimum software version, determine that the second verification result is verification failed.

[0208] In some embodiments, the texture display processing apparatus may further include an optimization unit, which is configured to: acquire exception information related to the rendering of the target texture when a first condition is met; determine the target exception type corresponding to the exception information; and determine a target optimization suggestion based on the exception type, so as to adjust the rendering of the target texture based on the target optimization suggestion.

[0209] It should be noted that the communication device of the application provided in this application embodiment includes all the units included, which can be implemented by a processor in an electronic device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP), or a field-programmable gate array (FPGA), etc.

[0210] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0211] It should be noted that, in the embodiments of this application, if the above-described vehicle driving control method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0212] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program or instructions, and when the computer program or instructions are executed by the processor, they implement the method provided in the first aspect.

[0213] Fourthly, embodiments of this application provide a storage medium, namely a computer-readable storage medium, on which a computer program or instructions are stored, which, when executed by a processor, implement the steps of any of the methods provided in the first aspect of the above embodiments.

[0214] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the steps of any of the methods provided in the first aspect of the above embodiments.

[0215] It should be noted that the descriptions of the above embodiments of storage media, devices, apparatuses, and program products are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of storage media, devices, apparatuses, and program products of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0216] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0217] It should be noted that, in this document, 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 a 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.

[0218] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another electronic device, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0219] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0220] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0221] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0222] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0223] The above are merely 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 scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for processing texture display, characterized in that, The method includes: In response to a received texture loading request, render the target texture; the target texture is the texture to be displayed as pointed to by the texture loading request. If the target texture meets the first condition, a pre-loaded successfully loaded alternative texture is rendered to display the alternative texture; the first condition is used to characterize that the target texture cannot be rendered successfully.

2. The method according to claim 1, characterized in that, The target texture for rendering includes: Load the texture file corresponding to the target texture; The texture file is parsed to obtain pixel data; The pixel data is rendered to obtain the rendered target texture; The first condition includes at least one of the following: loading failure, parsing failure, and rendering failure; the loading failure is used to indicate that loading the texture file corresponding to the target texture failed, the parsing failure is used to indicate that parsing the texture file failed, and the rendering failure is used to indicate that rendering the pixel data failed.

3. The method according to claim 2, characterized in that, Load the texture file corresponding to the target texture; The texture file is parsed to obtain pixel data; Rendering the pixel data to obtain the rendered target texture includes: The texture file corresponding to the target texture is loaded using the first thread; The texture file is parsed using a second thread to obtain pixel data; The pixel data is rendered using a third thread to obtain the rendered target texture; The first thread, the second thread, and the third thread are different threads.

4. The method according to claim 3, characterized in that, The method further includes: Manage the processes of the first thread, the second thread, and the third thread; so that after the first thread finishes loading the texture file corresponding to the target texture, the second thread is activated; and after the second thread finishes parsing the texture file to obtain pixel data, the third thread is activated.

5. The method according to any one of claims 2-4, characterized in that, Before loading the texture file corresponding to the target texture, the method further includes: The texture file is subjected to a first verification to obtain a first verification result; the first verification result is used to characterize whether the texture file is normal. A second verification is performed on the hardware and software resources of the electronic device running the texture file to obtain a second verification result; the second verification result is used to characterize whether the hardware and software resources can support the rendering of the target texture; If both the first and second verification results pass the verification, the process of loading the texture file corresponding to the target texture is executed. If either the first verification result or the second verification result indicates that the verification failed, then the first condition is determined to be met.

6. The method according to claim 5, characterized in that, The first verification of the texture file to obtain the first verification result includes: Determine the storage path of the texture file; Determine whether the storage path is valid, whether the access response to the storage path is normal, and whether the texture data under the storage path exists; If the storage path is valid, the access response is normal, and the texture data exists, the first verification result is determined to be a successful verification. If the storage path is invalid, the access response is abnormal, or the texture data does not exist, the first verification result is determined to be a verification failure.

7. The method according to claim 5, characterized in that, The second verification of the hardware resources of the electronic device running the texture file, to obtain the second verification result, includes: Determine the memory requirements of the texture file and the minimum software version required to render the target texture; Determine whether the memory of the electronic device meets the memory requirements, and determine whether the software configuration of the electronic device meets the minimum software version; If the memory of the electronic device meets the memory requirements and the software configuration of the electronic device meets the minimum software version, the second verification result is determined to be a successful verification. If the memory of the electronic device does not meet the memory requirements, or if the software configuration of the electronic device does not meet the minimum software version, the second verification result is determined to be a verification failure.

8. The method according to any one of claims 1-4, characterized in that, The method further includes: If the first condition is met, obtain abnormal information related to the target texture rendering; Determine the target anomaly type corresponding to the anomaly information; Based on the anomaly type, a target optimization suggestion is determined, and the rendering of the target texture is adjusted based on the target optimization suggestion.

9. A texture display processing device, characterized in that, The device includes: The first rendering unit is used to render a target texture in response to a received texture loading request; the target texture is the texture to be displayed as pointed to by the texture loading request. The second rendering unit is used to render a pre-loaded, successfully loaded alternative texture to display the alternative texture if the target texture meets the first condition; the first condition is used to characterize that the target texture cannot be rendered successfully.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor, wherein the memory stores a computer program or instructions, and when the computer program or instructions are executed by the processor, the method described in any one of claims 1-8 is implemented.

Images