Multi-display output resource dynamic management data processing method, system, device and medium

Abstract

The present invention discloses a data processing method, system, device and medium for dynamic management of multiple display output resources, which relates to the field of data processing technology, including: obtaining a physical display screen, obtaining cross-screen display content including multiple display partitions; obtaining historical on-screen delay data of the i-th physical display screen, if the historical on-screen delay data exceeds the on-screen delay threshold, obtaining real-time on-screen delay data of the i-th physical display screen, and determining whether the real-time on-screen delay data are all less than the on-screen delay threshold; if not, obtaining a resource demand index, and completing maintenance management according to the resource demand indicators of multiple physical display screens; if so, obtaining cross-screen real-time delay data, correcting the real-time on-screen delay data and obtaining corrected on-screen delay data, and determining whether the corrected on-screen delay data exceeds the on-screen delay threshold. The present invention has the advantages of high processing efficiency, dynamic self-adaptation and precise resource management.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to a method, system, device and medium for dynamically managing data of multiple display output resources. Background Art

[0002] With the widespread application of multimedia displays, digital advertising, control centers, and large-scale entertainment systems (such as KTV song request platforms), using multiple physical displays to achieve cross-screen display has become a mainstream demand. For example, in a music playback scenario, multiple display partitions (such as the music video lyrics display area, the music on-demand list area, and the music comment area) need to be presented simultaneously across multiple physical displays to provide an immersive user experience. However, due to differences in resolution, refresh rate, and processing power among multiple physical displays, coupled with the complexity of data transmission paths (such as network bandwidth fluctuations and uneven GPU resource allocation), cross-screen display is prone to intra-screen latency (i.e., delayed content updates between adjacent display partitions within a single display) and cross-screen latency (i.e., synchronization loss between display partitions on different physical displays). These latency issues are particularly prominent in dynamic content (such as real-time video streaming or user interaction). For example, when music videos and lyrics are displayed out of sync, on-demand playlists scroll slowly, or comment sections update with lags, the user experience can be severely degraded, manifested as screen tearing, content jumps, or sluggish responses. Furthermore, current reliance on static resource configuration (such as fixed bandwidth allocation or predefined GPU scheduling) makes it impossible to monitor latency changes in real time and lacks trend analysis of historical latency data. This leads to inaccurate resource scheduling, either over-allocating resources and causing waste (such as blindly increasing bandwidth when latency is high) or insufficient resources and failing to promptly mitigate deterioration (such as failing to intervene in advance when latency accumulates), ultimately reducing the overall reliability, smoothness, and energy efficiency of the system. Summary of the Invention

[0003] In response to the technical problems described in the background art, the present invention provides a method, system, device and medium for dynamically managing data of multiple display output resources.

[0004] A method for dynamically managing data for multiple display output resources includes: obtaining multiple physical display screens and obtaining cross-screen display content including multiple display partitions, wherein when multiple physical display screens display the cross-screen display content, each portion of each display partition is displayed on multiple physical display screens respectively; obtaining historical intra-screen delay data between adjacent display partitions in the ith physical display screen in a display cycle before a current display cycle; if any intra-screen historical delay data of the ith physical display screen exceeds an intra-screen delay threshold, obtaining real-time intra-screen delay data between adjacent display partitions in the ith physical display screen in the current display cycle, and determining the real-time intra-screen delay data of the ith physical display screen. Are they all less than the in-screen delay threshold? If not, obtain the resource demand index corresponding to the i-th physical display screen based on the in-screen historical delay data and the in-screen real-time delay data of the i-th physical display screen, and complete maintenance management according to the resource demand indicators of multiple physical display screens; if so, obtain the cross-screen real-time delay data of each display partition between adjacent physical display screens in the current display cycle, correct the in-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition, and obtain the corrected in-screen corrected delay data, and judge whether the in-screen corrected delay data corresponding to the i-th physical display screen exceeds the in-screen delay threshold.

[0005] Optionally, correcting the intra-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data associated with the i-th physical display screen in each display partition and obtaining the corrected intra-screen corrected delay data includes: obtaining the number of display partitions and the number of physical display screens adjacent to the i-th physical display screen; obtaining the cross-screen real-time delay data of each display partition between the i-th physical display screen and each physical display screen adjacent to the i-th physical display screen, and selecting the maximum cross-screen real-time delay data associated with the i-th physical display screen of each display partition;

[0006] According to the maximum cross-screen real-time delay data related to the i-th physical display screen under each display partition, the number of display partitions, and the number of physical displays adjacent to the i-th physical display screen, the intra-screen real-time delay data corresponding to the i-th physical display screen is corrected to obtain the corrected intra-screen corrected delay data.

[0007] Optionally, the intra-screen real-time delay data corresponding to the i-th physical display screen is corrected according to the cross-screen real-time delay data related to the i-th physical display screen in each display partition, and the corrected intra-screen corrected delay data is expressed as: ;in, is the corrected intra-screen correction delay data corresponding to the i-th physical display screen, To display the cross-screen delay threshold between adjacent physical displays, To display the number of partitions, is the number of physical displays adjacent to the i-th physical display, is the cross-screen real-time delay data between the i-th physical display and the j-th physical display adjacent to the i-th physical display in the k-th display partition. is the in-screen correction delay data corresponding to the i-th physical display.

[0008] Optionally, obtaining the resource demand indicator corresponding to the i-th physical display screen based on the in-screen historical delay data and the in-screen real-time delay data of the i-th physical display screen includes: obtaining the maximum in-screen historical delay data and the maximum in-screen real-time delay data of the i-th physical display screen, and obtaining the change trend based on the maximum in-screen historical delay data and the maximum in-screen real-time delay data, and obtaining the compensation amount based on the change trend; obtaining the resource demand indicator corresponding to the i-th physical display screen based on the maximum in-screen historical delay data, the maximum in-screen real-time delay data and the compensation amount of the i-th physical display screen.

[0009] Optionally, the resource requirement indicator corresponding to the i-th physical display screen is obtained based on the historical delay data and the real-time delay data of the i-th physical display screen, and is expressed as: ;in, is the resource demand indicator corresponding to the i-th physical display screen, is the number of adjacent display partitions in the i-th physical display screen, is the historical delay data within the screen between the pth pair of adjacent display partitions within the i-th physical display screen, is the intra-screen delay threshold between adjacent display partitions within the physical display. It is the intra-screen real-time delay data between the pth pair of adjacent display partitions in the i-th physical display screen.

[0010] Optionally, completing maintenance management according to the resource demand indicators of multiple physical display screens includes: obtaining physical display screens whose resource demand indicators exceed a maintenance threshold and using them as resource scheduling targets; and performing resource optimization on the physical display screens marked as resource scheduling targets, wherein the resource optimization includes at least one of performing display output clock synchronization, increasing data transmission channel bandwidth, and allocating graphics processing unit computing resources.

[0011] A multi-display output resource dynamic management data processing system is also provided, the system comprising: an acquisition module for acquiring multiple physical display screens and acquiring cross-screen display content including multiple display partitions, wherein when multiple physical display screens display the cross-screen display content, each part of each display partition is displayed on multiple physical display screens respectively; a data processing module for acquiring intra-screen historical delay data between adjacent display partitions in the ith physical display screen in a display cycle before a current display cycle, if any intra-screen historical delay data of the ith physical display screen exceeds an intra-screen delay threshold, then acquiring intra-screen real-time delay data between adjacent display partitions in the ith physical display screen in the current display cycle, and judging whether the intra-screen real-time delay data of the ith physical display screen are all less than the intra-screen delay threshold; a first judgment execution module for When the in-screen real-time delay data of the i-th physical display screen are all less than the in-screen delay threshold, the resource demand index corresponding to the i-th physical display screen is obtained according to the in-screen historical delay data and the in-screen real-time delay data of the i-th physical display screen, and maintenance management is completed according to the resource demand indicators of multiple physical display screens; the second judgment execution module is used to obtain the cross-screen real-time delay data of each display partition between adjacent physical display screens in the current display cycle when the in-screen real-time delay data of the i-th physical display screen are all less than the in-screen delay threshold, correct the in-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition, and obtain the corrected in-screen corrected delay data, and judge whether the in-screen corrected delay data corresponding to the i-th physical display screen exceeds the in-screen delay threshold.

[0012] Optionally, the second judgment execution module is also used to: obtain the number of display partitions and the number of physical display screens adjacent to the i-th physical display screen; obtain the cross-screen real-time delay data of each display partition between the i-th physical display screen and each physical display screen adjacent to the i-th physical display screen, and select the maximum cross-screen real-time delay data related to the i-th physical display screen of each display partition; correct the intra-screen real-time delay data corresponding to the i-th physical display screen according to the maximum cross-screen real-time delay data related to the i-th physical display screen under each display partition, the number of display partitions, and the number of physical display screens adjacent to the i-th physical display screen, and obtain the corrected intra-screen corrected delay data.

[0013] An electronic device is also provided, comprising: a memory storing a computer program; and a processor for executing the computer program in the memory to implement the above-mentioned method for dynamically managing data processing of multiple display output resources.

[0014] A non-transitory computer-readable storage medium is also provided, on which a computer program is stored. When the program is executed by a processor, the method for processing data for dynamic management of multiple display output resources is implemented.

[0015] The beneficial effects of the present invention are embodied in:

[0016] The data processing method for dynamic multi-display output resource management firstly quantifies intra-screen inter-partition synchronization (e.g., multi-combination detection of the auxiliary screen's advertising and lyrics areas in S2) and cross-screen coordination (e.g., extraction of the boundary delay between the main screen's lyrics area and adjacent screens in S4) based on the physical screen topology and the logical layout of display partitions (e.g., coordination across the central main screen and surrounding auxiliary screens in a six-screen concert). Furthermore, it combines comparative analysis of historical latency peaks (reflecting long-term load) with real-time latency peaks (capturing transient anomalies) (e.g., the identification of the deteriorating trend from 38ms to 42ms on the left auxiliary screen in S3). It also innovatively introduces a dynamic correction mechanism for cross-screen coupling (e.g., S4 amplifies the central main screen's apparent 28ms latency to 38ms due to interference from surrounding screens), thus overcoming the limitations of single-screen evaluation. Through a hierarchical scheduling strategy (clock synchronization, bandwidth expansion, and GPU task migration), it precisely injects resources only to deteriorating screens (e.g., the lower auxiliary screens) or screens with hidden cross-screen issues (e.g., the central main screen), avoiding the waste of statically configured global resources while proactively blocking latency transmission links. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly describes the drawings required for the specific embodiments or the description of the prior art. Similar elements or parts are generally identified by similar reference numerals throughout the drawings. Elements or parts in the drawings are not necessarily drawn to scale.

[0018] Figure 1 This is a partial flow chart of the method for dynamically managing data processing of multiple display output resources according to the present invention;

[0019] Figure 2 This is another partial flow chart of the method for dynamically managing data processing of multiple display output resources according to the present invention;

[0020] Figure 3 The distribution of the physical display screen and each display partition in one embodiment of the method for dynamically managing data for multiple display output resources of the present invention;

[0021] Figure 4 A schematic diagram of the steps of the method for dynamically managing data for multiple display output resources according to the present invention;

[0022] Figure 5 This is a schematic diagram of a portion of step S4 in the method for dynamically managing data for multiple display output resources of the present invention;

[0023] Figure 6This is a schematic diagram of a portion of step S3 in the method for dynamically managing data for multiple display output resources of the present invention;

[0024] Figure 7 Schematic diagram of another part of the steps of S3 in the method for dynamically managing data for multiple display output resources of the present invention;

[0025] Figure 8 The present invention is a block diagram of an electronic device according to an embodiment of the present invention.

[0026] Reference numerals:

[0027] 700 - electronic device, 701 - processor, 702 - memory, 703 - multimedia component, 704 - I / O interface, 705 - communication component. DETAILED DESCRIPTION

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations.

[0029] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention as claimed, but rather merely represents selected embodiments of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0030] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. In addition, the terms "first," "second," etc. are used only to distinguish the descriptions and are not to be understood as indicating or implying relative importance.

[0031] like Figure 1 、 Figure 2 、 Figure 3 and Figure 4 As shown, a method for processing data for dynamic management of multiple display output resources is provided, comprising:

[0032] S1. Acquire multiple physical display screens and acquire cross-screen display content including multiple display partitions, wherein when the multiple physical display screens display the cross-screen display content, respective portions of respective display partitions are displayed on the multiple physical display screens respectively;

[0033] S2. Obtaining historical intra-screen delay data between adjacent display partitions in the i-th physical display screen in the display cycle before the current display cycle. If any intra-screen historical delay data of the i-th physical display screen exceeds the intra-screen delay threshold, obtaining real-time intra-screen delay data between adjacent display partitions in the i-th physical display screen in the current display cycle, and determining whether the real-time intra-screen delay data of the i-th physical display screen are all less than the intra-screen delay threshold.

[0034] S3. If the unevenness of the real-time delay data within the i-th physical display screen is less than the intra-screen delay threshold, then obtain the resource demand indicator corresponding to the i-th physical display screen based on the historical intra-screen delay data and the real-time intra-screen delay data of the i-th physical display screen, and complete maintenance management according to the resource demand indicators of multiple physical display screens;

[0035] S4. If the in-screen real-time delay data of the i-th physical display screen are all less than the in-screen delay threshold, obtain the cross-screen real-time delay data of each display partition between adjacent physical display screens in the current display cycle, correct the in-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition, and obtain the corrected in-screen corrected delay data, and determine whether the in-screen corrected delay data corresponding to the i-th physical display screen exceeds the in-screen delay threshold.

[0036] In this embodiment, it should be noted that in S1, a logical framework for cross-screen display is constructed. Specifically, the physical display parameters are first obtained, and all connected physical display screens (such as the main screen, auxiliary screen, side screen, etc.) need to be identified, mainly collecting the relative positions of each physical display screen. For example, in a KTV scene, the main screen may be a large screen located in the center, surrounded by auxiliary screens, and the screen sizes of each screen are also different. Then, to obtain the cross-screen display content, it is necessary to obtain the logical layout of the cross-screen display content defined by the application layer, and divide the overall content into multiple dynamically associated display partitions (such as lyrics area, on-demand list area, and comment area). These partitions do not exist in isolation, but are distributed and presented collaboratively on multiple physical screens according to business logic. For example, the lyrics area may span the top of the main screen and the auxiliary screen, the on-demand list is displayed on the upper, right, and lower auxiliary screens, and the comment area is scrolled and updated in real time on the upper, left, and lower auxiliary screens.

[0037] Further, such as Figure 3 As shown, take the live broadcast of a concert as an example: deploy six physical screens, two of which serve as the central main screen, and the remaining four are located around the central main screen (in Figure 3 Indicated by a solid frame in the middle); Cross-screen display content includes stage partition, lyrics display partition, bullet screen interactive partition, advertising partition and preview partition (in Figure 3 Indicated by a dotted box). Among them, Figure 3As shown, the stage area is displayed across two screens on the central main screen; the lyrics area is displayed across the lower half of the five screens on the left, central main screen, bottom, and right sides; the bullet commentary area is displayed across the upper half of the five screens on the left, central main screen, top, and right sides; the advertisement area is displayed across the bottom half of the three screens on the left, bottom, and right sides; and the trailer area is displayed across the top half of the three screens on the left, top, and right sides. This precise mapping of physical screen parameters to logical areas provides a spatial benchmark for subsequent latency detection and resource scheduling.

[0038] In S2, intra-screen synchronization anomalies are located through dual verification of historical and real-time data. Specifically, a historical latency threshold trigger mechanism is first used to review the synchronization records of all adjacent display partitions on the i-th physical screen during the previous display cycle. If the historical latency of any pair of partitions (such as the lyrics and playlists) exceeds a preset threshold, the screen is identified as potentially at risk, triggering real-time in-depth monitoring for the current cycle. For example, if the stage and lyrics partitions of the central main screen experienced tearing due to uneven GPU load in the previous cycle, even if no lag occurs in the current cycle, real-time monitoring is still required. Then, a real-time latency verification decision is made. For the screen that triggered the alarm, synchronization data for all adjacent partition pairs within the screen (such as the frame time difference between lyrics scrolling and playlist refreshes) is collected in real time, and each pair of partitions is verified to ensure that they meet the latency threshold requirements. This stage covers all associated partition combinations within the screen. For example, the left auxiliary screen requires simultaneous testing of multiple pairs of partitions, such as the bullet screen area-advertising area and the advertising area-trailer area. If any pair exceeds the threshold, the entire screen is considered to have synchronization risk, providing accurate basis for subsequent resource scheduling.

[0039] For example, consider a live concert. Suppose that during the previous display cycle, the advertisement section (bottom banner) and trailer section (top pop-up window) on the lower auxiliary screen experienced a 45ms delay (threshold 40ms) due to network fluctuations. This automatically marks the screen for real-time monitoring. Real-time verification: During the current cycle, all adjacent section combinations on the lower auxiliary screen are continuously monitored. If the ad section lags behind the trailer section by 38ms (below the 40ms threshold), but the ad section and lyrics section are misaligned by 15ms (threshold 10ms), a substandard combination is identified, and the entire screen remains abnormal, triggering the S3 resource scheduling process. In summary, historical data is used to pre-screen high-risk screens, and real-time, full-combination verification is used to avoid missing local issues. For example, even if the ad-trailer section improves, a newly added ad-lyrics section may still require intervention if it's out of sync. This ensures strict coordination among all sections within a single screen.

[0040] S3 primarily addresses the issue of precise resource allocation when real-time delays within a screen exceed the limit. First, demand indicators are calculated. For the i-th physical screen experiencing excessive delays, the historical peak delay (reflecting long-term load pressure) and the real-time peak delay (reflecting the degree of instantaneous anomaly) within the screen are comprehensively analyzed. By comparing the difference between the two, deterioration trends are identified. If the real-time peak is significantly higher than the historical value, it indicates that the delay is worsening and a positive compensation amount is required (the compensation amount is positively correlated with the degree of deterioration). If the real-time peak is lower than or equal to the historical value, the compensation amount is zero, and resources are allocated based solely on the current load. Finally, the historical delay percentage, real-time delay percentage, and compensation amount are combined to generate a comprehensive resource demand indicator for that screen, which is quantified as the urgency of resource expansion. Subsequently, resource scheduling is executed, and the resource demand indicators of all physical screens are processed. Screens with indicators exceeding the maintenance threshold are prioritized as scheduling targets, and a hierarchical optimization strategy is implemented: hardware layer synchronization, by adjusting the display output clock phase to resolve frame synchronization distortion (such as lyrics and video misalignment); transmission layer optimization, dynamic allocation of network bandwidth or GPU decoding channels (such as expanding the data transmission pipeline when there is a sudden high concurrency of barrage); computing layer reallocation, on-demand deployment of GPU rendering core resources (such as migrating the particle special effects rendering tasks of the on-demand list to idle computing units).

[0041] For example, consider a live concert broadcast. Suppose the left auxiliary screen experiences excessive real-time latency due to frequent barrage updates. The lyrics and barrage areas previously reached 38ms (threshold 35ms). Currently, the latency is 42ms, a 4ms worse than the historical value. A trend of continued deterioration is identified, and a high compensation value is generated. After calculation, a high resource demand indicator is output. The dynamic scheduling process identifies the left auxiliary screen's threshold and marks it as a scheduling target. First, clock synchronization is initiated: the vertical blanking periods of the barrage and lyrics areas are aligned to eliminate screen tearing. GPU resources are then allocated: the 3D rendering tasks for the preview partition are migrated to the idle GPU cores of the central main screen. Finally, transmission channels are expanded: a dedicated high-priority network link is allocated for the barrage data stream. In summary, through three-dimensional assessments of historical, real-time, and deterioration trends, blind global optimization can be avoided. For example, precise scheduling is implemented only for the left auxiliary screen, while resources within the central main screen's threshold are retained, eliminating latency and improving energy efficiency.

[0042] In S4, for physical displays that meet the required intra-screen real-time latency (i.e., the opposite of the processing conditions in S3) but face cross-screen misalignment, the key is to reverse-correct the single-screen assessment results using cross-screen latency data. Specifically, the impact of cross-screen coupling is first quantified. When all partitions within the i-th screen are well synchronized in real time, the cross-screen coordination between that screen and all adjacent physical screens is actively monitored (e.g., the refresh time difference between lyrics on the central main screen and the left auxiliary screen). For each display partition (such as the bullet chat area), the maximum cross-screen latency between the i-th screen and its adjacent screens is extracted (reflecting the most severe boundary misalignment). The cross-screen interference weight is then calculated by combining the number of adjacent screens and the total number of partitions. For example, if the ad partition is misaligned between the left and lower auxiliary screens, but only the left auxiliary screen is adjacent to the central main screen, the left delay is prioritized in the calculation. Dynamic correction and secondary decision-making are then performed, using the cross-screen interference weight to perform a nonlinear amplification correction on the original intra-screen latency data. If overall cross-screen synchronization is poor (high average maximum latency), the correction value is significantly increased; if cross-screen coordination is good, a fine-tuning is performed. The corrected intra-screen delay data actually carries the cross-screen coupling pressure, and ultimately determines whether to trigger S3 resource scheduling through threshold comparison (for example, the original 15ms delay is corrected to 42ms due to cross-screen interference, and if it exceeds the threshold of 35ms, it will be transferred to the S3 process).

[0043] For example, suppose the lyrics section of the central main screen is perfectly synchronized with the stage section (latency 28ms, threshold 35ms). However, cross-screen issues with adjacent screens are detected: the lyrics section on the right auxiliary screen lags behind the central main screen by 25ms (maximum cross-screen latency due to network jitter); the bullet comment section on the upper auxiliary screen leads the central main screen by 18ms (due to refresh rate differences). The correction and decision-making process takes the maximum cross-screen latency between the central main screen and its surrounding adjacent screens (lyrics 25ms, bullet comment 18ms, etc.) across all sections (stage, lyrics, bullet comment, etc.). Based on the total number of sections (5) and the number of adjacent screens (4), a cross-screen interference weight is calculated, and the original intra-screen latency (28ms) is amplified and corrected to a corrected value of 38ms. Because 38ms exceeds the threshold of 35ms, a hidden risk is identified, and resource scheduling is initiated (e.g., optimizing the transmission path from the central main screen to the right auxiliary screen). This eliminates the misconception that a single screen is safe if it meets the requirements, for example, the central main screen may appear normal, but lyrics missynchronization across screens actually affects the overall experience. By quantifying cross-screen correlations, the fluctuation pressure of edge screens is transmitted to the central screen evaluation system, achieving preventive protection for cross-screen collaboration.

[0044] To summarize, the entire multi-display output resource dynamic management data processing method, first, based on the topological relationship of the physical screen and the logical layout of the display partitions (such as the partitions in the six-screen concert spanning the central main screen and the coordination of the surrounding auxiliary screens), accurately quantifies the synchronization between the partitions within the screen (such as the multi-combination detection of the auxiliary screen advertising area and the lyrics area in S2) and the coordination of the cross-screen partitions (such as the boundary delay extraction between the main screen lyrics area and the adjacent screen in S4); further, combined with the comparative analysis of historical delay peaks (reflecting long-term loads) and real-time delay peaks (capturing instantaneous anomalies) (such as the judgment of the deterioration trend from 38ms to 42ms on the left auxiliary screen in S3), and innovatively introduces a dynamic correction mechanism for the impact of cross-screen coupling (for example, S4 amplifies the 28ms delay on the central main screen surface to 38ms due to interference from surrounding screens), thus breaking the limitations of single-screen evaluation. Through hierarchical scheduling strategies (clock synchronization, bandwidth expansion, and GPU task migration), precise resource injection is implemented only for deteriorating screens (such as the auxiliary screen on the lower side) or cross-screen screens with hidden problems (such as the central main screen). This not only avoids the waste of statically configured global resources, but also blocks the delay transmission link in advance.

[0045] like Figure 5 As shown, in one embodiment, in S4, correcting the intra-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen in each display partition and obtaining the corrected intra-screen corrected delay data includes:

[0046] S41, obtaining the number of display partitions and the number of physical display screens adjacent to the i-th physical display screen;

[0047] S42: Obtain cross-screen real-time delay data between the i-th physical display screen and each physical display screen adjacent to the i-th physical display screen for each display partition, and select the maximum cross-screen real-time delay data associated with the i-th physical display screen for each display partition;

[0048] S43. Correct the intra-screen real-time delay data corresponding to the i-th physical display screen according to the maximum cross-screen real-time delay data related to the i-th physical display screen in each display partition, the number of display partitions, and the number of physical display screens adjacent to the i-th physical display screen, and obtain the corrected intra-screen corrected delay data.

[0049] In this embodiment, it should be noted that in S41, the coupling scale between display partitions and neighboring screens is quantified. The total number of partitions participating in cross-screen display must be counted, and all of these partitions require display across physical screen boundaries. For example, in a six-screen concert, the central main screen includes five cross-screen partitions, including the stage partition, lyrics partition, and bullet screen interaction partition, each of which requires coordination with other screens. Next, the number of adjacent physical screens is determined based on the topological structure of the physical display screens (e.g., the positional relationships established in S1). For example, the central main screen, due to its central location, is adjacent to the four auxiliary screens above, below, left, and right, resulting in four adjacent physical screens. The left auxiliary screen, on the other hand, is adjacent to the central main screen, the upper auxiliary screen, and the lower auxiliary screen, resulting in three adjacent physical screens. This step facilitates the subsequent revision of the spatial impact dimension framework. The total number of partitions determines the number of cross-screen objects, while the number of adjacent screens reflects the degree of pivotal importance of the screen in the cross-screen chain (the more adjacent screens, the greater the synchronization responsibility).

[0050] In S42, the focus is on identifying the most severe cross-screen latency threats. First, for each display partition (e.g., the lyrics partition) of the i-th screen, the synchronization time difference between that screen and each adjacent screen is measured. For example, the lyrics partition of the central main screen needs to measure the lyrics content refresh delay with the upper, lower, left, and right auxiliary screens (a total of four sets of data). Then, from the multiple sets of cross-screen data for a single partition, the maximum value is selected (reflecting the partition's weakest boundary during cross-screen). For example, if the lyrics on the right auxiliary screen lag behind the central main screen by 25ms (with the delays for the left, upper, and lower auxiliary screens all less than 20ms), 25ms is taken as the representative value for that partition. Finally, a set of extreme values ​​for all partitions is formed, summarizing the maximum cross-screen latency values ​​for all partitions to form a data set reflecting the global cross-screen risk. For example, in a concert, extreme values ​​such as 25ms for the lyrics partition and 18ms for the barrage partition form the basis for correction calculations. In summary, focusing only on the most severely misaligned boundaries of a single partition avoids redundant calculations while accurately identifying key bottlenecks.

[0051] In S43, based on the set of maximum delays across all zones from S42, the average maximum delay value (reflecting the overall degree of cross-screen misalignment) is calculated. This correction ratio is then combined with the total number of zones and the number of adjacent screens to generate a correction factor. This correction factor follows a core principle: the higher the average maximum delay, the greater the correction factor. Through a three-layer correction model of "zone-boundary-weight," local misalignment on edge screens is converted into a risk indicator for the center screen, making cross-screen risks explicit and proactive.

[0052] In one embodiment, in S4, the intra-screen real-time delay data corresponding to the i-th physical display screen is corrected according to the cross-screen real-time delay data related to the i-th physical display screen in each display partition, and the corrected intra-screen corrected delay data is expressed as:

[0053] ;in,

[0054] is the corrected intra-screen correction delay data corresponding to the i-th physical display screen, To display the cross-screen delay threshold between adjacent physical displays, To display the number of partitions, is the number of physical displays adjacent to the i-th physical display, is the cross-screen real-time delay data between the i-th physical display and the j-th physical display adjacent to the i-th physical display in the k-th display partition. is the in-screen correction delay data corresponding to the i-th physical display.

[0055] In this embodiment, it should be noted that Quantify the degree of cross-screen dissonance; its denominator It is used to extract the weakest link, that is, to take the maximum value of each partition (such as the maximum value of the top / bottom / left / right center of the bullet screen area), focusing only on the most serious boundary imbalance to avoid minor delays interfering with judgment; at the same time, the denominator It is used for global averaging, reflecting the collaborative pressure of all partitions by calculating the overall cross-screen status; its molecular combination shows the cross-screen delay threshold between adjacent physical displays of the partition. , together construct the imbalance ratio, that is, The smaller the value, the higher the average latency and the more severe the cross-screen issue (for example, a threshold of 20ms / an average of 14.8ms is ≈ 1.35; if the average rises to 20ms, the ratio equals 1). The deviation between the "average maximum latency" and the "system tolerance threshold" is converted into a quantifiable indicator. A ratio close to or less than 1 indicates an imminent crash or has exceeded the threshold.

[0056] Furthermore, in exp(-ratio), when the ratio is smaller (cross-screen latency is high), exp(-ratio) approaches 1 (e.g., exp(-0.95) ≈ 0.39); when the ratio is larger (cross-screen latency is low), exp(-ratio) approaches 0 (e.g., exp(-5) ≈ 0.0067). Furthermore, exp(-ratio) + 1 constructs a correction ratio, ensuring that the correction ratio has a range of [1, 2]; when the cross-screen problem is severe, exp(-ratio) increases, and the coefficient approaches 2 (e.g., 0.39 + 1 = 1.39); when the cross-screen problem is mild, exp(-ratio) decreases, and the coefficient approaches 1 (e.g., 0.0067 + 1 ≈ 1). In summary, an exponentially amplified correction ratio is constructed, and when cross-screen latency increases, the coefficient increases nonlinearly from 1 to 2.

[0057] In summary, the entire expression compresses the spatial distribution complexity of cross-screen imbalance (multiple partitions × multiple boundaries) into a single indicator, makes implicit problems explicit through nonlinear amplification, and drives the system to schedule in advance (such as optimizing the right link) when hub nodes such as the central main screen still have spare capacity, thereby blocking the chain spread of cross-screen delays from the root.

[0058] like Figure 6 As shown, in one embodiment, obtaining the resource demand indicator corresponding to the i-th physical display screen according to the historical on-screen delay data and the real-time on-screen delay data of the i-th physical display screen in S3 includes:

[0059] S31. Obtain the maximum historical in-screen delay data and the maximum real-time in-screen delay data of the i-th physical display screen, obtain a change trend based on the maximum historical in-screen delay data and the maximum real-time in-screen delay data, and obtain a compensation amount based on the change trend;

[0060] S32 : Obtain a resource demand indicator corresponding to the i-th physical display screen according to the maximum intra-screen historical delay data, the maximum intra-screen real-time delay data, and the compensation amount of the i-th physical display screen.

[0061] In this embodiment, it should be noted that in S31, the deterioration state is accurately identified and a pre-compensation amount is generated through dynamic comparison of historical and real-time delay peaks. Specifically, the historical delay peak (reflecting the long-term pressure baseline) and the real-time delay peak (capturing instantaneous anomalies) of all adjacent partition pairs of the i-th screen in the previous cycle are obtained. For example, the historical peak of the lyrics area-bullet screen area on the left auxiliary screen was 38ms (threshold 35ms), and it rose to 42ms in the current cycle. The relative change between the real-time peak and the historical peak is calculated (such as +4ms), and the compensation amount is generated based on the direction and amplitude of the change. +4ms indicates a deterioration trend, and the compensation amount increases linearly with the increase (such as +4ms corresponds to a high compensation amount), reflecting the delay diffusion risk level. If it is a negative / zero change (stable or improved), the compensation amount is zero to avoid ineffective resource investment. By introducing a sensitive response to the change trend, the resource demand indicator is improved at the early stage of deterioration (such as the +4ms deterioration of the left auxiliary screen triggers high compensation).

[0062] In S32, three core factors—historical pressure, real-time anomalies, and deterioration trends—are integrated into a single resource demand indicator. The base load assessment takes the maximum of the historical peak ratio (e.g., 38ms / 35ms ≈ 1.086) and the real-time peak ratio (42ms / 35ms ≈ 1.2) to ensure coverage of the most severe load conditions. Trend compensation overlay adds the compensation amount (e.g., the compensation value corresponding to +4ms) to the base load to form a comprehensive demand indicator. For example, the left auxiliary screen takes a real-time peak ratio of 1.2 as the base, and after adding the compensation amount, the indicator rises to 1.31 (if the compensation amount corresponds to 0.11). When the indicator exceeds the threshold (e.g., 1.2), hierarchical scheduling (e.g., GPU task migration + bandwidth expansion) is triggered. In summary, through the three-tiered linkage of peak monitoring, trend diagnosis, and dynamic compensation, complex latency conditions are transformed into quantifiable resource requirements.

[0063] In one embodiment, in S3, the resource demand indicator corresponding to the i-th physical display screen is obtained based on the historical delay data and the real-time delay data of the i-th physical display screen, and is expressed as:

[0064] ;in,

[0065] is the resource demand indicator corresponding to the i-th physical display screen, is the number of adjacent display partitions in the i-th physical display screen, is the historical delay data within the screen between the pth pair of adjacent display partitions within the i-th physical display screen, is the intra-screen delay threshold between adjacent display partitions within the physical display. It is the intra-screen real-time delay data between the pth pair of adjacent display partitions in the i-th physical display screen.

[0066] In this embodiment, it should be noted that It is the core load evaluation item. Among them, Extract the historical delay peaks of all adjacent partition pairs on the i-th screen (for example, the historical peak value of the lyrics and bullet screen area on the left auxiliary screen is 38ms). Extract the real-time delay peak value of the current cycle (for example, the real-time peak value of the lyrics area and the barrage area on the same screen is 42ms); the delay of multiple partitions in a single screen (such as the lyrics on-demand list and the lyrics comment area) may be uneven, and only the most serious pair (such as the lyrics barrage) can cause screen tearing; taking the peak value can avoid the misjudgment of "average safety" (for example, the average delay is 30ms but the lyrics area lags 45ms alone). At the same time, the denominator is , let the numerator be divided by the screen delay threshold (e.g., 35ms), converting absolute latency into relative load ratios (historical 38ms / 35ms ≈ 1.086, real-time 42ms / 35ms ≈ 1.2). Finally, taking the maximum value, retaining the higher of the historical and real-time load ratios (e.g., max(1.086, 1.2) = 1.2). This prevents resource scheduling from being misled by momentary improvements (e.g., real-time latency drops to 30ms after a sudden pause in barrage, but the historical peak of 1.086 still indicates the need to maintain bandwidth guarantees), ensuring global coverage of both long-term and instantaneous risks.

[0067] Further, is the trend compensation term. To calculate the numerator difference, subtract the real-time peak value from the historical peak value (e.g., 42ms-38ms=4ms). If the result is a positive difference (real-time > historical), it indicates that the delay has deteriorated (e.g., +4ms), triggering compensation; if the result is zero / negative difference (real-time ≤ historical), it indicates stability or improvement, and the compensation amount is 0. At the same time, divide the difference by Convert to a ratio (such as 4ms / 35ms≈0.114), and then pass Negative values ​​are eliminated, meaning stable or improving conditions are eliminated. Furthermore, the compensation amount is linearly positively correlated with the magnitude of the deterioration (e.g., a 0.0285 compensation value is added for every 1ms of deterioration). The deterioration rate is quantified as an incremental resource requirement (e.g., a 4ms deterioration on the left auxiliary screen represents a +0.114 compensation value), enabling trend-driven pre-intervention. If deterioration is rapid, high compensation is applied, leading to priority scheduling (e.g., pre-allocation of GPU cores). If there is no deterioration, no compensation is applied, thus avoiding waste.

[0068] Further, Add a trend compensation item to the core load evaluation item. For example, the core load evaluation item is max(38 / 35, 42 / 35)=max(1.086, 1.2)=1.2; the trend compensation item is max(0, (42-38) / 35)=4 / 35≈0.114; If the maintenance threshold is 1.2, scheduling is triggered.

[0069] In summary, the entire expression converts dynamic delay status into precise resource demand through the triple mechanisms of peak load monitoring, deterioration trend quantification, and historical baseline protection. This solves the problems of blind waste and delayed response in static resource allocation to a certain extent, and ultimately improves the smoothness and energy efficiency of the multi-screen system.

[0070] like Figure 7 As shown, in one embodiment, completing maintenance management according to resource demand indicators of multiple physical display screens in S3 includes:

[0071] S33, obtaining a physical display screen whose resource demand index exceeds a maintenance threshold and using it as a resource scheduling target;

[0072] S34. Perform resource optimization on the physical display screen marked as a resource scheduling target, wherein the resource optimization includes at least one of performing display output clock synchronization, increasing data transmission channel bandwidth, and allocating graphics processing unit computing resources.

[0073] In this embodiment, it should be noted that in S33, first, a global screen resource demand assessment is performed, and a resource demand index is calculated for each physical display screen (e.g., 0.98 for the central main screen, 1.31 for the left auxiliary screen, and 1.05 for the lower auxiliary screen). This index comprehensively reflects the resource scheduling needs of the screen. A dynamic maintenance threshold (e.g., 1.2) is set based on the total resource pool capacity, and only screens with indicators exceeding the limit are screened (e.g., 1.31>1.2 for the left auxiliary screen). At the same time, an incremental screening strategy is adopted: if too many screens exceed the limit, they are sorted from high to low by indicator value, with the most severely deteriorated screens being prioritized to ensure that key bottlenecks are resolved first.

[0074] In S34, a three-level, combinable optimization strategy is implemented for the marker screen, enabling on-demand resource injection. First, hardware-level frame synchronization calibration is performed to resolve inter-partition frame misalignment by resetting the display output clock phase. For example, to address tearing caused by refresh rate differences between the lyrics and bullet screen areas on the left auxiliary screen, their vertical blanking periods are aligned, ensuring strict synchronization between lyric scrolling and bullet screen refresh (eliminating a 50ms misalignment). Second, dynamic bandwidth allocation is implemented at the transport layer, prioritizing capacity expansion for high-latency channels based on data type (e.g., video stream, bullet screen text). For example, a dedicated network link is allocated to the bullet screen data stream on the left auxiliary screen, increasing transmission bandwidth by 300% to accommodate traffic bursts. Finally, compute-level GPU resource reallocation is implemented, migrating non-core rendering tasks to idle units. For example, 3D particle effects rendering for the left auxiliary screen's trailer partition can be offloaded to an idle GPU core on the central main screen, freeing up 35% of computing power for lyrics rendering on that screen and preventing global GPU overload.

[0075] A multi-display output resource dynamic management data processing system is also provided, the system comprising:

[0076] an acquisition module, configured to acquire multiple physical display screens and acquire cross-screen display content comprising multiple display partitions (the multiple display partitions need to be displayed simultaneously across the screens, for example, the multiple display partitions include a music video lyrics display area, a music on-demand list, a music comment area, etc., and these display partitions are displayed simultaneously across the screens on multiple physical display screens), wherein when the multiple physical display screens display the cross-screen display content, each portion of each display partition is displayed separately on the multiple physical display screens;

[0077] The data processing module is used to obtain the historical intra-screen delay data between adjacent display partitions in the ith physical display screen in the display cycle before the current display cycle. If any intra-screen historical delay data of the ith physical display screen exceeds the intra-screen delay threshold (starting the current display cycle verification mechanism), the data processing module is used to obtain the real-time intra-screen delay data between adjacent display partitions in the ith physical display screen in the current display cycle, and determine whether the real-time intra-screen delay data of the ith physical display screen are all less than the intra-screen delay threshold (verifying whether the delay in the current display cycle exceeds the limit);

[0078] The first judgment execution module is configured to, when the unevenness of the real-time on-screen delay data of the i-th physical display screen is less than the on-screen delay threshold, obtain a resource demand indicator corresponding to the i-th physical display screen based on the historical on-screen delay data and the real-time on-screen delay data of the i-th physical display screen, and perform maintenance management according to the resource demand indicators of the multiple physical display screens;

[0079] The second judgment execution module is used to obtain the cross-screen real-time delay data of each display partition between adjacent physical display screens in the current display cycle when the in-screen real-time delay data of the i-th physical display screen are all less than the in-screen delay threshold, correct the in-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition, and obtain the corrected in-screen corrected delay data, and judge whether the in-screen corrected delay data corresponding to the i-th physical display screen exceeds the in-screen delay threshold.

[0080] In one embodiment, the second judgment execution module is further used to: obtain the number of display partitions and the number of physical display screens adjacent to the i-th physical display screen; obtain cross-screen real-time delay data between the i-th physical display screen and each physical display screen adjacent to the i-th physical display screen for each display partition, and select the maximum cross-screen real-time delay data related to the i-th physical display screen for each display partition (that is, the i-th physical display screen may be adjacent to multiple physical display screens, and each adjacent physical display screen has a cross-screen real-time delay data, but only one cross-screen real-time delay data is required for calculation, so only the maximum cross-screen real-time delay data needs to be selected); correct the intra-screen real-time delay data corresponding to the i-th physical display screen according to the maximum cross-screen real-time delay data related to the i-th physical display screen under each display partition, the number of display partitions, and the number of physical display screens adjacent to the i-th physical display screen, and obtain the corrected intra-screen corrected delay data.

[0081] In this embodiment, it should be noted that the specific manner of executing operations in the above-mentioned multi-display output resource dynamic management data processing system has been described in detail in the embodiment of the multi-display output resource dynamic management data processing method, and will not be elaborated here.

[0082] Figure 8 FIG is a block diagram of an electronic device showing a method for processing data for dynamic management of multiple display output resources according to an exemplary embodiment. Figure 8 As shown, the electronic device 700 may include: a processor 701 , a memory 702 , and may further include one or more of a multimedia component 703 , an I / O interface 704 (input / output interface), and a communication component 705 .

[0083] The processor 701 is used to control the overall operation of the electronic device 700 to complete all or part of the steps in the above-mentioned method for dynamically managing data for multiple display output resources. The memory 702 is used to store various types of data to support the operation of the electronic device 700. This data may include, for example, instructions for any application or method operating on the electronic device 700, as well as application-related data such as contact information, sent and received messages, images, audio, video, etc. The memory 702 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in the memory 702 or transmitted via the communication component 705. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 704 provides an interface between the processor 701 and other interface modules, such as a keyboard, a mouse, and buttons. These buttons may be virtual or physical. The communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication may include Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G networks, or a combination thereof, without limitation. Accordingly, the communication component 705 may include a Wi-Fi module, a Bluetooth module, an NFC module, and the like.

[0084] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the above-mentioned method for dynamically managing data processing for multiple display output resources.

[0085] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, the program instructions implement the steps of the aforementioned method for dynamically managing data for multiple display output resources. For example, the computer-readable storage medium may be the aforementioned memory 702 including the program instructions. The program instructions may be executed by the processor 701 of the electronic device 700 to implement the aforementioned method for dynamically managing data for multiple display output resources.

[0086] In another exemplary embodiment, a computer program product is provided. The computer program product includes a computer program executable by a programmable device, and has a code portion for executing the above-mentioned multiple display output resource dynamic management data processing method when executed by the programmable device.

[0087] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings. However, the present disclosure is not limited to the specific details of the above embodiments. Within the technical concept of the present disclosure, various simple modifications can be made to the technical solutions of the present disclosure, and these simple modifications all fall within the scope of protection of the present disclosure.

[0088] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0089] In addition, the various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention, and they should all be included in the scope of the claims and description of the present invention.

Claims

1. A method for dynamically managing data for multiple display output resources, characterized in that: include: Acquire multiple physical display screens, and acquire cross-screen display content including multiple display partitions, wherein when the multiple physical display screens display the cross-screen display content, each portion of each display partition is displayed on the multiple physical display screens respectively; Obtain the historical intra-screen delay data between adjacent display partitions in the i-th physical display screen in the display cycle before the current display cycle. If any intra-screen historical delay data of the i-th physical display screen exceeds the intra-screen delay threshold, obtain the real-time intra-screen delay data between adjacent display partitions in the i-th physical display screen in the current display cycle, and determine whether the real-time intra-screen delay data of the i-th physical display screen are all less than the intra-screen delay threshold. If not, the resource demand index corresponding to the i-th physical display screen is obtained based on the historical delay data and real-time delay data of the i-th physical display screen, and maintenance management is completed according to the resource demand indicators of multiple physical display screens; Wherein, obtaining the resource demand indicator corresponding to the i-th physical display screen based on the in-screen historical delay data and the in-screen real-time delay data of the i-th physical display screen includes: obtaining the maximum in-screen historical delay data and the maximum in-screen real-time delay data of the i-th physical display screen, obtaining a change trend based on the maximum in-screen historical delay data and the maximum in-screen real-time delay data, and obtaining a compensation amount based on the change trend; obtaining the resource demand indicator corresponding to the i-th physical display screen based on the maximum in-screen historical delay data, the maximum in-screen real-time delay data, and the compensation amount of the i-th physical display screen; If so, obtain cross-screen real-time delay data between adjacent physical displays for each display partition in the current display cycle, correct the intra-screen real-time delay data corresponding to the i-th physical display according to the cross-screen real-time delay data related to the i-th physical display under each display partition, and obtain the corrected intra-screen corrected delay data, and determine whether the intra-screen corrected delay data corresponding to the i-th physical display exceeds the intra-screen delay threshold; Among them, correcting the intra-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition and obtaining the corrected intra-screen corrected delay data includes: obtaining the number of display partitions and the number of physical display screens adjacent to the i-th physical display screen; obtaining the cross-screen real-time delay data of each display partition between the i-th physical display screen and each physical display screen adjacent to the i-th physical display screen, and selecting the maximum cross-screen real-time delay data related to the i-th physical display screen of each display partition; correcting the intra-screen real-time delay data corresponding to the i-th physical display screen according to the maximum cross-screen real-time delay data related to the i-th physical display screen under each display partition, the number of display partitions, and the number of physical display screens adjacent to the i-th physical display screen and obtaining the corrected intra-screen corrected delay data.

2. The method for dynamically managing data of multiple display output resources according to claim 1, wherein: The intra-screen real-time delay data corresponding to the i-th physical display screen is corrected according to the cross-screen real-time delay data related to the i-th physical display screen in each display partition, and the corrected intra-screen corrected delay data is expressed as: ;in, is the corrected intra-screen correction delay data corresponding to the i-th physical display screen, To display the cross-screen delay threshold between adjacent physical displays, To display the number of partitions, is the number of physical displays adjacent to the i-th physical display, is the cross-screen real-time delay data between the i-th physical display and the j-th physical display adjacent to the i-th physical display in the k-th display partition. is the in-screen correction delay data corresponding to the i-th physical display.

3. The method for dynamically managing data of multiple display output resources according to claim 1, wherein: The resource requirement indicator corresponding to the i-th physical display screen is obtained according to the historical delay data and the real-time delay data of the i-th physical display screen as follows: ;in, is the resource demand indicator corresponding to the i-th physical display screen, is the number of adjacent display partitions in the i-th physical display screen, is the historical delay data within the screen between the pth pair of adjacent display partitions within the i-th physical display screen, is the intra-screen delay threshold between adjacent display partitions within the physical display. It is the intra-screen real-time delay data between the pth pair of adjacent display partitions in the i-th physical display screen.

4. The method for dynamically managing data for multiple display output resources according to claim 1, wherein: The maintenance management according to the resource requirement indicators of multiple physical display screens includes: Obtain physical display screens whose resource demand indicators exceed the maintenance threshold and use them as resource scheduling targets; Resource optimization is performed on the physical display screen marked as a resource scheduling target, where the resource optimization includes at least one of performing display output clock synchronization, increasing data transmission channel bandwidth, and allocating graphics processing unit computing resources.

5. A multi-display output resource dynamic management data processing system, characterized in that: The system comprises: an acquisition module, configured to acquire multiple physical display screens and acquire cross-screen display content including multiple display partitions, wherein when the multiple physical display screens display the cross-screen display content, each portion of each display partition is displayed on the multiple physical display screens respectively; A data processing module is configured to obtain historical intra-screen delay data between adjacent display partitions in the ith physical display screen in the display cycle before the current display cycle. If any intra-screen historical delay data of the ith physical display screen exceeds the intra-screen delay threshold, obtain real-time intra-screen delay data between adjacent display partitions in the ith physical display screen in the current display cycle, and determine whether all real-time intra-screen delay data of the ith physical display screen are less than the intra-screen delay threshold. The first judgment execution module is configured to, when the unevenness of the real-time on-screen delay data of the i-th physical display screen is less than the on-screen delay threshold, obtain a resource demand indicator corresponding to the i-th physical display screen based on the historical on-screen delay data and the real-time on-screen delay data of the i-th physical display screen, and perform maintenance management according to the resource demand indicators of the multiple physical display screens; Wherein, obtaining the resource demand indicator corresponding to the i-th physical display screen based on the in-screen historical delay data and the in-screen real-time delay data of the i-th physical display screen includes: obtaining the maximum in-screen historical delay data and the maximum in-screen real-time delay data of the i-th physical display screen, obtaining a change trend based on the maximum in-screen historical delay data and the maximum in-screen real-time delay data, and obtaining a compensation amount based on the change trend; obtaining the resource demand indicator corresponding to the i-th physical display screen based on the maximum in-screen historical delay data, the maximum in-screen real-time delay data, and the compensation amount of the i-th physical display screen; The second judgment execution module is used to obtain, when the in-screen real-time delay data of the i-th physical display screen are all less than the in-screen delay threshold, the cross-screen real-time delay data between adjacent physical displays of each display partition in the current display cycle, correct the in-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition, and obtain the corrected in-screen corrected delay data, and determine whether the in-screen corrected delay data corresponding to the i-th physical display screen exceeds the in-screen delay threshold; Among them, correcting the intra-screen real-time delay data corresponding to the i-th physical display screen according to the cross-screen real-time delay data related to the i-th physical display screen under each display partition and obtaining the corrected intra-screen corrected delay data includes: obtaining the number of display partitions and the number of physical display screens adjacent to the i-th physical display screen; obtaining the cross-screen real-time delay data of each display partition between the i-th physical display screen and each physical display screen adjacent to the i-th physical display screen, and selecting the maximum cross-screen real-time delay data related to the i-th physical display screen of each display partition; correcting the intra-screen real-time delay data corresponding to the i-th physical display screen according to the maximum cross-screen real-time delay data related to the i-th physical display screen under each display partition, the number of display partitions, and the number of physical display screens adjacent to the i-th physical display screen and obtaining the corrected intra-screen corrected delay data.

6. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor is configured to execute the computer program in the memory to implement the multi-display output resource dynamic management data processing method according to any one of claims 1 to 4.

7. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for processing data for dynamic management of multiple display output resources as claimed in any one of claims 1 to 4 is implemented.

Images