Multi-screen independent refreshing method and device under Android system

Abstract

According to the multi-screen independent refreshing method and device under the Android system, the display rhythm control process, the presentation judgment process and the presentation scheduling process are optimized on the basis of an existing Android display frame, so that different displays can independently execute frame presentation processing according to respective refreshing requirements; therefore, mutual restriction among the displays with different refresh rates is reduced, the display performance of the display with the high refresh rate and the fluency of multi-screen collaborative display are improved, and meanwhile, the simplicity, stability and compatibility of system implementation are considered.

Description

Technical Field

[0001] This disclosure relates to the field of display control technology, and more specifically, to a multi-screen independent refresh method and apparatus under the Android system. Background Technology

[0002] With the increasing popularity of foldable screen devices, dual-screen devices, and external display devices, the multi-screen display capabilities of the Android system are widely used in scenarios such as office collaboration, automotive displays, educational presentations, audio-visual entertainment, and industrial control. In these application scenarios, different displays often have different physical refresh rates; for example, the main display supports a higher refresh rate, while the auxiliary display uses a relatively lower refresh rate. In actual operation, multi-screen systems typically need to simultaneously meet the smooth display requirements of high refresh rate displays and the stable display requirements of low refresh rate displays. Therefore, how to enable multiple displays to operate independently according to their respective refresh rates within the same Android system has become a crucial technical challenge in the field of multi-screen displays.

[0003] In the existing Android display framework, application rendering, system compositing, and physical display are typically scheduled around a unified display rhythm. In multi-screen scenarios, the system generally uses a single-rhythm display to drive the overall display pipeline, enabling multiple displays to perform rendering, compositing, and presentation operations at the same VSync rhythm. Since different displays have different refresh rates, when high-refresh-rate displays and low-refresh-rate displays work together, existing solutions often limit the actual display rhythm of each display to the lower-refresh-rate display, preventing the high-refresh-rate display from fully utilizing its hardware refresh capabilities. Especially when the main screen requires a high frame rate for smooth display while the secondary screen only needs a lower frame rate for stable display, the existing unified scheduling method can easily lead to a decrease in the main screen's display performance, impacting the user's interactive experience. Summary of the Invention

[0004] This disclosure provides at least one multi-screen independent refresh method and apparatus under the Android system. By optimizing the display rhythm control, presentation judgment and presentation scheduling process on the basis of the existing Android display framework, different displays can independently perform frame presentation processing according to their own refresh requirements, thereby reducing the mutual constraints between displays with different refresh rates, improving the display performance of high refresh rate displays and the smoothness of multi-screen collaborative display, while taking into account the simplicity, stability and compatibility of system implementation.

[0005] This disclosure provides a multi-screen independent refresh method under the Android system, including: Determine multiple displays in the Android system and the refresh parameters corresponding to each display, and determine the target rhythm display with the highest refresh rate from the multiple displays; A display refresh driving rhythm is established based on the target rhythm display, so that the display pipeline runs according to the refresh rhythm corresponding to the target rhythm display. Before the rendering of each frame, the target rendering display set corresponding to the current frame is determined based on the current rendering time corresponding to the target rhythm display and the refresh requirements of each display. The system controls the displays in the target display set to perform frame rendering processing, and controls the displays not included in the target display set to skip the rendering processing of the current frame, so that different displays can refresh and display independently according to their respective refresh rhythms.

[0006] In one optional implementation, a display refresh driving rhythm is established based on the target rhythm display, causing the display pipeline to operate according to the refresh rhythm corresponding to the target rhythm display, specifically including: The refresh cycle corresponding to the target rhythm display is used as the unified driving rhythm for the application rendering end and the system compositing end. During the frame rendering phase, we only wait for the rendering operation corresponding to the target rhythm display to be completed before releasing the subsequent frame processing flow.

[0007] In one optional implementation, the target display set corresponding to the current frame is determined based on the current presentation time corresponding to the target rhythm display and the refresh requirements of each display, specifically including: Obtain the expected presentation time corresponding to the target rhythm display; The expected presentation time is compared with the corresponding refresh cycle of each display. Based on the phase comparison results, determine the display that is aligned with the current frame; The target rhythm display and the display aligned with the current frame are collectively defined as the target presentation display set.

[0008] In one optional implementation, controlling the displays in the target display set to perform frame rendering processing specifically includes: For non-target rhythm displays in the target display set, the corresponding display operations are executed asynchronously; Continue executing the rendering process corresponding to the target rhythm display in the current frame without waiting for the rendering of the non-target rhythm display to complete; Obtain the task object returned by the asynchronous execution and add the task object to the pending queue; At the beginning of subsequent frames, the task objects in the pending queue are uniformly waited for and cleaned up.

[0009] In one optional implementation, controlling displays not included in the target rendering display set to skip the rendering process of the current frame specifically includes: Identify target skipped displays that are not included in the target presentation display set at the presentation pipeline inlet; Skip the verification and presentation processes corresponding to the target display; Release the layer resources corresponding to the target skipped display, and reuse the release fence corresponding to the previous frame of the target skipped display when it was successfully rendered, as the basis for releasing the layer resources corresponding to the current frame.

[0010] In one alternative implementation, for a non-target pacing display that performs asynchronous rendering, the method further includes: Force the layers on the non-target rhythm display to be composited using a client-side compositing method; The hardware synthesizer is prohibited from performing device synthesis on the non-target rhythm display; Based on the timing of releasing the corresponding release fence constraint layer buffer in the client-side synthesis, the risk of screen tearing is reduced.

[0011] In one optional implementation, the method further includes: Detect whether multiple monitors are in mirrored display mode; When multiple displays are detected to be in the same stack mirror display mode, the independent refresh parameters set for each display are cleared, and the display is switched to a compatible rendering mode that renders all displays and waits for all displays to complete.

[0012] In an optional implementation, the method further includes a standalone VSync implementation process, which includes: The application rendering end senses the physical display identifier corresponding to the current window; Initiate a VSync request for the target physical display based on the physical display identifier; Based on the physical display identifier, the system synthesis server routes the VSync request to the independent scheduling channel of the corresponding display. Based on the independent scheduling channels of each display, the drawing and compositing processes of the corresponding display are triggered respectively.

[0013] In one optional implementation, based on the independent scheduling channels of each display, the drawing and compositing processes of the corresponding display are triggered respectively, specifically including: When the compositing thread is woken up by the VSync signal of any display, determine whether the current compositing cycle is the first wake-up; Upon determining that it is the first wake-up, execute the complete synthesis process and cache the synthesis result; If the wake-up is not the first time, skip the compositing step and use the cached compositing result to perform rendering processing on the corresponding display.

[0014] This disclosure also provides a multi-screen independent refresh device under the Android system, including: The rhythm display determination module is used to determine multiple displays in the Android system and the refresh parameters corresponding to each display, and to determine the target rhythm display with the highest refresh rate from the multiple displays. The rhythm driving module is used to establish a display refresh driving rhythm based on the target rhythm display, so that the display pipeline runs according to the refresh rhythm corresponding to the target rhythm display. The presentation set determination module is used to determine the target presentation display set corresponding to the current frame based on the current presentation time corresponding to the target rhythm display and the refresh requirements of each display before the presentation processing of each frame. The presentation control module is used to control the displays in the target presentation display set to perform frame presentation processing, and to control the displays not included in the target presentation display set to skip the presentation processing of the current frame, so that different displays can refresh and display independently according to their respective refresh rhythms.

[0015] This disclosure also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the multi-screen independent refresh method under the Android system described above, or any possible implementation of the multi-screen independent refresh method under the Android system described above.

[0016] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the multi-screen independent refresh method under the Android system described above, or any possible implementation of the multi-screen independent refresh method under the Android system described above.

[0017] This disclosure also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the multi-screen independent refresh method under the Android system described above, or any possible implementation of the multi-screen independent refresh method under the Android system described above.

[0018] This disclosure provides a multi-screen independent refresh method and apparatus under the Android system. By optimizing the display rhythm control, presentation judgment and presentation scheduling process on the basis of the existing Android display framework, different displays can independently perform frame presentation processing according to their own refresh requirements, thereby reducing the mutual constraints between displays with different refresh rates, improving the display performance of high refresh rate displays and the smoothness of multi-screen collaborative display, while taking into account the simplicity, stability and compatibility of system implementation.

[0019] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0021] Figure 1 A flowchart of a multi-screen independent refresh method under the Android system provided in this disclosure embodiment is shown; Figure 2 A flowchart is shown below illustrating another method for independent multi-screen refresh in an Android system provided by an embodiment of this disclosure. Figure 3 This illustration shows a schematic diagram of a multi-screen independent refresh device under an Android system provided in an embodiment of the present disclosure; Figure 4 A schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

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

[0024] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0025] Research has revealed that in the existing Android display framework, application rendering, system compositing, and physical display are typically scheduled around a unified display rhythm. In multi-screen scenarios, the system generally uses a single-rhythm display to drive the overall display pipeline, causing multiple displays to perform rendering, compositing, and presentation operations at the same VSync rhythm. Since different displays have different refresh rates, when high-refresh-rate displays and low-refresh-rate displays work together, existing solutions often limit the actual display rhythm of each display to that of the lower-refresh-rate display, preventing the high-refresh-rate display from fully utilizing its hardware refresh capabilities. Especially when the main screen requires a high frame rate for smooth display while the secondary screen only needs a lower frame rate for stable display, the existing unified scheduling method can easily lead to a decrease in the main screen's display performance, impacting the user's interactive experience.

[0026] Based on the above research, this disclosure provides a multi-screen independent refresh method and device under the Android system. By optimizing the display rhythm control, presentation judgment and presentation scheduling process on the basis of the existing Android display framework, different displays can independently perform frame presentation processing according to their own refresh requirements, thereby reducing the mutual constraints between displays with different refresh rates, improving the display performance of high refresh rate displays and the smoothness of multi-screen collaborative display, while taking into account the simplicity, stability and compatibility of system implementation.

[0027] To facilitate understanding of this embodiment, a multi-screen independent refresh method under the Android system disclosed in this disclosure will first be described in detail. The executing entity of the multi-screen independent refresh method under the Android system provided in this disclosure is generally a computer device with certain computing capabilities. This computer device may include, for example, a terminal device, a server, or other processing devices. The terminal device may be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, this multi-screen independent refresh method under the Android system can be implemented by the processor calling computer-readable instructions stored in the memory.

[0028] See Figure 1 The diagram shows a flowchart of a multi-screen independent refresh method under an Android system provided in this embodiment of the disclosure. The method includes steps S101 to S104, wherein: S101. Determine multiple displays in the Android system and the refresh parameters corresponding to each display, and determine the target display with the highest refresh rate from the multiple displays.

[0029] In practical implementation, the method of this embodiment is applied to a multi-display control scenario in the Android system. The multiple displays may include the main display built into the terminal device, the secondary display area in a foldable screen device, an external display, an extended display in a vehicle cockpit, or other physical display output units managed by the Android display framework.

[0030] Here, multiple displays in the Android system can be connected to the system via built-in screen interfaces, HDMI interfaces, DP interfaces, Type-C display interfaces, or other display connection methods, and are uniformly enumerated, identified, and managed by the system display service, display device management module, or underlying display driver. To achieve subsequent independent refresh control of multiple screens, it is first necessary to define the set of displays participating in the display output in the current system and determine the refresh parameters corresponding to each display. Based on this, the display with the highest refresh rate is selected as the target refresh rate display.

[0031] In one implementation, the Android system's display management framework can obtain the identification information of multiple currently connected displays and create a corresponding display object for each display. The identification information may include at least one of physical display identifier, logical display identifier, port information, display mode information, and layer stack affiliation information.

[0032] By iterating through these display objects, the multiple displays currently participating in the display output can be obtained. These multiple displays can be a combination of a main screen and a secondary screen, or a multi-screen combination consisting of two or more displays with different refresh rates.

[0033] For example, in a typical application scenario, the main screen can be a 120Hz display, and the secondary screen can be a 60Hz display; in another application scenario, there may be a high refresh rate internal screen, a medium refresh rate secondary screen, and a low refresh rate external display. This embodiment does not limit the number of displays or their specific connection methods; any display that is uniformly managed by the Android system and participates in display output can be included in this step for processing.

[0034] Furthermore, after identifying multiple displays, it is necessary to obtain the refresh parameters corresponding to each display. These refresh parameters are preferably used to characterize the display's refresh capability, refresh rate, and related timing characteristics. The refresh parameters may include at least one of the following: the display's nominal refresh rate, current operating refresh rate, refresh cycle, VSync cycle, display mode parameters, supported candidate refresh rate set, current frame interval parameters, and timestamp parameters related to refresh scheduling.

[0035] In some embodiments, the current operating mode parameters registered in the display driver layer, hardware abstraction layer, or display configuration module can be read first to obtain the refresh rate currently used by each display. In other embodiments, multiple mode parameters supported by the display can be obtained simultaneously, and the current active mode can be identified from them to improve the accuracy of refresh parameter determination.

[0036] It should be noted that for subsequent independent refresh scheduling, in addition to directly using the refresh rate parameter expressed in Hz, the refresh rate can be further converted into the corresponding refresh period so that phase comparison, frame alignment determination and frame-by-frame selective presentation control can be performed in subsequent steps.

[0037] In practical implementation, the refresh parameters for each display can be provided by the display event scheduling module, display mode management module, or underlying physical display control module in the Android display framework. For example, the currently active display mode of each display can be read, and the mode refresh rate can be extracted from that display mode; alternatively, the refresh parameters can be statistically analyzed and corrected by combining the actual occurrence interval of VSync events to obtain refresh rhythm information that is closer to the current running state.

[0038] For some monitors that support dynamic refresh rate switching, the current refresh rate status and the relationship between the refresh rate changes before and after switching can be recorded so as to achieve adaptive adjustment in subsequent independent refresh control.

[0039] After obtaining the refresh parameters for each display, a target rhythm display with the highest refresh rate is determined from among the multiple displays. Here, the target rhythm display refers to the display used to provide the basic driving rhythm for the Android display pipeline in the current multi-screen display scenario. This target rhythm display can serve as a unified rhythm reference in subsequent processing, ensuring that both the application rendering end and the system compositing end are scheduled around the higher refresh rate corresponding to this display.

[0040] Preferably, the monitor with the highest refresh rate among the current multiple monitors is determined as the target timing monitor. The reason for this setting is that if the monitor with the highest refresh rate is used as the reference for subsequent unified timing, it is possible to provide other monitors with the basic time coordinates for on-demand alignment and selective presentation without suppressing the performance of the high refresh rate monitor, thereby creating conditions for realizing independent refresh of multiple screens.

[0041] In a typical embodiment, when the system detects that the refresh rate of the first display is 120Hz and the refresh rate of the second display is 60Hz, the first display can be identified as the target rhythm display. Correspondingly, the refresh period of the first display is approximately 8.3ms, and the refresh period of the second display is approximately 16.6ms. In this case, subsequent rendering and compositing processes can preferentially use the rhythm of the 120Hz display as the basic driving rhythm, while whether the 60Hz display participates in rendering in a particular frame can be determined in subsequent steps based on the phase relationship between its own refresh period and the basic driving rhythm.

[0042] Furthermore, when two or more displays have the same maximum refresh rate, the target refresh rate display can be determined based on a preset priority rule. The preset priority rule may include at least one of the following: prioritizing the display corresponding to the system's main screen, prioritizing the display currently undertaking the primary interactive task, prioritizing the internally directly connected display, prioritizing the display in a non-mirrored independent display mode, or prioritizing the display with higher current display link stability.

[0043] In other embodiments, to improve the system's adaptability to complex operating scenarios, the determination of the target rhythm display can be based on a comprehensive assessment of the display's current connection status, display mode status, and multi-screen relationship status. For example, if a high refresh rate display, despite having the theoretically highest refresh rate, is currently in mirror display mode, low-power display mode, or restricted operating mode, its suitability as the target rhythm display can be determined by considering the currently active refresh parameters and display topology status. If the display is not currently suitable for rhythm-driven operation, the next priority display from the remaining displays can be selected as the target rhythm display.

[0044] Furthermore, this embodiment can also be understood in conjunction with the layered characteristics of the Android display pipeline. The display pipeline in the Android system typically includes the application rendering stage, the SurfaceFlinger compositing stage, and the physical display stage. The refresh behavior of the physical display stage is guaranteed by the display hardware itself, and is difficult for the software to directly modify; while the application rendering stage and the system compositing stage can be rhythm-controlled by software scheduling. Therefore, determining the target refresh rate display in this step is actually selecting a unified high-frequency refresh rate reference for the application rendering stage and the system compositing stage, so that subsequent controllable software components operate as close as possible to the refresh rate of this display.

[0045] It is understandable that the target rhythm display identified in this step essentially corresponds to a rhythmist role. Given that the existing Android framework typically only supports a single rhythmist, this embodiment does not change the overall organization of the single rhythmist. Instead, it selects the display with the highest refresh rate as the rhythmist, enabling the system to achieve a better multi-screen independent refresh implementation within the existing framework. Compared to directly using a low refresh rate display as a unified rhythm reference, this embodiment avoids prematurely limiting high refresh rate displays to operate at lower frame rates, thus laying the foundation for subsequently determining the target display set through phase comparison and decoupling the refresh processes of different displays through selective presentation.

[0046] In an optional implementation, after determining the target rhythm display, the display identifier, refresh rate parameters, refresh cycle parameters, and rhythm status information corresponding to the target rhythm display can be written into the rhythm control context for subsequent steps. The rhythm control context can be a runtime configuration structure in the system display service, a scheduling control object on the SurfaceFlinger side, or a global state management object associated with multi-screen independent refresh. By pre-recording these parameters, it is convenient to perform phase comparisons with the refresh cycles of each display based on the expected presentation time of the target rhythm display, and further determine the set of displays that should participate in the presentation for each frame.

[0047] S102. Establish a display refresh driving rhythm based on the target rhythm display, so that the display pipeline runs according to the refresh rhythm corresponding to the target rhythm display.

[0048] In practical implementation, the Android system's display pipeline typically includes an application rendering phase, a SurfaceFlinger compositing phase, and a physical display phase. The application rendering phase is responsible for generating graphics buffer data for each window based on the interface content. The SurfaceFlinger compositing phase is responsible for compositing multiple layers and generating frames to be displayed. The physical display phase is responsible for sending the corresponding frame data to the target display to complete the actual display. Since the VSync of the physical display phase is usually generated and guaranteed by the display hardware itself, the software layer cannot directly intervene in its generation process. Therefore, the display refresh driving rhythm established in this embodiment mainly introduces the refresh cycle corresponding to the target rhythm display into the application rendering phase and the SurfaceFlinger compositing phase, so that their scheduling rhythm revolves around the target rhythm display.

[0049] In one implementation, a display refresh driving rhythm is established based on the target rhythm display, including obtaining the current refresh rate parameter or refresh cycle parameter corresponding to the target rhythm display, and using the refresh cycle as the software scheduling base cycle of the display pipeline.

[0050] For example, when the target rhythm display is a 120Hz display, its refresh rate is about 8.3ms, so the rhythm of about 8.3ms can be used as the basic driving beat for the application rendering end and the system compositing end; when the target rhythm display is a 144Hz display, the corresponding rhythm of about 6.9ms can be used as the basic driving beat.

[0051] Therefore, the upper-layer rendering and compositing process of the system can be periodically driven at a higher temporal resolution, providing a unified time coordinate for subsequent frame-by-frame presentation on high refresh rate displays and periodic selective presentation on low refresh rate displays.

[0052] Furthermore, to ensure the display pipeline operates according to the refresh rate corresponding to the target rhythm display, the target rhythm display can be configured internally as the target rhythm source in the display refresh scheduling. This target rhythm source can be understood as a software rhythm controller in the current multi-monitor scenario, used to drive the wake-up of display-related tasks, the advancement of frame processing, and the organization of presentation timing.

[0053] In some embodiments, the rhythm reference originally used for unified scheduling can be switched to the rhythm reference corresponding to the target rhythm display through the system display service, VSync scheduling module, message queue wake-up module, or SurfaceFlinger internal scheduling object.

[0054] At the implementation level, preferred methods include having the application rendering end receive rendering triggers according to the refresh rate of the target rhythm display, and having the SurfaceFlinger compositing end receive compositing triggers according to the refresh rate of the target rhythm display. For the application rendering end, the rendering scheduling logic related to interface refresh can be periodically awakened according to the refresh cycle corresponding to the target rhythm display, so that the application can prepare graphics content at a higher refresh rate. For the SurfaceFlinger compositing end, it can periodically advance the commit, composite, and subsequent present preparation processes within the corresponding scheduling cycle.

[0055] In a typical embodiment, when the system includes a 120Hz main screen and a 60Hz secondary screen, if the 120Hz main screen is determined as the target rhythm display, the display pipeline can be driven at a rhythm of approximately 8.3ms. That is, the application rendering end and the compositing end can obtain a processing opportunity approximately every 8.3ms. Based on this, the main screen, because its refresh cycle is consistent with this driving rhythm, can participate in subsequent presentations within each driving cycle; while the 60Hz secondary screen does not need to participate in presentations in every 8.3ms cycle, its participation can be determined subsequently through phase determination.

[0056] It's important to note that operating according to the refresh rate corresponding to the target rhythm monitor in this step does not equate to all monitors physically refreshing at the target rhythm monitor's refresh rate. This step establishes a software-level driving rhythm to uniformly advance the processing pace of the application's rendering and compositing ends, rather than requiring all monitors to perform the same scanning display frequency at the physical level. In fact, different monitors can still maintain their original hardware refresh capabilities and physical VSync behavior. Through this distinction, the time granularity of the software scheduling side can be improved without compromising the physical characteristics of each monitor, creating conditions for subsequently implementing per-frame presentation for high refresh rate monitors and every-frame or periodic presentation for low refresh rate monitors.

[0057] Furthermore, to ensure that the main thread is not blocked during the presentation phase of low refresh rate displays, this embodiment can also establish a runtime foundation that prioritizes the target refresh rate display as the primary waiting object when establishing the display refresh driving rhythm. Specifically, in subsequent presentation-related processes, the main thread can prioritize advancing around the presentation completion state corresponding to the target refresh rate display, rather than treating all displays as equally blocked waiting objects.

[0058] In an optional implementation, to improve the stability of the rhythm operation, time reference information corresponding to the target rhythm display can be established simultaneously when establishing the display refresh drive rhythm. The time reference information may include at least one of the following: the expected VSync time sequence corresponding to the target rhythm display, the expected present time sequence corresponding to the target rhythm display, the mapping relationship between the current frame number and the rhythm period, and correction parameters related to historical period deviation.

[0059] In other embodiments, the display refresh driving rhythm can also be established using a combination of hardware VSync and software rhythm correction. Specifically, the actual hardware VSync events of the target rhythm display can be preferentially used as the rhythm driving basis to obtain higher timing accuracy; when the hardware VSync events have slight jitter, are temporarily unavailable, or require rhythm prediction, virtual rhythm signals generated by the software side can also be used for auxiliary correction. In a preferred embodiment, the hardware VSync of the target rhythm display is still used as the main rhythm source to further improve the actual frame rate performance and operational stability.

[0060] To facilitate internal system calls, after establishing the display refresh driving rhythm, the rhythm configuration information corresponding to the target rhythm display can be written into the display scheduling context. The rhythm configuration information may include the target rhythm display identifier, target refresh rate, target refresh period, current rhythm frame number, current rhythm start time, rhythm validity status, and basic parameters related to display set determination.

[0061] Furthermore, the approach of establishing a unified software-driven rhythm based on the target rhythm display used in this step has the advantage of requiring less modification to the existing Android framework. Compared to the end-to-end reconstruction scheme that establishes a complete and independent drawing and synthesis rhythm for each display, this embodiment does not completely overturn the existing single rhythm organizer method in Android. Instead, while retaining its overall architecture, it enhances the existing display framework with the basic capability to support independent refresh rates across multiple screens by elevating the rhythm reference to the highest refresh rate display.

[0062] S103. Before the rendering of each frame, the target rendering display set corresponding to the current frame is determined according to the current rendering time corresponding to the target rhythm display and the refresh requirements of each display.

[0063] After establishing the display refresh driving rhythm based on the target rhythm display, in order to enable multiple displays to run independently according to their respective refresh rhythms under the same Android display framework, before the rendering processing of each frame, it is necessary to determine the target rendering display set corresponding to the current frame based on the current rendering time corresponding to the target rhythm display and the refresh requirements of each display.

[0064] In specific implementation, the current presentation time is preferably the expected present time point of the current frame established around the target rhythm display, the trigger time point corresponding to the current rhythm cycle, or target time information associated with the current rhythm frame. Since the application rendering end and system composition end have already been made to run according to the refresh rhythm of the target rhythm display in the aforementioned steps, the system can obtain a current time reference corresponding to the target rhythm display whenever it enters the present preparation stage of a certain frame. This time reference can originate from the hardware VSync event of the target rhythm display, the software-predicted present time point, the current rhythm timestamp recorded by the scheduling module, or the result of these time information after correction. Subsequent determinations regarding whether other displays participate in the present of the current frame can then be made using this current presentation time as a unified reference point.

[0065] Furthermore, the refresh requirements of each display are preferably used to characterize whether each display needs to perform a present operation in the frame corresponding to the current presentation time in its current operating state. The refresh requirements can be determined by at least one of the following: the display's current refresh rate, refresh cycle, VSync cycle, current display mode, dynamic refresh rate status, historical present records, frame sequence number alignment relationship, and the display's display task requirements.

[0066] Typically, for high refresh rate displays, the refresh requirement manifests as a shorter present interval; for low refresh rate displays, the refresh requirement manifests as a longer present interval. Therefore, in this embodiment, it is not required that each display perform a present in every cycle driven by the target rhythm display. Instead, it determines whether each display is aligned with the current presentation time based on its own refresh cycle, and only displays that meet the current refresh requirement are included in the target presentation display set.

[0067] In a preferred embodiment, determining the target display set corresponding to the current frame based on the current presentation time corresponding to the target rhythm display and the refresh requirements of each display includes: obtaining the current expected presentation time corresponding to the target rhythm display; obtaining the refresh cycle parameters corresponding to each display; performing a phase comparison between the current expected presentation time and the refresh cycle of each display; determining the display that is aligned with the current expected presentation time in the current frame based on the phase comparison result; and jointly determining the target rhythm display and the display that is aligned with the current expected presentation time in the current frame as the target display set corresponding to the current frame.

[0068] The phase comparison described here essentially determines whether the refresh timing of a particular display falls within the present cycle driven by the current target rhythm display. This can be understood as using the high-frequency rhythm of the target rhythm display as a unified time scale, and at each scale point, determining whether each display has reached its own presenting time. If a display is currently at or near its next presenting time, it is determined that the display has a presenting requirement in this frame and is included in the target presenting display set; if a display has not yet reached its next presenting time, it is determined that it does not need to present in this frame and is skipped in subsequent presenting pipelines.

[0069] Taking a typical scenario as an example, when the system includes a 120Hz target rhythm display and a 60Hz auxiliary display, the refresh cycle of the 120Hz display is approximately 8.3ms, and the refresh cycle of the 60Hz display is approximately 16.6ms. In this case, at each 8.3ms interval, the system enters a present set determination. For the 120Hz target rhythm display, since its refresh cycle is consistent with the current driving rhythm, it meets the refresh requirements in every present cycle and is always included in the target present display set. For the 60Hz auxiliary display, it is only included in the target present display set if the current present time falls on its 16.6ms cycle boundary, or if it meets a preset phase alignment condition with its next expected present time. In other words, within two consecutive 120Hz cycles, the 60Hz auxiliary display is typically included in the set only in one cycle. This achieves refresh decoupling between displays with different refresh rates: the 120Hz display performs two presents within approximately 16.6ms, while the 60Hz display performs only one present within the same time frame.

[0070] In some embodiments, to facilitate phase comparison, refresh timing state information can be maintained for each display. This refresh timing state information may include at least one of the following: the most recent successful present time, the next expected present time, the current frame number, the period offset relative to the target rhythm display, the cumulative refresh error, and correction parameters for rhythm compensation. By maintaining this state information, the system can quickly determine whether each display meets the present conditions for the current frame before proceeding with the presenting of that frame, without having to perform a full calculation from scratch each time.

[0071] For example, the decision to include a device in the set can be made based on whether the current presentation time has reached the next expected presentation time recorded by the display. After the presentation is completed, the next expected presentation time for the corresponding display is updated. This not only improves the efficiency of the decision but also enhances the stability of the decision through error accumulation and compensation mechanisms when there are slight fluctuations in system scheduling.

[0072] Furthermore, the phase comparison need not be limited to an absolutely precise integer-cycle coincidence determination. In actual systems, due to thread scheduling jitter, timestamp sampling errors, or slight hardware VSync offsets, there may be a slight deviation between the current presentation time and the theoretical presentation time of a certain display. Therefore, in some embodiments, a phase tolerance range can be set. As long as the deviation between the current presentation time and the expected presentation time of a certain display falls within the preset tolerance range, it can be determined that the display is aligned with the current frame and included in the target presentation display set.

[0073] In a preferred embodiment, the target rhythm display is preferably always included in the target presentation display set corresponding to the current frame. This is because the target rhythm display serves as the reference display for the entire software-driven rhythm, and its refresh cycle is the basic time granularity for the current display pipeline progression. If the target rhythm display is excluded from the present set in certain rhythm cycles, the continuity of the overall high-frequency driving rhythm may be disrupted, which is detrimental to the performance of high refresh rate displays. Therefore, this embodiment typically adopts a set construction method where the target rhythm display is always included, and other displays are included as needed.

[0074] In other embodiments, in addition to the refresh cycle itself, the current operating state of the display can also be included in the determination of refresh requirements. For example, when a display is currently in mirror mode, static display mode, low-power mode, or a specific system-restricted state, its presentation requirements in the current frame can be modified by additional determination rules. For displays in mirror mode, since multiple displays may share the same layer stack or need to maintain a more stringent consistent display relationship, in subsequent steps, the entire display can be reverted to the standard present mode according to the system compatibility strategy.

[0075] For example, in some scenarios, if an auxiliary display does not currently show any changes in content, or if its corresponding layer does not require updating in the current period, it can be determined whether to include it in the present set by combining refresh requirements and content update requirements, in order to further optimize system load.

[0076] To facilitate subsequent present pipeline calls, after determining the target display set for the current frame, a set identifier or a present permission flag for each display can be generated. The set identifier can be implemented using a display identifier list, a Boolean flag mapping table, a bitmap flag structure, or other data structures that characterize which displays need to be presented in the current frame. Subsequently, at the present entry point, the system can directly use this set identifier to determine whether the currently processed display should undergo the validate and present processes, or whether it should be skipped and resource release logic executed.

[0077] In an optional extended embodiment, if the system adopts an alternative end-to-end independent VSync architecture, the method for determining the target display set corresponding to the current frame can also be used in conjunction with the independent VSync channels of each display. For example, when the compositing thread is awakened by the independent VSync of any display, the display that triggered the awakening can be directly regarded as the basic candidate display for the current frame. Then, combined with the cached compositing results, whether other displays have reached their respective present times, and other conditions, the final set of displays that need to be presented can be further determined.

[0078] S104. Control the displays in the target display set to perform frame rendering processing, and control the displays not included in the target display set to skip the rendering processing of the current frame, so that different displays can refresh and display independently according to their respective refresh rhythms.

[0079] After determining the target display set corresponding to the current frame, it is necessary to control the displays in the target display set to perform frame rendering processing, and control the displays not included in the target display set to skip the rendering processing of the current frame, so that different displays can refresh and display independently according to their own refresh rhythm.

[0080] In specific implementation, the frame presentation processing preferably includes verification, submission, fence management, and display status update processes related to the current frame display output. For displays included in the target presentation display set, the system allows them to enter the complete present path of the current frame; for displays not included in the target presentation display set, the system identifies them at the present pipeline entry point and terminates their entry into the corresponding present path in the current frame.

[0081] In one implementation, controlling the displays in the target display set to perform frame rendering processing may include: for a target display whose current frame belongs to the target display set, allowing it to continue performing display verification processing, layer composition result submission processing, and final rendering processing for the current frame, and recording the current frame rendering state corresponding to the target display after rendering is completed. The display verification processing can be used to confirm that the current layer configuration, buffer state, and composition method meet the submission requirements; the layer composition result submission processing can be used to establish a correspondence between the current frame content generated by the application rendering end and the system composition end and the current target display; and the final rendering processing is used to actually submit the current frame to the display output path corresponding to the target display.

[0082] Furthermore, in a preferred embodiment, the target rhythm display preferably performs frame presentation processing within each rhythm cycle. This is because the target rhythm display itself serves as the software-driven rhythm reference for the display pipeline, and the continuous advancement of its present path directly affects whether the high refresh rate display capability can be unleashed. Therefore, for the target rhythm display, once the current frame enters the present stage, it is preferable to always allow it to complete the present process for the current frame. Taking a 120Hz target rhythm display as an example, the system allows it to perform one present operation within each approximately 8.3ms rhythm cycle, thereby ensuring that it can continuously output images at near the hardware capability limit, without being slowed down to 60Hz or even lower due to the presence of a low refresh rate auxiliary display.

[0083] For non-target rhythm displays within the target display set, this embodiment preferably employs an asynchronous frame presentation processing method. Specifically, when an auxiliary display is determined to be included in the target display set in the current frame, the system does not require the main thread to synchronously wait for the auxiliary display's presentation to complete. Instead, it encapsulates the presentation operation corresponding to the auxiliary display as an asynchronous execution task and allows it to complete the current frame submission in an independent execution path. Therefore, the main process containing the target rhythm display can continue to advance preferentially without being blocked while waiting for the auxiliary display to complete its presentation.

[0084] In one specific implementation, for auxiliary displays that need to perform a present operation in the current frame but are not part of the target rhythm display, a corresponding asynchronous present task can be generated, and the future object, task handle, or other task identifier that can represent the asynchronous execution state returned by the asynchronous present task can be obtained. Then, the future object or task identifier is added to a waiting queue, for example, to a queue structure used to record asynchronous present tasks that are yet to be completed. In this way, in the current frame, the main thread can immediately continue the next rhythm progression after the target rhythm display completes the necessary present wait, without synchronously blocking and waiting for the auxiliary display's present operation to finish within the current rhythm cycle. When entering the start stage of the subsequent frame, the asynchronous tasks left in the waiting queue of the previous frame are uniformly waited for, their status checked, and resources cleaned up.

[0085] Furthermore, to prevent duplicate submissions or hardware synthesizer state abnormalities caused by asynchronous presentation, after making the presentation of non-target rhythm displays asynchronous, the unfinished asynchronous presentation tasks of the preceding sequence can be checked at the beginning of the subsequent frame. Only after confirming that the relevant asynchronous tasks have been completed and the corresponding hardware state has been recovered can the auxiliary display be allowed to enter the next new presentation operation.

[0086] For displays not included in the target presentation display set, this embodiment does not simply refrain from performing the present function at the final output stage, but rather preferably performs a complete skip control at the entry point of the present pipeline. Specifically, when the system identifies a display that does not belong to the target presentation display set of the current frame, it can directly terminate its subsequent verification, submission, and presentation-related processes before the display enters the present path of the current frame, thus completely skipping its entire present path.

[0087] The complete skipping of the present path, as described here, preferably includes skipping at least the hardware synthesizer verification stage and the final present stage corresponding to the current frame. This is because if a display does not actually need to perform a present operation in the current frame but still enters part of the verification process, it may lead to inconsistencies between the internal state of the display system and the actual submission state, or even cause the underlying hardware synthesizer to deadlock or stagnate in an abnormal path where only validating is performed without presenting. Therefore, this embodiment emphasizes that for displays that do not need to present in the current frame, their entire present pipeline should be skipped at the entry point, rather than just skipping the final submission action.

[0088] In a preferred embodiment, for displays not included in the target display set, while skipping the present path of the current frame, it is also necessary to perform layer resource release processing corresponding to that display. Specifically, dedicated resource release processing logic can be invoked to release or reclaim the relevant layer resources in the current frame that were originally prepared for that display but are no longer actually used for display output because the present path of the current frame has been skipped. The layer resources may include graphics buffer references, layer commit records, temporary display status information, and handles to be released associated with the current display.

[0089] Furthermore, in scenarios where a presentation is skipped, to ensure the correct timing of layer resource release, this embodiment preferably does not directly use an invalid or empty barrier for the skipped display. Instead, it reuses the release barrier corresponding to the successful presentation of the previous frame for that display as the basis for releasing the relevant layers in the current frame. This is because, although the current frame does not perform a new presentation on that display, the screen still retains the content successfully displayed in the previous frame. If the layer resources associated with the current frame are incorrectly marked as immediately releaseable, or if an invalid barrier without constraint is assigned to them, the graphics buffer may be prematurely reclaimed and reused, leading to display errors, content tearing, or buffer overwriting issues.

[0090] In some embodiments, for auxiliary displays that perform frame rendering processing in an asynchronous presentation mode, the auxiliary display can be further forced to use the client-side composition path in asynchronous presentation mode, while prohibiting it from using the device composition path. Specifically, when the system determines that an auxiliary display will perform a presentation asynchronously in the current frame, the layer composition strategy on the auxiliary display can be switched to be performed by the client, and the hardware compositor can be prevented from directly undertaking the device composition task for the current frame of the display.

[0091] The reason for this setting is that in asynchronous presentation scenarios, if some layers are still allowed to follow the device composition path, the graphics buffer may be mistakenly judged as reclaimable by the upper layer before the actual display is completed due to the hardware or driver releasing the signal too early, which may lead to screen tearing or display instability on the auxiliary screen.

[0092] At the implementation level, the system controls the displays in the target display set to perform frame presentation processing, and controls displays not included in the target display set to skip the presentation processing of the current frame. It may also include updating the display state frame by frame. For displays performing a presentation, the system can update their most recent successful presentation time, current frame number, next expected presentation time, and current display state; for displays whose presentation is skipped, the system can update their current frame skip flag, continued display state, and next candidate presentation time.

[0093] In a typical embodiment, when the system includes a 120Hz target rhythm display and a 60Hz auxiliary display, it is assumed that the current time window covers two consecutive 120Hz rhythm cycles. In the first 8.3ms cycle, the system determines that both the 120Hz target rhythm display and the 60Hz auxiliary display belong to the target presentation display set. Therefore, the 120Hz target rhythm display is allowed to perform a present for the current frame, while the 60Hz auxiliary display initiates an asynchronous present. In the second 8.3ms cycle, the system determines that only the 120Hz target rhythm display belongs to the target presentation display set, while the 60Hz auxiliary display does not meet the present condition for this cycle. Therefore, only the 120Hz target rhythm display is allowed to perform a present, and the verification and submission process of the 60Hz auxiliary display is skipped entirely at its corresponding present entry point. Simultaneously, corresponding resource release and barrier reuse are performed. Thus, within a total time of approximately 16.6ms, the 120Hz target rhythm display completes two presents, while the 60Hz auxiliary display completes only one present, thereby enabling both to refresh and display independently according to their respective refresh rhythms.

[0094] In other embodiments, compatibility processing can also be combined with mirrored display mode. When the system detects that multiple displays are in mirrored mode on the same stack, since multiple displays in mirrored mode usually require a high degree of consistency in the displayed content and display rhythm, the independent refresh strategy of selective presentation per display can be abandoned. Instead, the specific present parameters and asynchronous states maintained per display can be cleared, and the system can fall back to the standard compatibility mode.

[0095] In this compatibility mode, the system can perform the current frame presentation on all displays and wait for all display-related rendering processes to complete in the traditional manner. This ensures that the display behavior in mirror mode remains compatible with the existing Android system, avoiding disruption of display consistency in mirrored scenarios due to excessively independent scheduling.

[0096] It is understandable that although this compatibility fallback is an auxiliary process in a special scenario, its essence is still to control which displays execute the present function and which do not execute the present function in the current frame. It is just that a compatibility strategy of executing the present function on all displays is adopted in the mirror scenario.

[0097] Furthermore, this step can be extended to an alternative end-to-end independent VSync implementation. In this alternative, different displays can trigger rendering and composition through their own independent VSync channels, and the composition main thread can be woken up by the VSync of any display. In this case, controlling the display in the target rendering display set to perform frame rendering processing can be manifested as follows: when the current cycle is the first wake-up, a complete composition and present are performed on the triggering display, and the composition result is cached; when the current cycle is not the first wake-up, the complete composition process can be skipped, and the cached result can be directly called to perform a present on the display that needs to be refreshed.

[0098] Meanwhile, for other displays not included in the target display set for the current frame, their present processing for the current cycle can also be skipped. Therefore, regardless of whether a selective present master scheme under a single tempo or an alternative scheme using independent VSync is adopted, the core idea of ​​this step remains the same: based on the target display set already determined for the current frame, perform differentiated present control on different displays, so that each display operates independently according to its own rhythm.

[0099] See Figure 2 The diagram shows a flowchart of another multi-screen independent refresh method under the Android system provided in this embodiment of the disclosure. The method includes steps S201 to S204, wherein: S201. The application rendering end senses the physical display identifier corresponding to the current window.

[0100] S202. Initiate a VSync request for the target physical display based on the physical display identifier.

[0101] S203. Based on the physical display identifier, the system synthesis server routes the VSync request to the independent scheduling channel of the corresponding display.

[0102] S204. Based on the independent scheduling channels of each display, trigger the drawing and compositing processes of the corresponding display respectively.

[0103] In practical implementation, to further achieve independent multi-screen refresh from the source of display events, an implementation path based on physical display identifiers to establish independent VSync request and independent scheduling channels can be adopted. This implementation differs from the aforementioned main scheme based on target rhythm displays and selective presentation. Instead of relying solely on a single rhythm display to drive the entire display pipeline, it enables the application rendering end to perceive the actual physical display corresponding to the current window and establish a dedicated VSync request channel for that physical display. The system composition server then routes the request to the independent scheduling channel of the corresponding display based on the physical display identifier, thereby triggering the rendering and composition processes corresponding to each display.

[0104] In specific implementations, the application rendering end preferably includes a scheduling component related to interface refresh in the Android application framework, such as Choreographer, DisplayEventReceiver, ViewRootImpl, or other modules responsible for receiving display ticks and driving interface rendering. The physical display identifier corresponding to the current window is preferably used to characterize the physical output terminal where the current window is actually displayed, and can be a physical display ID, an underlying display device handle, a display identifier bound to a physical port, or other identification information that can uniquely indicate the target physical display.

[0105] In this embodiment, when the application drawing end initializes the drawing scheduling object, requests VSync, or handles window migration, it needs to first perceive the real physical display corresponding to the current window, so that the VSync requested later is no longer oriented towards the globally unified display rhythm, but towards the target physical display to which the current window actually belongs.

[0106] In one specific implementation, after the application window is created, the window display target is changed, the window is migrated from the main screen to the secondary screen or an external monitor is connected, the system can obtain the correspondence between the current window and the physical monitor through the window management module, the display management module or the display mapping relationship maintenance module, and determine the physical monitor identifier corresponding to the current window.

[0107] The awareness here can be obtained actively during the initialization of the drawing component, or it can be updated by a system callback when the window display target changes. For example, when the application initially runs on the main display, the physical display identifier corresponding to its current window can be the physical display ID of the main screen; when the application window is dragged to an external display, the application drawing end can obtain the updated physical display identifier again and switch the target of subsequent VSync requests accordingly.

[0108] Furthermore, after the application rendering end perceives the physical display identifier corresponding to the current window, it initiates a VSync request for the target physical display based on the physical display identifier. Preferably, the VSync request here refers to a request submitted by the application rendering end to the system display event service, display scheduling service, or underlying display event receiving module to obtain the next refresh trigger signal.

[0109] In this embodiment, the request needs to explicitly carry the target physical display identifier so that the system can clearly identify that this request is not for a globally uniform rhythm, but for a specific physical display's exclusive refresh rate.

[0110] In practical implementation, the VSync request chain on the application rendering end can be parameterized and extended so that the physical display identifier is included in the constructor, request interface, or cross-process call parameters related to the VSync request. For example, when the display event receiving object is created, displayId, physicalDisplayId, or an equivalent identifier can be passed as an initialization parameter; the physical display identifier can also be passed in subsequent VSync requests.

[0111] In a preferred embodiment, the VSync request carrying the physical display identifier is transparently transmitted through the call chain between the application framework layer and the system service layer. That is, after the application process generates a request, it does not directly generate the final VSync event locally, but instead sends the request to the system display server through an inter-process communication mechanism. Upon receiving the request, the system display server parses the physical display identifier carried within and performs request routing accordingly.

[0112] The request routing here refers to allocating the VSync request to an independent scheduling channel corresponding to the physical display identifier, rather than sending it to a unified single display rhythm channel.

[0113] Furthermore, the system can establish its own independent scheduling channel for each display. This independent scheduling channel preferably includes at least one of the following: a VSync event source associated with the corresponding physical display, a scheduler instance, an event dispatch queue, a callback registration relationship, and a control object related to drawing or compositing triggers. In other words, each physical display is no longer merely a display output terminal, but can also correspond to an independent refresh event stream and scheduling stream.

[0114] For example, a 120Hz main display can correspond to an independent scheduling channel with a 120Hz rhythm, and a 60Hz auxiliary display can correspond to an independent scheduling channel with a 60Hz rhythm; each channel receives, maintains, and distributes its own VSync beats, without being forced to be flattened by a single unified rhythm.

[0115] When triggering the rendering and compositing processes for each display based on its own independent scheduling channel, a two-tiered decoupling approach is preferred. First, rendering-side decoupling: the rendering request for an application window is independently triggered by the VSync channel of its respective physical display. Second, compositing-side decoupling: upon receiving events from different independent scheduling channels, the system compositing service can proceed with its respective compositing or rendering processes for the corresponding display. Thus, if an application window is located on a 120Hz display, its rendering callback can be triggered at a 120Hz pace; if it's located on a 60Hz display, its rendering callback can be triggered at a 60Hz pace. Therefore, applications on different displays achieve rhythm separation during the rendering phase.

[0116] In a preferred implementation, the system can maintain corresponding display context information for each independent scheduling channel. The display context information may include the physical display identifier, the corresponding current refresh rate, the most recent VSync time, the next expected VSync time, the set of windows associated with that display, the most recent composite result, and the current independent channel status, etc.

[0117] To enhance the system's adaptability to window migration and dynamic monitor changes, after the application rendering end senses the physical monitor identifier corresponding to the current window, it can dynamically update the independent scheduling channel bound to the window when the window's display target changes. For example, a window may initially be located on the primary monitor and driven by the independent VSync channel corresponding to the primary monitor; when the window is moved to a secondary monitor, the system can reacquire its new physical monitor identifier and redirect its subsequent rendering requests to the independent scheduling channel corresponding to the secondary monitor. Simultaneously, the system's compositing server can also synchronously update the mapping relationship between the window and the scheduling channel.

[0118] In some embodiments, after triggering the drawing and compositing processes of each display based on its own independent scheduling channel, finer-grained display optimization can be performed by combining the aforementioned selective present, asynchronous present, or cache reuse mechanisms. That is, although this embodiment achieves independence of VSync requests and scheduling channels from the source, in the final present stage, it is still possible to choose to perform a full present, perform only a cached result present, or postpone certain non-critical display updates, depending on the load of each display, the reuse conditions of the compositing results, and the current cycle status.

[0119] This disclosure provides a multi-screen independent refresh method under the Android system. By optimizing the display rhythm control, presentation judgment and presentation scheduling process on the basis of the existing Android display framework, different displays can independently perform frame presentation processing according to their own refresh requirements, thereby reducing the mutual constraints between displays with different refresh rates, improving the display performance of high refresh rate displays and the smoothness of multi-screen collaborative display, while taking into account the simplicity, stability and compatibility of system implementation.

[0120] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0121] Based on the same inventive concept, this disclosure also provides a multi-screen independent refresh device under the Android system, which corresponds to the multi-screen independent refresh method under the Android system. Since the principle of the device in this disclosure for solving the problem is similar to the multi-screen independent refresh method under the Android system described above, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0122] Please see Figure 3 , Figure 3 This is a schematic diagram of a multi-screen independent refresh device under the Android system provided in an embodiment of this disclosure. Figure 3 As shown in the embodiments of this disclosure, the multi-screen independent refresh device 300 under the Android system includes: The rhythm display determination module 310 is used to determine multiple displays in the Android system and the refresh parameters corresponding to each display, and to determine the target rhythm display with the highest refresh rate from the multiple displays.

[0123] The rhythm driving module 320 is used to establish a display refresh driving rhythm based on the target rhythm display, so that the display pipeline runs according to the refresh rhythm corresponding to the target rhythm display.

[0124] The presentation set determination module 330 is used to determine the target presentation display set corresponding to the current frame based on the current presentation time corresponding to the target rhythm display and the refresh requirements of each display before the presentation processing of each frame.

[0125] The presentation control module 340 is used to control the displays in the target presentation display set to perform frame presentation processing, and to control the displays not included in the target presentation display set to skip the presentation processing of the current frame, so that different displays can refresh and display independently according to their respective refresh rhythms.

[0126] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0127] This disclosure provides a multi-screen independent refresh device under the Android system. By optimizing the display rhythm control, presentation judgment and presentation scheduling process on the basis of the existing Android display framework, different displays can independently perform frame presentation processing according to their own refresh requirements, thereby reducing the mutual constraints between displays with different refresh rates, improving the display performance of high refresh rate displays and the smoothness of multi-screen collaborative display, while taking into account the simplicity, stability and compatibility of system implementation.

[0128] Corresponding to Figure 1 and Figure 2 This disclosure also provides an electronic device 400, such as a multi-screen independent refresh method under the Android system. Figure 4 The diagram shown is a structural schematic of an electronic device 400 provided in an embodiment of this disclosure, including: Processor 41, memory 42, and bus 43; memory 42 is used to store execution instructions, including main memory 421 and external memory 422; the main memory 421, also called internal memory, is used to temporarily store the computational data in processor 41, as well as the data exchanged with external memory 422 such as hard disk. Processor 41 exchanges data with external memory 422 through main memory 421. When the electronic device 400 is running, processor 41 and memory 42 communicate through bus 43, enabling processor 41 to execute... Figure 1 and Figure 2 The steps for multi-screen independent refresh in the Android system.

[0129] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the multi-screen independent refresh method under the Android system described in the above method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0130] This disclosure also provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, they can perform the steps of the multi-screen independent refresh method under the Android system described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0131] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0133] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0134] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0135] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A multi-screen independent refresh method under the Android system, characterized in that, include: Determine multiple displays in the Android system and the refresh parameters corresponding to each display, and determine the target rhythm display with the highest refresh rate from the multiple displays; A display refresh driving rhythm is established based on the target rhythm display, so that the display pipeline runs according to the refresh rhythm corresponding to the target rhythm display. Before the rendering of each frame, the target rendering display set corresponding to the current frame is determined based on the current rendering time corresponding to the target rhythm display and the refresh requirements of each display. The system controls the displays in the target display set to perform frame rendering processing, and controls the displays not included in the target display set to skip the rendering processing of the current frame, so that different displays can refresh and display independently according to their respective refresh rhythms.

2. The method according to claim 1, characterized in that, Based on the target rhythm display, a display refresh driving rhythm is established, causing the display pipeline to operate according to the refresh rhythm corresponding to the target rhythm display. Specifically, this includes: The refresh cycle corresponding to the target rhythm display is used as the unified driving rhythm for the application rendering end and the system compositing end. During the frame rendering phase, we only wait for the rendering operation corresponding to the target rhythm display to be completed before releasing the subsequent frame processing flow.

3. The method according to claim 1, characterized in that, Based on the current presentation time corresponding to the target rhythm display and the refresh requirements of each display, the set of target presentation displays corresponding to the current frame is determined, specifically including: Obtain the expected presentation time corresponding to the target rhythm display; The expected presentation time is compared with the corresponding refresh cycle of each display. Based on the phase comparison results, determine the display that is aligned with the current frame; The target rhythm display and the display aligned with the current frame are collectively defined as the target presentation display set.

4. The method according to claim 1, characterized in that, Controlling the displays in the target display set to perform frame rendering processing specifically includes: For non-target rhythm displays in the target display set, the corresponding display operations are executed asynchronously; Continue executing the rendering process corresponding to the target rhythm display in the current frame without waiting for the rendering of the non-target rhythm display to complete; Obtain the task object returned by the asynchronous execution and add the task object to the pending queue; At the beginning of subsequent frames, the task objects in the pending queue are uniformly waited for and cleaned up.

5. The method according to claim 1, characterized in that, Controlling displays not included in the target display set to skip the rendering process of the current frame specifically includes: Identify target skipped displays that are not included in the target presentation display set at the presentation pipeline inlet; Skip the verification and presentation processes corresponding to the target display; Release the layer resources corresponding to the target skipped display, and reuse the release fence corresponding to the previous frame of the target skipped display when it was successfully rendered, as the basis for releasing the layer resources corresponding to the current frame.

6. The method according to claim 4, characterized in that, For non-target pacing displays that perform asynchronous rendering, the method further includes: Force the layers on the non-target rhythm display to be composited using a client-side compositing method; The hardware synthesizer is prohibited from performing device synthesis on the non-target rhythm display; Based on the timing of releasing the corresponding release fence constraint layer buffer in the client-side synthesis, the risk of screen tearing is reduced.

7. The method according to claim 1, characterized in that, The method further includes: Detect whether multiple monitors are in mirrored display mode; When multiple displays are detected to be in the same stack mirror display mode, the independent refresh parameters set for each display are cleared, and the display is switched to a compatible rendering mode that renders all displays and waits for all displays to complete.

8. The method according to claim 1, characterized in that, The method also includes a standalone VSync implementation process, which includes: The application rendering end senses the physical display identifier corresponding to the current window; Initiate a VSync request for the target physical display based on the physical display identifier; Based on the physical display identifier, the system synthesis server routes the VSync request to the independent scheduling channel of the corresponding display. Based on the independent scheduling channels of each display, the drawing and compositing processes of the corresponding display are triggered respectively.

9. The method according to claim 8, characterized in that, Based on the independent scheduling channels of each display, the drawing and compositing processes of the corresponding display are triggered separately, specifically including: When the compositing thread is woken up by the VSync signal of any display, determine whether the current compositing cycle is the first wake-up; Upon determining that it is the first wake-up, execute the complete synthesis process and cache the synthesis result; If the wake-up is not the first time, skip the compositing step and use the cached compositing result to perform rendering processing on the corresponding display.

10. A multi-screen independent refresh device under the Android system, characterized in that, include: The rhythm display determination module is used to determine multiple displays in the Android system and the refresh parameters corresponding to each display, and to determine the target rhythm display with the highest refresh rate from the multiple displays. The rhythm driving module is used to establish a display refresh driving rhythm based on the target rhythm display, so that the display pipeline runs according to the refresh rhythm corresponding to the target rhythm display. The presentation set determination module is used to determine the target presentation display set corresponding to the current frame based on the current presentation time corresponding to the target rhythm display and the refresh requirements of each display before the presentation processing of each frame. The presentation control module is used to control the displays in the target presentation display set to perform frame presentation processing, and to control the displays not included in the target presentation display set to skip the presentation processing of the current frame, so that different displays can refresh and display independently according to their respective refresh rhythms.

Images