Adaptive compression method for floating window scene and electronic device

Abstract

This application provides an adaptive compression method and electronic device for floating window scenarios, relating to the field of image processing technology. In floating window scenarios, an adaptive compression control algorithm is invoked to determine a fixed bitrate compression method and compression ratio based on scenario information such as the content type and window size of the floating window, user interaction information acting on the floating window, device power consumption mode, and device performance status. The compression ratio is then dynamically adjusted to perform fixed bitrate compression on the content of the floating window. This effectively controls the system resource usage, reducing memory bandwidth consumption, lowering CPU / GPU power consumption, improving system performance, and providing visually lossless effects. Especially for low-performance electronic devices (e.g., those with limited memory and low CPU / GPU performance), this solves problems such as lag and insufficient battery life, significantly improving the user experience.

Description

Technical Field

[0001] This application relates to the field of image processing technology, and in particular to an adaptive compression method and electronic device for a floating window scene. Background Technology

[0002] When a floating window is enabled on an electronic device, multiple tasks are executed in parallel. This increases the demand for memory bandwidth and significantly increases the GPU load on the device, leading to a decrease in performance and an increase in power consumption. For devices with lower performance, this can easily cause problems such as lag and insufficient battery life, seriously affecting the user experience. Summary of the Invention

[0003] This application provides an adaptive compression method and electronic device for floating window scenarios, which can effectively control the occupation of system resources, reduce memory bandwidth usage, reduce power consumption, and avoid problems such as lag and insufficient battery life, thereby improving the user experience.

[0004] Firstly, this application provides an adaptive compression method for a floating window scenario, applied to an electronic device. The method includes: activating a first floating window in response to a user operation; identifying the content type and window size of the first floating window; monitoring the device power consumption mode and device performance status; and, based on first scenario information, invoking an adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate. The first scenario information includes at least one of the following: the content type of the first floating window, the window size of the first floating window, user interaction information acting on the first floating window, the device power consumption mode, and the device performance status information.

[0005] Fixed bitrate compression is a hardware-based texture compression technology. Since the texture compression module is a hardware-level compression module, it can achieve a high compression ratio and significantly reduce the amount of texture data while ensuring rendering quality.

[0006] The adaptive compression method for floating window scenarios provided in this application, in a floating window scenario, can determine a fixed bitrate compression method and compression ratio based on scenario information such as the content type (e.g., video / image / document) and window size of the first floating window, user interaction information acting on the first floating window (e.g., operation frequency), device power consumption mode (e.g., power saving mode), and device performance status (e.g., low performance state). It then dynamically adjusts the compression ratio to perform fixed bitrate compression on the content of the floating window. This effectively controls the system resource usage, reducing memory bandwidth consumption, lowering CPU / GPU power consumption, improving system performance, and providing visually lossless effects. Especially for low-performance electronic devices (e.g., small memory size, low CPU / GPU performance), it solves problems such as lag and insufficient battery life, greatly improving the user experience.

[0007] Fixed bitrate compression is a lossy compression method that allows for some quality loss during rendering. Because at higher bitrates, despite being lossy compression, the image loss is almost imperceptible, achieving a visually lossless effect, fixed bitrate compression is also known as visually lossless compression.

[0008] It is understandable that when an electronic device has a floating window open, multiple tasks run in parallel, increasing the demand for memory bandwidth and significantly increasing the GPU load. The solution in this application, based on the current scene information, performs fixed-bitrate compression on the content of the floating window, which reduces memory bandwidth usage, lowers CPU / GPU power consumption, improves system performance, and provides visually lossless effects.

[0009] In some possible implementations, based on the first scene information, an adaptive compression control algorithm is invoked to perform fixed bit rate compression on the content of the first floating window, including: based on the first scene information, the adaptive compression control algorithm is invoked to determine a fixed bit rate compression strategy, wherein the fixed bit rate compression strategy includes adopting a fixed bit rate compression method and a first compression level; and based on the fixed bit rate compression strategy, texture compression is performed on the content of the first floating window.

[0010] The above approach allows for the use of a fixed bit rate compression method in floating window scenarios. By selecting an appropriate compression level based on the scene information, texture compression can be applied to the floating window content. This reduces memory usage and bandwidth consumption, lowers overall power consumption, improves performance, and provides visually lossless effects.

[0011] In some possible implementations, the first compression level can correspond to a compression ratio.

[0012] In some other possible implementations, the first compression level can correspond to multiple alternative compression ratios.

[0013] In some possible implementations, the step of performing texture compression on the content of the first floating window according to the fixed bit rate compression strategy includes: determining a first compression ratio from a plurality of alternative compression ratios based on the compression ratio supported by the view texture format corresponding to the first floating window and the compression ratio supported by the hardware module in the electronic device; and performing texture compression on the content of the first floating window using the first compression ratio.

[0014] The above approach allows for more precise control of the fixed bit rate compression ratio, more effective control of system resource usage, reduced memory consumption and bandwidth usage, lower overall power consumption, and better improvement of device performance.

[0015] It is understandable that increasing the compression ratio of textures reduces the memory occupied by textures, reduces GPU load, reduces power consumption, and makes the improvement in device performance more obvious.

[0016] The compression ratio can also be called the compression ratio or compression rate.

[0017] For example, a compression ratio of 4:1 means the ratio of the original data size to the compressed data size is 4:1 (i.e., 8:2). A compression ratio of 2:1 means the ratio is 2:1 (i.e., 8:4). A compression ratio of 8:5 means the ratio is 8:5. A compression ratio of 4:1 is greater than a compression ratio of 2:1, and a compression ratio of 2:1 is greater than a compression ratio of 8:5. It should be noted that the above compression ratios are illustrative examples; in actual implementation, the compression ratio can be set according to actual usage requirements.

[0018] In some possible implementations, fixed bitrate compression can be implemented as texture block compression. This involves dividing the texture into multiple texture blocks, for example, each containing 4x4 pixels, and then compressing each texture block. The compressed pixel information is stored in a pixel set, and the index position of each texture block is stored in a block index map. By dividing the texture into fixed-size texture blocks, compressing each texture block individually, and loading it into video memory, video memory usage can be reduced.

[0019] Besides using compression ratio to characterize the degree of compression at a fixed bit rate, the compressed bit rate can also be used. For example, the unit of compressed bit rate can be BPC (bits per component, the number of bits per color channel). The compressed bit rate represents the number of bits per color channel per pixel after compression at a fixed bit rate.

[0020] In some embodiments, the compression bit rate can be 2 BPC, that is, after compression at a fixed bit rate, each color channel corresponds to 2 bits (i.e., occupies 2 bits).

[0021] In other embodiments, the compression bit rate can be 4 BPC, meaning that after compression at a fixed bit rate, each color channel corresponds to 4 bits (i.e., occupies 4 bits).

[0022] In some cases, compression bitrate can be understood as the number of bits per second used to represent encoded (compressed) audio / video data. Generally, a higher compression bitrate (smaller compression ratio) results in a larger amount of data transmitted and better audio / video quality. Conversely, a lower compression bitrate (larger compression ratio) results in a smaller amount of data transmitted, but with a slight decrease in audio / video quality.

[0023] In some cases, compression bitrate can be understood as the number of bits per second used to represent encoded (compressed) audio / video data. Generally, a higher compression bitrate (smaller compression ratio) results in a larger amount of data transmitted and better audio / video quality. Conversely, a lower compression bitrate (larger compression ratio) results in a smaller amount of data transmitted, but with a slight decrease in audio / video quality.

[0024] In some possible implementations, after determining the fixed bit rate compression strategy, the method further includes: creating compression control parameters in the form of a structure, the compression control parameters including a first flag bit and a second flag bit; writing an identifier of the fixed bit rate compression method into the first flag bit and writing an identifier of the first compression level into the second flag bit; and calling the graphics API interface of the electronic device to pass the first compression control parameters to a hardware module with texture compression capability.

[0025] Fixed bitrate compression is a hardware-based texture compression technology. Since the texture compression module is a hardware-level compression chip, it can achieve a high compression ratio and significantly reduce the amount of texture data while maintaining rendering quality. It is understandable that in floating window scenarios, the memory bandwidth requirements of electronic devices increase, and the GPU load on these devices increases significantly. The solution in this application, by performing fixed bitrate compression on the floating window content based on the current scene information, can reduce memory bandwidth usage, lower CPU / GPU power consumption, improve system performance, and provide visually lossless effects.

[0026] In some possible implementations, monitoring the device performance status includes: acquiring real-time dynamic performance parameters of the electronic device, including CPU utilization, DDR memory utilization, DDR bandwidth, and / or GPU load; acquiring pre-configured performance parameters of the electronic device, including available DDR memory, available DDR bandwidth, and GPU frequency; and determining the device performance status based on the real-time dynamic performance parameters and the pre-configured performance parameters.

[0027] In some possible implementations, the adaptive compression control algorithm includes: for the device performance state, the compression ratio corresponding to the low performance state is higher than the compression ratio corresponding to the high performance state.

[0028] For example, the device performance status may include multiple levels, such as two states: high and low. Alternatively, it may include three states: high, medium, and low, or it may be divided into even more states.

[0029] It should be noted that the performance status of electronic devices is related not only to pre-configured performance parameters but also to real-time dynamic performance parameters. For the same device, performance can be affected by foreground and background applications. Under conditions of high resource contention, background applications may impact the performance of foreground applications. Therefore, the adaptive compression control algorithm provided in this application embodiment can adjust the fixed bit rate compression ratio in real time according to the dynamic changes in device performance status, effectively controlling the occupation of system resources, improving performance, and providing visually lossless effects.

[0030] In some possible implementations, the method further includes: displaying the floating window in a first interface after the first floating window is launched. The first interface can be the interface of a system application such as a desktop, or it can be the interface of a third-party application.

[0031] In some possible implementations, an initial compression ratio can be preset based on an adaptive compression control algorithm. For example, the preset compression ratio could be 2:1.

[0032] In some possible implementations, the step of invoking an adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate based on the first scene information includes the following three implementation methods:

[0033] Implementation Method 1: When a floating window appears on the first interface, a fixed bitrate compression method is directly used to compress the content of the first floating window at a preset compression ratio. This method reduces memory bandwidth usage and lowers CPU and GPU power consumption, thus avoiding issues such as lag and insufficient battery life, thereby improving the user experience.

[0034] Implementation Method Two: Determine if the electronic device is under high load and / or low performance. If under high load and / or low performance, use a fixed bitrate compression method to perform texture compression on the content of the first floating window at a preset compression ratio. This approach determines whether the electronic device is under high load and / or low performance in the floating window scenario. If so, the content of the floating window is compressed at a fixed bitrate using a preset compression ratio. This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding issues such as lag and insufficient battery life, thus improving the user experience.

[0035] Implementation Method 3: Determine if the electronic device is in a high-load and / or low-performance state; in such states, based on the first scenario information, invoke an adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate. Through this scheme, in the floating window scenario, determine if the electronic device is in a high-load and / or low-performance state. If so, based on scenario information such as the content type and window size of the first floating window, user interaction information acting on the first floating window, device power consumption mode, and device performance status, invoke an adaptive compression control algorithm to determine the fixed bit rate compression method and compression ratio, and dynamically adjust the compression ratio to compress the content of the floating window at a fixed bit rate. This reduces memory bandwidth usage and lowers CPU and GPU power consumption, more effectively avoiding problems such as lag and insufficient battery life, thus improving the user experience.

[0036] In some possible implementations, the content displayed in the first floating window can be a video, an image, or a document. Accordingly, the adaptive compression control algorithm includes: a higher compression ratio for video content compared to image content; and a higher compression ratio for image content compared to document content.

[0037] It should be noted that because the sensitivity to visual quality may vary when displaying different types of content in a floating window, different compression strategies are required for different types of content. The solution in this application first analyzes the attributes of the content displayed in the floating window to determine whether it is video, image, or text. Then, an appropriate compression strategy is determined based on the content attributes of the floating window. For example, text content may require a lower compression ratio to maintain clarity, while video content may tolerate a higher compression ratio.

[0038] In this embodiment of the application, the content type of the floating window can be determined based on the view type contained in the window.

[0039] For example, if the window includes a TextureView and / or a SurfaceView, then the content type in the floating window can be determined to be video.

[0040] If the window contains a TextView, then the content type in the floating window can be determined to be document type.

[0041] If the window contains an ImageView, then the content type in the floating window can be determined to be an image.

[0042] The above solution allows electronic devices to automatically select a compression strategy and compress the content of the floating window at a fixed bit rate by recognizing the content type (such as video, image, or document). This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding issues such as lag and insufficient battery life, thus improving the user experience.

[0043] In some possible implementations, the adaptive compression control algorithm includes a higher compression ratio for smaller window sizes compared to larger window sizes. This application determines the compression ratio strategy based on the window size. In smaller windows, due to the limited display area, users may find it difficult to perceive subtle changes in image quality. Therefore, a higher compression ratio can be used to save resources without significantly impacting the user experience. Conversely, in larger windows, a lower compression ratio can be used to maintain good visual quality.

[0044] The above solution allows electronic devices to automatically select a compression strategy by recognizing the size of the floating window and compress the content of the floating window at a fixed bit rate. This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding problems such as lag and insufficient battery life, thus improving the user experience.

[0045] In some possible implementations, the adaptive compression control algorithm includes: for device power consumption modes, the compression ratio corresponding to the power saving mode / memory saving mode is higher than the compression ratio corresponding to the normal mode.

[0046] This application determines the compression ratio strategy based on the device's power consumption mode. When the electronic device is in a power-saving mode, the consumption of memory bandwidth can be reduced by increasing the compression ratio, thereby reducing power consumption.

[0047] In some possible implementations, the content type of the first floating window, the window size of the first floating window, the user interaction information applied to the first floating window, the device power consumption mode, and the device performance status each correspond to a weight coefficient. Accordingly, the electronic device calls an adaptive compression control algorithm to perform weighted calculations based on the content type of the first floating window, the window size of the first floating window, the user interaction information applied to the first floating window, the device power consumption mode, the device performance status, and the weight coefficients, to obtain the compression ratio.

[0048] It is understandable that the larger the weighting coefficient, the greater its reference value or contribution in determining the compression ratio.

[0049] It should be noted that the weighting coefficients of each factor can be set according to the actual performance of the electronic device and the actual needs of the user (such as smoothness requirements or clarity requirements).

[0050] For example, for electronic devices with lower performance (e.g., less memory, lower CPU / GPU performance), if users have high demands for smoothness, then a higher weighting can be applied to the device's performance status. This is because, in a low-performance state, increasing the compression ratio can improve smoothness.

[0051] For example, if users have high requirements for clarity, then a larger weighting coefficient can be set for the content type and window size of the first floating window.

[0052] The above solution can determine an appropriate compression ratio based on the current scene information, the actual performance of the electronic device, and the actual needs of the user. It can adaptively compress the content of the floating window at a fixed bit rate, effectively control the system resource usage, reduce memory bandwidth usage, reduce power consumption, improve system performance, solve problems such as lag and insufficient battery life, and greatly enhance the user experience.

[0053] In some possible implementations, after the content of the first floating window is compressed at a fixed bit rate, the method further includes: when the first scene information changes, calling an adaptive compression control algorithm to adjust the compression ratio, and using the adjusted compression ratio to compress the content of the first floating window at a fixed bit rate.

[0054] In some possible implementations, the step of invoking an adaptive compression control algorithm to adjust the compression ratio when the first scene information changes includes:

[0055] When the content type of the first floating window is switched from document type to video type, the adaptive compression control algorithm is invoked to increase the compression ratio; when the content type of the first floating window is switched from video type to document type, the adaptive compression control algorithm is invoked to decrease the compression ratio.

[0056] And / or, when the first floating window is displayed in a smaller size, the adaptive compression control algorithm is invoked to increase the compression ratio; when the first floating window is displayed in a larger size, the adaptive compression control algorithm is invoked to decrease the compression ratio.

[0057] And / or, when the electronic device switches from normal mode to power saving mode, the adaptive compression control algorithm is invoked to increase the compression ratio; when the electronic device switches from power saving mode to normal mode, the adaptive compression control algorithm is invoked to decrease the compression ratio.

[0058] For example, in a floating window scenario, when the floating window displays video content, increasing the compression ratio reduces memory bandwidth consumption and power consumption, ensuring a lossless visual effect without affecting the user experience. When the floating window displays text content, decreasing the compression ratio maintains clarity and improves the user experience.

[0059] For example, in a floating window scenario, when the floating window is shrunk, users may not be able to perceive subtle changes in image quality due to the limited display area. Therefore, increasing the compression ratio can reduce memory bandwidth consumption, lower power consumption, and improve performance. When the floating window is enlarged, the compression ratio can be reduced to improve image quality and enhance the user experience.

[0060] For example, in a floating window scenario, when an electronic device switches to power-saving mode, the compression ratio can be increased to reduce memory bandwidth consumption, lower power consumption, and ensure visually lossless results. When the electronic device switches to normal mode, the compression ratio can be reduced to improve image quality and enhance the user experience.

[0061] The above solution allows for dynamic adjustment of the compression ratio in floating window scenarios based on changes in scenario information such as the content type and window size of the floating window, user interaction information acting on the floating window, device power consumption mode, and device performance status. This effectively controls the system's resource usage, reduces memory bandwidth consumption, lowers CPU / GPU power consumption, and improves system performance. Especially for electronic devices with lower performance (e.g., small memory and low CPU / GPU performance), it solves problems such as lag and insufficient battery life, greatly enhancing the user experience.

[0062] In practical implementation, in some cases, a single floating window exists on the desktop or application interface, while in others, multiple floating windows exist. In scenarios with multiple floating windows, this application can also dynamically adjust the compression strategy for each floating window based on user interaction attributes. For example, the compression strategy can be dynamically adjusted for each floating window based on the frequency of user interaction with the floating window and the complexity of its content.

[0063] For example, the method further includes: displaying multiple floating windows, including a first floating window and a second floating window; acquiring user interaction information corresponding to the multiple floating windows, the user interaction information including the interaction frequency and / or interaction content complexity corresponding to each floating window; based on the user interaction information, calling an adaptive compression control algorithm to adjust the compression ratio corresponding to the first floating window and / or the compression ratio corresponding to the second floating window; using the adjusted first compression ratio to perform fixed bit rate compression on the content of the first floating window, and using the adjusted second compression ratio to perform fixed bit rate compression on the content of the second floating window.

[0064] For example, the adaptive compression control algorithm includes the following: the higher the interaction frequency corresponding to the floating window, the greater the compression ratio corresponding to the floating window.

[0065] For example, the adaptive compression control algorithm includes the following: the greater the complexity of the interactive content corresponding to the floating window, the greater the compression ratio of the floating window.

[0066] Electronic devices can identify floating windows with high user interaction or dynamic content (such as video playback scenarios), as well as floating windows with low user interaction or static content (such as document preview scenarios), and dynamically adjust compression strategies accordingly.

[0067] In some scenarios, when multiple floating windows are displayed on an electronic device at the same time, for floating windows with more user interaction or more dynamic content (such as video playback scenarios), a higher compression ratio can be selected for fixed bit rate compression to ensure the smoothness of floating window operation and reduce GPU load.

[0068] In some scenarios, when an electronic device displays multiple floating windows simultaneously, for floating windows with less user interaction or more static content (such as document preview scenarios), the electronic device can reduce the compression ratio to maintain high visual quality.

[0069] The above solution allows for dynamic adjustment of compression strategies for multiple floating windows in various scenarios, based on the frequency of user interaction and the complexity of the content. Adaptively adjusting compression strategies for different floating windows based on user interaction scenarios more effectively controls system resource usage, reduces memory bandwidth consumption, and lowers CPU and GPU power consumption. This also helps avoid issues such as lag and insufficient battery life, thus improving the user experience.

[0070] In some possible implementations, the electronic device includes hardware modules such as a central processing unit (CPU), a texture compression module, a graphics processing unit (GPU), and DDR. The texture compression module is a chip with texture compression capabilities.

[0071] Accordingly, the step of calling the adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate includes: the CPU calling the texture compression module and using the adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate; the CPU storing the texture compression data of the first floating window in DDR and sending the graphics drawing instructions of the first floating window to the GPU.

[0072] The above solution utilizes a hardware-level texture compression module, enabling a high compression ratio and significantly reducing texture data volume while maintaining rendering quality. By applying fixed-bitrate compression to the content of the floating window, the module effectively controls system resource usage, reduces memory bandwidth consumption, lowers power consumption, and improves system performance. This is particularly beneficial for low-performance electronic devices (e.g., those with limited memory or low CPU / GPU performance), resolving issues such as lag and insufficient battery life, and greatly enhancing the user experience.

[0073] In some possible implementations, electronic devices also include software modules such as hardware-accelerated rendering engines (e.g., HWUI), graphics processing engines (e.g., Skia), and graphics API interfaces (e.g., OpenGL).

[0074] Accordingly, the CPU invokes the texture compression module and uses an adaptive compression control algorithm to perform fixed bit rate compression on the content of the first floating window, including: the CPU determines a fixed bit rate compression strategy through the hardware accelerated rendering engine; the hardware accelerated rendering engine passes the fixed bit rate compression strategy to the graphics processing engine; the graphics processing engine obtains texture compression parameters based on the fixed bit rate compression strategy and passes the texture compression parameters to the texture compression module through the graphics API interface; the texture compression parameters include the compression ratio corresponding to the first floating window; the texture compression module performs fixed bit rate compression on the content of the first floating window based on the texture compression parameters.

[0075] In some possible implementations, the electronic device also includes an application framework layer module. This module is used to identify the content type and window size of the first floating window when it is launched, detect user interaction information acting on the first floating window, and monitor the device's power consumption mode and performance status. The application framework layer module is also used to pass graphics drawing instructions for the first floating window to the hardware-accelerated rendering engine.

[0076] Accordingly, the hardware-accelerated rendering engine determines a fixed bitrate compression strategy, including: in response to the graphics drawing instructions of the first floating window, the hardware-accelerated rendering engine obtains first scene information such as the content type and window size of the first floating window and the device power consumption mode from the application framework layer module; the hardware-accelerated rendering engine calls an adaptive compression control algorithm to determine the fixed bitrate compression strategy based on the first scene information.

[0077] In some possible implementations, the electronic device also includes a display screen. Accordingly, after the CPU sends a graphics drawing instruction for the first floating window to the GPU, the method further includes: in response to the graphics drawing instruction for the first floating window sent by the CPU, the GPU reads the texture compression data of the first floating window from DDR and decompresses the texture compression data; the GPU performs texture rendering based on the decompressed texture data and transmits the texture rendering result to the display screen; the display screen displays the content of the first floating window based on the texture rendering result.

[0078] By combining the software and hardware modules of the electronic device with the above solution, and adaptively compressing the content of the floating window at a fixed bit rate based on the current scene information, the system resource usage can be effectively controlled, memory bandwidth usage can be reduced, power consumption can be lowered, system performance can be improved, and problems such as lag and insufficient battery life can be solved, greatly enhancing the user experience.

[0079] Secondly, this application provides an adaptive compression device for a floating window scene, the device including units for performing the method described in the first aspect above. This device can correspond to performing the method described in the first aspect above; for a detailed description of the units in the device, please refer to the description in the first aspect above, and for the sake of brevity, it will not be repeated here.

[0080] The method described in the first aspect above can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a processing module or unit, a display module or unit, etc.

[0081] Thirdly, this application provides an electronic device including a processor, a computer program or instructions stored in a memory, the processor being used to execute the computer program or instructions to cause the method in the first aspect to be performed.

[0082] Fourthly, this application provides a computer-readable storage medium having a computer program (also referred to as instructions or code) stored thereon for implementing the method of the first aspect. For example, when the computer program is executed by a computer, it enables the computer to perform the method of the first aspect.

[0083] Fifthly, this application provides a chip including a processor. The processor is used to read and execute a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof. Optionally, the chip further includes a memory connected to the processor via a circuit or wire.

[0084] Sixthly, this application provides a chip system including a processor. The processor is used to read and execute a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof. Optionally, the chip system further includes a memory connected to the processor via a circuit or wire.

[0085] In a seventh aspect, this application provides a computer program product comprising a computer program (also referred to as instructions or code), which, when executed by an electronic device, causes the electronic device to implement the method in the first aspect.

[0086] It is understood that the beneficial effects of the second to seventh aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0087] Figure 1A A schematic diagram of a floating window provided in an embodiment of this application;

[0088] Figure 1B A schematic diagram illustrating an improvement to the adaptive compression method for a floating window scenario provided in an embodiment of this application;

[0089] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0090] Figure 3 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0091] Figure 4A A schematic diagram of the texture view of the floating window provided in an embodiment of this application;

[0092] Figure 4B A schematic diagram illustrating texture compression and rendering via CPU, texture compression module, GPU, etc., provided for embodiments of this application;

[0093] Figure 4CThis application provides an embodiment of a method for implementing texture compression and rendering using a CPU, texture compression module, GPU, etc. Figure 2 ;

[0094] Figures 5A to 5C A schematic diagram of texture compression in the adaptive compression method for a floating window scene provided in the embodiments of this application;

[0095] Figure 6 A flowchart illustrating the adaptive compression method for a floating window scenario provided in this application embodiment;

[0096] Figure 7 A schematic diagram illustrating the selection of a compression ratio based on scene information in the adaptive compression method for a floating window scene provided in this application embodiment;

[0097] Figure 8 A flowchart illustrating the adaptive compression method for floating window scenarios provided in this application embodiment. Figure 2 ;

[0098] Figure 9 A schematic diagram of the timing interaction process of the adaptive compression method for the floating window scenario provided in the embodiments of this application;

[0099] Figure 10 This is a flowchart illustrating the adaptive compression method provided in this application when applied to a game scenario. Detailed Implementation

[0100] The embodiments of this application will be further described in detail below with reference to specific examples and the accompanying drawings.

[0101] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "more than" means two or more.

[0102] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0103] The following is a detailed description of some of the terms used in the embodiments of this application.

[0104] 1) Texture: A texture is a structured storage format that can be read and written by a shader. For example, the content texture of a floating window can include 2D textures, 3D textures, and video textures. Texture format is a data format that the GPU can directly sample and is used when the GPU loads and renders textures.

[0105] 2) GPU: A GPU is a type of dedicated hardware in electronic devices used for processing graphics. A GPU can read texture data (referred to as texture data), load textures, and render textures, thereby efficiently rendering graphics, images, and video content.

[0106] It's important to note that if texture data consumes too much memory, it can cause overheating and negatively impact graphics rendering performance on devices with limited memory bandwidth. Memory bandwidth refers to the amount of data that memory can transfer per unit of time, typically expressed in bytes per second or bits per second.

[0107] 3) Texture Compression: Texture compression is an image compression technique specifically designed for storing textures in computer graphics rendering systems to address memory bandwidth issues. For example, texture compression compresses data in 4x4 pixel blocks. Texture-compressed data can be directly read by the GPU, which then decodes it for graphics rendering, reducing the CPU load and improving GPU rendering efficiency.

[0108] The embodiments of this application may use compression ratio or compression bit rate to characterize the degree of texture compression.

[0109] 4) Compression Ratio: The compression ratio refers to the ratio between the original data size and the data size after texture compression. The compression ratio can also be called the compression rate or compression ratio.

[0110] The smaller the compression ratio, the better the graphics rendering effect, but the larger the file will be.

[0111] The higher the compression ratio, the lower the graphics rendering effect, but the more significantly it can reduce memory usage and transmission bandwidth consumption.

[0112] 5) Compression Bitrate: Compression bitrate indicates how many bits are needed to represent each color channel of each pixel in the encoded (compressed) texture data, measured in bits per component (BPC). A bit is the smallest unit in binary, represented by 0 or 1. The compressed video data is called a bitstream. Generally, a higher compression bitrate means a larger amount of data transmitted and better audio and video quality.

[0113] 6) Floating Window (or Small Window): A floating window is a multitasking mechanism for electronic devices. It allows users to open a floating window on top of an application interface while continuing to perform other tasks. A floating window is a window that overlays other applications and offers a degree of interactivity, allowing users to perform specific actions without leaving the current interface. This feature is widely used in areas such as information reminders, shortcuts, and game assistance.

[0114] It's worth noting that the floating window is a rather unique UI component in the Android system. It's not just a simple display layer; it integrates multiple functions, such as weather forecasts, notes, and quick tools.

[0115] like Figure 1A As shown in (a), an electronic device can display a floating window on the desktop while simultaneously displaying system application interfaces such as the desktop. Figure 1A As shown in (b), an electronic device can display a floating window on the current application interface while displaying an application interface such as a video or game screen. For example, the floating window can display content such as documents, social chat windows, pictures, or playing videos.

[0116] When a floating window is enabled on an electronic device, multiple tasks are executed in parallel. This is especially true when displaying high-resolution content through the floating window, which increases the memory bandwidth requirements of the electronic device and significantly increases the GPU load. This leads to a decrease in the performance of the electronic device and an increase in power consumption. For electronic devices with small memory capacity and / or low GPU and CPU performance, stuttering may occur, which seriously affects the user experience.

[0117] It's important to note the system resource consumption of the floating window, including memory, CPU, GPU, and battery usage. Furthermore, the system may reclaim the floating window when resources are insufficient, causing it to become unresponsive.

[0118] To address the aforementioned issues, this application proposes an adaptive compression method for floating window scenarios. This method is an adaptive lossy compression method based on fixed bit rate compression. By identifying the scenario, the compression ratio of the floating window content is dynamically adjusted, thereby effectively controlling the system resource usage when rendering the floating window.

[0119] In various floating window scenarios, the content displayed in the floating window will differ. For example, sometimes it may display videos, sometimes images, and sometimes documents. The displayed content varies, users have different requirements for the clarity of the displayed content, and users' visual sensitivities also differ.

[0120] In various floating window scenarios, the display size of the floating window varies; sometimes it is relatively large, and sometimes it is relatively small. Different window sizes reflect different user requirements for the clarity of the displayed content, and also different user visual sensitivities.

[0121] In various floating window scenarios, the system state of electronic devices (such as power consumption mode, battery mode, or memory mode) may change. For example, it is usually in normal mode to ensure high-performance operation of the device; under high load, it may start power saving mode or memory saving mode to reduce power consumption, battery consumption, or memory usage.

[0122] In various floating window scenarios, the hardware performance of electronic devices will constantly change. For example, the hardware performance is usually good, but sometimes it will be low under high load, which can easily cause lag. In this case, it is necessary to reduce the hardware load.

[0123] This application can identify the scene and dynamically adjust the fixed bit rate compression ratio according to the current scene information. This can effectively control the system resource usage, reduce memory bandwidth usage, reduce power consumption, and avoid problems such as lag and insufficient battery life, thus improving the user experience.

[0124] First, let's explain the various possible texture compression methods. For example, texture compression can include uncompressed compression, hardware-specific compression, and fixed bit rate compression.

[0125] Uncompressed textures are the most basic storage method, applying no compression whatsoever to the texture data; this method can also be called lossless compression. The color information for each pixel is stored directly, typically including red, green, blue, and possibly alpha (RGBA) channels. Advantages include: maintaining the highest quality of the original image due to the lack of compression; relatively simple algorithms for processing uncompressed textures, easy to implement and understand; and direct GPU access to texture data without decompression, improving rendering speed. Disadvantages include: high memory consumption; no compression means more storage space and memory bandwidth are required, which can be problematic on resource-constrained devices. Furthermore, higher memory bandwidth requirements can lead to higher power consumption.

[0126] The default compression methods used by chips include many GPU-supported hardware-accelerated compression formats, such as S3TC / DXT, PVRTC, ETC, and ASTC. These formats are typically designed by GPU manufacturers based on hardware characteristics. In practice, the chip encodes the texture image using the default compression method and then decompresses the texture using the GPU. This texture compression method results in a large memory footprint for the compressed texture data, leading to significant resource consumption during decompression. Advantages include: hardware-accelerated decompression can reduce memory usage and improve rendering performance while maintaining good image quality. Many modern GPUs support one or more hardware compression formats. Disadvantages include: to reduce data volume, these formats often sacrifice some image quality. Furthermore, different GPUs may support different compression formats, which can lead to cross-platform compatibility issues.

[0127] Fixed bitrate compression (CBRC) is a technique that allocates a fixed number of bits to each image block for compression. It offers predictable resource consumption and performance while maintaining image quality within acceptable limits. Advantages include: using the same bitrate for each image block makes the memory and bandwidth requirements of the compressed image predictable (i.e., predictable resource consumption), aiding resource management. Compared to uncompressed data, CBRC significantly reduces memory read / write traffic. At higher bitrates, image loss is almost imperceptible, providing a good visual experience. It also reduces memory and bandwidth consumption, helping to lower GPU and CPU power consumption. Disadvantages include: although the visual effect is good at high bitrates, CBRC is still a lossy compression technique and may sacrifice some image detail. While the overhead on modern hardware is relatively small, performing CBRC compression and decompression still requires certain computational resources.

[0128] The choice of each texture storage format needs to be comprehensively considered based on the application scenario, performance requirements, and resource constraints. In practical use, these different texture storage formats can be combined according to specific needs.

[0129] It should be noted that the initial setting of the floating window is the chip's default compression. This application can effectively control system resource usage by selecting an appropriate texture compression method based on the scene information corresponding to the floating window through scene recognition. The scene information corresponding to the floating window may include the floating window's content attributes / type, window size, device power consumption mode, and user interaction information, etc.

[0130] In this embodiment of the application, in the floating window scenario, a fixed bit rate compression method can be used to compress the content of the floating window at a fixed bit rate, and the compression ratio can be adjusted according to the current scenario information. This can effectively control the occupation of system resources, reduce memory bandwidth occupation, reduce power consumption, and avoid problems such as lag and insufficient battery life in the floating window scenario, thus improving the user experience.

[0131] To better understand the embodiments of this application, the embodiments of this application will be briefly described below:

[0132] The adaptive compression method for a floating window scenario provided in this application includes: activating a first floating window in response to a user operation; identifying the content type and window size of the first floating window; detecting user interaction information acting on the first floating window; monitoring device power consumption mode and device performance status; and, based on first scenario information, invoking an adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate. When the first scenario information changes, the adaptive compression control algorithm is invoked to dynamically adjust the compression ratio. The first scenario information includes at least one of the following: the content type of the first floating window, the window size of the first floating window, user interaction information acting on the first floating window, device power consumption mode, and device performance status information.

[0133] The adaptive compression method for floating window scenarios provided in this application allows for texture compression of the floating window content using a fixed bitrate compression method, based on the content type and window size of the floating window, user interaction information acting on the floating window, device power consumption mode, and / or device performance status. By applying a fixed bitrate compression method to the floating window content based on the current scene information, this solution ensures that each image texture block is stored and transmitted using a fixed bitrate, effectively controlling system resource usage. This not only reduces memory bandwidth consumption but also lowers CPU / GPU power consumption, improves system performance, and provides visually lossless effects. Especially for low-performance electronic devices (e.g., those with limited memory and low CPU / GPU performance), this method solves problems such as lag and insufficient battery life, significantly improving the user experience.

[0134] Figure 1B This demonstrates the improvements and technical effects of the proposed solution compared to traditional solutions. In traditional solutions, displaying a floating window on an electronic device consumes significant system resources, especially when displaying high-resolution content via the floating window. This consumes a large amount of content and bandwidth, leading to decreased performance, increased power consumption, and a tendency to lag.

[0135] Power consumption measures the efficiency of resource (electricity) consumption during computation. Given a fixed battery capacity, higher power consumption means greater power consumption per unit time, resulting in shorter usage time.

[0136] After improvements, in floating window scenarios, especially when device resources are limited (e.g., when the electronic device is under high load and / or low performance), a fixed bit rate compression method is enabled. This method adaptively compresses the floating window content based on current scenario information, optimizing memory usage and bandwidth consumption. Specifically, after the floating window is activated, the electronic device dynamically adjusts the content compression ratio based on current scenario information such as the content type (content complexity), window size, user interaction information interacting with the floating window, and device power consumption mode. This effectively controls system resource usage, reduces memory consumption and bandwidth consumption, and lowers overall power consumption.

[0137] The following description, in conjunction with the accompanying drawings, describes the electronic device to which the adaptive compression method for floating window scenarios provided in this application is applied. For example, the electronic device in this application embodiment may be a mobile phone, tablet computer, ultra-mobile personal computer (UMPC), netbook, as well as a cellular phone, personal digital assistant (PDA), wearable device (such as a smartwatch, smart bracelet), or other device with image display capabilities. This application embodiment does not impose any special limitations on the specific form of the electronic device.

[0138] Figure 2 This illustration shows a hardware structure diagram of an electronic device according to an embodiment of this application. For example, a mobile phone is used as an example. Figure 2 As shown, the electronic device may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver (i.e., earpiece) 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The aforementioned sensor module may include pressure sensors and touch sensors.

[0139] Processor 110 may include one or more processing units, such as a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0140] The CPU performs calculations and decoding on the resources, and then transmits the texture data to the GPU. The GPU decompresses the texture data into a texture buffer and performs texture rendering based on the decompressed texture data.

[0141] GPUs employ a massively parallel hardware architecture, enabling the simultaneous execution of multiple threads, thereby significantly enhancing graphics rendering and data-parallel computing capabilities. As a key hardware component of a computer system, GPUs can be embedded within a chip system or connected to the motherboard as a standalone graphics card unit. Regardless of the method, GPUs provide powerful graphics rendering and visual computing support for the system. Electronic devices equipped with GPU acceleration can not only smoothly render 3D graphics, animations, and video content, but also are widely used in visually intensive scenarios such as gaming, professional graphics, and video editing.

[0142] A controller can be the nerve center and command center of an electronic device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0143] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0144] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0145] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0146] In this embodiment, the processor 110 may further include a texture compression module. The texture compression module is hardware with texture compression and decompression capabilities. The specific application of the texture compression module will be described in detail below.

[0147] In this embodiment, the processor 110 is used to perform fixed bit rate compression on the content of the floating window using a texture compression module in the floating window scenario. It also dynamically adjusts the content compression ratio of the floating window based on the content type (content complexity), window size, user interaction information applied to the floating window, and device power consumption mode, etc., to achieve adaptive compression control. This can effectively control the occupation of system resources, reduce memory occupation and bandwidth consumption, and reduce overall power consumption.

[0148] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0149] Internal memory 121 can be used to store computer executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc. The data storage area may store data created during the use of the electronic device, etc.

[0150] For example, in this embodiment, the processor 110 can implement the adaptive compression method for the floating window scene provided in this embodiment by executing instructions stored in the internal memory 121.

[0151] In addition, the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. The processor 110 performs various functional applications and data processing of the electronic device by executing instructions stored in the internal memory 121 and / or instructions stored in memory disposed in the processor.

[0152] For example, in this embodiment of the application, the internal memory 121 may include DDR main memory, DDR video memory, and texture cache.

[0153] The charging management module 140 receives charging input from a charger (such as a wireless charger or a wired charger) to charge the battery 142. The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power various components of the electronic device.

[0154] The wireless communication function of electronic devices can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0155] Electronic devices can achieve shooting functions through image signal processors, cameras 193, video codecs, GPUs, displays 194, and application processors.

[0156] Electronic devices can implement display functions through GPUs, displays 194, and application processors. A GPU is a microprocessor for image processing, connecting the display 194 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0157] The display screen 194 is used to display images, videos, etc. In this embodiment, the display screen 194 can display one or more floating windows, and display game screens, videos, pictures, documents, or chat windows, etc. in the floating windows.

[0158] The above is a detailed description of the embodiments of this application using electronic device 100 as an example. It should be understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on electronic device 100. Electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations. The various components shown in the figures can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0159] In addition, an operating system runs on top of the aforementioned hardware. This operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. Applications can be installed and run on this operating system.

[0160] The operating system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0161] Figure 3 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0162] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TM The system is divided into five layers, from top to bottom: application layer, application framework layer, native system library layer, hardware abstraction layer (HAL), and kernel layer.

[0163] The application layer can include a series of application packages. For example, the application layer can include a gallery app, a browser app, a video app, and a game app.

[0164] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications within the application layer. The application framework layer includes some predefined functions. It may include functional modules such as Activity Management (ActivityManager), Window Management (WindowManager), ViewSystem (ViewSystem), Input Management Service (InputManagerService), and power management; however, this embodiment does not impose any limitations on these modules.

[0165] The Activity management module can be used to manage application Activities, etc.

[0166] In this embodiment of the application, when an Activity is launched, the Activity creates or binds to a window. This window is a container for the view hierarchy, and all views are drawn in this window.

[0167] The window management module is responsible for managing application windows, handling window layout on the screen, hierarchical relationships between windows, and operations such as adding, moving, and deleting windows.

[0168] The view system can manage the views within a window and can provide a view tree structure. In this embodiment, the view system can determine whether the current window is a floating window and obtain the content and size of the floating window view.

[0169] The input management service module is responsible for managing the processing and distribution of input events from different input devices. For example, based on the input management service module, user interaction information applied to the floating window can be detected.

[0170] The power management module can be used to manage device power consumption modes, etc. In the floating window scenario, the power management module will obtain power consumption mode information. If the power consumption mode information indicates that power saving mode is enabled, the electronic device can increase the fixed bit rate compression ratio to reduce power consumption.

[0171] The native system library layer, also known as the native service layer or native framework layer, is a native code platform library that provides native services and link libraries for hardware operations to the upper layers. In this embodiment, the native system library may include a hardware-accelerated rendering engine (such as the HWUI engine) and a graphics processing engine (such as the Skia engine).

[0172] HWUI (hardware accelerated rendering engine for UI) is a GPU-accelerated 2D graphics engine primarily used for UI rendering in the Android system.

[0173] Skia is a 2D graphics processing engine that provides basic graphics drawing functions, including the processing of graphics, text, bitmaps, etc. Skia can be a 2D graphics processing function library that uses the CPU for computation. In the Android system, Skia is mainly used to handle non-hardware accelerated graphics drawing tasks. When hardware acceleration is unavailable or not fully supported, Skia will take over some drawing tasks.

[0174] In the Android system, HWUI uses Skia as the core graphics library, supporting hardware-accelerated rendering to achieve UI rendering goals.

[0175] In this embodiment, the local system library also includes an adaptive compression control algorithm. Using the adaptive compression control algorithm provided in this embodiment, a texture compression module is used to compress the content of the floating window at a fixed bit rate in a floating window scenario. Furthermore, the algorithm can dynamically adjust the content compression ratio of the floating window based on current scenario information such as the content type (content complexity), the window size, user interaction information applied to the floating window, and the device power consumption mode. This achieves adaptive compression control, effectively controlling system resource usage, reducing memory consumption and bandwidth consumption, lowering overall power consumption, and providing visually lossless effects.

[0176] The Hardware Abstraction Layer (HAL) is a wrapper around Linux kernel drivers, providing interfaces to the upper layers and shielding them from the implementation details of the lower-level hardware.

[0177] In this embodiment of the application, the hardware abstraction layer may include display HAL and graphics API, etc.

[0178] A graphics API is an interface that allows software programs to communicate with graphics hardware, enabling control of the GPU and graphics rendering functions. For example, graphics APIs include graphics interfaces such as OpenGL and / or Vulkan. These graphics APIs define a set of programming interfaces for rendering 2D and 3D graphics, through which the GPU can be invoked for graphics rendering.

[0179] The Display Layout Algorithm (HAL) is used to define a set of routines, protocols, and tools for interacting with the hardware. In Android, the HAL ensures consistent graphics rendering across different devices and supports various graphics APIs such as OpenGL and Vulkan.

[0180] The kernel layer is the layer between hardware and software. The kernel layer contains at least a display driver. The display driver is the driver layer for the display screen. For example, the display driver can start the display screen in the hardware layer, and the display screen can show a floating window.

[0181] For clarity, the diagram also illustrates the hardware layer that interacts with the aforementioned software architecture. For example, the hardware layer may include components such as the CPU, GPU, DDR, display screen, and texture compression module.

[0182] It should be noted that the texture compression module can be a module with texture compression / decompression capabilities, or it can be a chip with texture compression / decompression capabilities.

[0183] In some embodiments, the texture compression module is integrated on the CPU.

[0184] In other embodiments, the texture compression module is integrated on the GPU.

[0185] In other embodiments, the texture compression module is independent of the CPU and GPU.

[0186] In some embodiments, the CPU invokes the texture compression module to implement fixed bit rate compression.

[0187] In other embodiments, the GPU invokes a texture compression module to implement fixed bit rate compression / decompression.

[0188] It should be noted that although the embodiments of this application are described using the Android system as an example, the basic principles are also applicable to electronic devices based on operating systems such as iOS or Windows.

[0189] The following describes the view of the floating window and the view drawing process.

[0190] Floating window view

[0191] In Android, each interface is composed of views of varying sizes. Each view in an application undergoes measurement, layout, and drawing. The main thread passes view resources to the CPU, which decompresses the resources, performs texture compression using a texture compression module, and then uses the OpenGL / Vulkan interface to call the GPU to decompress the texture and render the graphics. The data to be displayed is then passed to SurfaceFlinger via inter-process communication. SurfaceFlinger then hands the rendering result to the hardware compositor for compositing and output to the display screen, where the floating window content is displayed.

[0192] It's important to note that floating windows are not merely simple display layers; they integrate multiple functions, such as weather forecasts, notes, and quick tools. For example, for a floating chat window, a transparent window is first created, and the chat interface content is rendered on top of it. As another example, a floating music player control can display information about the currently playing song and control buttons while music is playing in the background.

[0193] The implementation of floating windows relies on the window management service provided by the Android system. The window management service is a service in Android used to manage windows. It provides interfaces for operations such as adding, deleting, modifying, and querying windows. The window management service runs in the system process and is responsible for adding the window's view to the screen. Each window can be considered an independent layer, and the order in which these layers are added determines their hierarchical relationship.

[0194] like Figure 4AAs shown, the window contains a root view (DecorView), a surface view (SurfaceView), and a texture view (TextureView). These are controls used in Android development to display images. The various views in the window are compressed and encoded before being passed to SurfaceFlinger. SurfaceFlinger contains multiple layers and layer buffers. SurfaceFlinger is a system process used to integrate images from different windows, composite them, and then display them on the hardware.

[0195] It's important to note that each Activity has an associated Window, which contains a DecorView. The DecorView can include a title bar and content panes, among other things. The DecorView is the root view of all views in an Android application and is one of the core components of the framework used to manage and display the application's interface. As the top-level container, the DecorView carries the application's view structure, defines the boundaries of the application's interface, and all views are drawn and events are dispatched within these boundaries.

[0196] SurfaceView is a special type of view in Android. It inherits from the View class, but unlike a regular View, SurfaceView has its own independent drawing surface, not shared with its host window. Because it has a separate drawing surface, SurfaceView's UI can be drawn in a separate thread, without consuming main thread resources, thus avoiding UI lag caused by the main thread being occupied. This makes SurfaceView particularly suitable for applications requiring efficient display of frequently updated content, such as video playback and high-performance game graphics rendering.

[0197] TextureView is a view that displays content, inheriting from the View class. It allows for complex view transformations on its content, such as scaling and rotation. The content rendered by TextureView is treated as a texture within the view hierarchy. Unlike SurfaceView, TextureView's drawing operations are performed on the UI thread, meaning it can directly utilize hardware acceleration and supports complex view transformations.

[0198] In this embodiment of the application, fixed bitrate compression of the content of the floating window refers to texture compression of the view content in the floating window.

[0199] The process of drawing the view of a floating window

[0200] The following describes the view drawing process. Phase 1: UI Thread Drawing. When a View needs to be drawn, the UI thread calls the corresponding drawing method, such as onDraw(). These drawing methods perform drawing operations through the interface provided by the Canvas class. The Canvas drawing commands are translated into Skia drawing commands and stored in the display list. Phase 2: The rendering thread retrieves the drawing commands from the display list and sends these commands to the GPU for execution via the OpenGL / Vulkan interface. Phase 3: The GPU completes the rendering and outputs the rendering results to the screen.

[0201] In this embodiment of the application, displaying the view in the floating window on the screen requires the collaboration of the CPU and GPU.

[0202] Figure 4B This is a flowchart illustrating a possible implementation of texture compression using a CPU, a texture compression module, and a GPU, as provided in an embodiment of this application. The CPU decodes the view resource, the texture compression module performs texture compression on the decoded view resource, the CPU uploads the compressed texture resource, and then the CPU calls a graphics API to decompress the texture and complete the rendering. The graphics API includes OpenGL and / or Vulkan interfaces.

[0203] It's important to note that, in addition to the CPU, GPU, and display, the texture compression process also involves DDR main memory and DDR video memory. The CPU is responsible for loading the compressed texture data from DDR main memory into DDR video memory. The CPU sets the rendering state and instructs the GPU to start rendering via a Draw Call command. The GPU can access DDR video memory, obtain the compressed texture data, decompress the compressed texture data, and store it in the layer buffer. The GPU then performs texture rendering based on the decompressed texture data.

[0204] Texture compression reduces the package size and the amount of data. After texture compression, memory usage is more efficient, reducing the pressure of bandwidth calculation and reducing GPU load.

[0205] Figure 4C This is a schematic diagram illustrating the interaction between various hardware components in the embodiments of this application. For example... Figure 4C As shown, in a floating window scenario, after acquiring the content of the floating window, the CPU can call the texture compression module to perform fixed-bitrate compression on the floating window content, achieving hardware-level texture compression, and storing the compressed texture data in DDR main memory. The CPU sets the rendering state and instructs the GPU to start rendering via a Draw Call command. The CPU loads the compressed texture data from DDR main memory into DDR video memory.

[0206] After receiving a Draw Call command, the GPU reads compressed texture data from DDR memory. The GPU then calls the texture compression module to decompress the read texture data and stores the decompressed texture data in a texture buffer. Next, the GPU performs texture rendering based on the texture data cached in the texture buffer. Finally, the GPU transmits the texture rendering result to the display screen.

[0207] The display shows the content of the floating window based on the texture rendering results.

[0208] The system resource consumption of the floating window includes memory, CPU, GPU, and battery usage.

[0209] This application embodiment can use a fixed bitrate compression method to compress the content of the floating window. This fixed bitrate compression is a hardware-based texture compression technology. Since the texture compression module is a hardware-level compression module, it can achieve a high compression ratio and significantly reduce the amount of texture data while ensuring rendering quality.

[0210] This application embodiment can employ an adaptive compression control algorithm to adaptively compress the content of the floating window. This algorithm uses a texture compression module to compress the floating window content at a fixed bit rate in the floating window scenario. Furthermore, it dynamically adjusts the fixed bit rate compression ratio based on current scenario information such as floating window attribute information (content type and window size), device power consumption mode, and user interaction information. This achieves adaptive compression control, effectively controlling system resource usage, reducing memory consumption and bandwidth consumption, and lowering overall power consumption.

[0211] It should be noted that the fixed bit rate compression used in the embodiments of this application is lossy compression, which allows for a certain loss of quality during rendering, and can achieve a visually lossless effect.

[0212] In this embodiment, data compressed at a fixed bit rate can be directly read by the GPU, enabling faster loading of floating window textures and reducing GPU and DDR load.

[0213] The implementing entity of the adaptive compression method for floating window scenes provided in this application embodiment can be the aforementioned electronic device, or a functional module and / or functional entity within the electronic device capable of implementing the adaptive compression method for floating window scenes. Furthermore, the solution of this application can be implemented through hardware and / or software, the specific implementation depending on actual usage requirements, and this application embodiment does not impose any limitations. The following description uses an electronic device as an example, in conjunction with the accompanying drawings, to exemplarily illustrate the adaptive compression method for floating window scenes provided in this application embodiment.

[0214] The embodiments of this application will be described below with reference to the accompanying drawings and through several exemplary embodiments. The methods in the following embodiments can all be implemented in an electronic device having the above-described hardware structure and software architecture. The hardware structure diagram of the electronic device can be as follows: Figure 2 As shown, the software structure block diagram of an electronic device can be as follows: Figure 3 As shown, the embodiments of this application are not limited to this. For ease of explanation, the electronic device used in the embodiments of this application is a mobile phone.

[0215] First, the implementation method and principle of texture compression used in the embodiments of this application will be explained.

[0216] Implementation methods and principles of texture compression

[0217] Texture compression can refer to texture block compression. For example... Figure 5A As shown, the original image texture is divided into multiple texture blocks, for example, each texture block contains 4*4 pixels (16 pixels in total), and then each texture block is compressed.

[0218] Texture compression includes two methods: variable rate compression (VRC) and fixed-rate compression (FRC).

[0219] Dynamic bitrate compression, also known as variable bitrate compression, dynamically adjusts the compression ratio based on the complexity of the image content (4x4 pixel blocks). For example, more bits are allocated to complex image areas to maintain image quality, while fewer bits are allocated to simpler image areas to reduce storage space and transmission bandwidth. VRC is typically set as the default compression format.

[0220] Fixed bitrate compression (FRC) refers to compression by allocating a fixed number of bits to each pixel block (4x4 pixel block). With this compression method, the same bitrate is used for compression regardless of the complexity of the image content. For example, compression is performed in 4x4 pixel blocks, with each compressed block having a fixed size. This fixed block structure allows the GPU to quickly access any part of the texture because the entire block can be decompressed at once and stored in the texture cache, thus improving access efficiency. In other words, consistent decoding speed for any pixel ensures that the GPU can efficiently access pixels randomly. FRC is particularly suitable for electronic devices with limited memory and bandwidth.

[0221] The main differences between FRC and VRC are explained below with reference to Table 1, in terms of bit rate allocation, predictability of resource usage, visual quality, power consumption and application scenarios.

[0222] Table 1

[0223]

[0224] Regarding bitrate allocation, VRC can dynamically adjust the bitrate based on the complexity of the image content, meaning it uses different compression ratios for each texture block; a relatively low compression ratio is used for complex image areas, while a relatively high compression ratio is used for simple areas. FRC, on the other hand, can allocate a fixed number of bits for compression to each texture block, meaning it uses the same compression ratio for all texture blocks. This implies that regardless of the image content, the data size of each block is the same.

[0225] Regarding the predictability of resource usage, for VRC, the bit rate varies depending on the image content, and the compressed data size may fluctuate significantly, making it difficult to accurately predict resource usage. For FRC, since each image block uses a fixed bit rate, the system can accurately predict the memory and bandwidth required for the compressed image, which is highly advantageous for devices with limited resources such as memory and bandwidth.

[0226] In terms of visual quality, VRC (Dynamic Voltage Compression) intelligently allocates bitrates to maintain image quality as much as possible while keeping file size low. However, in extreme cases, simple areas may be over-compressed, while complex areas may lose detail due to bitrate limitations. FRC (Fragmented Rendering) at higher bitrates, although it involves lossy compression, the image loss is almost imperceptible, achieving a visually lossless effect.

[0227] In terms of power consumption, while VRC can also reduce power consumption to some extent by decreasing file size, the dynamic bitrate characteristic may result in a less significant power reduction compared to FRC. FRC, by reducing memory and bandwidth usage, can significantly reduce GPU and CPU power consumption, making it particularly suitable for power-saving modes.

[0228] In terms of application scenarios, VRC is more suitable for scenarios with high image quality requirements, such as high-quality image storage and non-real-time video processing. FRC is particularly suitable for scenarios with strict resource requirements, such as mobile devices, real-time rendering, and video playback.

[0229] It should be noted that when a floating window is enabled on an electronic device, multiple tasks are executed in parallel. This increases the demand for memory bandwidth and significantly increases the GPU load, leading to performance degradation and increased power consumption. For lower-performance devices, this can easily result in stuttering and insufficient battery life. Therefore, in this embodiment, a fixed bitrate compression method can be used to compress the texture of the floating window content in the floating window scenario. Under this compression method, the same bitrate is used for compression regardless of the complexity of the image content.

[0230] For example, fixed-bitrate compression can be performed using 4x4 pixel blocks, with each compressed block having a fixed size. This fixed block structure allows the GPU to quickly access any part of the texture because the entire block can be decompressed at once and stored in the texture buffer, thereby improving access efficiency. This effectively controls system resource usage, reduces memory consumption and bandwidth consumption, and lowers overall power consumption.

[0231] Because at higher bit rates, although it is lossy compression, the image loss is almost imperceptible, achieving a visually lossless effect, fixed bit rate compression is also called visually lossless compression.

[0232] The adaptive compression control algorithm provided in this application can support multiple levels of compression ratio. The compression ratio can also be referred to as the compression ratio or compression rate.

[0233] For example, a compression ratio of 4:1 means that the ratio between the original data size and the compressed data size is 4:1 (i.e., 8:2).

[0234] For example, a compression ratio of 2:1 means that the ratio between the original data size and the compressed data size is 2:1 (i.e., 8:4).

[0235] For example, a compression ratio of 8:5 means that the ratio between the original data size and the compressed data size is 8:5.

[0236] Among them, the compression ratio 4:1 is greater than the compression ratio 2:1, and the compression ratio 2:1 is greater than the compression ratio 8:5.

[0237] It should be noted that the above compression ratio is an illustrative example. In actual implementation, the compression ratio can be set according to actual usage requirements.

[0238] It is understandable that increasing the compression ratio of textures reduces the memory occupied by textures, reduces GPU load, reduces power consumption, and makes the improvement in device performance more obvious.

[0239] It should be noted that fixed bitrate compression can be a method of texture block compression. That is, the texture is divided into multiple texture blocks, for example, each texture block contains 4*4 pixels, and then each texture block is compressed. The compressed pixel information is stored in a pixel set, and the index position of each texture block is stored in a block index map. By dividing the texture into fixed-size texture blocks, compressing each texture block separately, and loading it into video memory, the video memory usage can be reduced.

[0240] In addition to using the compression ratio to characterize the degree of compression at a fixed bit rate, the compression bit rate can also be used to characterize the degree of compression at a fixed bit rate.

[0241] For example, the unit of compression bit rate can be BPC (bits per component, the number of bits per color channel). Compression bit rate represents the number of bits per color channel per pixel after compression at a fixed bit rate.

[0242] The following example illustrates the compression bit rate. The original image is an RGBA image (RGB three channels + Alpha channel), with each pixel including four color channels, and each color channel corresponding to 8 bits (i.e., occupying 8 bits).

[0243] In some embodiments, the compression bit rate can be 2 BPC, meaning that after compression at a fixed bit rate, each color channel corresponds to 2 bits (i.e., occupies 2 bits). It can be understood that the original image has 8 bits per color channel, and after compression, each color channel has 2 bits, a ratio of 4:1, therefore the corresponding compression ratio is 4:1.

[0244] It should be noted that the above example of each color channel corresponding to 2 bits is for illustrative purposes only. In actual implementation, since each pixel is not necessarily represented by RGBA when storing texture according to image blocks, 2 bits is an equivalent statement.

[0245] In this embodiment of the application, if the compression bit rate is 2BPC, then after compression at a fixed bit rate, the average number of bits for multiple channels of a pixel can be 2 bits.

[0246] In some embodiments, the compression bit rate can be 4 BPC, meaning that after compression at a fixed bit rate, each color channel corresponds to 4 bits (i.e., occupies 4 bits). It can be understood that the original image has 8 bits per color channel, and after compression, each color channel has 4 bits, a ratio of 2:1, therefore the corresponding compression ratio is 2:1.

[0247] In this embodiment of the application, if the compression bit rate is 4 BPC, then after compression at a fixed bit rate, the average number of bits for multiple channels of a pixel can be 4 bits.

[0248] In some cases, compression bitrate can be understood as how many bits per second are needed to represent the encoded (compressed) audio / video data.

[0249] It's understandable that a higher compression bitrate, i.e., a lower compression ratio, results in a larger amount of data transmitted and better audio / video quality. Conversely, a lower compression bitrate, i.e., a higher compression ratio, results in a smaller amount of data transmitted, but at the cost of lower audio / video quality.

[0250] The basic principle of fixed bit rate compression used in the embodiments of this application will be explained below with reference to the accompanying drawings. For ease of explanation, a compression ratio of 2:1 or 4:1 will be used as an example for illustration.

[0251] Let's start by explaining fixed bit rate compression from the perspective of each pixel.

[0252] refer to Figure 5B As shown in (a), each pixel includes four color channels: RGBA, and each color channel occupies 8 bits. If a fixed bit rate compression is performed at a compression ratio of 4:1, then each color channel occupies 2 bits after compression. Therefore, this compression at a 4:1 compression ratio can also be called 2BPC texture compression.

[0253] refer to Figure 5B As shown in (b), each pixel includes four color channels: RGBA, and each color channel occupies 8 bits. If a fixed bit rate compression is performed at a compression ratio of 2:1, then each color channel occupies 4 bits after compression. Therefore, this compression at a compression ratio of 2:1 can also be called 4BPC texture compression.

[0254] It's understandable that fixed bit rate compression reduces the number of bits per color channel.

[0255] Next, let's explain fixed bit rate compression from the perspective of each texture block.

[0256] refer to Figure 5C As shown in (a), for the original image, each texture block consists of 4*4 pixels, and each pixel includes four color channels (RGBA), with each color channel occupying 8 bits. Each texture block in the original image occupies 16×4×8=512 bits. If a fixed bitrate compression ratio of 2:1 is used (corresponding to a compression bitrate of 4 BPC), after compression, each color channel occupies 4 bits, and correspondingly, each texture block occupies 16×4×4=256 bits. In other words, through fixed bitrate compression, the number of bits occupied by each texture block is reduced from 512 to 256.

[0257] refer to Figure 5CAs shown in (b), if a fixed bit rate compression is performed at a compression ratio of 4:1 (corresponding to a compression bit rate of 2 BPC), then after compression, each color channel occupies 2 bits, and correspondingly, each texture block occupies 16 × 2 × 4 = 128 bits. That is to say, through fixed bit rate compression, the number of bits occupied by each texture block is reduced from 512 to 128.

[0258] It is understandable that by using fixed bit rate compression, the number of bits per color channel is reduced, thereby reducing the number of bits per texture block.

[0259] In this embodiment of the application, by dividing the texture into texture blocks of fixed size, compressing each texture block separately and loading it into the video memory, the video memory usage can be reduced.

[0260] Fixed-bitrate compression reduces memory usage and bandwidth consumption, thereby alleviating memory pressure on mobile devices, reducing the decoding burden on the CPU / GPU, and improving rendering performance. Reducing memory usage also helps prevent crashes on low-end devices due to insufficient memory.

[0261] Adaptive compression method for floating window scenarios

[0262] The above explains the two compression methods of texture compression and the basic principles of fixed bit rate compression. The following describes the adaptive compression method for floating window scenes provided in this application, with reference to specific embodiments.

[0263] First Embodiment

[0264] In some cases, in floating window scenarios, a fixed bit rate compression method is directly used to perform texture compression on the content of the first floating window at a preset compression ratio.

[0265] In other cases, in the case of a floating window, it can be determined whether the electronic device is in a high-load state and / or a low-performance state based on the pre-configured performance parameters and real-time dynamic performance parameters of the electronic device; if it is determined that the electronic device is in a high-load state, a fixed bit rate compression method is used to perform texture compression on the content of the first floating window at a preset compression ratio.

[0266] For example, pre-configured performance parameters include the amount of available DDR memory, the available range of DDR bandwidth, and GPU frequency.

[0267] For example, real-time dynamic performance parameters include CPU utilization, DDR memory usage, DDR bandwidth, and / or GPU load.

[0268] For example, when CPU utilization exceeds a first threshold, DDR memory utilization exceeds a second threshold, bandwidth is insufficient, and / or GPU load exceeds a third threshold, it can be determined that the electronic device is in a high-load and / or low-performance state. Each threshold is determined by pre-configured performance parameters.

[0269] The above solution determines whether the electronic device is under high load and / or low performance in the floating window scenario. If the electronic device is under high load and / or low performance, the content of the floating window is compressed at a fixed bit rate with a preset compression ratio. This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding problems such as lag and insufficient battery life, thus improving the user experience.

[0270] For example, the preset compression ratio can be 2:1 or other possible compression ratios.

[0271] The above solution directly compresses the content of the floating window at a fixed bit rate with a preset compression ratio in the floating window scenario. This reduces memory bandwidth usage and lowers CPU and GPU power consumption, thus avoiding problems such as lag and insufficient battery life, thereby improving the user experience.

[0272] Second Embodiment

[0273] In the second embodiment, in the floating window scenario, an adaptive compression control algorithm can be invoked to determine the fixed bit rate compression method and compression ratio based on the content type and window size of the first floating window, user interaction information acting on the first floating window, device power consumption mode, and device performance status. The compression ratio is then dynamically adjusted to perform fixed bit rate compression on the content of the first floating window. This more effectively controls system resource usage, reduces memory bandwidth consumption, lowers CPU / GPU power consumption, and improves system performance.

[0274] Figure 6 This is a flowchart illustrating the adaptive compression method for a floating window scenario provided in an embodiment of this application. (Refer to...) Figure 6 As shown, the method includes the following steps S201-S207.

[0275] S201. In response to user operation, launch the first floating window.

[0276] For example, electronic devices can have a smart multi-window function that allows users to swipe and pause from the edge of the screen to quickly open a floating window. For instance, when the electronic device displays the first interface, in response to the user's swipe and pause from the screen edge, the device displays icons for multiple applications in the sidebar; in response to the user's click on the icon of the first application, the electronic device displays a floating window on the first interface, through which the interface of the first application is displayed.

[0277] The first interface can be the interface of a system application such as a desktop, or it can be the interface of a third-party application.

[0278] It should be noted that in actual implementation, electronic devices provide various possible ways to launch floating windows, and this application does not limit this.

[0279] S202. Identify the content type and window size of the first floating window.

[0280] Electronic devices can display various types of content through a first floating window. For example, the content type can be a video, an image, or a document.

[0281] It should be noted that users have different sensitivities to visual quality when displaying different types of content in a floating window, meaning their visual quality requirements vary. For example, as shown in Table 2, compared to a full-screen window, a floating window is smaller. Therefore, users have lower visual quality requirements when displaying video content, medium requirements when displaying images, and higher resolution when displaying documents.

[0282] Table 2

[0283] Floating window displays content types Visual quality requirements video lower picture medium document higher

[0284] In different situations, the window size of the first floating window will vary due to different floating window settings.

[0285] In addition, users can manipulate the first floating window to adjust its size as needed. For example, users can drag the corners or sides of the first floating window to change its size.

[0286] It's important to note that user sensitivity to visual quality varies depending on the size of the floating window. For example, in a smaller window, due to the limited display area, users may have difficulty perceiving subtle changes in image quality. In a larger window, users are relatively more sensitive to visual quality, and the content displayed in the floating window needs to be more detailed to maintain a good visual experience. As shown in Table 3, users have lower requirements for visual quality when the floating window size is small, and higher requirements for visual quality and detail are needed when the floating window size is large.

[0287] Table 3

[0288] Window size of floating window Visual quality requirements Smaller window lower Larger window higher

[0289] S203, Monitoring device power consumption mode.

[0290] For example, device power consumption modes can include power saving mode and normal mode.

[0291] In normal mode, electronic devices perform well, with the CPU and GPU operating at maximum frequency, providing optimal performance and user experience.

[0292] In power-saving mode, electronic devices extend battery life by reducing device power consumption. For example, in power-saving mode, electronic devices automatically adjust system settings, such as reducing CPU performance and disabling unnecessary hardware functions. Due to power management limitations, device performance in power-saving mode is reduced, with lower CPU and GPU operating frequencies, resulting in overall performance that is not as good as in normal mode.

[0293] It should be noted that electronic devices adjust the visual quality of the content displayed in the floating window depending on the device's power consumption mode. For example, as shown in Table 4, when the electronic device is in normal mode, it is usually required to display content with high visual quality in the floating window for good performance and user experience; when the electronic device is in power-saving mode, it is necessary to reduce the consumption of memory bandwidth to reduce power consumption and improve smooth performance, so the visual quality of the content displayed in the floating window will be appropriately reduced.

[0294] Table 4

[0295] Device power consumption mode Visual quality requirements Smoothness requirements Normal mode higher Keep Power saving mode lower promote

[0296] S204. Monitor the performance status of equipment.

[0297] For example, equipment performance status can include normal status, high load status, or low performance status.

[0298] When the electronic device is in normal working order, it can provide good operational smoothness.

[0299] When electronic devices are under high load or low performance, their operation becomes less smooth and they are prone to lag.

[0300] S205. Detect user interaction information applied to the floating window.

[0301] In some embodiments, the electronic device initiates a first floating window, and the electronic device detects user interaction information acting on the floating window, including the frequency of user interaction with the first floating window.

[0302] As shown in Table 5, when the user's interaction frequency with the floating window is greater than a certain frequency threshold, the interaction frequency is high, and the operation smoothness requirement of the floating window is high in order to ensure user experience; when the user's interaction frequency with the floating window is less than or equal to a certain frequency threshold, the interaction frequency is low, and in order to reduce power consumption, the operation smoothness requirement of the floating window is low.

[0303] Table 5

[0304] User interaction information Operational smoothness requirements High interaction frequency higher lower interaction frequency lower

[0305] In another embodiment, when the electronic device activates multiple floating windows, the electronic device monitors user interaction information applied to each of the multiple floating windows. This user interaction information includes the interaction frequency and / or the complexity of the interaction content corresponding to each floating window. The complexity of the interaction content refers to the degree of complexity of the content.

[0306] For example, multiple floating windows include a first floating window and a second floating window. If the first floating window has a higher interaction frequency and / or higher interaction content complexity, and the second floating window has a higher interaction frequency and / or lower interaction content complexity, then the first floating window is the primary floating window, and the second floating window is the secondary floating window.

[0307] This application does not limit the execution order of S202, S203 and S204 above; they can be executed in parallel or sequentially.

[0308] S206. Based on the content type and window size of the first floating window, the power consumption mode of the device acting on the first floating window, user interaction information and / or device performance status, call the adaptive compression control algorithm to determine the compression ratio.

[0309] In this embodiment, in a floating window scenario, an adaptive compression control algorithm can be invoked to determine a fixed bitrate compression method and compression ratio based on scenario information such as the content type and window size of the first floating window, user interaction information acting on the first floating window, device power consumption mode, and device performance status. The compression ratio is then dynamically adjusted to perform fixed bitrate compression on the content of the first floating window. This more effectively controls system resource usage, reduces memory bandwidth consumption, lowers CPU / GPU power consumption, and improves system performance.

[0310] It should be noted that in a floating window scenario, different scene information corresponding to the first floating window will result in different requirements for visual quality or operational smoothness. These different requirements will lead to different compression ratios.

[0311] For example, the higher the visual quality requirement, the smaller the corresponding compression ratio.

[0312] For example, the higher the requirement for smooth operation, the greater the corresponding compression ratio.

[0313] Referring to Table 6, suggested compression ratios are given for different scenarios, such as the content type, window size, power consumption mode, and user interaction information of the floating window.

[0314] Table 6

[0315]

[0316] The compression ratio is not limited in this embodiment; it can be set according to actual usage requirements.

[0317] For example, a higher compression ratio can be 4:1, a medium compression ratio can be 2:1, and a lower compression ratio can be 8:5.

[0318] Figure 7 Possible implementations of the adaptive compression control algorithm provided in the embodiments of this application.

[0319] Method 1: Determine the fixed bit rate compression ratio based on the content type of the floating window.

[0320] In some possible implementations, the content displayed in the first floating window can be a video, an image, or a document. Accordingly, the adaptive compression control algorithm includes: a higher compression ratio for video content compared to image content; and a higher compression ratio for image content compared to document content.

[0321] Because different types of content displayed in a floating window may have varying sensitivities to visual quality, different compression strategies are required for different content types. The solution in this application first analyzes the attributes of the content displayed in the floating window to determine whether it is video, image, or text. Then, it determines an appropriate compression strategy based on the content attributes. For example, text content may require a lower compression ratio to maintain clarity, while video content may tolerate a higher compression ratio.

[0322] For example, such as Figure 7 As shown, when the content type of the first floating window is video, a higher compression ratio can be selected. When the content type of the first floating window is image, a medium compression ratio can be selected. When the content type of the first floating window is document, a lower compression ratio can be selected.

[0323] Electronic devices automatically select compression strategies and compress the content of the floating window at a fixed bit rate by recognizing the content type (such as video, image or document). This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding problems such as lag and insufficient battery life, thus improving the user experience.

[0324] Method 2: Determine the fixed bit rate compression ratio based on the window size of the floating window.

[0325] This application can determine the compression ratio strategy based on the window size. In a smaller window, due to the limited display area, users may find it difficult to perceive subtle changes in image quality. Therefore, a higher compression ratio can be used to save resources without significantly impacting the user experience. Conversely, in a larger window, a lower compression ratio can be used to maintain good visual quality.

[0326] For example, when the window size of the first floating window is smaller than the window threshold, a higher compression ratio of 4:1 can be selected for smaller windows. When the window size of the first floating window is greater than or equal to the window threshold, a lower compression ratio of 8:5 can be selected for larger windows.

[0327] The above solution allows electronic devices to automatically select a compression strategy by recognizing the size of the floating window and compress the content of the floating window at a fixed bit rate. This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding problems such as lag and insufficient battery life, thus improving the user experience.

[0328] Method 3: Determine the fixed bit rate compression ratio based on the device performance status.

[0329] For example, the compression ratio in low-performance states is higher than that in high-performance states. This is because, in low-performance states, increasing the compression ratio can improve smoothness.

[0330] Method 4: Determine the fixed bit rate compression ratio based on the device power consumption mode.

[0331] In some possible implementations, the device power consumption mode is either a power-saving mode or a normal mode. Accordingly, the adaptive compression control algorithm includes a compression ratio higher in the power-saving mode than in the normal mode.

[0332] This application determines the compression ratio strategy based on the device's power consumption mode. For example, when the electronic device's current power consumption mode is power saving mode, a higher compression ratio of 4:1 can be selected. When the electronic device's current power consumption mode is normal mode, the compression ratio can be selected based on the content type and window size.

[0333] When an electronic device is in power-saving mode, the consumption of memory bandwidth can be reduced by increasing the compression ratio, thereby reducing power consumption.

[0334] Method 5: Determine the fixed bit rate compression ratio based on user interaction information applied to the floating window.

[0335] For example, a higher compression ratio corresponds to a higher interaction frequency than a lower interaction frequency. This is because if users interact with the floating window frequently, increasing the compression ratio can improve smoothness. If users interact with the floating window less frequently, the compression ratio can be selected based on the content type and window size.

[0336] Furthermore, when multiple floating windows exist, the primary and secondary floating windows can be determined based on user actions or the content displayed in the windows. For example, a floating window with frequent user interaction, a floating window that is playing a video, or a floating window with dynamic data can be identified as the primary floating window. Other floating windows are identified as secondary floating windows.

[0337] The compression ratio for a fixed bit rate can be determined based on the primary and secondary floating windows. For example, the compression ratio corresponding to the primary floating window is higher than that corresponding to the secondary floating window.

[0338] Method 6: Calculate the fixed bit rate compression ratio based on weighted average of multiple scenario information.

[0339] For example, the content type of the first floating window corresponds to the first weight parameter, the window size of the first floating window corresponds to the second weight parameter, the user interaction information corresponds to the third weight coefficient, the device power consumption mode corresponds to the fourth weight coefficient, and the device performance status corresponds to the fifth weight coefficient. Accordingly, the electronic device can use the adaptive compression control algorithm to perform weighted calculations based on the content type and first weight parameter of the first floating window, the window size and second weight parameter of the first floating window, the user interaction information and third weight coefficient, the device power consumption mode and fourth weight parameter, and the device performance status and fifth weight coefficient to obtain the compression ratio.

[0340] It is understandable that the larger the weighting coefficient, the greater its reference value or contribution in determining the compression ratio.

[0341] It should be noted that the weighting coefficients of each factor can be set according to the actual performance of the electronic device and the user's actual needs (such as smoothness requirements or clarity requirements). For example, for electronic devices with lower performance (such as small memory size or low CPU / GPU performance), a larger weighting coefficient can be set for the device's power consumption mode.

[0342] In addition, different weighting coefficients can be set for different content types, window sizes, device power consumption modes, and user interaction information according to clarity and / or smoothness requirements.

[0343] For example, if users have high requirements for clarity, then the content type should be given the highest weight, and the strategy should be: when displaying the document in a floating window, a lower compression ratio can be selected to ensure the clarity requirement.

[0344] For example, if users have a high demand for smoothness, then the content type should be given the highest weight, and the strategy should be: when displaying video in a floating window, a higher compression ratio can be selected to ensure smoothness.

[0345] The following examples illustrate how to select a compression strategy based on a preset calculation method and / or user needs in some scenarios.

[0346] For example, if the content displayed in the first floating window is a video, presented in a smaller window, and the device power consumption mode is in power saving mode, a higher compression ratio can be selected in this scenario, such as 4:1, thereby ensuring the content display quality and smoothness requirements.

[0347] For example, if the content displayed in the first floating window is a video, presented in a large window, and the device power consumption mode is normal, a medium compression ratio, such as 2:1, can be selected in this scenario to ensure the content display quality and smoothness requirements.

[0348] For example, if the content displayed in the first floating window is a document, presented in a large window, and the device power consumption mode is normal, a lower compression ratio, such as 8:5, can be selected in this scenario to ensure the content display quality and smoothness requirements.

[0349] The above solution can determine an appropriate compression ratio based on the current scene information, the actual performance of the electronic device, and the actual needs of the user. It can adaptively compress the content of the floating window at a fixed bit rate, effectively control the system resource usage, reduce memory bandwidth usage, reduce power consumption, improve system performance, solve problems such as lag and insufficient battery life, and greatly enhance the user experience.

[0350] S207. The content of the first floating window is texture compressed using a fixed bit rate compression ratio, and the content of the first floating window is rendered based on the texture compression data of the first floating window and displayed on the screen.

[0351] In this embodiment, the compressed texture data of the first floating window can be stored in DDR. The compressed texture data of the first floating window is read from the DDR, decompressed, and then used for texture rendering. Finally, the content of the first floating window is displayed on the screen based on the texture rendering result.

[0352] The adaptive compression method for floating window scenarios provided in this application allows for texture compression of the floating window content using a fixed bitrate compression method, based on the content type and window size of the floating window, user interaction information acting on the floating window, device power consumption mode, and / or device performance status. By applying a fixed bitrate compression method to the floating window content based on the current scene information, this solution ensures that each image texture block is stored and transmitted using a fixed bitrate, effectively controlling system resource usage. This not only reduces memory bandwidth consumption but also lowers CPU / GPU power consumption, improves system performance, and provides visually lossless effects. Especially for low-performance electronic devices (e.g., those with limited memory and low CPU / GPU performance), this method solves problems such as lag and insufficient battery life, significantly improving the user experience.

[0353] It is understandable that when an electronic device has a floating window open, multiple tasks run in parallel, increasing the demand for memory bandwidth and significantly increasing the GPU load. The solution in this application, based on the current scene information, performs fixed-bitrate compression on the content of the floating window, which reduces memory bandwidth usage, lowers CPU / GPU power consumption, improves system performance, and provides visually lossless effects.

[0354] Third Embodiment

[0355] In the third embodiment, in a floating window scenario, it is determined whether the electronic device is in a high-load and / or low-performance state. If it is determined that the electronic device is in a high-load and / or low-performance state, an adaptive compression control algorithm is invoked to determine a fixed bitrate compression method and compression ratio based on scenario information such as the content type and window size of the first floating window, user interaction information acting on the first floating window, device power consumption mode, and device performance status. This fixed bitrate compression ratio is then used to perform texture compression on the content of the first floating window. When the scenario information changes, the compression ratio is adjusted according to the changed scenario information, and the adjusted fixed bitrate compression ratio is used to perform texture compression on the content of the first floating window. This can more effectively control the occupation of system resources, reduce memory bandwidth usage, reduce CPU / GPU power consumption, and improve system performance.

[0356] Figure 8 This is a flowchart illustrating the adaptive compression method for a floating window scenario provided in an embodiment of this application. (Refer to...) Figure 8 As shown, the method includes the following steps S301-S306.

[0357] S301, In response to user operation, launch the first floating window.

[0358] S302. Determine whether the electronic device is in a high-load state and / or a low-performance state based on the pre-configured performance parameters and real-time dynamic performance parameters of the electronic device.

[0359] For example, pre-configured performance parameters include the amount of available DDR memory, the available range of DDR bandwidth, and GPU frequency.

[0360] For example, real-time dynamic performance parameters include CPU utilization, DDR utilization, DDR bandwidth, and / or GPU load.

[0361] DDR stands for Double Data Rate Synchronous Dynamic Random Access Memory.

[0362] When the electronic device is determined to be in a high-load state and / or a low-performance state, the electronic device identifies the content type and window size of the first floating window, monitors the device power consumption mode and device performance status, and detects user interaction information applied to the floating window.

[0363] S303. When the electronic device is not under high load and / or low performance, the electronic device may use the default compression method (such as lossless compression or dynamic bit rate compression) to compress the content displayed in the floating window.

[0364] S304. When the electronic device is under high load and / or low performance, based on scenario information such as the content type and window size of the first floating window, user interaction information acting on the first floating window, device power consumption mode and device performance status, the adaptive compression control algorithm is invoked to determine the fixed bit rate compression method and compression ratio, and the compression ratio is dynamically adjusted.

[0365] S305. The content of the first floating window is texture compressed using a fixed bit rate compression ratio, and the content of the first floating window is rendered based on the texture compression data of the first floating window and displayed on the screen.

[0366] This reduces memory bandwidth usage and lowers CPU and GPU power consumption, effectively avoiding issues such as lag and insufficient battery life, thus improving the user experience.

[0367] Continue executing S302 after S305.

[0368] In a floating window scenario, the electronic device can monitor changes in scene information in real time. If changes occur, an adaptive compression control algorithm is invoked to adjust the fixed bitrate compression ratio based on the changed scene information. The adjusted fixed bitrate compression ratio is then used to perform texture compression on the content of the first floating window. Finally, the texture-compressed data from the first floating window is rendered, and its content is displayed on the screen.

[0369] It should be noted that the third embodiment differs from the second embodiment in that:

[0370] (1) In the floating window scenario, the electronic device will monitor the device performance status and determine whether the electronic device is in a high load state and / or a low performance state. When it is determined that the electronic device is in a high load state and / or a low performance state, the adaptive compression control algorithm is called to determine the fixed bit rate compression ratio according to the scenario information corresponding to the first floating window.

[0371] (2) In the floating window scenario, the electronic device will determine whether the content type, window size, user interaction information acting on the first floating window, device power consumption mode and / or device performance status, etc. have changed. When it is determined that the scene information has changed, the compression ratio is adjusted according to the changed scene information, and the content of the first floating window is texture compressed using the adjusted fixed bit rate compression ratio.

[0372] In this embodiment, after compressing the content of the first floating window at a fixed bit rate, if the scene information corresponding to the first floating window changes, an adaptive compression control algorithm is invoked to adjust the compression ratio, and the content of the first floating window is then compressed at a fixed bit rate using the adjusted compression ratio. For example, invoking the adaptive compression control algorithm to adjust the compression ratio when the scene information corresponding to the first floating window changes includes at least one of the following:

[0373] Scenario 1: Adjust the compression ratio based on changes in content type.

[0374] When the content type of the first floating window is switched from document type to video type, the adaptive compression control algorithm is invoked to increase the compression ratio; when the content type of the first floating window is switched from video type to document type, the adaptive compression control algorithm is invoked to decrease the compression ratio.

[0375] For example, in a floating window scenario, when the floating window displays video content, increasing the compression ratio reduces memory bandwidth consumption, lowers power consumption, improves smoothness, and ensures visually lossless quality without affecting the user experience. When the floating window displays text content, decreasing the compression ratio improves image quality and enhances the user experience.

[0376] Scenario 2: Adjust the compression ratio based on changes in window size.

[0377] When the first floating window is displayed in a smaller size, the adaptive compression control algorithm is invoked to increase the compression ratio; when the first floating window is displayed in a larger size, the adaptive compression control algorithm is invoked to decrease the compression ratio.

[0378] For example, in a floating window scenario, when the floating window is shrunk, users may not be able to perceive subtle changes in image quality due to the limited display area. Therefore, increasing the compression ratio can reduce memory bandwidth consumption and power consumption without affecting the user experience. When the floating window is enlarged, the compression ratio can be reduced to improve system performance and enhance the user experience.

[0379] Scenario 3: Adjust the compression ratio based on changes in device power consumption mode.

[0380] When an electronic device switches from normal mode to power-saving mode, the adaptive compression control algorithm is invoked to increase the compression ratio; when the electronic device switches from power-saving mode to normal mode, the adaptive compression control algorithm is invoked to decrease the compression ratio.

[0381] For example, in a floating window scenario, when an electronic device switches to power-saving mode, the compression ratio can be increased to reduce memory bandwidth consumption, lower power consumption, and ensure visually lossless results. When the electronic device switches to normal mode, the compression ratio can be reduced to improve image quality and enhance the user experience.

[0382] The above solution allows for dynamic adjustment of the compression ratio in floating window scenarios based on changes in scenario information such as the content type and window size of the floating window, user interaction information acting on the floating window, device power consumption mode, and device performance status. This effectively controls the system's resource usage, reduces memory bandwidth consumption, lowers CPU / GPU power consumption, and improves system performance. Especially for electronic devices with lower performance (e.g., small memory and low CPU / GPU performance), it solves problems such as lag and insufficient battery life, greatly enhancing the user experience.

[0383] Case 4: Adjust the compression ratio based on the primary and secondary floating windows.

[0384] In scenarios with multiple floating windows, this application can dynamically adjust the compression strategy for each floating window based on user interaction attributes. For example, the compression strategy can be dynamically adjusted for each floating window based on the frequency of user interaction with the floating windows and the complexity of the content.

[0385] For example, an electronic device displays multiple floating windows, including a first floating window and a second floating window. The electronic device acquires user interaction information corresponding to the multiple floating windows, including the interaction frequency and / or complexity of the interaction content for each floating window. Based on the user interaction information, the electronic device invokes an adaptive compression control algorithm to adjust the compression ratio corresponding to the first floating window and / or the compression ratio corresponding to the second floating window. The electronic device applies the adjusted first compression ratio to perform fixed bitrate compression on the content of the first floating window, and applies the adjusted second compression ratio to perform fixed bitrate compression on the content of the second floating window.

[0386] For example, the adaptive compression control algorithm includes the following: the higher the interaction frequency corresponding to the floating window, the greater the compression ratio of the floating window. The greater the complexity of the interactive content corresponding to the floating window, the greater the compression ratio of the floating window.

[0387] Electronic devices can identify floating windows with high user interaction or dynamic content (such as video playback scenarios), as well as floating windows with low user interaction or static content (such as document preview scenarios), and dynamically adjust compression strategies accordingly.

[0388] In some scenarios, when multiple floating windows are displayed on an electronic device at the same time, for floating windows with more user interaction or more dynamic content (such as video playback scenarios), the compression ratio can be increased to perform fixed bit rate compression, so as to ensure the smoothness of floating window operation and reduce GPU load.

[0389] In some scenarios, when an electronic device displays multiple floating windows simultaneously, for floating windows with less user interaction or more static content (such as document preview scenarios), the electronic device can reduce the compression ratio to maintain high visual quality.

[0390] Regarding how to adjust the compression ratio corresponding to the first floating window and / or the second floating window based on user interaction information by calling the adaptive compression control algorithm, this application provides the following three possible implementation methods:

[0391] Implementation method 1:

[0392] If the interaction frequency corresponding to the first floating window is higher than that corresponding to the second floating window, then increase the compression ratio corresponding to the first floating window and / or decrease the compression ratio corresponding to the second floating window, so that the compression ratio corresponding to the first floating window is higher than that corresponding to the second floating window.

[0393] If the interaction frequency corresponding to the first floating window is less than the interaction frequency corresponding to the second floating window, then the compression ratio corresponding to the first floating window is reduced, and / or the compression ratio corresponding to the second floating window is increased, so that the compression ratio corresponding to the first floating window is less than the compression ratio corresponding to the second floating window.

[0394] Implementation Method Two:

[0395] If the complexity of the interactive content corresponding to the first floating window is greater than that of the interactive content corresponding to the second floating window, then increase the compression ratio of the first floating window and / or decrease the compression ratio of the second floating window so that the compression ratio of the first floating window is greater than that of the second floating window.

[0396] If the complexity of the interactive content corresponding to the first floating window is less than that of the interactive content corresponding to the second floating window, then the compression ratio of the first floating window is reduced, and / or the compression ratio of the second floating window is increased, so that the compression ratio of the first floating window is less than that of the second floating window.

[0397] Implementation method three:

[0398] If the interaction frequency of the first floating window is higher than that of the second floating window, and the complexity of the interaction content of the first floating window is greater than that of the second floating window, then increase the compression ratio of the first floating window and / or decrease the compression ratio of the second floating window so that the compression ratio of the first floating window is greater than that of the second floating window.

[0399] If the interaction frequency of the first floating window is lower than that of the second floating window, and the complexity of the interaction content of the first floating window is less than that of the second floating window, then the compression ratio of the first floating window is reduced, and / or the compression ratio of the second floating window is increased, so that the compression ratio of the first floating window is less than that of the second floating window.

[0400] The above solution allows for dynamic adjustment of compression strategies for multiple floating windows in various scenarios, based on the frequency of user interaction and the complexity of the content. Adaptively adjusting compression strategies for different floating windows based on user interaction scenarios more effectively controls system resource usage, reduces memory bandwidth consumption, and lowers CPU and GPU power consumption. This also helps avoid issues such as lag and insufficient battery life, thus improving the user experience.

[0401] The above details the possible implementations of the adaptive compression method for floating window scenes provided in the embodiments of this application. The implementation process of the adaptive compression method for floating window scenes is described below in conjunction with software and hardware.

[0402] The electronic device includes hardware modules such as a CPU, texture compression module, GPU, and DDR, as well as software modules such as a hardware-accelerated rendering engine, the Skia graphics processing engine, and a graphics API interface. In this embodiment, the software and hardware modules of the electronic device achieve fixed-bitrate compression of the floating window's content. Furthermore, the fixed-bitrate compression ratio is adaptively adjusted based on real-time scene information. This effectively controls system resource usage, reduces memory bandwidth consumption, lowers power consumption, and improves system performance, resolving issues such as lag and insufficient battery life, and significantly enhancing the user experience.

[0403] Figure 9 This is a flowchart illustrating the adaptive compression method for a floating window scene provided in an embodiment of this application. The functional modules used to implement this process include an application framework layer module, an input management service module, a power management module (PowerManager), a view system module, a hardware performance monitoring module, a hardware-accelerated rendering engine (such as HWUI), a graphics processing engine (such as Skia), a graphics API, and a texture compression module.

[0404] In this embodiment of the application, when a user triggers the display of a floating window on an electronic device, the various functional modules of the electronic device perform the following steps in the floating window scenario:

[0405] S400 receives user operations and responds to user operations by performing scene recognition to identify whether the current scene is a floating window scene.

[0406] In steps S401 and S402, upon identifying the current scene as a floating window scene, the application framework layer module registers a callback function with the hardware performance monitoring module. This callback function is used to obtain the hardware performance status in the floating window scene. The hardware performance monitoring module monitors the hardware performance status in the floating window scene and transmits the device performance status information to the application framework layer module.

[0407] For example, hardware performance status may include CPU utilization, DDR utilization, bandwidth and / or GPU load, etc.

[0408] S403 and S404, the application framework layer module registers a callback function with the window management module. This callback function is used to obtain the floating window attribute information in the floating window scenario. The window management module monitors the floating window attribute information in the floating window scenario and passes the floating window attribute information to the application framework layer module.

[0409] For example, the floating window's property information includes the type of content to be displayed and the window size.

[0410] S405 and S406, the application framework layer modules, register callback functions with the power management module. These callback functions are used to obtain device power consumption mode information in the floating window scenario. The power management module monitors the device power consumption mode information in the floating window scenario and passes this information to the application framework layer module.

[0411] For example, device power consumption mode information includes whether power saving mode is enabled.

[0412] S407 and S408, the application framework layer module, register a callback function with the input management service module. This callback function is used to obtain user interaction information applied to the floating window in the floating window scenario. The input management service module detects the user interaction information applied to the floating window and passes the user interaction information to the application framework layer module.

[0413] For example, user interaction information includes the frequency or speed at which the user interacts with the floating window.

[0414] S409, The application framework layer module sends instructions to the hardware-accelerated rendering engine to draw the content of the floating window.

[0415] S410 and S411, in response to the floating window content drawing command, the hardware-accelerated rendering engine obtains the scene information corresponding to the floating window from the application framework layer module.

[0416] The scene information corresponding to the floating window includes device performance status information, floating window attribute information, device power consumption mode, and / or user interaction information.

[0417] For example, the hardware-accelerated rendering engine could be HWUI. HWUI is a hardware-accelerated rendering engine for UI, a GPU-accelerated 2D graphics engine. HWUI can leverage the powerful computing capabilities of the GPU to provide faster rendering speeds and a better user experience. HWUI achieves hardware acceleration through graphics APIs such as OpenGL, making drawing smoother and more efficient.

[0418] The S412 hardware-accelerated rendering engine determines or updates the fixed bitrate compression strategy based on the scene information corresponding to the floating window.

[0419] In the case of a floating window, an appropriate compression strategy is automatically selected based on the floating window's attribute information (such as content type and window size), user interaction information applied to the floating window, device power consumption mode, and device performance status.

[0420] In some embodiments, the system automatically selects a compression strategy by recognizing the content type of the floating window (such as video, image, or document) and the current state of the device (such as whether power-saving mode is enabled). When the content in the floating window is complex (such as high-resolution video or animated images), the system prioritizes using fixed bitrate compression technology to perform lossy compression on the content, significantly reducing memory and bandwidth usage while maintaining near-lossless visual quality.

[0421] S413, the hardware-accelerated rendering engine, transmits fixed bitrate compression strategies and drawing instructions to the graphics processing engine.

[0422] The fixed bit rate compression strategy can include a fixed bit rate compression method and a compression level.

[0423] In this embodiment, the compression level can be high, medium, or low. This application does not limit the method of dividing the compression levels. Alternatively, compression levels can be represented by 1, 2, and 3.

[0424] Each compression level may include one compression ratio, or it may include multiple compression ratios.

[0425] For example, a fixed bit rate compression strategy can include a fixed bit rate compression method and a high compression level.

[0426] S414, the graphics processing engine Skia sets compression parameters according to a fixed bit rate compression strategy.

[0427] In this embodiment of the application, the compression parameters (or compression attributes) include a fixed bit rate compression method and a compression ratio.

[0428] For example, the graphics processing engine could be Skia. Skia, as a 2D graphics processing engine, provides basic graphics drawing functions, including the processing of graphics, text, bitmaps, etc. Skia queries the Vulkan interface to determine the current texture compression module and the supported bitrates for the texture format, and then determines the compression ratio based on the query results and the compression level. The process of setting the compression parameters will be explained in detail below.

[0429] S415: The graphics processing engine calls the graphics API interface to pass compression parameters to the texture compression module.

[0430] For example, the graphics API can be a Vulkan / OpenGL interface.

[0431] The texture compression module is a functional module with texture compression capabilities. For example, the texture compression module can be integrated onto the GPU. Alternatively, the texture compression module can be a chip with texture compression capabilities, independent of the GPU.

[0432] S416 The texture compression module compresses the content of the floating window at a fixed bit rate according to the set compression parameters.

[0433] The S417, hardware-accelerated rendering engine, graphics processing engine, graphics API interface, and texture compression module interact to complete the texture rendering of the floating window content.

[0434] In the terminal device's operating system, compression is primarily related to Skia's GPU-accelerated rendering. The system uses GrContext as the main interface for interacting with the GPU. Texture compression typically occurs before image data is uploaded to the GPU to reduce GPU memory usage and improve rendering performance.

[0435] For example, after HWUI passes the compression strategy and drawing instructions to Skia, Skia calls the Vulkan / OpenGL interface, selects parameters according to the compression strategy, and performs fixed-bitrate compression and encapsulation of the floating window content through the texture compression module. Skia then passes the compressed and encapsulated data to the GPU, which performs graphics rendering based on the compressed and encapsulated data.

[0436] For example, the image view of the floating window, ImageView, can be converted into DrawImage. DrawImage is processed as a texture in Skia and is encapsulated as TextureOp. TextureOp is provided to the GPU for rendering.

[0437] S418, the hardware-accelerated rendering engine returns a rendering completion message to the application framework layer module.

[0438] HWUI can work in conjunction with Skia and graphics APIs to achieve UI rendering. Through the embodiments of this application, it is possible to achieve fixed-bitrate compression and graphics rendering of the UI content of a floating window: In a floating window scenario, the content compression ratio of the floating window is dynamically adjusted based on current scenario information such as the content type (content complexity), window size, user interaction information applied to the floating window, and device power consumption mode. This effectively controls system resource usage, reduces memory consumption and bandwidth consumption, and lowers overall power consumption.

[0439] Set compression parameters

[0440] The following describes the specific implementation method for setting compression parameters.

[0441] The compression parameters that Skia passes to graphics APIs (such as Vulkan) can be in the form of a structure, which contains a fixed bit rate compression method and a specific compression ratio / bit rate.

[0442] In this embodiment of the application, compression parameters can be passed in when creating VkImage.

[0443] VkImage is the core object in Vulkan used to store image data, supporting the rendering of 2D, 3D, and multi-layered images.

[0444] First, the lossy compression parameters are set using the VkImageCompressionControlEXT parameter (referred to as the EXT parameter). For example, a fixed bitrate compression flag and a compression ratio flag are written using this EXT parameter. Then, the VkImageCreateInfo parameter is created, and the initial information required to create a VkImage object is set. Finally, the VkCreateImage function is called, and a VkImage object is created based on this initial information.

[0445] Among them, lossy compression parameters include compression method and compression ratio (or compression bit rate).

[0446] In this embodiment, the VkImageCompressionControlEXT parameter can be a structure that includes the flags parameter and the pFixedRateFlags parameter.

[0447] The flags parameter can be used as a fixed bit rate compression flag to indicate the use of a fixed bit rate compression method.

[0448] The pFixedRateFlags parameter can be used as a compression ratio flag, specifying the compression bit rate.

[0449] By setting the flags and pFixedRateFlags parameters, the lossy compression parameters can be configured.

[0450] For example, the pseudocode for setting lossy compression parameters through a structure is as follows:

[0451] VkImageCompressionControlEXT

[0452] compression_control{VK_structure_type_IMAGE_COMPRESSION_CONTROL_EXT};

[0453] compression_control.flags=VK_IMAGE_COMPRESSION_FIXED_RATE_EXPLICIT_EXT

[0454] / / Specifies the use of fixed bit rate compression.

[0455] compression_control.pFixedRateFlags=VK_IMAGE_COMPRESSION_FIXED_RATE_4BPC_BIT_EXT

[0456] / / Specifies the compression bit rate as 4 BPC

[0457] Then pass the compression_control from the VkImageCompressionControlEXT parameter to image_info.pNext from the VkImageCreateInfo parameter.

[0458] For example, image_info.pNext = &compression_control.

[0459] The first piece of information needed to create a VkImage is image_info.pNext.

[0460] Then, the VkCreateImage function is called to create a VkImage object using the first information image_info.pNext. For example, vkCreateImage(device,&image_info,nullptr,&new_image).

[0461] After creating a VkImage object, you can further implement fixed bitrate compression and texture rendering based on the VkImage object.

[0462] This provides a possible way to achieve lossy compression settings.

[0463] It should be noted that a fixed bit rate compression strategy needs to be determined before setting up lossy compression. The following describes possible implementations for determining the compression strategy and setting compression parameters based on that strategy.

[0464] After the application framework layer module reads all the necessary content, it will pass it to HWUI. HWUI manages the drawing content. HWUI uses the adaptive compression method for the floating window scene provided in this application to determine whether fixed bit rate compression (AFRC) needs to be enabled based on the floating window attribute information (such as content type and window size), user interaction information acting on the floating window, device power consumption mode, and device performance status. If it is determined that fixed bit rate compression is to be used, the compression level is determined.

[0465] For example, compression levels can be divided into high, medium, and low levels, or levels represented by 1, 2, and 3. Each compression level can include multiple compression ratios.

[0466] HWUI can provide compression levels to Skia. Skia is a rendering engine that encapsulates low-level Vulkan / OpenGL instructions into drawing instructions (XXXOp), primarily targeting TextureOp, i.e., drawing images.

[0467] It should be noted that if the decision is to use fixed bitrate compression, Skia queries the Vulkan interface to see which compression bitrates the current texture compression module and floating window texture format support. Then, based on the determined compression level and the query results, it selects a suitable compression bitrate (e.g., 4 BPC) and passes this compression bitrate to the VkImageCompressionControlEXT parameter mentioned above, and performs lossy compression settings as described above.

[0468] The embodiments of this application employ fixed bit rate compression to perform texture compression on the content of the floating window, which has the following beneficial effects.

[0469] Predictable resource consumption: Because each image patch uses the same bit rate, the system can accurately predict the memory and bandwidth required for the compressed image. This is crucial in mobile devices, helping them allocate memory and processing power more efficiently.

[0470] Reduce memory bandwidth usage: Compared to uncompressed data, fixed bit rate compression technology can significantly reduce memory read and write traffic, and is especially suitable for processing high-resolution content in floating windows.

[0471] Visually lossless: Although fixed bitrate compression is a lossy compression technique, at higher bitrates, the image loss is almost imperceptible, hence the term "visually lossless." This makes it virtually impossible for users to perceive quality differences when compressing high-resolution videos or images.

[0472] Power optimization: By reducing memory and bandwidth usage, fixed bitrate compression can significantly reduce the power consumption of the GPU and CPU, thereby extending device battery life. This effect is particularly noticeable in power-saving modes.

[0473] Efficient image and video processing: For applications such as real-time rendering and video playback, fixed bitrate compression can provide stable memory and bandwidth usage, thereby ensuring a balance between smooth video playback and device performance.

[0474] The improvements of this application compared to the prior art include:

[0475] On the one hand, adaptive compression control based on scene recognition: the system uses scene recognition technology to dynamically analyze the complexity of the floating window content and the device status, and automatically adjusts the compression ratio to achieve an intelligent balance between performance and visual quality.

[0476] On the other hand, by using fixed bit rate compression technology (AFRC), this application significantly reduces memory bandwidth usage, lowers power consumption, and improves system performance in floating window / small window scenarios. In particular, in power-saving mode, it ensures a balance between battery life and smooth operation.

[0477] Expanding application scenarios

[0478] The application scenarios of this application include, but are not limited to, the aforementioned floating window scenario, and can also be applied to various small window scenarios.

[0479] For example, the solution proposed in this application can be applied to video window playback scenarios. When playing high-resolution videos in a floating window, the system can determine the complexity of the video through scene recognition and enable an appropriate lossy compression strategy to ensure smooth playback while reducing bandwidth and memory usage.

[0480] For example, the solution proposed in this application can be applied to document preview and social interaction scenarios. In scenarios where static content is previewed in a small window, the system maintains high image clarity by reducing the compression ratio, while optimizing memory usage in the background to improve overall performance.

[0481] By combining fixed bit rate compression technology with scene recognition, this application can dynamically adjust the compression ratio of content in small window scenarios, thereby effectively reducing memory and bandwidth usage, lowering power consumption, extending device battery life, and significantly improving user experience.

[0482] It should be noted that the adaptive scene rendering control technology of this application can not only be applied to floating windows, but also extended to the main rendering process of games to optimize overall game performance and resource management. The following are some possible application scenarios and implementation methods.

[0483] Method 1: Dynamically adjust rendering quality based on scene complexity. Different scenes in the game may have significantly different resource requirements. Complex battle scenes may require more computing and memory resources, while simple dialogue scenes are relatively lightweight. This application can dynamically adjust rendering quality, such as texture resolution and effects quality, based on scene complexity to maintain a smooth gaming experience while reducing unnecessary resource consumption.

[0484] Method 2: Optimize in-game UI elements. For in-game UI elements such as maps, menus, and HUDs (Head-Up Displays), this application utilizes fixed bitrate compression technology for optimization. By appropriately compressing these elements without affecting player readability and operation, rendering burden and memory usage can be reduced.

[0485] Method 3: Optimize data transmission in online multiplayer games. For online multiplayer games, data transmission is a crucial factor affecting the gaming experience. Using fixed bitrate compression technology to compress game state and player action data can reduce network latency and improve the synchronization and smoothness of multiplayer games.

[0486] Figure 10 This is a flowchart illustrating the application of the proposed solution in a game scenario.

[0487] S501, The current scene is identified as a game scene.

[0488] S502-S504. In game scenarios, identify scene complexity. If the scene complexity is high, dynamically adjust the rendering quality; if the scene complexity is low, maintain standard rendering quality.

[0489] S505 uses a fixed bit rate compression method to compress UI elements in the game interface.

[0490] S506. Determine whether the game scene is an online multiplayer game.

[0491] S507. When it is determined to be an online multiplayer game, use a fixed bit rate compression method to compress game state and player operation data.

[0492] If it is determined that it is not an online multiplayer game, return to S502 and continue to perform scene recognition.

[0493] This solution can also be applied to gaming and multitasking scenarios. When a user enables a floating window for multitasking in a game, the system uses scene recognition and dynamic compression strategies to ensure that both the main game task and the floating window content run smoothly, while reducing system load.

[0494] It should be noted that in the embodiments of this application, "greater than" can be replaced with "greater than or equal to", "less than or equal to" can be replaced with "less than", or "greater than or equal to" can be replaced with "greater than", and "less than" can be replaced with "less than or equal to".

[0495] The various embodiments described herein can be independent solutions or combinations thereof based on their inherent logic, and all such solutions fall within the protection scope of this application.

[0496] The foregoing mainly describes the solutions provided by the embodiments of this application from the perspective of method steps. It is understood that, in order to achieve the above functions, the electronic device implementing this method includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of protection of this application.

[0497] This application embodiment can divide an electronic device into functional modules based on the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other feasible division methods may exist. The following description uses the division of functional modules according to each function as an example.

[0498] This application also provides a chip coupled to a memory, which is used to read and execute computer programs or instructions stored in the memory to perform the methods in the above embodiments.

[0499] This application also provides an electronic device including a chip for reading and executing computer programs or instructions stored in a memory, causing the methods in the various embodiments to be performed.

[0500] This embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the adaptive compression method for the floating window scenario in the above embodiment.

[0501] This embodiment also provides a computer program product. The computer-readable storage medium stores program code. When the computer program product is run on a computer, it causes the computer to perform the above-mentioned related steps to realize the adaptive compression method for the floating window scene in the above embodiment.

[0502] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

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

[0504] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0505] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. In the description of embodiments in this application, unless otherwise stated, "multiple" means two or more; for example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0506] The above description is merely a specific embodiment 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. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An adaptive compression method for floating window scenarios, characterized in that, Applied to electronic devices, the method includes: In response to user interaction, launch the first floating window; Identify the floating window attribute information, which includes the content type and window size of the first floating window; Detect user interaction information applied to the first floating window; Monitor the power consumption mode and performance status of the device; Based on the first scene information, the adaptive compression control algorithm is invoked to compress the content of the first floating window at a fixed bit rate; The first scene information includes at least one of the following: the content type of the first floating window, the window size of the first floating window, the user interaction information, the device power consumption mode, and the device performance status.

2. The method according to claim 1, characterized in that, The step of invoking an adaptive compression control algorithm based on the first scene information to perform fixed-bit-rate compression on the content of the first floating window includes: Based on the first scenario information, the adaptive compression control algorithm is invoked to determine a fixed bit rate compression strategy, which includes adopting a fixed bit rate compression method and a first compression level. According to the fixed bit rate compression strategy, the content of the first floating window is subjected to texture compression.

3. The method according to claim 2, characterized in that, The first compression level corresponds to multiple alternative compression ratios; The step of performing texture compression on the content of the first floating window according to the fixed bit rate compression strategy includes: Based on the compression ratio supported by the view texture format corresponding to the first floating window and the compression ratio supported by the hardware module in the electronic device, a first compression ratio is determined from the plurality of alternative compression ratios. The content of the first floating window is texture compressed using the first compression ratio.

4. The method according to claim 2 or 3, characterized in that, After determining the fixed bit rate compression strategy, the method further includes: Create compression control parameters in the form of a structure, wherein the compression control parameters include a first flag bit and a second flag bit; Write the identifier of the fixed bit rate compression method into the first flag bit, and write the identifier of the first compression level into the second flag bit; The graphics API interface of the electronic device is invoked to pass the first compression control parameters to a hardware module with texture compression capability.

5. The method according to any one of claims 2 to 4, characterized in that, The content type of the first floating window, the window size of the first floating window, the user interaction information, the device power consumption mode, and the device performance status each correspond to a weighting coefficient; The step of calling the adaptive compression control algorithm to determine the fixed bit rate compression strategy based on the first scenario information includes: calling the adaptive compression control algorithm to perform weighted calculation based on the content type of the first floating window, the window size of the first floating window, the user interaction information, the device power consumption mode, the device performance status, and the weight coefficient to obtain the compression level of the fixed bit rate compression method.

6. The method according to any one of claims 1 to 5, characterized in that, The step of invoking an adaptive compression control algorithm based on the first scene information to perform fixed-bit-rate compression on the content of the first floating window includes: Determine whether the electronic device is in a high-load state and / or a low-performance state; In the high-load and / or low-performance state, based on the first scenario information, the adaptive compression control algorithm is invoked to compress the content of the first floating window at a fixed bit rate.

7. The method according to any one of claims 1 to 6, characterized in that, After performing fixed-bitrate compression on the content of the first floating window, the method further includes: If the first scene information changes, the adaptive compression control algorithm is invoked to adjust the compression ratio, and the content of the first floating window is compressed at a fixed bit rate using the adjusted compression ratio.

8. The method according to any one of claims 1 to 7, characterized in that, The adaptive compression control algorithm includes: For the content type of the first floating window, the compression ratio corresponding to the video type is higher than that corresponding to the image type; the compression ratio corresponding to the image type is higher than that corresponding to the document type. For the window size of the first floating window, the compression ratio corresponding to the smaller window size is higher than the compression ratio corresponding to the larger window size; For user interaction information applied to the first floating window, the compression ratio corresponding to a higher interaction frequency is higher than the compression ratio corresponding to a lower interaction frequency. For the device power consumption mode, the compression ratio corresponding to the power saving mode is higher than the compression ratio corresponding to the normal mode. Regarding the device performance state, the compression ratio corresponding to the low performance state is higher than the compression ratio corresponding to the high performance state.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: When multiple floating windows are displayed, a primary floating window and a secondary floating window are determined based on user interaction information applied to the multiple floating windows; the multiple floating windows include a first floating window and a second floating window; the user interaction information includes the interaction frequency and / or the complexity of the interaction content corresponding to each floating window; The adaptive compression control algorithm is invoked to adjust the compression ratio corresponding to the first floating window and / or the compression ratio corresponding to the second floating window.

10. The method according to claim 9, characterized in that, The step of determining the main floating window and the secondary floating window based on user interaction information applied to the plurality of floating windows includes: If the interaction frequency corresponding to the first floating window is higher than that corresponding to the second floating window, and / or if the complexity of the interaction content corresponding to the first floating window is greater than that corresponding to the second floating window, then the first floating window is determined to be the main floating window and the second floating window is determined to be the secondary floating window.

11. The method according to claim 9 or 10, characterized in that, The adaptive compression control algorithm includes: the compression ratio corresponding to the main floating window is higher than the compression ratio corresponding to the secondary floating window.

12. The method according to any one of claims 1 to 11, characterized in that, The performance status of the monitoring equipment includes: The real-time dynamic performance parameters of the electronic device are obtained, including the CPU utilization rate, DDR memory utilization rate, DDR bandwidth and / or GPU load. Obtain the pre-configured performance parameters of the electronic device, including the amount of available DDR memory, the available range of DDR bandwidth, and the GPU frequency; The device performance status is determined based on the real-time dynamic performance parameters and the pre-configured performance parameters.

13. The method according to any one of claims 1 to 12, characterized in that, The electronic device includes a central processing unit (CPU), a texture compression module, a graphics processing unit (GPU), and double data rate synchronous dynamic random access memory (DDR). The step of invoking the adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate includes: The CPU calls the texture compression module and uses the adaptive compression control algorithm to compress the content of the first floating window at a fixed bit rate. The CPU stores the texture compression data of the first floating window in the DDR and sends the graphics drawing instructions of the first floating window to the GPU.

14. The method according to claim 13, characterized in that, The electronic device also includes a hardware-accelerated rendering engine, a graphics processing engine, and a graphics API interface; The CPU invokes the texture compression module and uses the adaptive compression control algorithm to perform fixed-bit-rate compression on the content of the first floating window, including: The CPU determines the fixed bitrate compression strategy through the hardware-accelerated rendering engine. The hardware-accelerated rendering engine passes the fixed bitrate compression strategy to the graphics processing engine. The graphics processing engine obtains texture compression parameters based on the fixed bit rate compression strategy and passes the texture compression parameters to the texture compression module through the graphics API interface; the texture compression parameters include the compression ratio corresponding to the first floating window. The texture compression module performs fixed bit rate compression on the content of the first floating window based on the texture compression parameters.

15. The method according to claim 14, characterized in that, The electronic device also includes an application framework layer module; The application framework layer module is used to identify the content type and window size of the first floating window when the first floating window is launched, check the user interaction information, and monitor the device power consumption mode and the device performance status. The application framework layer module is also used to pass the graphics drawing instructions of the first floating window to the hardware-accelerated rendering engine; The hardware-accelerated rendering engine determines a fixed bitrate compression strategy, including: In response to the graphics drawing command of the first floating window, the hardware-accelerated rendering engine obtains the first scene information from the application framework layer module; The hardware-accelerated rendering engine determines the fixed bit rate compression strategy by calling the adaptive compression control algorithm based on the first scene information.

16. The method according to any one of claims 13 to 15, characterized in that, The electronic device also includes a display screen; After the CPU sends the graphics drawing instructions for the first floating window to the GPU, the method further includes: In response to the graphics drawing instruction for the first floating window sent by the CPU, the GPU reads the texture compression data of the first floating window from the DDR and decompresses the texture compression data; The GPU performs texture rendering based on the decompressed texture data and transmits the texture rendering result to the display screen. The display screen shows the content of the first floating window based on the texture rendering result.

17. An electronic device, characterized in that, The electronic device includes: one or more processors, and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 16.

18. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 16.

19. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 16.

Images