A cross-platform, installation-free, high-performance visual editor for RPA process blocks.

Abstract

This invention belongs to the field of RPA technology, specifically relating to a cross-platform, installation-free, high-performance RPA process block visual editor. The system includes a process block model module for maintaining process block data and publishing component modification events; a controller module for responding to user interface (UI) operations, encapsulating operations as command objects, executing commands to modify the process block model, and simultaneously calling event publishing methods on the process block model to notify listeners of the modified components; and a view module, including a view manager and a user interface (UI). The view manager maintains a rendering tree consistent with the process block model structure, recording the rendering position information of each component relative to its parent component. The view manager also listens for component modification events, updates the rendering tree, and locates components within the visible area based on the rendering tree, driving the UI to render only the components within that visible area.

Description

Technical Field

[0001] This invention belongs to the field of RPA technology, specifically relating to a cross-platform, installation-free, high-performance RPA process block visual editor. Background Technology

[0002] Robotic Process Automation (RPA) is a technology that uses software programs to simulate human actions on a computer (such as mouse movement, clicking, keyboard input, and data reading) to automate processes involving data integration, aggregation, and analysis across systems (such as ERP, OA, Excel, and web platforms).

[0003] From a technical implementation perspective, an RPA process is essentially executable program code, where each "process block" corresponds to a function logic that implements a specific function (such as "data validation", "file export", "system login"). To reduce the development threshold and cost of RPA processes, mainstream RPA software is equipped with a visual RPA process block editor - developers do not need to write complex code, but can complete process development through visual operations of "drag and drop components and configure parameters", which greatly shortens the process development cycle.

[0004] However, the current RPA process block visual editor has significant performance issues, including the following aspects: 1. Lack of cross-platform compatibility, limited by operating system type: Current high-performance RPA workflow block editors mostly rely on native technologies (such as the WPF framework on Windows and the Cocoa framework on Mac), and are only compatible with a single operating system. For example, some editors only support Windows 10 and above, and cannot run on Mac OS or Linux systems. They also have compatibility issues with lower versions of the same system (such as Windows 7). This strong binding means that when users switch between multiple devices (such as office Windows computers and personal Mac laptops), they need to find a new compatible version, failing to achieve "one tool for all platforms," ​​and severely limiting the flexibility of use.

[0005] 2. Relies on local client deployment, resulting in high usage barriers and management costs: High-performance RPA workflow block editors based on native technology require downloading the installation package (usually over 200MB) from official channels and completing environment configuration (such as installing .NET Framework and Java Runtime) before they can be launched. If the device is reinstalled or replaced, the "download-install-configure" process must be repeated. This model not only fails to meet users' needs for "temporary office work and quick startup," but also increases team management costs—IT personnel need to maintain separate installation packages and adaptation solutions for devices with different systems, and client version updates need to be pushed out one by one, resulting in low efficiency.

[0006] 3. The browser-side editor suffers from significant performance bottlenecks and cannot support large-scale component editing: Because the components within a workflow block form a tree structure, statement-based components render across different areas, making partial rendering using virtual lists unsuitable. Existing browser-based RPA workflow block editors generally employ full rendering. When the number of components in a workflow exceeds 3000, DOM repainting and reflow take considerable time, causing lag, such as node dragging taking over 2 seconds to respond. Enterprise-level workflows (such as batch financial reconciliation and end-to-end data entry) often have workflow blocks exceeding 3000 components, making it impossible to meet performance requirements.

[0007] Therefore, it is very important to design a visual editor for RPA process blocks that uses a browser as the implementation platform and meets the requirements of cross-platform compatibility, installation-free operation, and high performance. Summary of the Invention

[0008] This invention aims to overcome the problems of existing RPA process block visual editors, such as lack of cross-platform adaptability, high usage threshold and management cost, and inability to meet performance requirements. It provides a cross-platform, installation-free, high-performance RPA process block visual editor that uses a browser as the implementation platform.

[0009] To achieve the above-mentioned objectives, the present invention adopts the following technical solution: A cross-platform, installation-free, high-performance RPA process block visual editor, including: The process block model module is used to maintain process block data and publish component modification events; The controller module is used to respond to user interface (UI) operations, encapsulate the operations as command objects, execute the commands to modify the process block model, and call the event publishing methods on the process block model to notify the listeners of the modified components. The view module includes the view manager and the user interface (UI). The view manager is used to maintain a rendering tree consistent with the process block model structure. The rendering tree records the rendering position information of each component relative to its parent component. The view manager is also used to listen for component modification events, update the rendering tree, and find components located within the visible area based on the rendering tree, driving the user interface (UI) to render only the components within the visible area.

[0010] Preferably, in the process block model module, the process block data is organized in a tree structure, including statement-type components and instruction-type components, and a mechanism for publishing component modification events is provided. The statement component includes adding conditional statements (IF) and exception handling (Try-Catch); the statement component contains one or more slots; each slot is a container used to hold child components; the statement component displays labels above and below each slot. The instruction-type component represents a command, including printing a regular log; The component modification event is used to notify the view module of any modified components and to update the user interface (UI) in a timely manner.

[0011] Preferably, the controller module specifically includes the following processes: External interface call requests to the controller module are encapsulated into command objects. Executed commands are stored in the undo stack, and undoed commands are stored in the redo stack. After modifying a component, a component modification event is published through the process block model.

[0012] Preferably, in the view module, the construction of the rendering tree includes the following process: Traverse the process block model tree from bottom to top, construct the rendering tree nodes and calculate the height of each node; Traverse the rendering tree from top to bottom and calculate the starting and ending positions of each node relative to its parent node.

[0013] Preferably, the calculation rules for the node height include the following: Set the height of the instruction-type component to a fixed value; Set the height of the statement component to a fixed value when it is collapsed, and the height of the component when it is not collapsed is the sum of the heights of all its tags and the heights of all its child components; Set the height of the slot node to the sum of the heights of all its child components.

[0014] Preferably, in the view manager, the process of finding components located within the visible area based on the rendering tree is as follows: Traverse the rendering tree from top to bottom and calculate the absolute position of the rendering area of ​​each node; Determine whether the rendering area of ​​a node overlaps with the currently visible area; If the rendering area of ​​a node overlaps with the visible area, then the corresponding component is within the visible area; if the rendering area of ​​a node does not overlap with the visible area, then the subtree rooted at that node is pruned, and the downward traversal stops.

[0015] Preferably, the calculation of the absolute position of the node's rendering area includes the following process: Set the absolute start position of the root node's rendering area to 0 and the absolute end position to height-1; height is the height of the component's rendering area. Set the absolute start position of all nodes except the root node to the absolute start position of the parent node + start, and the absolute end position to the absolute start position of the parent node + end; start is the rendering start position of the corresponding component of the node relative to the top of the parent component; end is the rendering end position of the corresponding component of the node relative to the top of the parent component.

[0016] Preferably, the method for updating the rendering tree in the view manager includes the following process: Remove the rendering node corresponding to the component to be deleted from the rendering tree; Traverse the subtree rooted at the newly added node in the model tree to complete the rendering tree, ensuring that the rendering tree structure is consistent with the model tree. Calculate the height of all newly added nodes and their corresponding descendant nodes; Calculate the height of the left sibling node of all newly added and deleted nodes; Calculate the height of all nodes on the root path from all newly added nodes; Calculate the height of all nodes on the root path from all deleted nodes; Traverse the rendering tree in a "top-down, left-to-right" order, updating the rendering positions of nodes whose heights have changed and their right siblings.

[0017] Preferably, the view manager is also used to calculate the placement position indication in real time when dragging components, as follows: The bottom-level component corresponding to the mouse position is found in the rendering tree using a binary search method. The insertion line is displayed above or below the component depending on the relative position of the mouse within the component's rendering area.

[0018] Compared with the prior art, the beneficial effects of this invention are: (1) Performance breakthrough, supporting smooth editing of ultra-large-scale process blocks: This invention solves the pain point of "excessive component lag" in existing browser editors by optimizing the rendering mechanism and data processing method; even if the process contains 20,000 components, it can still maintain the smoothness of operation - the node drag response delay is controlled within 0.1 seconds, and there is no risk of memory overflow or page crash; this performance far exceeds the existing technology (existing browser editors lag with 3,000 components), which can easily support the editing needs of enterprise-level ultra-complex RPA processes, greatly improve the efficiency of process development, and reduce the editing cost of complex processes; (2) Native cross-platform compatibility on the browser side, breaking the limitations of devices and systems: This invention is based on browser development and does not need to rely on native technology to adapt to specific systems, and can achieve seamless compatibility across all platforms: it can be used normally in mainstream desktop operating systems such as Windows, Mac, and Linux through browsers such as Chrome, Edge, and Safari; on mobile devices In browsers (such as mobile phones and tablets), the interface layout can be adapted to support core editing operations. Compared with existing editors based on Native development that only support a single system, this invention completely breaks down the barriers between devices and systems. Users can access the editor at any time on any terminal (office computer, laptop, mobile device) without having to deploy it separately for different systems, thus improving the flexibility of use. (3) Lightweight deployment without installation, greatly reducing the threshold for use: This invention adopts a lightweight browser architecture, which does not require downloading or installing any client program or dependent plugins. Users only need to enter the access link through the browser to directly start the editor and carry out process editing work, realizing "ready to use". Compared with existing editors that require client installation, this invention completely eliminates the "installation and deployment" step: On the one hand, it avoids the client occupying device storage space (especially friendly to low-end devices); on the other hand, in scenarios such as temporary office work and switching between multiple devices, users do not need to repeatedly install and configure, and can quickly get started with work, significantly reducing the threshold for use. It is especially suitable for scenarios with high demand for "quick start", improving the popularity and ease of use of RPA technology. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of an architecture for a cross-platform, installation-free, high-performance RPA process block visual editor according to the present invention. Figure 2 This is a schematic diagram of a process block model in this invention; Figure 3 This is a schematic diagram of the controller in this invention; Figure 4 A schematic diagram illustrating the calculation of the height of an instruction-type component provided in an embodiment of the present invention; Figure 5A schematic diagram illustrating the calculation of the folded state height of a statement-type component according to an embodiment of the present invention; Figure 6 A schematic diagram illustrating the calculation of the height of a statement-type component in its non-folded state, provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the calculation of slot node height according to an embodiment of the present invention; Figure 8 A schematic diagram of the component node position calculation rule provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the slot node position calculation rule provided in an embodiment of the present invention; Figure 10 This is a schematic diagram illustrating the label position calculation rule in a statement component provided in an embodiment of the present invention; Figure 11 A schematic diagram illustrating the component search process within a visible area provided in an embodiment of the present invention; Figure 12 A schematic diagram of the absolute rendering position calculation process provided in an embodiment of the present invention; Figure 13 A schematic diagram of a process block containing 35,021 components provided in an embodiment of the present invention; Figure 14 This is a flowchart illustrating the process of calculating the placement position of a component after the mouse is released during dragging, as provided in an embodiment of the present invention. Detailed Implementation

[0020] To more clearly illustrate the embodiments of the present invention, specific implementation methods will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0021] This invention provides a cross-platform, installation-free, high-performance RPA process block visual editor, which uses a browser as the implementation platform to meet the requirements of cross-platform compatibility and installation-free operation; it also provides a layout algorithm and a rendering scheme to meet the requirements of high performance.

[0022] The layout algorithm consists of two parts: 1) creating a rendering tree with the same structure as the component tree, and the rendering tree records the rendering position information of the components; 2) when the component tree is modified, the rendering tree is locally adjusted to make its structure consistent with the component tree.

[0023] The rendering scheme is as follows: based on the rendering tree, identify the components within the visible area and draw them using React.

[0024] On a typical office computer (CPU 2GHz), with 20,000 components, the creation and maintenance of the render tree takes less than 10 microseconds; finding and rendering components within the visible area of ​​the render tree takes less than 50 milliseconds. All editing operations have a response time of less than 100 milliseconds, meeting the requirements for smooth editing.

[0025] A cross-platform, installation-free, high-performance RPA process block visual editor using an MVC architecture, such as... Figure 1 As shown, it mainly includes a process block model, a controller, and a view. Figure 3 Each module.

[0026] The process block model is responsible for maintaining process block data and publishing component modification events.

[0027] The controller responds to requests from the UI layer and modifies the model. It then calls the event publishing method on the model to notify the listeners of the modified components.

[0028] The view module consists of two parts: the UI and the view manager. The view manager initializes and maintains the render tree and controls the UI rendering components. It also listens for user actions, translates them into API calls to the controller, and modifies the model.

[0029] 1) Process Block A process block is a tree composed of components, such as Figure 2 The image shows a model example with a root node `main` and a single slot. A conditional statement `If` has one slot, and the exception handling component `try-catch` has three slots, corresponding to the three blocks of the `try-catch-finally` block in programming languages.

[0030] Components are divided into two types: statement components and instruction components.

[0031] Statement-based components, such as those adding conditional statements (IF) and exception handling (Try-Catch), contain one or more slots. A slot is a container used to hold child components. Statement-based components display labels above and below the slot; for example, an exception handling component has three slots and displays four labels.

[0032] Some special statement components, such as those with added conditional statements, can be paired with the right sibling node. When paired, the last label is not displayed.

[0033] An instruction-type component represents a command, such as printing a regular log.

[0034] The relationships between different types of components are as follows: Component is the parent class of StatementComponent and InstructionComponent. StatementComponent contains slots, and slots contain Components.

[0035] Component modification events are used to notify the view module which components have been modified, allowing for timely UI updates. The relationships between different types of events are as follows: Events are divided into three types: AddChildrenEvent, RemoveChildrenEvent, and PropertyChangeEvent.

[0036] The meaning of the "Add Child Component" event is: In the slot with componentId, after the component with preId, several new components are added to the component with componentId. The ID of the new components is addIds.

[0037] The meaning of the delete child component event is: In the slot with componentId, after the component with preId, several components are deleted from the component with componentId. The deleted component ID is rmIds.

[0038] The meaning of the property event is: the property of the component with componentId has changed.

[0039] 2) Controller Controller structure as follows Figure 3 As shown, external interface call requests are encapsulated into Command objects. After executing the command's redo method, it is placed on the undo stack. After a command is undoed, it is placed on the redo stack. The command's redo and undo methods publish component modification events through the process block model after the component has been modified.

[0040] 3) View Render Tree The render tree has the same structure as the model tree, with node IDs corresponding to the model IDs. Each node records the rendering position information of the corresponding component relative to the top of its parent component: start is the starting position of the rendering relative to the top of the parent component; end is the ending position of the rendering relative to the top of the parent component; and height is the height of the component's rendering area. There is a mathematical relationship between start, end, and height: height = end - start + 1.

[0041] Render Tree Creation The creation of the render tree involves two steps: a) Traverse the model tree from bottom to top, construct the rendering tree structure, and calculate the node height; b) Traverse the rendering tree from top to bottom and calculate the position of each node relative to its parent node.

[0042] Node height calculation rules Based on the node type in the component tree corresponding to the node in the rendering tree, the calculation rules are divided into three categories: a) Command-type components Set the height to a fixed value, specifically as follows: Figure 4 As shown.

[0043] b) Statement-based components Set the folded height to a fixed value, as follows: Figure 5 As shown; Set the height in the non-collapsed state to the sum of the heights of all labels and all child components, as shown below. Figure 6 As shown.

[0044] There are two special cases: 1. The root node main component has no label; 2. If the right sibling of the if component is elseif or else, the last label is omitted.

[0045] c) Slot Node Set the height to the sum of the heights of all child components, as follows: Figure 7 As shown.

[0046] Node position calculation rules a) Root node (main component) Set start to a fixed value of 0; end to start + height - 1.

[0047] b) Components (including statement components and instruction components) like Figure 8 As shown, if there is a left sibling, start is the end position of the left sibling + 1, and end is start + height - 1.

[0048] If there is no left sibling, start is 0 and end is height-1.

[0049] c) Slot Node like Figure 9 As shown, if there is a label on the upper side of the slot, then start is the end position of the label on the upper side + 1, and end is start + height - 1.

[0050] If there is no label (slot of the main component) above the slot, then start is a fixed value of 0 and end is height-1.

[0051] Calculating the label position in a statement component, such as Figure 10 As shown: `start` is the sum of the heights of all labels and slots displayed before the `label` element within the component, and `end` is `start + height - 1`.

[0052] 4) Component search within the visible area like Figure 11 As shown, rendering the entire process block requires a much larger area than the visible area, wasting CPU resources and causing lag. To improve performance, components appearing within the visible area are searched in the rendering tree, and only those components within the visible area are rendered.

[0053] The search method is as follows: traverse the rendering tree from top to bottom, calculate the absolute position of the node's rendering area (relative to the rendering position above the main component), and compare it with the visible area: if the node's rendering area overlaps with the visible area, then the corresponding component is within the visible area.

[0054] During the traversal, if the node's rendering area does not overlap with the visible area, the subtree rooted at the node is pruned to avoid invalid traversal.

[0055] Absolute rendering position calculation: Set the absolute start position of the rendering area of ​​the root node (main component) to 0, and the absolute end position to height-1. For example... Figure 12 As shown, the absolute start position of the remaining nodes is set to the absolute start position of the parent node + start, and the absolute end position is set to the absolute start position of the parent node + end.

[0056] 5) Render tree update The view manager listens for component modification events and adds them to a cache queue. Events are processed in batches each browser rendering cycle, updating the render tree. The processing steps are as follows: 1. Remove the rendering node corresponding to the component to be deleted from the rendering tree.

[0057] 2. Traverse the subtree rooted at the newly added node in the model tree to complete the rendering tree. At this point, the rendering tree structure is consistent with the model tree.

[0058] 3. Calculate the height of all newly added nodes and their descendant nodes.

[0059] 4. Calculate the height of the left sibling node of all newly added and deleted nodes. This step handles the pairing of adjacent components. If paired, the left component will hide its last label, and its height will decrease.

[0060] 5. Calculate the height of all nodes that published new and deleted events, as well as the height of all nodes on the path to the root.

[0061] 6. Traverse the render tree in a top-down, left-to-right order, updating the rendering positions of nodes whose heights have changed and their right siblings. After the rendering tree is updated, the view manager notifies the UI to refresh and display the edited flow block.

[0062] Based on the technical solution of this invention, the implementation process of this invention in practical applications will be illustrated through the following case scenarios. The specific application implementation scheme is as follows: Edit with the process block editor, such as Figure 13 Taking the flow block of 35,021 components as an example, the scrolling of the view, as well as the dragging, adding, deleting and selecting of components, all respond within 0.1ms without any lag.

[0063] The execution process will be explained below based on specific scenarios.

[0064] I. Editor Initialization: The process from the editor initially loading the workflow block data to finally rendering the UI consists of four steps: 1. The process block model module reads the JSON data representing the process block and converts it into a model tree; 2. The view manager module traverses the model tree to construct the rendering tree; 3. The view manager module registers listener functions on the process block model module to listen for component change events; 4. The view manager searches for all components within the visible area in the render tree and renders them via the UI.

[0065] 2. Scroll the specified component into the visible area: When a user scrolls a component with a specific ID into the visible area, the absolute rendering position needs to be calculated, and then the UI scroll value needs to be set. The specific steps are as follows: 1. In the render tree, the view manager module starts from the node corresponding to the specified component, follows the path to the root, finds the node with an absolute rendering position, and records the path. 2. The view manager module calculates the absolute rendering position of each node in reverse order along the path, and finally obtains the absolute rendering position of the specified component. 3. The View Manager module sets the scroll value of the UI.

[0066] III. New Components 1. Modify the process block model in the controller module and insert the new component at the user-specified location; 2. The controller module publishes component modification events through the process block model module; 3. The view manager module listens for model modification events and puts them into the event cache queue; 4. When the next rendering cycle arrives, the view manager module updates the rendering tree; 5. The View Manager module locates components within the visible area and refreshes the UI.

[0067] IV. Drag and drop components: Users can drag and drop components to change their position. During the dragging process, the component's final position after the mouse button is released needs to be displayed.

[0068] The calculation process for the placement location is as follows, such as... Figure 14 As shown: 1. The view manager module starts from the root node of the rendering tree and uses a binary search method to search for the lowest-level component in the display area containing the mouse position. 2. If the mouse position is biased towards the top of the component, the view manager module controls the UI to display the insertion line on the top of the component; otherwise, the insertion line is displayed on the bottom of the component.

[0069] The innovative aspects of this invention are as follows: 1. The process block editor consists of three main modules: controller, process block model, and view. The controller handles UI requests, modifies process blocks, and publishes component modification events through the process block model. The process block model maintains process block data, provides the functionality to register event listeners, and offers an interface for publishing component modification events. The view is divided into UI and view manager. The view manager maintains the rendering tree and drives the UI to render components within the visible area.

[0070] 2. The controller encapsulates the model modification request into a command, executes it, and then places it on the undo stack. The command execution flow is as follows: first, the components in the model are modified, and then the modified components are published through the event publishing interface of the process block model.

[0071] 3. The rendering tree is constructed as follows: Traverse the model tree from bottom to top to build the rendering tree structure and calculate the height of all nodes. Traverse the rendering tree from top to bottom to calculate the rendering position of all nodes relative to their parent nodes.

[0072] 4. The method for finding components within the visible area is as follows: traverse the render tree from top to bottom, calculate the absolute rendering position of each node, and then compare it with the visible area to determine whether the component is within the visible area. During the traversal, prune nodes that are not within the rendering area.

[0073] 5. The render tree is updated as follows: Model modification events are processed centrally within each browser rendering cycle. First, the render tree structure is adjusted to be consistent with the model tree structure; then, the actual height of nodes whose height may change is calculated; finally, the rendering position of the node whose height has changed, as well as the rendering positions of its sibling nodes, are calculated.

[0074] 6. The method for calculating the component below the mouse is to use a binary search on the rendering tree to find the component in the lowest rendering area that contains the mouse.

[0075] 7. The method for calculating the rendering position of a specified component is as follows: In the rendering tree, starting from the node corresponding to the specified component, find the node with an absolute rendering position along the path to the root and record the path. Calculate the absolute rendering position of each node in reverse order along the path to obtain the absolute rendering position of the specified component.

[0076] The above description is merely a detailed explanation of preferred embodiments and principles of the present invention. For those skilled in the art, there may be changes in specific implementation methods based on the ideas provided by the present invention, and these changes should also be considered within the scope of protection of the present invention.

Claims

1. A cross-platform installation-free high-performance RPA process block visual editor, characterized in that, include: The process block model module is used to maintain process block data and publish component modification events; The controller module is used to respond to user interface (UI) operations, encapsulate the operations as command objects, and execute commands to modify the process block model. At the same time, the event publishing method on the process block model is called to notify the listener of the modified component; The view module includes the view manager and the user interface (UI). The view manager is used to maintain a rendering tree consistent with the process block model structure. The rendering tree records the rendering position information of each component relative to its parent component. The view manager is also used to listen for component modification events, update the rendering tree, and find the components located in the visible area according to the rendering tree, driving the user interface (UI) to render only the components in the visible area. In the process block model module, the process block data is organized in a tree structure, including statement-type components and instruction-type components, and provides a mechanism for publishing component modification events; The statement component includes adding conditional statements (IF) and exception handling (Try-Catch); the statement component contains one or more slots; each slot is a container used to hold child components; the statement component displays labels above and below each slot. The instruction-type component represents a command, including printing a regular log; The component modification event is used to notify the view module of any modified components and to update the user interface (UI) in a timely manner.

2. The cross-platform installation-free high-performance RPA process block visual editor according to claim 1, wherein, The controller module specifically includes the following processes: External interface call requests to the controller module are encapsulated into command objects. Executed commands are stored in the undo stack, and undoed commands are stored in the redo stack. After modifying a component, a component modification event is published through the process block model.

3. The cross-platform, installation-free, high-performance RPA process block visual editor according to claim 2, characterized in that, In the view module, the construction of the rendering tree includes the following process: Traverse the process block model tree from bottom to top, construct the rendering tree nodes and calculate the height of each node; Traverse the rendering tree from top to bottom and calculate the starting and ending positions of each node relative to its parent node.

4. The cross-platform, installation-free, high-performance RPA process block visual editor according to claim 3, characterized in that, The rules for calculating the node height include the following: Set the height of the instruction-type component to a fixed value; Set the height of the statement component to a fixed value when it is collapsed, and the height of the component when it is not collapsed is the sum of the heights of all its tags and the heights of all its child components; Set the height of the slot node to the sum of the heights of all its child components.

5. The cross-platform, installation-free, high-performance RPA process block visual editor according to claim 4, characterized in that, In the view manager, the process of finding components located within the visible area based on the rendering tree is as follows: Traverse the rendering tree from top to bottom and calculate the absolute position of the rendering area of ​​each node; Determine whether the rendering area of ​​a node overlaps with the currently visible area; If the rendering area of ​​a node overlaps with the visible area, then the corresponding component is within the visible area; If the rendering area of ​​a node does not overlap with the visible area, then the subtree rooted at that node is pruned, and the downward traversal stops.

6. The cross-platform, installation-free, high-performance RPA process block visual editor according to claim 5, characterized in that, The calculation of the absolute position of a node's rendering area includes the following process: Set the absolute start position of the root node's rendering area to 0 and the absolute end position to height-1; height is the height of the component's rendering area. Set the absolute start position of all nodes except the root node to the absolute start position of the parent node + start, and the absolute end position to the absolute start position of the parent node + end; start is the rendering start position of the corresponding component of the node relative to the top of the parent component; end is the rendering end position of the corresponding component of the node relative to the top of the parent component.

7. The cross-platform, installation-free, high-performance RPA process block visual editor according to claim 6, characterized in that, In the view manager, the method for updating the render tree includes the following process: Remove the rendering node corresponding to the component to be deleted from the rendering tree; Traverse the subtree rooted at the newly added node in the model tree to complete the rendering tree, ensuring that the rendering tree structure is consistent with the model tree. Calculate the height of all newly added nodes and their corresponding descendant nodes; Calculate the height of the left sibling node of all newly added and deleted nodes; Calculate the height of all nodes on the root path from all newly added nodes; Calculate the height of all nodes on the root path from all deleted nodes; Traverse the rendering tree in a "top-down, left-to-right" order, updating the rendering positions of nodes whose heights have changed and their right siblings.

8. The cross-platform, installation-free, high-performance RPA process block visual editor according to claim 7, characterized in that, The view manager is also used to calculate the placement position indication in real time when dragging components, as follows: The bottom-level component corresponding to the mouse position is found in the rendering tree using a binary search method. The insertion line is displayed above or below the component depending on the relative position of the mouse within the component's rendering area.

Images