An Electron screen optimization method based on polymorphic rendering and state awareness

Abstract

This invention provides an Electron ad-dominating optimization method based on polymorphic rendering and state awareness, applied in the field of data processing technology. This application targets Electron ad-dominating applications, using BrowserWindowAPI and Node.js powerMonitor to monitor window focus, power status, and user interaction to determine three playback states: active, low-frequency, and background. The rendering mode is dynamically switched based on the state: GPU acceleration + 60fps high frame rate during active playback, CPU software rendering + 15fps low frame rate during low-frequency playback, and off-screen rendering with cached frame data during background playback. Partial redrawing is achieved by combining OffscreenCanvas and WebWorker, reducing unnecessary computation. In the background state, resources such as DOM nodes and GPU memory are actively reclaimed, and focus is quickly restored, all without user awareness, significantly reducing resource consumption and energy usage, and improving operational stability.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an Electron dominance optimization method based on polymorphic rendering and state awareness. Background Technology

[0002] The Electron framework is widely used in the development of full-screen (dominating) applications for advertising or information display due to its ability to package web front-end projects into desktop applications. These applications often need to display rich content such as videos and animations to ensure the display effect.

[0003] However, existing Electron-based ad playback applications have many technical flaws in the full-screen rendering process, as follows:

[0004] The application window's foreground and background states were not taken into account, and it always ran in a fixed high-quality rendering mode, resulting in a high CPU / GPU resource utilization rate for a long time, causing unnecessary waste of resources.

[0005] The lack of a monitoring mechanism for the operating system's power status (such as charging / discharging and power-saving modes) makes it impossible to automatically adjust power consumption strategies in scenarios such as low battery levels, making it difficult to adapt to the device's battery life requirements.

[0006] The control precision of the drawing area is insufficient, and the interface update is handled by global redraw. Even if only part of the area changes, the entire interface still needs to be redrawn, resulting in performance redundancy.

[0007] When an application enters the background or is inactive, failure to release redundant resources such as rendering cache and layers in a timely manner can easily lead to a continuous increase in memory and video memory usage, which not only affects system operating efficiency but may also cause stability defects such as application lag and crashes.

[0008] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0009] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0010] According to one aspect of this application, an Electron domination optimization method based on polymorphic rendering and state awareness is provided, including: listening to Electron window focus, operating system power status and user interaction events;

[0011] The system comprehensively judges the monitored information to identify whether the advertisement playback status is active playback, low-frequency playback, or background silent mode.

[0012] The rendering mode is switched based on the ad playback status. During active playback, GPU hardware acceleration and high frame rate rendering are enabled, and the rendering loop is maintained by requestAnimationFrame. During low-frequency playback, CPU software rendering is switched to reduce the frame rate, and cancelAnimationFrame is called to stop the high-frequency loop. In the background state, off-screen rendering is used, the requestAnimationFrame loop is paused and frame data is cached.

[0013] Local redrawing is achieved through area change monitoring and OffscreenCanvas and WebWorker technologies. The main thread converts the Canvas into an offscreen canvas and sends it to the WebWorker. After the Worker completes the drawing in the background thread, it sends the result back to the main thread for composite display. Only the area of ​​the interface that has changed is redrawn.

[0014] When in the background or in a static state, pause all timers and animations, destroy invalid DOM nodes, layers and Canvas contexts, release WebGL textures, image and video caches and GPU memory, and call the Electron interface to close the webContents of inactive windows;

[0015] When the application regains focus or the user resumes interaction, GPU acceleration, normal frame rate, and related DOM nodes and layers are restored, and the entire state transition process is imperceptible to the user.

[0016] This application presents an Electron screen-dominating optimization method based on polymorphic rendering and state awareness. It uses BrowserWindowAPI and Node.js powerMonitor to monitor window focus, power status, and user interaction to determine three playback states: active, infrequent, and background. During active playback, GPU acceleration and 60fps high frame rate rendering are enabled; during infrequent playback, CPU software rendering and 15fps low frame rate rendering are switched, with the option to enable frame dropping strategies; and during background playback, off-screen rendering is used to cache frame data. Partial redrawing is implemented using OffscreenCanvas and WebWorker, updating only changed areas. In the background state, resources such as DOM nodes and GPU memory are actively reclaimed, and the system quickly resumes operation when the application regains focus or when user interaction occurs, all seamlessly.

[0017] This application significantly reduces system CPU / GPU load and improves rendering efficiency; it also reduces memory usage and resource utilization, lowering power consumption to 8.0% after one hour of operation, adapting to low-power scenarios and extending device battery life. Local redrawing avoids redundant global calculations, shortening the first frame visibility time to 2.0 seconds, rendering does not block the UI thread, reducing stuttering, and timely reclaiming of invalid resources to prevent memory leaks and reduce the risk of application crashes; state transitions are smooth and imperceptible, ensuring a smooth 60fps display during active operation, balancing performance and viewing experience.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0019] Figure 1 The flowchart illustrates an embodiment of an Electron dominance optimization method based on polymorphic rendering and state awareness provided in this application.

[0020] Figure 2 This illustration shows a schematic diagram of an Electron dominance optimization device based on polymorphic rendering and state awareness, provided in an embodiment of this application. Detailed Implementation

[0021] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0022] The following is combined Figure 1 This application describes an Electron screen-dominating optimization method based on polymorphic rendering and state awareness, according to exemplary embodiments thereof. It should be noted that the application scenarios described below are merely illustrative for understanding the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0023] In one implementation, Figure 1 The diagram illustrates a flowchart of an Electron dominance optimization method based on polymorphic rendering and state awareness according to an embodiment of this application.

[0024] S101 monitors Electron window focus, operating system power status, and user interaction events.

[0025] In one implementation, in the full-screen (dominant screen) mode of an advertising or information display application within the Electron framework, a state awareness module is activated to monitor the Electron window focus, operating system power status, and user interaction events in real time, providing complete data support for subsequent advertising playback status determination.

[0026] To monitor window focus in Electron, the BrowserWindow API is called to specifically listen for the window's focus and blur events, thus accurately determining whether the window is currently in a foreground focused state or a background out-of-focus state. For example, when a user clicks on the application window to make it the currently active window, the focus event is triggered, indicating that the window is in a foreground focused state; when the user clicks on another window or a region of the desktop, causing the application window to lose its current active focus, the blur event is triggered, indicating that the window is in a background out-of-focus state.

[0027] For monitoring the operating system's power status, the `powerMonitor` module in Node.js is used to comprehensively monitor various power-related states, including the system's charging status, discharging status, screen lock status, and power-saving mode. For example, when the device is detected to be connected to a power adapter for charging, it is determined to be in a charging state; when the device is not connected to a power adapter and is powered by its built-in battery, it is determined to be in a discharging state; when the user manually locks the screen or the system automatically locks the screen after a timeout, it is determined to be in a screen lock state; and when the system automatically switches to a low-performance operating mode to save power, it is determined to be in a power-saving state.

[0028] For user interaction event monitoring, various user actions on the application interface are captured in real time, including mouse clicks, keyboard input, page scrolling, and other interactive actions. Simultaneously, a timestamp is recorded for each user interaction to determine whether the user is in a continuous operational state. For example, clicking interactive buttons on an advertisement interface, controlling advertisement playback via keyboard shortcuts, and swiping through multiple pages of advertisement content are all considered valid user interaction events and their corresponding timestamps are recorded.

[0029] S102 performs a comprehensive judgment on the monitored information to identify whether the advertisement playback status is active playback, low-frequency playback, or background silent mode.

[0030] In one implementation, user interaction timestamps are recorded, and the window focus state, operating system power state, and user interaction behavior are monitored in real time. After an Electron ad playback or information display application starts and enters full-screen (dominated) mode, the state awareness module starts simultaneously, continuously monitoring and recording basic data. The BrowserWindow API listens for window focus / blur events to monitor the Electron window's focus state (focused in the foreground or out of focus in the background); Node.js powerMonitor listens for power and screen lock events to capture the operating system's power state (charging, discharging, screen lock, power saving mode, etc.); and user interaction behavior (mouse clicks, keyboard operations, page scrolling, etc.) is monitored in real time. For each valid user interaction, a corresponding timestamp is accurately recorded, serving as the core basis for judging the continuity of user operations and providing comprehensive, real-time data support for determining the subsequent ad playback status.

[0031] If the application is detected to be in an initial startup state, it is directly marked as an active playback state. When the application is detected to have completed its initial startup and successfully entered full-screen ad playback mode, the system initially assumes that it is in an active playback state without the need for additional judgment conditions. This is because at the beginning of the application startup, the user is in a state of preparing to watch the ad by default, and a high-performance rendering mode is needed to ensure the ad display effect. This initial state setting also lays the foundation for subsequent state switching, and the state awareness module continues to run to capture subsequent state changes.

[0032] If user inactivity is detected for 30 seconds and the window remains in focus, it is marked as a low-frequency playback state. During continuous monitoring, if the recorded user inactivity lasts for 30 seconds and the application window remains in the foreground and focused state, not obscured or switched by other windows, the ad playback status is changed from active playback to low-frequency playback. For example, if a user opens the ad application but does not perform any action, and the window remains in the foreground, the system automatically determines it to be low-frequency playback after 30 seconds, triggering subsequent low-power rendering strategies to reduce unnecessary resource consumption.

[0033] If a window is detected to be out of focus, the screen is locked, or the system enters power-saving mode, it will be marked as background silent mode regardless of user interaction. During the monitoring process, if any of the following situations are detected, the ad playback status will be directly marked as background silent mode regardless of current user interaction: 1. The application window loses focus, is covered by other windows, or the user switches to another application; 2. The operating system enters screen lock mode, and the screen stops displaying content; 3. The system starts power-saving mode, with reducing energy consumption as the core operating goal. For example, if a user switches to browsing a webpage during ad playback, and the window loses focus, even if there was previous interaction, the system will immediately mark it as background silent mode; or, if the system automatically locks the screen due to timeout, regardless of whether the ad window is focused, it will directly enter background silent mode, triggering subsequent deep energy-saving optimization logic.

[0034] The system continuously monitors data and updates ad playback status markers in real time. The status awareness module remains constantly running, synchronizing various monitoring data such as window focus, power status, and user interaction to dynamically verify and update ad playback status. When the conditions upon which a previously marked status depends change, a re-determination and re-marking of the status is immediately triggered. For example, if a user clicks and interacts again during low-frequency playback, the system will update the status to active playback in real time; if a user switches back to the ad window and gains focus in background silent mode, or unlocks the screen and exits power-saving mode, the status will be updated to active playback; if the conditions for low-frequency or background status are met during active playback, the status will also switch promptly, ensuring that the ad playback status remains consistent with the actual operating scenario and achieving dynamic adaptation of the rendering strategy.

[0035] S103 switches rendering modes based on the ad playback status. During active playback, GPU hardware acceleration and high frame rate rendering are enabled, and the rendering loop is maintained by requestAnimationFrame. During low-frequency playback, CPU software rendering is switched to reduce the frame rate, and cancelAnimationFrame is called to stop the high-frequency loop. In the background state, off-screen rendering is used, requestAnimationFrame loop is paused and frame data is cached.

[0036] In one implementation, when the ad playback status is identified as active playback, GPU hardware acceleration is enabled, causing Canvas / API calls to use the GPU channel. The `requestAnimationFrame` method is called to maintain a 60fps rendering loop, ensuring smooth animation and video display. When the playback status determination module outputs an "active playback" result, the polymorphic rendering module immediately executes a high-performance rendering strategy. First, Electron's default GPU hardware acceleration function is enabled, ensuring that Canvas and related API calls are processed through the GPU channel, fully utilizing hardware performance to improve rendering efficiency. Simultaneously, the `requestAnimationFrame` method is called to maintain a high frame rate rendering loop of 60fps, allowing the use of WebGL or hardware-accelerated Canvas to render complex effects, ensuring smooth display of dynamic videos and complex animations in the ad, providing users with a high-quality viewing experience. For example, when a user is clicking on the ad interface or swiping through ad content, the system will continue to run in this mode. Even with relatively high CPU / GPU load, this mode can still meet the visual needs of the user during the interaction phase, aligning with the user's experience of viewing content.

[0037] When the ad playback status is identified as low-frequency playback, `cancelAnimationFrame` is called to stop the high-frequency rendering loop, switching to CPU software rendering in the Canvas2D context. Rendering is then performed at a 15fps rhythm using `setTimeout`, with a frame dropping strategy enabled to save computational resources. When the playback status switches to "low-frequency playback," the polymorphic rendering module initiates low-energy rendering adjustments. First, the `cancelAnimationFrame` method is called to stop the previous high-frequency rendering loop, terminating unnecessary high-load computation. Then, the rendering mode is switched to CPU software rendering in the Canvas2D context, no longer relying on GPU resources. Rendering operations are performed at a low frame rate of 15fps using the `setTimeout` method, reducing resource consumption. Furthermore, a frame dropping strategy can be enabled based on system resource usage, conditionally skipping some non-critical frames in the rendering loop to further save computational resources and reduce GPU load. For example, if a user opens the ad application and does not perform any operation for a long time, but the window remains in the foreground focus state, the system will automatically switch to this mode, achieving energy saving without affecting the basic display of the ad and effectively reducing the GPU load.

[0038] When the ad playback status is identified as background silent mode, all timers and animations are paused, the current Canvas is converted to OffscreenCanvas and passed to the Worker thread to be saved as the last frame, and the main thread only retains the most basic UI elements, reducing rendering and script execution workload. When the ad playback status is identified as "background silent" mode, the polymorphic rendering module executes a deep energy-saving rendering strategy. First, all timers and animations in the application are paused, all unnecessary rendering-related operations are stopped, and the traditional requestAnimationFrame rendering loop is paused. Next, the Canvas of the currently displayed ad screen is converted to OffscreenCanvas and passed to the WebWorker thread through the postMessage mechanism. The Worker thread saves the last frame of the current screen, ensuring quick connection when it is restored later and avoiding unnecessary redrawing. At the same time, the main thread only retains the most basic UI elements, significantly reducing the workload of rendering operations and script execution, and avoiding unnecessary resource consumption. For example, when the user switches the ad window to the background, the system locks the screen, or enters power-saving mode, the system will immediately execute this strategy, which ensures the integrity of the ad screen while minimizing resource consumption, meeting the core energy-saving requirements of background silent mode.

[0039] S104 achieves partial redrawing through area change listening and OffscreenCanvas and WebWorker technologies. The main thread converts the Canvas into an offscreen canvas and sends it to the WebWorker. After the Worker completes the drawing in the background thread, it sends the result back to the main thread for composite display. Only the area of ​​the interface that has changed is redrawn.

[0040] In one implementation, region change monitoring technology is used to capture dynamically updated parts of the ad screen and animation areas in the interface in real time, accurately identifying the target areas that need to be redrawn, and not triggering redraw commands for static parts of the interface. The region change monitoring technology is activated to monitor the full-screen interface of Electron ad playback in real time, accurately capturing dynamically updated parts of the interface such as ad screens and animation areas, and clearly defining the target areas that need to be redrawn. For static parts of the interface, no redraw commands are triggered, avoiding the performance waste caused by traditional global redraws, achieving minimal control over the drawing range, and reducing additional CPU / GPU overhead. This technology is particularly suitable for scenarios where ad content is frequently redrawn or dynamically updated. When ad content is static, only the updated animation or video parts are focused on, avoiding irrelevant drawing and laying the foundation for efficient subsequent rendering.

[0041] Extract the HTMLCanvasElement used for ad display from the main thread and convert it to OffscreenCanvas to separate the drawing operations from the main thread. This conversion completely separates the drawing operations from the main thread, freeing it from complex drawing calculations and effectively reducing its load, thus ensuring smooth UI interaction. Simultaneously, the offscreen canvas allows drawing operations to be completed in an independent canvas, creating conditions for subsequent background thread drawing, aligning with the core requirements of "resource isolation and optimized rendering chain."

[0042] Using the postMessage API, the transformed OffscreenCanvas is sent to a separate WebWorker thread. Following a strict "main thread → OffscreenCanvas → postMessage → Worker" transmission flow, the postMessage API ensures the offscreen canvas and related drawing configuration information are completely transmitted, enabling the WebWorker thread to obtain complete drawing resources and providing reliable support for independent background drawing.

[0043] After receiving the OffscreenCanvas, the WebWorker thread independently performs complex drawing calculations in the background, without relying on the main thread for scheduling, ensuring that the drawing process does not block UI interaction. The entire drawing process does not depend on the main thread for scheduling and is not disturbed by main thread UI operations or script execution, allowing it to focus on completing the drawing work. At the same time, this method avoids drawing tasks blocking the UI thread, effectively solving page lag issues and significantly improving rendering efficiency, especially when handling complex advertising effects.

[0044] After rendering is complete, the WebWorker sends the generated Bitmap format rendering result back to the main thread via `postMessage`. Once the WebWorker thread has finished its rendering calculations, it follows the "Worker rendering → `postMessage(Bitmap) → main thread` return flow, sending the generated Bitmap format rendering result back to the main thread via the `postMessage` API. The Bitmap format preserves rendering details, ensuring the integrity and accuracy of the rendering result, and guaranteeing that the main thread can accurately receive the rendering output, preparing for subsequent targeted compositing and display.

[0045] After receiving the Bitmap result, the main thread composites and displays only the previously identified changed areas, completing the local redraw process. Static parts remain unchanged. Similarly, after receiving the Bitmap rendering result, the main thread combines it with the previously identified target redraw areas and composites and displays only these changed areas, completing the local redraw process. Static parts of the interface remain unchanged, eliminating the need for repeated drawing and further reducing unnecessary computation and resource consumption. This process achieves efficient updates to the advertising interface, reducing CPU / GPU overhead while ensuring a consistent user visual experience, fully leveraging the performance optimization value of local redraw.

[0046] S105, when in the background or in a static state, pauses all timers and animations, destroys invalid DOM nodes, layers and Canvas contexts, releases WebGL textures, image and video caches and GPU memory, and can call the Electron interface to close the webContents of inactive windows.

[0047] In one implementation, when the state awareness module detects that an application has entered background mode or is in a static state, it immediately triggers a resource reclamation process and initiates a comprehensive resource cleanup mechanism. This triggering condition strictly adheres to the criteria for determining the "silent background" mode, covering core scenarios where applications are idle. This ensures timely resource reclamation, prevents ineffective resources from occupying system resources for extended periods, lays the foundation for subsequent energy-saving optimizations from the outset, and aligns with the core design logic of the resource reclamation mechanism: "proactively cleaning up idle resources."

[0048] Prioritize pausing all animation timers and rendering loops to terminate unnecessary computational tasks. The resource reclamation module prioritizes pausing all animation timers and rendering loops (including the requestAnimationFrame loop) in the application, completely terminating meaningless computational tasks. This operation strictly follows the resource reclamation process of "background silence → cancel timers → stop rendering loops." By stopping these operations that continuously consume CPU / GPU resources, it reduces resource waste at the source, quickly reduces system load, meets the core energy-saving requirements of background silence mode, and clears obstacles for subsequent in-depth resource cleanup.

[0049] This process accurately identifies and destroys invalid DOM nodes and redundant layers that are not displayed in the foreground, while simultaneously clearing the Canvas content and destroying the Canvas context. This thoroughly releases resources used during UI rendering. This step strictly corresponds to the execution logic of "destroy Canvas context → remove invalid DOM nodes" in the resource reclamation process, preventing invalid UI elements from consuming memory, reducing additional overhead in video memory and system memory, improving system resource utilization efficiency, and further consolidating energy-saving effects.

[0050] This process releases WebGL texture resources, expired image caches, and video caches, and reclaims the GPU memory they occupy. It comprehensively releases WebGL texture resources, as well as expired image and video caches, and reclaims the GPU memory used by these resources. This operation follows the resource reclamation process of "releasing WebGL textures," avoiding the problem of "continuously increasing VRAM and system memory usage" in existing technologies by cleaning up redundant cached data. It reduces the risk of resource leaks and reserves more available resources for other applications, ensuring overall system stability and echoing the invention's core objective of "reducing resource consumption."

[0051] By calling native Electron interfaces, the webContents of inactive windows are closed, and unnecessary page elements are removed. Alternatively, native Electron interfaces (such as win.webContents.hide() or win.webContents.destroy()) are called to close the webContents of inactive windows and remove unnecessary page elements. At this point, the system only maintains the most basic state monitoring and core control display functions, strictly implementing the design philosophy of "cleaning up invalid resources and reducing energy consumption," further streamlining resource usage, significantly reducing memory usage and power consumption, maximizing energy savings, and ultimately achieving the invention's objective of "improving overall system performance."

[0052] S106: When the application regains focus or the user resumes interaction, GPU acceleration, normal frame rate, and related DOM nodes and layers are restored. The entire state switching process is imperceptible to the user.

[0053] In one implementation, when the state awareness module detects that the application has regained window focus, or that the user has resumed interactive behaviors such as mouse clicks and keyboard operations, it immediately identifies it as an "active playback" state and sends a state restoration command to the polymorphic rendering module and the resource recycling module. Upon receiving the command, the polymorphic rendering module re-enables Electron's default GPU hardware acceleration, causing Canvas / API calls to return to the GPU channel, and simultaneously restarts the requestAnimationFrame rendering loop to restore a high frame rate of 60fps, ensuring smooth animation and video display. The resource recycling module, based on the application's operational needs, recreates previously recycled DOM nodes, layers, and Canvas contexts, and restores related resources such as WebGL textures. The entire state transition process is fast and smooth, imperceptible to the user. The application can instantly restore high-quality ad playback effects, maintaining intelligent adaptation between different states and ensuring a consistent user viewing experience.

[0054] In one implementation, such as Figure 2 As shown, this application also provides an Electron screen-dominating optimization device based on polymorphic rendering and state awareness, comprising:

[0055] The state awareness module 201 is used to listen to focus / blur events through BrowserWindowAPI and power and screen lock events through Node.jspowerMonitor, and to capture the focus state of Electron window, the power state of operating system (charging / discharging, screen lock, power saving mode, etc.) and user interaction events (mouse, keyboard operation, etc.) in real time, so as to provide data support for playback state determination.

[0056] The playback status determination module 202 is used to receive monitoring data transmitted by the status perception module, and after comprehensive analysis based on preset determination rules, identify the advertisement playback status as active playback, low-frequency playback (user inactive for 30 seconds and window focused) or background silent mode (window out of focus, screen locked or system power saving), and output the status determination result.

[0057] The multi-state rendering switching module 203 is used to receive the playback status determination result and dynamically switch the corresponding rendering mode: during active playback, GPU hardware acceleration is enabled, so that Canvas / API uses the GPU channel and requestsAnimationFrame maintains a 60fps loop; during low-frequency playback, cancelAnimationFrame is called to stop the high-frequency loop, and the CPU software rendering in the Canvas2D context is switched to execute at a 15fps rhythm and a frame dropping strategy can be enabled; in background mode, timers and animations are paused, the last frame is cached through OffscreenCanvas, and the main thread only retains the basic UI.

[0058] The partial redrawing module 204 is used to identify dynamically updated areas of the interface through area change listening technology. It converts the main thread HTMLCanvasElement into OffscreenCanvas and sends it to the WebWorker thread via postMessage. The Worker backend performs drawing calculations and returns a Bitmap result. The main thread only composites and displays the changed areas to achieve partial redrawing.

[0059] The background resource recycling module 205 is used to pause all animation timers and rendering loops, destroy invalid DOM nodes, layers and Canvas contexts, release WebGL textures, expired image and video caches and GPU memory, and call the Electron interface to close inactive windows webContents when the application is detected to be in the background or in a static state, while retaining only basic state monitoring functions.

[0060] The state recovery module 206 is used to receive the active state signal from the state awareness module when the application regains focus or the user resumes interaction, and to notify each module to restore GPU hardware acceleration, normal frame rate and previously recycled DOM nodes and layers, so as to ensure that the state switch is imperceptible to the user and maintain the smoothness of ad playback.

[0061] The computer-readable storage medium provided in the above embodiments of this application and the Electron screen-dominating optimization method based on polymorphic rendering and state awareness provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0062] The various embodiments in this application are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for evaluating the Electron screen-dominating optimization method, system, electronic device, and readable storage medium based on polymorphic rendering and state awareness are basically similar to the embodiments of the Electron screen-dominating optimization method based on polymorphic rendering and state awareness described above, and are therefore described simply. Relevant parts can be referred to in the descriptions of the embodiments of the Electron screen-dominating optimization method based on polymorphic rendering and state awareness described above.

Claims

1. A method for optimizing screen domination in Electron based on polymorphic rendering and state awareness, characterized in that, include: Listen for Electron window focus, operating system power status, and user interaction events; The system comprehensively judges the monitored information to identify whether the advertisement playback status is active playback, low-frequency playback, or background silent mode. The rendering mode is switched based on the ad playback status. During active playback, GPU hardware acceleration and high frame rate rendering are enabled, and the rendering loop is maintained by requestAnimationFrame. During low-frequency playback, CPU software rendering is switched to reduce the frame rate, and cancelAnimationFrame is called to stop the high-frequency loop. In the background state, off-screen rendering is used, the requestAnimationFrame loop is paused and frame data is cached. Partial redrawing is achieved through region change monitoring and OffscreenCanvas and WebWorker technologies. The main thread converts the Canvas into an offscreen canvas and sends it to the WebWorker. After the Worker completes the drawing in a background thread, it sends the result back to the main thread for composite display. Redrawing is only performed on areas of the interface that are changing. This includes using region change monitoring technology to capture dynamically updated parts of the interface such as advertisements and animations in real time, accurately identifying the target areas that need to be redrawn, and not triggering redrawing instructions for static parts of the interface. The HTMLCanvasElement used for advertisement display in the main thread is extracted and converted into OffscreenCanvas to separate the drawing operation from the main thread. The converted OffscreenCanvas is sent to an independent WebWorker thread using the postMessage API. After receiving the OffscreenCanvas, the WebWorker thread independently performs complex drawing calculations in the background without relying on the main thread for scheduling, ensuring that the drawing process does not block UI interaction. After the drawing is completed, the WebWorker sends the generated Bitmap format rendering result back to the main thread via postMessage; after receiving the Bitmap result, the main thread only performs composite display on the previously identified changed areas, completing the local redrawing process, while the static parts remain unchanged. When in the background or in a static state, pause all timers and animations, destroy invalid DOM nodes, layers and Canvas contexts, release WebGL textures, image and video caches and GPU memory, and call the Electron interface to close the webContents of inactive windows; When the application regains focus or the user resumes interaction, GPU acceleration, normal frame rate, and related DOM nodes and layers are restored, and the entire state transition process is imperceptible to the user.

2. The method as described in claim 1, characterized in that, The monitored information is comprehensively analyzed to identify whether the advertisement playback status is active, infrequent, or silent in the background, including: Record user interaction timestamps and monitor window focus status, operating system power status, and user interaction behavior in real time. If the application is detected to be starting up for the first time, it will be marked as an active playback state. If the user is not active for 30 seconds and the window is in focus, it is marked as a low-frequency playback state. If the window is out of focus, the screen is locked, or the system enters power-saving mode, it will be marked as background silent mode regardless of whether the user interacts with it. Continuously monitor data and update ad playback status markers in real time.

3. The method as described in claim 2, characterized in that, The rendering mode is switched based on the ad playback status. During active playback, GPU hardware acceleration and high frame rate rendering are enabled, and the rendering loop is maintained by requestAnimationFrame. During low-frequency playback, CPU software rendering is switched to reduce the frame rate, and cancelAnimationFrame is called to stop the high-frequency loop. In the background state, off-screen rendering is used, the requestAnimationFrame loop is paused and frame data is cached, including: When the ad playback status is identified as active playback, GPU hardware acceleration is enabled, so that Canvas / API calls go through the GPU channel and requestAnimationFrame is called to maintain a 60fps rendering loop to ensure smooth display of animations and videos; When the ad playback status is identified as low-frequency playback, cancelAnimationFrame is called to stop the high-frequency rendering loop, and the CPU software rendering in the Canvas2D context is switched to execute rendering at a rate of 15fps using setTimeout. A frame dropping strategy can be enabled to save computing resources. When the ad playback status is identified as background silent mode, all timers and animations are paused, the current Canvas is converted to OffscreenCanvas and passed to the Worker to be saved as the last frame, and the main thread only retains the most basic UI elements to reduce the amount of rendering and script execution.

4. The method as described in claim 1, characterized in that, When in the background or in a static state, pause all timers and animations, destroy invalid DOM nodes, layers, and Canvas contexts, release WebGL textures, image and video caches, and GPU memory. The Electron interface can be used to close the webContents of inactive windows, including: When the state awareness module detects that the application has entered background mode or is in a static state, it immediately triggers the resource reclamation process and starts a comprehensive resource cleanup mechanism. Prioritize pausing all animation timers and rendering loops, and terminating invalid computation tasks; Accurately identify and destroy invalid DOM nodes and redundant layers that are not displayed on the front end, while clearing the Canvas content and destroying the Canvas context; Release WebGL texture resources, expired image and video caches, and reclaim occupied GPU memory; Call the Electron native API to close the webContents of inactive windows and remove page elements that do not need to be retained.

Images