Monitoring interface rendering method, device and computer program product

Abstract

This application discloses a method, device, and computer program product for rendering a monitoring interface, relating to the field of interface rendering technology. The method includes: acquiring spatiotemporal data to be rendered from each monitored device; constructing a device rendering buffer pool based on the spatiotemporal data to be rendered, and determining the device rendering weight of each monitored device; acquiring the system idle time of the monitoring system, which is used to monitor the monitored devices; determining the target rendering device among the monitored devices based on the system idle time and the device rendering weight; acquiring the spatiotemporal data to be rendered from the target rendering buffer pool as the target rendering data, and rendering the monitoring interface of the monitoring system based on the target rendering data. This application temporarily stores the spatiotemporal data to be rendered in the device rendering buffer pool, and adaptively filters the rendering data with more urgent rendering needs based on two dimensions: system idle time and device rendering weight, thereby avoiding problems such as interface freezing and system unresponsiveness.

Description

Technical Field

[0001] This application relates to the field of interface rendering technology, and in particular to monitoring interface rendering methods, devices and computer program products. Background Technology

[0002] With the rapid development of computer graphics rendering technology and low-altitude aircraft technology, interface rendering technology for monitoring low-altitude aircraft has become a core supporting technology in the fields of low-altitude traffic supervision and aircraft operation management. Currently, various low-altitude aircraft, such as drones and electric vertical takeoff and landing (eVTOL) aircraft, are being used on a large scale and in densely populated basis, covering multiple fields including urban logistics, emergency rescue, aerial commuting, and patrol mapping. Against this backdrop, enterprise operation management platforms and government regulatory agencies' low-altitude monitoring systems need to implement comprehensive, real-time, and precise visual monitoring of massive numbers of low-altitude aircraft to ensure low-altitude flight order, avoid flight conflicts, and enable emergency response.

[0003] However, as the number of aircraft increases, the concurrency of aircraft data rises exponentially. During rendering, issues such as interface freezes and system unresponsiveness can easily occur. Therefore, monitoring systems with high data concurrency are prone to technical problems such as interface freezes and system unresponsiveness.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method for rendering a monitoring interface, which aims to solve the technical problem that monitoring systems with high data concurrency are prone to interface freezing and system unresponsiveness.

[0006] To achieve the above objectives, this application proposes a monitoring interface rendering method, which includes: Obtain the spatiotemporal data to be rendered for each monitored device; Based on the spatiotemporal data to be rendered, a device rendering buffer pool is constructed, and the device rendering weight of each monitored device is determined. The system idle time of the monitoring system is obtained, and the monitoring system is used to monitor the monitored equipment. Based on the system idle time and the device rendering weight, the target rendering device is determined among the monitored devices; The target rendering device's spatiotemporal data to be rendered is obtained from the device's rendering buffer pool as target rendering data, and the monitoring interface of the monitoring system is rendered based on the target rendering data.

[0007] In one feasible implementation, the step of determining the device rendering weight of each of the monitored devices includes: Based on the device speed, alarm level, and buffer pool dwell time of each of the spatiotemporal data to be rendered, the device rendering weight of each of the monitored devices is calculated. The faster the device speed, the longer the dwell time, and the higher the alarm level of the spatiotemporal data to be rendered, the greater the device rendering weight of the monitored device corresponding to the spatiotemporal data to be rendered.

[0008] In one feasible implementation, the step of obtaining the target rendering device among the monitored devices based on the system idle time and the device rendering weight includes: The amount of rendering data is calculated based on the system idle level, wherein the greater the system idle level, the greater the amount of rendering data. Based on the amount of rendering data and the device rendering weight, the target rendering device is determined. The larger the device rendering weight of the monitored device, the greater the probability that it will be determined as the target rendering device. The total amount of spatiotemporal data to be rendered by the target rendering device does not exceed the amount of target rendering data.

[0009] In one feasible implementation, the monitoring interface rendering method further includes: Among the monitored devices, the data devices to be merged are obtained, wherein the smaller the device rendering weight of the monitored device, the greater the possibility that it is a data device to be merged; Obtain the spatiotemporal data to be rendered from the device to be merged as the data to be merged; The latest spatiotemporal state data in the data to be merged is used to overwrite the spatiotemporal data to be rendered of the data device to be merged, so as to perform overwrite merging of the spatiotemporal data to be rendered of the data device to be merged.

[0010] In one feasible implementation, the step of acquiring the data device to be merged from the monitored device includes: Obtain the overall data generation rate and overall data consumption rate of each of the spatiotemporal data to be rendered; Determine whether the overall data generation rate is greater than the overall data consumption rate; If the overall data generation rate is greater than the overall data consumption rate, then the step of obtaining the data to be merged from the monitored devices is executed.

[0011] In one feasible implementation, the step of obtaining the spatiotemporal data to be rendered for the target rendering device from the device rendering buffer pool as the target rendering data includes: Obtain the rendering smoothing value of each rendering frame in the spatiotemporal data to be rendered; When the rendering smoothing value is less than the preset smoothing threshold, the rendering frame is padded. The spatiotemporal data to be rendered after frame interpolation is used as the target rendering data.

[0012] In one feasible implementation, the step of obtaining the rendering smoothing value of each rendering frame in the spatiotemporal data to be rendered includes: Calculate the rendering time difference based on the timestamp of each rendering frame and the timestamp of the previous rendering frame; Based on the rendering time difference, the rendering smoothing value of the rendering frame is calculated, wherein the larger the rendering time difference, the smaller the rendering smoothing value of the rendering frame.

[0013] In one feasible implementation, the monitoring system includes a DOM layer and a WebGL layer, and the monitoring interface rendering method includes: Obtain the frame rate per second and memory usage of the monitoring system; The system health of the monitoring system is calculated based on the frame rate per second and the memory usage rate, wherein the higher the frame rate per second and the lower the memory usage rate, the higher the system health. Based on the system health status, the rendering strategies for the DOM layer and the WebGL layer are set.

[0014] Furthermore, to achieve the above objectives, this application also proposes a monitoring interface rendering device, which includes: Acquisition module: Used to acquire the spatiotemporal data to be rendered from each monitored device; Construction module: used to construct a device rendering buffer pool based on the spatiotemporal data to be rendered, and to determine the device rendering weight of each of the monitored devices; The acquisition module is also used to acquire the system idle rate of the monitoring system, which is used to monitor the monitored device. The determination module is used to determine the target rendering device among the monitored devices based on the system idle time and the device rendering weight; The rendering module is used to obtain the spatiotemporal data to be rendered of the target rendering device from the device rendering buffer pool as the target rendering data, and to render the monitoring interface of the monitoring system based on the target rendering data.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the monitoring interface rendering method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the monitoring interface rendering method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the monitoring interface rendering method described above.

[0018] This application proposes a method for rendering a monitoring interface. First, it acquires the spatiotemporal data to be rendered from each monitored device. Then, based on this spatiotemporal data, it constructs a device rendering buffer pool and determines the device rendering weight for each monitored device. The device rendering buffer pool temporarily stores the spatiotemporal data to be rendered that has not yet been rendered onto the monitoring interface. Next, it acquires the system idle time of the monitoring system used to monitor the monitored devices. Based on the system idle time and the device rendering weight, it identifies a target rendering device among the monitored devices and retrieves the spatiotemporal data to be rendered from the device rendering buffer pool as the target rendering data. This method maximizes the utilization of system resources by considering both system idle time and device rendering weight, while simultaneously filtering out the rendering data that most urgently needs to be rendered onto the monitoring interface. Finally, it renders the monitoring interface of the monitoring system based on the target rendering data.

[0019] In this application, after the spatiotemporal data to be rendered by the monitored device is generated, it is not rendered directly on the monitoring interface. Instead, it is temporarily stored in the device rendering buffer pool. Then, based on two dimensions, system idle time and device rendering weight, the rendering data with more urgent rendering needs is adaptively selected. This achieves the maximum utilization of system resources while selecting the most urgent rendering data to be rendered on the monitoring interface, ensuring system stability and rendering effect. It avoids the monitoring system directly rendering massive amounts of data, thereby avoiding the problems of interface freezing and system unresponsiveness. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1This is a first flowchart illustrating the monitoring interface rendering method provided in an embodiment of this application. Figure 2 This is a second flowchart illustrating the monitoring interface rendering method provided in the embodiments of this application; Figure 3 A schematic diagram of the third process of the monitoring interface rendering method provided in the embodiments of this application; Figure 4 This is a schematic diagram of the module structure of the monitoring interface rendering device according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the monitoring interface rendering method in this application embodiment.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] With the rapid development of the low-altitude economy, the large-scale application of low-altitude aircraft such as drones and electric vertical take-off and landing (eVTOL) aircraft is becoming increasingly widespread. In the intranet monitoring systems of low-altitude command and control centers of enterprises and regulatory agencies, it is often necessary to access and display massive amounts of spatial location, telemetry status, and alarm data of aircraft in real time. However, existing monitoring interface rendering methods suffer from problems such as easy blocking of the front-end rendering main thread and a lack of concurrency anti-jump mechanisms. This causes the massive, high-frequency status data concurrently transmitted from low-altitude aircraft to trigger extremely frequent browser repaints and reflows. If the view update is driven directly at the actual frequency, it will lead to severe blocking of the front-end main thread and a frozen interface. This manifests as the monitoring system not only being unable to respond to operations, but also as the aircraft trajectory exhibiting severe "jumping" and "flickering" visual jitters.

[0027] This application proposes a method for rendering a monitoring interface. First, it acquires the spatiotemporal data to be rendered from each monitored device. Then, based on this spatiotemporal data, it constructs a device rendering buffer pool and determines the device rendering weight for each monitored device. The device rendering buffer pool temporarily stores the spatiotemporal data to be rendered that has not yet been rendered onto the monitoring interface. Next, it acquires the system idle time of the monitoring system used to monitor the monitored devices. Based on the system idle time and the device rendering weight, it identifies a target rendering device among the monitored devices and retrieves the spatiotemporal data to be rendered from the device rendering buffer pool as the target rendering data. This method maximizes the utilization of system resources by considering both system idle time and device rendering weight, while simultaneously filtering out the rendering data that most urgently needs to be rendered onto the monitoring interface. Finally, it renders the monitoring interface of the monitoring system based on the target rendering data.

[0028] In this application, after the spatiotemporal data to be rendered by the monitored device is generated, it is not rendered directly on the monitoring interface. Instead, it is temporarily stored in the device rendering buffer pool. Then, based on two dimensions, system idle time and device rendering weight, the rendering data with more urgent rendering needs is selected. This achieves adaptive selection of the most urgent rendering data to be rendered on the monitoring interface while making the maximum use of system resources. This ensures system stability and rendering effect, and avoids the monitoring system directly rendering massive amounts of data, thereby avoiding the problems of interface freezing and system unresponsiveness.

[0029] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of realizing the above functions.

[0030] Reference Figure 1 , Figure 1 This paper illustrates a first flowchart of a monitoring interface rendering method provided in an embodiment of this application. In this embodiment, the monitoring interface rendering method includes steps S1 to S5: It should be noted that the monitoring interface rendering method of this embodiment is applicable to all intranet monitoring systems with high-frequency spatial data concurrency characteristics, such as UAV monitoring systems, vehicle-to-everything (V2X) monitoring systems, and smart factory monitoring systems. In the UAV monitoring system, the monitored device is the aircraft; in the autonomous vehicle fleet monitoring system, the monitored device is the vehicle in the autonomous vehicle fleet; and in the smart factory monitoring system, the monitored device is the IoT device in the massive IoT sensor topology diagram. The following uses a UAV monitoring system as an example to illustrate this embodiment and the subsequent embodiments.

[0031] Step S1: Obtain the spatiotemporal data to be rendered for each monitored device; It should be noted that the spatiotemporal data to be rendered refers to the multi-dimensional monitoring data reported in real time by the monitored equipment, which includes time attributes, spatial location, telemetry status, and alarm data. It is the core data source for the monitoring interface to draw equipment locations, trajectories, and status labels. Taking the monitoring of low-altitude economic drones as an example, the monitored equipment is the aircraft, and the spatiotemporal data to be rendered is the aircraft's telemetry data. Each piece of telemetry data contains the aircraft's identification code, latitude and longitude, altitude, equipment speed, heading angle, timestamp, and alarm level at the current time.

[0032] Additionally, it should be noted that the monitoring system can establish a WebSocket long connection at the front end to communicate with the internal network data server, continuously receiving real-time telemetry data from the aircraft, ensuring low latency and continuity of data transmission, while also supporting batch reception of concurrent data from multiple devices, adapting to scenarios with massive concurrent reporting from devices.

[0033] Step S2: Based on the spatiotemporal data to be rendered, construct a device rendering buffer pool and determine the device rendering weight of each monitored device; It should be noted that the device rendering buffer pool is a temporary data cache queue established in the monitoring system. It is used to temporarily store the received spatiotemporal data to be rendered, preventing high-frequency data from directly flooding the rendering thread and causing blockage. Its core function is peak shaving and valley filling, that is, to perform ordered caching and frame synchronization scheduling of concurrent data to prevent data loss, duplicate rendering, or screen flickering. At the same time, it supports classified storage by device identification code and historical data backtracking, providing a data carrier for rendering priority scheduling.

[0034] As an example, the monitoring system maintains a device rendering buffer pool in memory. This buffer pool is a hash map structure with the aircraft identification code as the key and a time series array as the value, used to temporarily store native high-frequency data points that have not yet been rendered to the screen.

[0035] As another example, the device rendering buffer is not a simple queue, but a key-value map with a spatiotemporal index. Its internal data structure typically contains the following three layers of information: 1. Unique identifier (Key): Aircraft ID (e.g., drone_id_001); 2. State snapshot (Value / Payload): Telemetry data of the current target, including latitude and longitude, altitude, speed, heading angle, battery level, alarm status, etc.; 3. Spatiotemporal weight metadata: Timestamp (T): the time the data arrived, dynamic weight (W): a value calculated in real time based on "aircraft speed" and "alarm level". For example, a drone diving at high speed has a weight of 0.9, while a hovering aerial photography drone has a weight of 0.2. It is understood that the device rendering buffer in this embodiment is not just a simple cache queue, but a non-linear, searchable, and modifiable state space. The device buffer stores the "latest physical world model to be rendered," rather than simply "messages to be processed."

[0036] Additionally, it's important to note that device rendering weight is a quantifiable value representing the rendering priority of the monitored device. The higher the device rendering weight of a monitored device, the higher the priority the monitoring interface will have in rendering the spatiotemporal data of that monitored device. Its purpose is to ensure that critical devices are displayed first, avoid a large number of low-priority devices occupying rendering resources, and ensure that the status of alarm devices, core devices, and devices of key concern is displayed first, balancing rendering efficiency and monitoring effectiveness.

[0037] Additionally, it should be noted that device rendering weights can be determined in several ways. For example, the device rendering weight of the monitored device can be determined based on the alarm level, i.e., the higher the alarm level, the higher the device rendering weight (e.g., emergency alarm > important alarm > general alarm > normal state), prioritizing the rendering of devices with alarms such as faults, anomalies, and boundary violations; the device rendering weight can be determined based on the importance level of the monitored device, i.e., core devices (such as the main aircraft) have a higher weight than ordinary devices, and are assigned values ​​according to the preset device level; the device rendering weight can be determined based on spatial focus, i.e., devices located in the center of the monitoring field of view or in the user's zoom-in viewing area have a higher weight than devices at the edge of the field of view, improving the smoothness of rendering in the focused area; the device rendering weight can be determined based on the data update frequency, i.e., devices that move frequently and report frequently (such as high-speed drones) have a higher weight than static devices, ensuring the real-time trajectory of dynamic devices; the device rendering weight can be determined based on the timestamp freshness, i.e., the device rendering weight corresponding to the most recently reported data is higher, prioritizing the rendering of real-time data and avoiding interference from expired data.

[0038] In one feasible implementation, step S2: determining the device rendering weight of each of the monitored devices includes: Based on the device speed, alarm level, and buffer pool dwell time of each of the spatiotemporal data to be rendered, the device rendering weight of each of the monitored devices is calculated. The faster the device speed, the longer the dwell time, and the higher the alarm level of the spatiotemporal data to be rendered, the greater the device rendering weight of the monitored device corresponding to the spatiotemporal data to be rendered.

[0039] It should be noted that device speed refers to the real-time movement rate of each monitored device, used to characterize the degree of dynamic change of the device. The faster the monitored device moves, the more frequently its geographical location and operating posture change. If the rendering is not timely, problems such as screen offset and trajectory disconnection are very likely to occur. Alarm level is a level classification standard preset by the system according to the abnormality type and danger level of the monitored device. It can be divided into emergency alarm, important alarm, general alarm, and normal state, with decreasing levels. It directly reflects the safety risk level of the monitored device's operation failure, violation of boundaries, signal abnormality, etc., and is a core indicator that the monitoring system focuses on. Buffer pool dwell time is the timestamp of the earliest piece of spatiotemporal data to be rendered by the monitored device stored in the device rendering buffer pool. It is the dwell time that has not been scheduled for rendering up to the current moment. It can objectively reflect the backlog of spatiotemporal data to be rendered for a single monitored device and the rendering scheduling delay under high concurrency scenarios. This embodiment selects three types of parameters—device speed, alarm level, and buffer pool dwell time—to jointly construct device rendering weight, in order to solve the problem that a single-dimensional device rendering weight cannot adapt to complex scenarios of high-frequency concurrency, mixed dynamic and static data, and multi-device collaborative monitoring. Among them, device speed focuses on the device's motion attributes, solving the problem of rendering lag for dynamic targets; alarm level focuses on business security attributes, aligning with the core requirements of monitoring and early warning; and buffer pool dwell time focuses on system scheduling attributes, balancing front-end rendering load and data processing pressure. These three types of parameters constrain and complement each other, enabling refined and dynamic adjustment of rendering priority. It is worth noting that the difference between dynamic weight and device rendering weight lies in the fact that dynamic weight is based on two parameters: device speed and alarm level. Device rendering weight, on the other hand, adds a third parameter—buffer pool dwell time—to the dynamic weight. This is because buffer pool dwell time changes constantly; calculating it only when using device rendering weight reduces computational load and saves system resources.

[0040] As an example, each aircraft in the device rendering buffer pool is traversed, and the device rendering weight of each aircraft is calculated, where the device rendering weight is... The formula is as follows:

[0041] in, This refers to the spatial displacement velocity in the latest telemetry data; The alarm status is a Boolean value (0 or 1, indicating whether the system is in a dangerous state such as yaw). This refers to the time the aircraft remained in the buffer pool. , , These are the weighting coefficients preset by the system.

[0042] Additionally, it should be noted that the parameters in the device rendering weight formula can be expanded, for example, by adding a spatial density factor (how many aircraft are clustered in a small area), which further reduces the update priority for overlapping rendering caused by regional clustering.

[0043] Step S3: Obtain the system idle time of the monitoring system, which is used to monitor the monitored devices; It should be noted that the monitoring system can be a drone monitoring system, a vehicle-to-everything (V2X) monitoring system, a smart factory monitoring system, etc. System idle time is a quantitative indicator used to characterize the resource availability of the main thread of the monitoring system's front-end and the level of rendering load pressure. It can intuitively reflect the remaining usable space of the system's CPU (Central Processing Unit), GPU (Graphics Processing Unit), and thread scheduling resources. A higher system idle time indicates a lower main thread task load and more available rendering resources, enabling the system to handle more synchronous rendering tasks of device data. A lower system idle time indicates main thread congestion and severe task backlog, requiring compression of rendering tasks and reduction of concurrent rendering frequency to avoid problems such as interface lag, freezes, and frame drops.

[0044] As an example, the steps to obtain the system idle time of a monitoring system include: obtaining the available time slice of the main thread; and calculating the system idle time based on the available time slice. Specifically, the method for obtaining the available time slice of the main thread is as follows: Utilizing the browser's underlying native scheduling interface `requestIdleCallback(deadline)`, the remaining idle time within the current frame period is actively captured. The remaining idle time of a single frame can be accurately read by calling the `deadline.timeRemaining()` method. This remaining time is used as the available time slice of the main thread, providing a basis for the subsequent quantitative calculation of the system idle time.

[0045] Step S4: Based on the system idle time and the device rendering weight, determine the target rendering device among the monitored devices; Understandably, this step combines the hardware load status of the monitoring system with the priority of the monitored devices to dynamically select the target rendering devices that are allowed to be rendered in the current frame. This avoids resource overload caused by uniform full rendering, achieves dynamic matching between rendering tasks and system performance, prioritizes the visualization of key devices under limited thread resources, and balances interface smoothness with the effectiveness of monitoring services.

[0046] In a feasible implementation, step S4: determining the target rendering device among the monitored devices based on the system idle time and the device rendering weight includes steps S41-S42: Step S41: Calculate the amount of rendering data based on the system idle time, wherein the greater the system idle time, the greater the amount of rendering data; It should be noted that the amount of rendering data refers to the maximum number of rendering tasks that the system's main thread and graphics rendering thread can handle within the current rendering frame cycle. Specifically, it can be represented by the total data scale of the number of device points, trajectory points, status labels, and topology elements that can be drawn synchronously. The higher the system idle time, the more abundant the remaining computing power resources of the main thread, and the larger the amount of rendering data that can be handled; conversely, the lower the system idle time, the more severe the thread load congestion, and the more necessary it is to strictly limit the amount of rendering data and reduce unnecessary rendering tasks.

[0047] Step S42: Based on the amount of rendering data and the device rendering weight, determine the target rendering device, wherein the larger the device rendering weight of the monitored device, the greater the probability of it being determined as the target rendering device, and the total amount of spatiotemporal data to be rendered by the target rendering device does not exceed the amount of target rendering data.

[0048] As an example, the `timeRemaining()` function is used to obtain the idle time of a single frame for threshold determination. If the idle time is greater than 10ms, it indicates that the main thread has sufficient resources and a low load. In this case, the amount of rendering data is increased, and the points, trajectory points, and status information of all monitored devices in the device rendering buffer pool are uniformly generated into standardized rendering instructions to achieve full synchronous rendering. If the idle time is less than 5ms, it indicates that the main thread is congested and the computing power is extremely strained. The monitoring system automatically performs adaptive truncation and load reduction. Specifically, all monitored devices are sorted in descending order according to their rendering weight. High-speed moving, high alarm level, and data backlog target rendering devices are selected first. The spatiotemporal data to be rendered by the target rendering devices are integrated and converted into batch rendering instruction packages for priority rendering. For low-priority devices that are running slowly, hovering, or without alarms or abnormalities, the generation of rendering instructions for the current frame is directly abandoned. Their spatiotemporal data to be rendered is temporarily retained and accumulated in the device rendering buffer pool, and rendering scheduling is postponed. This allows limited CPU and GPU computing resources to be reasonably allocated to high-risk abnormal devices and highly dynamic mobile devices.

[0049] In this embodiment, by dynamically calculating the amount of rendering data that can be carried by combining system idle time and linking device rendering weight to select target rendering devices, adaptive matching between rendering tasks and system load is achieved. When system resources are sufficient, the rendering range is expanded to ensure the complete display of global device screens. When main thread resources are scarce, low-priority rendering tasks are automatically truncated to prioritize the real-time rendering of key devices with high-speed movement and high alarm levels. At the same time, low-weight device data is temporarily stored in a buffer pool for delayed rendering. This effectively reduces the rendering pressure of a single frame, alleviates the main thread blocking and interface lag and frame drop problems, avoids the loss of monitoring data, reasonably balances the allocation of CPU and GPU computing power, and enhances the visualization and early warning capabilities of high-risk abnormal targets. This adapts to high-frequency concurrent and multi-device mixed monitoring scenarios such as drones, vehicle networks, and smart factories, and comprehensively improves the rendering smoothness of the monitoring interface, the rationality of scheduling, and the overall operational stability of the system.

[0050] Step S5: Obtain the spatiotemporal data to be rendered from the target rendering device in the device rendering buffer pool as the target rendering data, and render the monitoring interface of the monitoring system based on the target rendering data.

[0051] In a feasible embodiment, step S5: obtaining the spatiotemporal data to be rendered from the target rendering device as target rendering data from the device rendering buffer pool, and rendering the monitoring interface of the monitoring system based on the target rendering data includes steps S51~S53: Step S51: Obtain the rendering smoothing value of each rendering frame in the spatiotemporal data to be rendered; It should be noted that a rendering frame is an independent image unit generated by a single screen refresh of the monitoring interface. It is the basic rendering unit for continuous rendering of the front-end interface, updating of device positions, and display of motion trajectories. By playing multiple sets of rendering frames in sequence, a visual image of the dynamic movement of the monitored device can be formed. The rendering smoothness value is a quantitative adjustment parameter used to control the transition effect of device position movement and trajectory rendering. It is used to characterize the smoothness of the transition and the interpolation compensation strength of the current frame image rendering. The higher the rendering smoothness value, the more continuous and smooth the transition effect of device position offset and posture change, which can effectively reduce the problems of screen jitter and position jump.

[0052] As an example, the spatial coordinate offset, heading angle change, and position change amplitude of the device between adjacent rendering frames are used as the calculation basis. The rendering smoothing value is dynamically assigned according to the actual spatial motion change of the device. The smaller the spatial displacement of the device and the more stable the motion posture, the higher the rendering smoothing value. When the device position jumps sharply or the posture changes abruptly, the smoothing value is reduced. This is suitable for static or low-speed monitoring objects such as factory IoT sensors and fixed-point monitoring equipment with slow movement and unstable data reporting frequency.

[0053] As another example, the time dimension constraint is imposed by combining the timestamp difference between the rendering frames before and after, while extracting the spatial position deviations of the device, such as latitude, longitude, coordinate position, and height, between adjacent frames. The final rendering smoothness value is obtained by combining the change amplitude of time interval and the change amplitude of spatial displacement. This approach takes into account both the temporal stability of the frame refresh rhythm and the constraints on the sudden changes in the image caused by device spatial jumps. It is suitable for dynamic monitoring equipment such as drones and autonomous vehicles that move at high speeds and jump over large areas of space.

[0054] In a feasible embodiment, step S51: obtaining the rendering smoothing value of each rendering frame in the spatiotemporal data to be rendered includes steps S511~S512: Step S511: Calculate the rendering time difference based on the timestamp of each rendering frame and the timestamp of the previous rendering frame; For example, the current rendering frame timestamp is 256ms, the previous rendering frame timestamp is 160ms, and the rendering time difference between the two frames is 96ms.

[0055] Step S512: Calculate the rendering smoothing value of the rendering frame based on the rendering time difference, wherein the larger the rendering time difference, the smaller the rendering smoothing value of the rendering frame.

[0056] Understandably, monitoring systems are prone to unstable frame refresh intervals and fluctuating data reporting intervals under high-concurrency data surges and main thread load fluctuations, making it difficult for fixed smoothing parameters to adapt to dynamic frame interval changes. This embodiment calculates the rendering time difference based on the timestamps of preceding and following frames, and then reverse-maps it to generate differentiated rendering smoothing values. This allows for adaptive adjustment of the image interpolation compensation strategy according to the frame refresh rhythm, adapting to rendering scenarios with irregular frame intervals.

[0057] In this embodiment, the rendering time difference is calculated in real time based on the timestamps of the preceding and following rendering frames, and the corresponding rendering smoothing value is dynamically matched, which facilitates the adaptive adjustment of the screen transition compensation intensity according to the fluctuation of the frame refresh interval.

[0058] Step S52: When the rendering smoothing value is less than the preset smoothing threshold, perform frame interpolation on the rendering frame; It should be noted that the preset smoothing threshold is a pre-defined critical judgment standard used to delineate the boundary between smooth rendering and stuttering. It is used to determine whether the transition effect of the current frame meets the standard, thereby triggering the corresponding frame interpolation optimization logic. For example, the preset smoothing threshold can be set to 50ms. When the calculated rendering smoothing value is less than this threshold, it means that the frame interval is too large, the screen refresh lag is serious, and the device position is prone to cliff jumps and trajectory breaks, requiring active frame interpolation optimization.

[0059] Additionally, it should be noted that frame interpolation refers to the process of generating multiple sets of transitional intermediate frames between two consecutive frames of real-time spatiotemporal data using algorithms. This fills in the gaps in the image caused by excessive frame intervals, mitigates point jumps and trajectory discontinuities, and optimizes the continuous transition of the device's motion image. Various lightweight and highly adaptable algorithms can be used for frame interpolation, including: Hermite curve interpolation for smooth trajectory transitions; the introduction of Kalman filtering algorithms for front-end state prediction and smoothing correction of device position, speed, and heading, adapting to trajectory prediction of highly dynamic motion devices; and the use of simplified Bezier curve fitting for rapid interpolation calculations, effectively reducing front-end CPU and GPU computational overhead and adapting to low-to-medium performance monitoring terminals.

[0060] Step S53: Use the spatiotemporal data to be rendered after frame interpolation as the target rendering data.

[0061] As an example, during the process of extracting rendering execution instructions in the WebGL rendering engine, the time difference between the current rendering frame time and the actual rendering time of the previous frame is calculated in real time. When the frame interval exceeds the preset smoothing threshold and the rendering smoothness value does not meet the smoothness requirements, the velocity vector and heading angle parameters of the previous real data point are extracted, and the built-in Hermite curve interpolation algorithm is called to dynamically solve the intermediate transition points of position and posture in the WebGL underlying rendering layer, automatically interpolating multiple intermediate transition frames to generate a continuous and smooth tweened animation trajectory. In this way, without relying on high-frequency data push from the backend, the front-end algorithm can autonomously interpolate frames to fix the screen stuttering problem, ensuring that the point movement, heading change, and trajectory display of high-speed moving targets such as drones and autonomous vehicles are continuous and smooth.

[0062] In this embodiment, a preset smoothing threshold is set as the judgment criterion. For abnormal rendering frames with excessively large frame intervals and delayed screen refresh, frame interpolation is automatically triggered. This can intelligently fill in the screen blanks and trajectory gaps caused by excessively large frame intervals without increasing the pressure on backend data push or excessively consuming the computing power of frontend hardware. By using the spatiotemporal data optimized by frame interpolation as the final target rendering data and relying on the WebGL engine to achieve efficient underlying rendering, it effectively improves problems such as device position jumps, screen jitter, trajectory tearing, and ghosting distortion caused by frame rate fluctuations, uneven data transmission and reception, and main thread load fluctuations. It balances rendering smoothness, position display accuracy, and system load, significantly improving the continuity and visual consistency of dynamic display of various types of monitoring devices. This ensures that the interface rendering effect of various monitoring objects such as drones, autonomous vehicles, and factory IoT sensors is stable and reliable in high-concurrency, high-load, and complex scenarios.

[0063] To further address the issue of UI freezing and system unresponsiveness caused by rendering massive amounts of data, some rendering methods have proposed data discarding strategies. However, existing data discarding strategies are prone to trajectory distortion. This is because existing front-end throttling techniques simply discard data packets at fixed time windows. This coarse data discarding can cause discontinuities in the high-speed movement trajectory of the drone, making it impossible to smoothly reproduce the true physical motion state on the front end.

[0064] Based on this, refer to Figure 2 , Figure 2 This illustration shows a second flowchart of the monitoring interface rendering method provided in this application embodiment. Content that is the same as or similar to the above description in the following description can be referred to the above introduction and will not be repeated hereafter. In this embodiment, the monitoring interface rendering method further includes steps S01~S05: Step S01: Obtain the overall data generation rate and overall data consumption rate of each of the spatiotemporal data to be rendered; It should be noted that the overall data generation rate is the total amount of data or the total number of messages continuously reported and generated by all monitored devices per unit time, representing the speed at which data is generated at the moment of rendering; the overall data consumption rate is the total amount of data or the total number of messages parsed, processed, and rendered by the monitoring system per unit time, representing the data processing consumption speed of the monitoring system's rendering link. The overall data generation rate can be calculated by statistically analyzing the total amount of data reported by all monitored devices within a fixed time window, and simultaneously calculating the total amount of data successfully parsed and rendered by the monitoring system within the same time window, thus obtaining the overall data consumption rate.

[0065] Step S02: Determine whether the overall data generation rate is greater than the overall data consumption rate; Understandably, by comparing the rate magnitudes, it is possible to identify whether the monitoring system is experiencing overload or data accumulation and congestion due to data production exceeding rendering processing.

[0066] Step S03: If the overall data generation rate is greater than the overall data consumption rate, obtain the data device to be merged from the monitored devices, wherein the smaller the device rendering weight of the monitored device, the greater the possibility of it being the data device to be merged. It should be noted that the data devices to be merged refer to the monitored target devices with low rendering weight and low monitoring priority (such as slow movement, fixed-point hovering, and non-key focus), and are candidate devices for triggering data overlay merging and data simplification rendering.

[0067] In this embodiment, by filtering the data devices to be merged based on the device rendering weight, low-priority and non-key monitoring devices are prioritized for inclusion in the data merging scope. This enables complete and high-precision rendering of key devices and reasonable data simplification of low-weight devices, effectively balancing the integrity of the overall monitoring screen with the monitoring reliability of core targets, avoiding mindless packet loss, and achieving frame-level anti-shake based on physical spatiotemporal characteristics.

[0068] Step S04: Obtain the spatiotemporal data to be rendered from the data device to be merged as the data to be merged; It is understandable that the full amount of spatiotemporal data to be rendered, which is queued in the device rendering pool of the data device to be merged, is extracted as the processing object for subsequent overlay merging.

[0069] Step S05: Use the latest spatiotemporal state data in the data to be merged to overwrite the spatiotemporal data to be rendered of the data device to be merged, so as to overwrite and merge the spatiotemporal data to be rendered of the data device to be merged.

[0070] It should be noted that the latest spatiotemporal status data refers to the latest reported spatiotemporal dimension status information of the same aircraft, including its position coordinates, operating attitude, speed, and timestamp.

[0071] As an example, for low-priority, hovering, or slow-moving devices to be monitored, the latest spatiotemporal data to be rendered is directly used to overwrite and replace the old historical spatiotemporal data to be rendered in the device rendering buffer pool, discarding the redundant old data in the middle, and only retaining the latest state for interface rendering.

[0072] Additionally, it should be noted that the coverage merging trigger is not based on a fixed period, but rather constructs a production-consumption balance feedback loop. When the rate of the production side (sensor high-frequency data) far exceeds that of the consumption side (monitoring system rendering capability), the device rendering weight is used as a throttling valve to trigger the merging operation in real time at the two nodes of data storage (i.e., triggering once when entering the buffer pool) and retrieval (i.e., triggering once when leaving the buffer pool), thereby achieving anti-vibration operation of the intranet interface under extreme pressure environment.

[0073] As an example, spatiotemporal data to be rendered can be merged in situ within the device rendering buffer. The specific process includes: when new spatiotemporal data arrives, the scheduler first checks if the device rendering buffer already contains unconsumed data for the monitored device corresponding to the new spatiotemporal data; if it exists, and if the monitored device is a high-weight target, the new spatiotemporal data is directly appended to the device rendering buffer, preserving trajectory details without triggering merging; if the monitored device is a low-weight device, the coordinates and state of the new spatiotemporal data are directly overwritten with the old spatiotemporal data, but the timestamp is updated. It can be understood that through the above process, dynamic compression of the device rendering buffer can be achieved. When the main thread "harvests" the spatiotemporal data to be rendered from the device rendering buffer, it receives a merged "final state snapshot."

[0074] In this embodiment, by using the latest spatiotemporal data to be rendered to cover and merge the old spatiotemporal data to be rendered on the same device, redundant historical data in the device rendering buffer pool can be effectively eliminated, significantly reducing the amount of data parsing, caching and rendering calculations in the monitoring system. This alleviates the congestion, screen stuttering and update delays caused by the data generation rate being greater than the consumption rate, improves the overall rendering smoothness and real-time status update of the monitoring interface, and saves system storage and computing resources.

[0075] Reference Figure 3 , Figure 3 This illustration shows a third flowchart of the monitoring interface rendering method provided in an embodiment of this application. In this embodiment, the monitoring system includes a DOM layer and a WebGL layer, and the monitoring interface rendering method includes steps S06-S08: It should be noted that the front-end interface of the monitoring system is divided into two completely independent rendering pipelines. The first layer is the DOM (Document Object Model) layer, which is rendered by the browser's Blink or WebKit engine, controlling the absolute positioning layer; the second layer is the WebGL (Web Graphics Library) layer, which uses... <canvas>The nodes use the WebGL API (Application Programming Interface) to render the aircraft body and its trajectory. The two layers achieve event separation through Pointer Events, ensuring that the high-frequency redrawing of WebGL will never trigger a DOM tree reflow. This isolates the rendering overhead of the two layers from the bottom layer, preventing mutual interference and dragging down the overall page performance.

[0076] Step S06: Obtain the frame rate per second and memory usage of the monitoring system; Step S07: Calculate the system health of the monitoring system based on the frame rate per second and the memory usage rate, wherein the higher the frame rate per second and the lower the memory usage rate, the higher the system health. It should be noted that frames per second (fps) refers to the number of times the monitoring interface can complete screen rendering and refresh per second, which directly reflects the smoothness of the front-end screen; memory usage refers to the ratio of the heap memory occupied by the front-end application of the monitoring system to the maximum heap memory that the browser can allocate, which is used to characterize the tightness of system memory resource usage.

[0077] Additionally, it's worth noting that the monitoring system's front-end performance probe can use `requestAnimationFrame` to calculate real-time FPS (Frames Per Second) and call `performance.memory` to obtain heap memory usage, continuously outputting a system health score. It's noteworthy that the performance probe's triggering mechanism can be expanded according to business needs: besides purely front-end calculations of FPS and memory usage, it can also receive CPU or bandwidth pressure alerts from the server via WebSocket, allowing the back-end to initiate UI (User Interface) degradation commands.

[0078] Step S08: Based on the system health status, set the rendering strategies for the DOM layer and the WebGL layer.

[0079] As an example, when the system health is greater than 80, it is considered to be in a normal state. At this time, the WebGL layer renders a high-precision 3D (Three-Dimensional) aircraft model (GLTF format, Graphics Library Transmission Format), and the DOM layer loads CSS3 (Cascading Style Sheets Level 3) with a backdrop filter and glowing text effects. When the system health is greater than 50 and less than or equal to 80, the DOM layer intelligently strips shadows and complex gradient properties, the WebGL layer disables particle trails, and reduces the polygon count of the 3D model (LOD degradation). When the system health is less than 50, it is considered to be in an extreme state. At this time, all 3D instances of the WebGL layer are forcibly destroyed, and the rendering is downgraded to 2D (Two-Dimensional) batch point sprites with extremely low performance overhead. At the same time, by globally replacing the CSS root variables, all DOM styles are instantly reconstructed into an unadorned "high-contrast black and white warning mode" (e.g., pure black background, pure yellow border).

[0080] Additionally, as an example, once the concurrent surge subsides and the system health recovers to above 80 for five consecutive sampling periods, the system reverse-engineers the UI assets according to priority, achieving fully automatic system self-healing.

[0081] In this embodiment, the solution avoids the problem of multi-layer rendering slowing down each other by splitting the DOM layer and WebGL layer for independent rendering and isolating the impact of events and reordering. At the same time, it dynamically calculates the system health based on the number of frames per second and memory usage, and realizes hierarchical adaptive UI rendering degradation and intelligent reconstruction of the status interface. It can automatically match the appropriate rendering strategy according to the system load. Under high load, it actively reduces special effects, degrades model accuracy, and simplifies DOM styles to ensure that the monitoring interface does not lag and the alarm status does not become invalid. After the load drops, it can automatically reverse the process to restore the visual effects and rendering accuracy, taking into account the aesthetic display of the interface under normal conditions, the stability and smoothness of the system under high concurrency pressure, and the high readability of information in extreme alarm scenarios. This greatly improves the adaptive capability and operational robustness of the monitoring system in multi-device concurrency and big data rendering scenarios.

[0082] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the monitoring interface rendering method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0083] This application also provides a monitoring interface rendering device, please refer to... Figure 4 The monitoring interface rendering device includes: Acquisition Module 10: Used to acquire the spatiotemporal data to be rendered for each monitored device; Construction module 20: used to construct a device rendering buffer pool based on each of the spatiotemporal data to be rendered, and to determine the device rendering weight of each of the monitored devices; The acquisition module 10 is also used to acquire the system idle rate of the monitoring system, which is used to monitor the monitored device. The determination module 30 is used to determine the target rendering device among the monitored devices based on the system idle time and the device rendering weight; The rendering module 40 is used to obtain the spatiotemporal data to be rendered of the target rendering device from the device rendering buffer pool as target rendering data, and to render the monitoring interface of the monitoring system based on the target rendering data.

[0084] The monitoring interface rendering device provided in this application, employing the monitoring interface rendering method in the above embodiments, can solve the technical problem of interface freezing and system unresponsiveness in monitoring systems with high data concurrency. Compared with the prior art, the beneficial effects of the monitoring interface rendering device provided in this application are the same as those of the monitoring interface rendering method provided in the above embodiments, and other technical features in the monitoring interface rendering device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0085] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the monitoring interface rendering method in Embodiment 1 above.

[0086] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0087] like Figure 5 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0088] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0089] The electronic device provided in this application, employing the monitoring interface rendering method in the above embodiments, can solve the technical problem of interface freezing and system unresponsiveness in monitoring systems with high data concurrency. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the monitoring interface rendering method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0090] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0091] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0092] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the monitoring interface rendering method in the above embodiments.

[0093] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0094] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0095] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to: execute the aforementioned monitoring interface rendering method.

[0096] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0097] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0098] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0099] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described monitoring interface rendering method. This solves the technical problem of interface freezing and system unresponsiveness in monitoring systems with high data concurrency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the monitoring interface rendering method provided in the above embodiments, and will not be repeated here.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the monitoring interface rendering method described above.

[0101] The computer program product provided in this application can solve the technical problem of interface freezing and system unresponsiveness in monitoring systems with high data concurrency. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the monitoring interface rendering method provided in the above embodiments, and will not be repeated here.

[0102] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.< / canvas>

Claims

1. A method for rendering a monitoring interface, characterized in that, The monitoring interface rendering method includes: Obtain the spatiotemporal data to be rendered for each monitored device; Based on the spatiotemporal data to be rendered, a device rendering buffer pool is constructed, and the device rendering weight of each monitored device is determined. The system idle time of the monitoring system is obtained, and the monitoring system is used to monitor the monitored equipment. Based on the system idle time and the device rendering weight, the target rendering device is determined among the monitored devices; The target rendering device's spatiotemporal data to be rendered is obtained from the device's rendering buffer pool as target rendering data, and the monitoring interface of the monitoring system is rendered based on the target rendering data.

2. The monitoring interface rendering method as described in claim 1, characterized in that, The step of determining the device rendering weight of each monitored device includes: Based on the device speed, alarm level, and buffer pool dwell time of each of the spatiotemporal data to be rendered, the device rendering weight of each of the monitored devices is calculated. The faster the device speed, the longer the dwell time, and the higher the alarm level of the spatiotemporal data to be rendered, the greater the device rendering weight of the monitored device corresponding to the spatiotemporal data to be rendered.

3. The monitoring interface rendering method as described in claim 1, characterized in that, The step of obtaining the target rendering device from among the monitored devices based on the system idle time and the device rendering weight includes: The amount of rendering data is calculated based on the system idle level, wherein the greater the system idle level, the greater the amount of rendering data. Based on the amount of rendering data and the device rendering weight, the target rendering device is determined. The larger the device rendering weight of the monitored device, the greater the probability that it will be determined as the target rendering device. The total amount of spatiotemporal data to be rendered by the target rendering device does not exceed the amount of target rendering data.

4. The monitoring interface rendering method as described in claim 1, characterized in that, The monitoring interface rendering method also includes: Among the monitored devices, the data devices to be merged are obtained, wherein the smaller the device rendering weight of the monitored device, the greater the possibility that it is a data device to be merged; Obtain the spatiotemporal data to be rendered from the device to be merged as the data to be merged; The latest spatiotemporal state data in the data to be merged is used to overwrite the spatiotemporal data to be rendered of the data device to be merged, so as to perform overwrite merging of the spatiotemporal data to be rendered of the data device to be merged.

5. The monitoring interface rendering method as described in claim 4, characterized in that, Prior to the step of obtaining the data to be merged from the monitored equipment, the following steps are included: Obtain the overall data generation rate and overall data consumption rate of each of the spatiotemporal data to be rendered; Determine whether the overall data generation rate is greater than the overall data consumption rate; If the overall data generation rate is greater than the overall data consumption rate, then the step of obtaining the data to be merged from the monitored devices is executed.

6. The monitoring interface rendering method as described in claim 1, characterized in that, The step of obtaining the spatiotemporal data to be rendered from the target rendering device as the target rendering data from the device rendering buffer pool includes: Obtain the rendering smoothing value of each rendering frame in the spatiotemporal data to be rendered; When the rendering smoothing value is less than the preset smoothing threshold, the rendering frame is padded. The spatiotemporal data to be rendered after frame interpolation is used as the target rendering data.

7. The monitoring interface rendering method as described in claim 6, characterized in that, The step of obtaining the rendering smoothing value of each rendering frame in the spatiotemporal data to be rendered includes: Calculate the rendering time difference based on the timestamp of each rendering frame and the timestamp of the previous rendering frame; Based on the rendering time difference, the rendering smoothing value of the rendering frame is calculated, wherein the larger the rendering time difference, the smaller the rendering smoothing value of the rendering frame.

8. The monitoring interface rendering method as described in claim 1, characterized in that, The monitoring system includes a DOM layer and a WebGL layer, and the monitoring interface rendering method includes: Obtain the frame rate per second and memory usage of the monitoring system; The system health of the monitoring system is calculated based on the frame rate per second and the memory usage rate, wherein the higher the frame rate per second and the lower the memory usage rate, the higher the system health. Based on the system health status, the rendering strategies for the DOM layer and the WebGL layer are set.

9. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the monitoring interface rendering method as described in any one of claims 1 to 8.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the monitoring interface rendering method as described in any one of claims 1 to 8.

Images