A cave and LED-based multi-screen interactive real estate display method

Abstract

The application discloses a kind of multi-screen interactive real estate display methods based on cave and LED, belong to vehicle-mounted electronic technology field, including user interaction in Pad end generates operation item, analysis request, generates rendering instruction, Babylon.js rendering display content, frame time and delay are counted, whether the difference between screen synchronization is over threshold is judged, execute adjustment strategy, generate frame image and push to three screens, solve the technical problem of the synchronization control and space consistency rendering of multiple independent view angle LED screen in multiple frame rendering, the three view angle independent rendering mechanism between multiple screens is realized in the application, ensure that multiple screen content is stably synchronized, support real-time Pad control and state response mechanism, improve the smoothness of user operation and visual feedback, modular system architecture is convenient for deployment and extension, adapt to a variety of display environments and resolution specifications.

Description

Technical Field

[0001] This invention belongs to the field of vehicle electronic technology, and in particular relates to a multi-screen interactive real estate display method based on a cave and LED. Background Technology

[0002] With the increasing demand for multimedia displays, immersive experiences, and digital real estate presentations, multi-screen interactive display systems are becoming increasingly widespread in practical applications. Especially in scenarios such as property developments, industrial models, and interactive museums, immersive visualization methods that integrate 3D rendering and multi-screen interaction have become an important means of enhancing user interaction and spatial awareness.

[0003] CAVE (Cave Automatic Virtual Environment) is a way to build immersive virtual environments that can present three-dimensional information through multiple screens.

[0004] Currently, mainstream multi-screen display solutions mainly rely on single-viewpoint replication or simple split-screen methods for image projection. Although these solutions can achieve basic multi-screen expansion, they generally suffer from the following technical bottlenecks:

[0005] Traditional split-screen methods often use mirrored rendering, resulting in multiple screens displaying identical content, lacking spatial depth, and failing to reproduce the user's realistic experience of observing a scene from multiple viewpoints in space.

[0006] During multi-screen rendering, due to factors such as network fluctuations, GPU scheduling, and computing load, frame latency differences can easily occur between different screens, causing screen tearing or frame skipping, which affects the smoothness of viewing.

[0007] When users operate via tablets or control terminals, the existing system suffers from intermediate delays in request distribution and view response, which cannot support real-time control and feedback requirements and reduces the user experience. Summary of the Invention

[0008] The purpose of this invention is to provide a multi-screen interactive real estate display method based on caves and LEDs, which solves the technical problems of synchronous control and spatial consistency rendering of multiple independent viewpoint LED screens in multi-frame rendering.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] A multi-screen interactive real estate display method based on cave and LED includes the following steps:

[0011] Step 1: The user selects a view or operation item through the control interface on the Pad. The Pad generates an operation request, encapsulates the operation request, and sends it to the backend service system.

[0012] The operation items include the operation type and the corresponding operation parameters;

[0013] The Pad client and the backend service system establish a connection via WebSocket and communicate in real time.

[0014] Step 2: The backend service system continuously listens for WebSocket connections, receives and parses operation requests sent from the Pad in real time, and generates rendering instructions based on the parsed operation item classification results;

[0015] Step 3: The backend service system calls the Babylon.js rendering engine and executes the corresponding graphics update logic according to the operation type of the operation item in the rendering instruction;

[0016] The backend service system initializes the basic viewpoint and calculates the camera rotation angle corresponding to each screen based on the fixed spatial arrangement of the three screens.

[0017] The Babylon.js rendering engine binds rendering tasks to three camera views respectively;

[0018] Step 4: The Babylon.js rendering engine performs split-screen rendering. The backend service system continuously receives and monitors the frame time and rendering latency of each screen, and counts the current frame rendering status of each screen.

[0019] Step 5: The backend service system determines in real time whether there is a difference in frame latency between the three screens, and calculates the difference Δt between the frame latency of each screen and the average latency.

[0020] The difference Δt is compared with multiple preset delay thresholds, the synchronization adjustment window is divided, and the corresponding number of aligned frames or the frame reduction magnitude is calculated.

[0021] Step 6: The Babylon.js rendering engine generates the current frame image content in real time based on the viewing angle offset of each screen. The rendered content is then pushed to the corresponding screen and displayed through the backend service system.

[0022] Preferably, the operation request is specifically user operation behavior data generated by the Pad after the user interacts through the Web control interface on the Pad, and different behaviors correspond to different operation items;

[0023] The operation items in the operation request include switching the apartment model, rotating the angle, starting the animation, and zooming in and out.

[0024] Preferably, the backend service system continuously listens for WebSocket connections through a Node.js service, maintains the connection session on the Pad, and listens for message events;

[0025] The backend service system records the current system execution status in real time and generates a current status log;

[0026] The backend service system parses the operation items and processes them by category:

[0027] The operation item is to switch the apartment type model, which triggers the loading of the new model and the replacement of the scene;

[0028] The operation option is rotation angle, which triggers the camera viewpoint transformation.

[0029] The action option is to start an animation, which triggers the execution of a predefined animation.

[0030] The operation option is zoom in / out, which triggers the adjustment of the field of view.

[0031] The backend service system generates different rendering engine instructions based on the parsing results of the operation items.

[0032] Preferably, step 3 includes the following steps:

[0033] Step 3-1: The backend service system calls the Babylon.js rendering engine. The Babylon.js rendering engine initializes the rendering scene based on the current state logs, and sets the initial position and orientation of the main camera according to the current model and base viewpoint in the rendering scene. Specifically, it initializes the base camera position P. base :

[0034]

[0035] Step 3-2: Based on the physical spatial arrangement of the three screens, set the offset angles respectively, from left to right as θ1, θ2, and θ3;

[0036] Step 3-3: Calculate the camera position P used for rendering each screen according to the following formula. i :

[0037] Rotation matrix:

[0038]

[0039] P i =R y (θ i )·P base ;

[0040] Among them, R y (θ) is the rotation matrix of the vector around the y-axis, where θ is the offset angle; i represents the screen number, with the default being 1 for the left screen, 2 for the middle screen, and 3 for the right screen; θ i This represents the offset angle of the i-th screen.

[0041] Steps 3-4: Bind a corresponding independent camera object to each screen, and write its view parameters into the Babylon.js rendering engine; the view parameters include the camera's position and rotation angle.

[0042] Preferably, step 4 includes the following steps:

[0043] Step 4-1: The Babylon.js rendering engine renders the current frame image based on the camera offset angle of each screen.

[0044] Step 4-2: After each rendering is completed, record the start and end timestamps, and calculate the rendering time of the current frame:

[0045] T i frame=T i end-T i start;

[0046] Among them, T i `frame` represents the rendering time of the i-th screen, and `T` represents the rendering time of the i-th screen. i end indicates the rendering end time of the i-th screen, T i start indicates the start time of rendering for the i-th screen;

[0047] Step 4-3: After the rendering frame is generated, the image result is pushed to the corresponding screen in real time via WebSocket;

[0048] Step 4-4: Monitor and aggregate the rendering time for each screen.

[0049] Preferably, step 5 includes the following steps:

[0050] Step 5-1: Calculate the average rendering time (Tavg) for the current frame across the three screens:

[0051] Tavg=(T1frame+T2frame+T3frame) / 3;

[0052] Step 5-2: Calculate the difference Δt between the frame latency of each screen and the average latency:

[0053] Δt=T i frame-Tavg;

[0054] Step 5-3: Classify and determine the frame synchronization status of the three screens: If the difference Δt between the three screens is less than 12ms, the current synchronization is considered normal and no synchronization adjustment state is entered; if the delay of any screen is greater than 20ms, the synchronization adjustment state is entered.

[0055] Step 5-4: Enter the synchronization adjustment state, specifically by setting three threshold windows and comparing them:

[0056] w1:12ms≤|Δt|<20ms→ΔN=5;

[0057] w2:20ms≤|Δt|<33ms→ΔN=10;

[0058] w3:|Δt|≥33ms→ΔN=15;

[0059] Where w1, w2, and w3 represent the window levels set in step 3, and ΔN represents the number of frames adjusted.

[0060] Preferably, when performing step 6, a preset adjustment strategy is executed based on the difference Δt of each screen calculated in step 5, thereby enabling frame-level synchronization during multi-screen display.

[0061] Preferably, the preset adjustment strategy includes:

[0062] Strategy 1: Establish a short-time frame buffer in the sending queue of each screen, push the screen that triggers the w1 window level with delay according to Δt, and pre-render and cache the screen that triggers the w3 window level.

[0063] Strategy 2: The backend service system obtains the ACK messages from all screens for the previous frame N, and determines whether to push the next frame N+1 based on the ACK messages; the push of the next frame N+1 is only triggered after all screens have completed displaying frame N.

[0064] Strategy 3: After receiving an image frame, each screen displays the content and returns an ACK message to the backend service system via WebSocket. The ACK message contains the screen number and frame number. The backend service system controls the synchronization rhythm based on the ACK message.

[0065] Strategy 4: When any screen sends an ack message within the preset delay, the backend service system retransmits the current frame N or skips the current frame N and directly enters the push of the next frame N+1, and resets the cache queue.

[0066] This invention presents a multi-screen interactive real estate display method based on caves and LEDs, solving the technical problems of synchronous control and spatial consistency rendering of multiple independent-view LED screens in multi-frame rendering. This invention implements a three-view independent rendering mechanism among multiple screens, constructing a realistic and immersive visual effect. It also constructs a dynamic frame synchronization adjustment model based on latency thresholds to ensure stable synchronization of content across multiple screens. Furthermore, it supports real-time Pad control and status response mechanisms, improving the smoothness of user operation and visual feedback. The modular system architecture facilitates deployment and expansion, adapting to various display environments and resolution specifications. Attached Figure Description

[0067] Figure 1 This is the main flowchart of the present invention;

[0068] Figure 2 This is a schematic diagram of the system architecture of the present invention;

[0069] Figure 3 This is a flowchart of step 3 of the present invention;

[0070] Figure 4 This is a flowchart of step 4 of the present invention;

[0071] Figure 5 This is a flowchart of step 5 of the present invention. Detailed Implementation

[0072] like Figures 1-5 The method for multi-screen interactive real estate display based on cave and LED, as shown, includes the following steps:

[0073] Step 1: The user selects a view or operation item through the control interface on the Pad. The Pad generates an operation request, encapsulates the operation request, and sends it to the backend service system.

[0074] The operation items include the operation type and the corresponding operation parameters;

[0075] The Pad client and the backend service system establish a connection via WebSocket and communicate in real time.

[0076] The operation request is specifically user operation behavior data generated by the Pad after the user interacts through the web control interface on the Pad. Different behaviors correspond to different operation items.

[0077] The operation items in the operation request include switching the apartment model, rotating the angle, starting the animation, and zooming in and out.

[0078] In this embodiment, the user's actions on the Pad (such as clicking a button or selecting a floor plan) are converted into structured operation requests in real time.

[0079] An operation request must include at least the operation type (e.g., switching models, adjusting viewpoints) and parameter values. These operation requests are transmitted to the backend service system via the WebSocket protocol to achieve low-latency, bidirectional communication.

[0080] For example: When a user clicks the "Change Apartment Type" button on the Pad and selects Apartment Type B, the fields requested for the operation are as follows:

[0081] user_id="U123", timestamp="2025-05-08T14:32:21Z", operation="switch_model", parameters:{"model_id"="B}.

[0082] Step 2: The backend service system continuously listens for WebSocket connections, receives and parses operation requests sent from the Pad in real time, and generates rendering instructions based on the parsed operation item classification results;

[0083] The backend service system continuously listens for WebSocket connections through Node.js services, maintains the connection session on the Pad, and listens for message events;

[0084] The backend service system records the current system execution status in real time and generates a current status log;

[0085] The backend service system parses the operation items and processes them by category:

[0086] The operation item is to switch the apartment type model, which triggers the loading of the new model and the replacement of the scene;

[0087] The operation option is rotation angle, which triggers the camera viewpoint transformation.

[0088] The action option is to start an animation, which triggers the execution of a predefined animation.

[0089] The operation option is zoom in / out, which triggers the adjustment of the field of view.

[0090] The backend service system generates different rendering engine instructions based on the parsing results of the operation items.

[0091] In this embodiment, the backend service system can adopt an event-driven architecture (such as Node.js) to listen for WebSocket connections.

[0092] Whenever the backend service system receives a new operation request, it triggers the parsing and classification module to perform semantic parsing and mapping of the operation items, generating executable rendering instructions for Babylon.js (such as updating the model or changing the viewpoint). At the same time, the backend service system records the processing logs for each request, supporting subsequent debugging and backtracking.

[0093] Step 3: The backend service system calls the Babylon.js rendering engine and executes the corresponding graphics update logic according to the operation type of the operation item in the rendering instruction;

[0094] The backend service system initializes the basic viewpoint and calculates the camera rotation angle corresponding to each screen based on the fixed spatial arrangement of the three screens.

[0095] The Babylon.js rendering engine binds rendering tasks to three camera views respectively;

[0096] Step 3 includes the following steps:

[0097] Step 3-1: The backend service system calls the Babylon.js rendering engine. The Babylon.js rendering engine initializes the rendering scene based on the current state logs, and sets the initial position and orientation of the main camera according to the current model and base viewpoint in the rendering scene. Specifically, it initializes the base camera position P. base :

[0098]

[0099] In this embodiment, the basic camera position is the center point of the scene directly opposite the center screen, and the position is set to (0, y, z), and the direction is set to the positive Z-axis.

[0100] Step 3-2: Based on the physical spatial arrangement of the three screens, set the offset angles respectively, from left to right as θ1, θ2, and θ3;

[0101] Step 3-3: Calculate the camera position P used for rendering each screen according to the following formula. i :

[0102] Rotation matrix:

[0103]

[0104] P i =R y (θ i )·P base ;

[0105] Among them, R y (θ) is the rotation matrix of the vector around the y-axis, where θ is the offset angle; i represents the screen number, with the default being 1 for the left screen, 2 for the middle screen, and 3 for the right screen; θ i This represents the offset angle of the i-th screen. In this embodiment, the default value is θ. i The values ​​can be θ1 = -30°, θ2 = 0°, and θ3 = +30°. The specific values ​​can also be set according to the installation position of the screen, or they can be calculated using the following formula: Offset angle = screen pitch / user viewing distance × scaling factor.

[0106] Steps 3-4: Bind a corresponding independent camera object to each screen, and write its view parameters into the Babylon.js rendering engine; the view parameters include the camera's position and rotation angle.

[0107] Step 4: The Babylon.js rendering engine performs split-screen rendering. The backend service system continuously receives and monitors the frame time and rendering latency of each screen, and counts the current frame rendering status of each screen.

[0108] Step 4 includes the following steps:

[0109] Step 4-1: The Babylon.js rendering engine renders the current frame image based on the camera offset angle of each screen.

[0110] Step 4-2: After each rendering is completed, record the start and end timestamps, and calculate the rendering time of the current frame:

[0111] T i frame=T i end-T i start;

[0112] Among them, T i `frame` represents the rendering time of the i-th screen, and `T` represents the rendering time of the i-th screen. i end indicates the rendering end time of the i-th screen, T i start indicates the start time of rendering for the i-th screen;

[0113] Step 4-3: After the rendering frame is generated, the image result is pushed to the corresponding screen in real time via WebSocket;

[0114] Step 4-4: Monitor and aggregate the rendering time for each screen.

[0115] In this embodiment, the Babylon.js engine will render the three images separately. Each time a frame is rendered, the start and end times of the current frame are recorded, and the image is packaged and sent to the corresponding screen via WebSocket.

[0116] The backend service system also needs to listen to feedback from all screens simultaneously, and count and update the rendering time of each screen for subsequent latency assessment and synchronization control.

[0117] Step 5: The backend service system determines in real time whether there is a difference in frame latency between the three screens, and calculates the difference Δt between the frame latency of each screen and the average latency.

[0118] The difference Δt is compared with multiple preset delay thresholds, the synchronization adjustment window is divided, and the corresponding number of aligned frames or the frame reduction magnitude is calculated.

[0119] Step 5 includes the following steps:

[0120] Step 5-1: Calculate the average rendering time (Tavg) for the current frame across the three screens:

[0121] Tavg=(T1frame+T2frame+T3frame) / 3;

[0122] Step 5-2: Calculate the difference Δt between the frame latency of each screen and the average latency:

[0123] Δt=T i frame-Tavg;

[0124] Step 5-3: Classify and determine the frame synchronization status of the three screens: If the difference Δt between the three screens is less than 12ms, the current synchronization is considered normal and no synchronization adjustment state is entered; if the delay of any screen is greater than 20ms, the synchronization adjustment state is entered.

[0125] Step 5-4: Enter the synchronization adjustment state, specifically by setting three threshold windows and comparing them:

[0126] w1:12ms≤|Δt|<20ms→ΔN=5;

[0127] w2:20ms≤|Δt|<33ms→ΔN=10;

[0128] w3:|Δt|≥33ms→ΔN=15;

[0129] Where w1, w2, and w3 represent the window levels set in step 3, and ΔN represents the number of frames adjusted.

[0130] Step 6: The Babylon.js rendering engine generates the current frame image content in real time based on the viewing angle offset of each screen. The rendered content is then pushed to the corresponding screen and displayed through the backend service system.

[0131] In this embodiment, the Babylon.js rendering engine generates corresponding image content based on the viewpoint offset configuration of each screen within each frame period. The specific operation is as follows:

[0132] First, each screen is configured with an independent virtual camera. The viewing angle parameters of the virtual camera are set according to the calculated offset angle to ensure that the image rendered by each screen maintains an angle difference and conforms to the overall spatial layout.

[0133] Within each frame rendering cycle, the rendering engine renders the scene from the perspective of each virtual camera, generating the current frame image in real time.

[0134] Then, after the image is generated, the image content is packaged into a data stream of a specified format (such as a Base64 encoded image frame) and the current frame number (such as frame_id) is appended. This number remains consistent across all screens and is used as a synchronization reference.

[0135] The rendering results are then sent to the corresponding screen via WebSocket through the backend service system.

[0136] In this embodiment, to ensure frame-level synchronization of multi-screen display, a frame-level synchronization can also be achieved before pushing.

[0137] In step 5, the frame time offset of each screen is calculated and combined with the current frame number to execute a preset adjustment strategy. The preset adjustment strategies that can be used in this embodiment are as follows:

[0138] Strategy 1: Establish a short-time frame buffer in the sending queue of each screen, push the screen that triggers the w1 window level with delay according to Δt, and pre-render and cache the screen that triggers the w3 window level.

[0139] Strategy 2: The backend service system obtains the ACK messages from all screens for the previous frame N, and determines whether to push the next frame N+1 based on the ACK messages; the push of the next frame N+1 is only triggered after all screens have completed displaying frame N.

[0140] Strategy 3: After receiving an image frame, each screen displays the content and returns an ACK message to the backend service system via WebSocket. The ACK message contains the screen number and frame number. The backend service system controls the synchronization rhythm based on the ACK message.

[0141] Strategy 4: When any screen sends an ack message within the preset delay, the backend service system retransmits the current frame N or skips the current frame N and directly enters the push of the next frame N+1, and resets the cache queue. In this embodiment, the preset delay can be set to 3 consecutive frames.

[0142] This invention presents a multi-screen interactive real estate display method based on caves and LEDs, solving the technical problems of synchronous control and spatial consistency rendering of multiple independent-view LED screens in multi-frame rendering. This invention implements a three-view independent rendering mechanism among multiple screens, constructing a realistic and immersive visual effect. It also constructs a dynamic frame synchronization adjustment model based on latency thresholds to ensure stable synchronization of content across multiple screens. Furthermore, it supports real-time Pad control and status response mechanisms, improving the smoothness of user operation and visual feedback. The modular system architecture facilitates deployment and expansion, adapting to various display environments and resolution specifications.

Claims

1. A multi-screen interactive real estate display method based on cave and LED, characterized in that: Includes the following steps: Step 1: The user selects the view and operation items through the control interface on the Pad. The Pad generates an operation request, encapsulates the operation request, and sends it to the backend service system. The operation items include the operation type and the corresponding operation parameters; The operation request is specifically user operation behavior data generated by the Pad after the user interacts through the web control interface on the Pad. Different behaviors correspond to different operation items. The operation items in the operation request include switching the apartment model, rotating the angle, starting the animation, and zooming in and out; The Pad client and the backend service system establish a connection via WebSocket and communicate in real time. Step 2: The backend service system continuously listens for WebSocket connections, receives and parses operation requests sent from the Pad in real time, and generates rendering instructions based on the parsed operation item classification results; The backend service system continuously listens for WebSocket connections through Node.js services, maintains the connection session on the Pad, and listens for message events; The backend service system records the current system execution status in real time and generates a current status log; The backend service system parses the operation items and processes them by category: The operation item is to switch the apartment type model, which triggers the loading of the new model and the replacement of the scene; The operation option is rotation angle, which triggers the camera viewpoint transformation. The action option is to start an animation, which triggers the execution of a predefined animation. The operation option is zoom in / out, which triggers the adjustment of the field of view. The backend service system generates different rendering engine instructions based on the parsing results of the operation items; Step 3: The backend service system calls the Babylon.js rendering engine and executes the corresponding graphics update logic according to the operation type of the operation item in the rendering instruction; The backend service system initializes the basic viewpoint and calculates the camera rotation angle corresponding to each screen based on the fixed spatial arrangement of the three screens. The Babylon.js rendering engine binds rendering tasks to three camera views respectively; Step 4: The Babylon.js rendering engine performs split-screen rendering. The backend service system continuously receives and monitors the frame time and rendering latency of each screen, and counts the current frame rendering status of each screen. Step 5: The backend service system determines in real time whether there are differences in frame latency between the three screens, and calculates the difference between the frame latency of each screen and the average latency. ; Difference The system compares the data with multiple preset latency thresholds, divides the synchronization adjustment window, and calculates the corresponding number of aligned frames or the frame reduction magnitude. Step 6: The Babylon.js rendering engine calculates the difference between the viewing angle offset of each screen and the value obtained in Step 5. According to the difference Based on the window level and a preset synchronization strategy, the current frame image is generated in real time, and the previous frame image is pushed to the corresponding screen and displayed through the backend service system.

2. The multi-screen interactive real estate display method based on cave and LED as described in claim 1, characterized in that: Step 3 includes the following steps: Step 3-1: The backend service system calls the Babylon.js rendering engine. The Babylon.js rendering engine initializes the rendering scene based on the current state logs, and sets the initial position and orientation of the main camera according to the current model and base viewpoint in the rendering scene. Specifically, it initializes the base camera position. : ； Step 3-2: Based on the physical spatial arrangement of the three screens, set the offset angles for each, from left to right as follows: ; Step 3-3: Calculate the camera position for rendering each screen using the following formula. : ； ； in, Let be the rotation matrix of the vector about the y-axis. The offset angle; i represents the screen number, with the left screen being 1, the middle screen 2, and the right screen 3 by default; This represents the offset angle of the i-th screen. Steps 3-4: Bind a corresponding independent camera object to each screen, and write its view parameters into the Babylon.js rendering engine; the view parameters include the camera's position and rotation angle.

3. The multi-screen interactive real estate display method based on cave and LED as described in claim 1, characterized in that: Step 4 includes the following steps: Step 4-1: The Babylon.js rendering engine renders the current frame image based on the camera offset angle of each screen. Step 4-2: After each rendering is completed, record the start and end timestamps, and calculate the rendering time of the current frame: ； in, This represents the rendering time of the i-th screen. This indicates the rendering end time of the i-th screen. Indicates the start time of rendering for the i-th screen; Step 4-3: After the rendering frame is generated, the image result is pushed to the corresponding screen in real time via WebSocket; Step 4-4: Monitor and aggregate the rendering time for each screen.

4. The multi-screen interactive real estate display method based on cave and LED as described in claim 3, characterized in that: Step 5 includes the following steps: Step 5-1: Take the average rendering time of the current frame for the three screens. calculate: ； Step 5-2: Calculate the difference between the frame latency of each screen and the average latency. : ； Step 5-3: Classify and determine the frame synchronization status of the three screens: If the difference between the three screens is... If the delay is less than 12ms, the current synchronization is considered normal and the synchronization adjustment state is not entered; if the delay of any screen is greater than 20ms, the synchronization adjustment state is entered. Step 5-4: Enter the synchronization adjustment state, specifically by setting three threshold windows and comparing them: ； ； ； in, These represent the window levels set in step 3. Indicates the number of frames adjusted.

5. The multi-screen interactive real estate display method based on cave and LED as described in claim 4, characterized in that: When performing step 6, the difference between each screen obtained in step 5 is used. According to the difference The window level is assigned a preset adjustment strategy to achieve frame-level synchronization during multi-screen display. The preset adjustment strategy includes: Strategy 1: Establish a short-time frame buffer in the transmission queue of each screen, based on... Trigger Window-level screen delay push, for triggering Window-level screens are pre-rendered and cached; Strategy 2: The backend service system obtains the ACK messages from all screens for the previous frame N, and determines whether to push the next frame N+1 based on the ACK messages; the push of the next frame N+1 is only triggered after all screens have completed displaying frame N. Strategy 3: After receiving an image frame, each screen displays the content and returns an acknowledgment message (ack) to the backend service system via WebSocket. The acknowledgment message ack contains the screen number and frame number. The backend service system controls the synchronization rhythm based on the message ack. Strategy 4: When any screen sends an ack message within the preset delay, the backend service system retransmits the current frame N or skips the current frame N and directly enters the push of the next frame N+1, and resets the cache queue.

Images