Adaptive rendering optimization method, system, device and medium for large-scale workflow engine

Abstract

The application discloses a kind of self-adapting rendering optimization method, system, equipment and medium for large-scale workflow engine, by creating corresponding node agent object for each business node, all core operations of rendering optimization are completed based on node agent object and its corresponding dynamic runtime state, incremental off-screen rendering and synthesis based on tile and dirty mark are realized, only the minimum tile that changes in viewable area needs to be redrawn, update granularity is reduced from entire viewable area to single tile, solve the problem that large-scale workflow engine in single page causes object quantity and drawing instruction double pressure leading to full rendering performance collapse.

Description

Technical Field

[0001] This invention belongs to the field of graphics data processing technology, specifically relating to an adaptive rendering optimization method, system, device, and medium for large-scale workflow engines. Background Technology

[0002] Traditional workflow engines typically use full rendering when rendering on the front end. When the number of process nodes is small (e.g., less than 100), they can still maintain smooth rendering. However, when the number of nodes increases to more than 500, the frame rate of page scrolling, zooming, panning and other operations will drop sharply, resulting in obvious stuttering or even browser unresponsiveness.

[0003] While existing infinite canvas technologies (such as Canvas or WebGL) can support more graphics, they lack efficient management of complex attributes within workflow engine nodes (such as input / output parameters, execution status, icons, etc.). Direct rendering would require redrawing all nodes every frame, thus consuming a large amount of CPU / GPU resources.

[0004] When users zoom in or out, traditional rendering solutions cannot intelligently adjust the level of detail (LOD) of the rendered content according to the current zoom ratio. For example, when viewing the entire view, detailed text and icons inside nodes will still be rendered, resulting in serious waste of resources. When zooming in on a local area, it cannot smoothly transition to high-precision details, resulting in a poor visual experience. Summary of the Invention

[0005] The purpose of this invention is to provide an adaptive rendering optimization method, system, device, and medium for large-scale workflow engines, in order to solve the problems of unresponsiveness, high resource consumption, and poor visual experience in large-scale workflow rendering processes.

[0006] This invention is achieved through the following technical solution: An adaptive rendering optimization method for large-scale workflow engines includes the following steps: A unique node proxy object is created for each original workflow node to build a node proxy pool. The node proxy object includes static metadata, dynamic runtime state data and behavior interface. The static metadata includes the node's attribute data. The dynamic runtime state data includes the node proxy object's current rendering level, the screen / world boundary occupied during the last rendering, dirty flag, weak references pointing to its off-screen tile and local coordinates within the off-screen tile. Construct a global space index for the node proxy object, and based on the global space index, retrieve the node proxy object corresponding to the current viewport from the node proxy pool to obtain a set of node proxy objects to be rendered; Iterate through the collection of proxy objects for the nodes to be rendered, and calculate the current LOD level of the proxy objects for the nodes to be rendered based on the current canvas scaling ratio and the attributes of the proxy objects themselves. Establish a mapping relationship between node proxy objects and tiles. When the LOD level of a node proxy object changes, mark the tile corresponding to that node proxy object as a dirty tile. Poll or receive notifications of dirty tile markings, obtain the node proxy objects to be rendered corresponding to the tiles marked as dirty tiles, obtain all node proxy objects to be rendered, and form a list of node proxy objects; for each node proxy object in the list of node proxy objects, call the behavior interface of the node proxy object, and generate drawing instructions based on the current LOD level and static metadata of the node proxy object to be rendered. The corresponding tiles are rendered off-screen according to the drawing instructions.

[0007] In some embodiments, the behavior interface includes interfaces for calling the following functions, which include updateLOD(zoom), markDirty(type), and getRenderCommand(zoom, lod); The updateLOD(zoom) method is used to receive the current zoom level, calculate the new LOD level of the proxy object of the node to be rendered based on the preset threshold and the node's own attributes, and compare it with the current LOD level of the proxy object of the node to be rendered. If there is a change, the current LOD level of the proxy object of the node to be rendered is updated. The markDirty(type) is used to receive the dirty mark type string, set the corresponding dirty mark field to true, and notify the tile manager of the tile ID where the node proxy object is located; The getRenderCommand(zoom, lod) function receives the current zoom level and the current LOD level of the proxy object to be rendered. Based on the static metadata and the current LOD level of the proxy object to be rendered, it returns an array of drawing commands.

[0008] In some embodiments, the global spatial index adopts a quadtree structure.

[0009] In some embodiments, the step of off-screen rendering of the corresponding tile according to the drawing instructions includes: Apply the drawing commands to the off-screen Canvas context of the corresponding tile for drawing; Composite the off-screen Canvas tiles located within the viewport onto the main canvas.

[0010] In some embodiments, when the current LOD level of the proxy object to be rendered does not change, the corresponding off-screen cache is directly reused during rendering and compositing.

[0011] In some embodiments, after off-screen rendering of the corresponding tiles according to drawing instructions, the method further includes an event delegation and synchronization step, including: When the canvas receives a click event, it calculates the world position based on the coordinates and looks up the corresponding target node proxy object through the global spatial index. Get the current LOD level of the target node proxy object, and output the interaction response of the original workflow node corresponding to the target node proxy object based on the current LOD level of the target node proxy object and the corresponding response rules.

[0012] In some embodiments, the event proxy and synchronization steps include synchronizing events back to the workflow engine, updating the original workflow node state, and updating the data of the node proxy object.

[0013] On the other hand, the present invention also provides an adaptive rendering optimization system for large-scale workflow engines, for executing the aforementioned adaptive rendering optimization method for large-scale workflow engines, comprising: The node proxy pool module is used to create node proxy objects, build the node proxy pool, and maintain a global space index. The viewport awareness and interval calculation module is used to listen for canvas changes, calculate the visible interval, query the node proxy pool, and output a set of node proxy objects to be rendered. The adaptive LOD scheduling module is used to calculate the current LOD level of each node proxy object to be rendered based on its scaling ratio and the node proxy object's own attributes, and generate corresponding rendering instructions. The tiled off-screen rendering engine manages virtual tiles and their off-screen canvases; it receives rendering instructions generated by the adaptive LOD scheduling module and executes drawing to the specified tiles. The event proxy and synchronization module is used to capture global events, query the corresponding node proxy object using the global space index, and determine the granularity of the interaction response of the corresponding original workflow node based on the current LOD level and response rules of the node proxy object, and synchronize it back to the workflow engine.

[0014] On the other hand, the present invention also provides an electronic device, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to execute the adaptive rendering optimization method for large-scale workflow engines by executing the executable instructions.

[0015] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned adaptive rendering optimization method for large-scale workflow engines.

[0016] Compared with the prior art, the present invention has the following advantages and beneficial effects: This invention creates a corresponding node proxy object for each business node. All core operations for rendering optimization are performed based on the node proxy object and its corresponding dynamic runtime state. This achieves incremental off-screen rendering and compositing based on tiles and dirty marking. Only the smallest tile that has changed in the viewport needs to be redrawn. The update granularity is reduced from the entire viewport to a single tile. This solves the problem of full rendering performance crash in a single page due to the dual pressure of the number of objects and drawing instructions in a large-scale workflow engine (more than 2000 nodes).

[0017] This invention achieves consistency between interactive feedback and the current user's visual perception, solving the problem in traditional solutions where rendering strategy (LOD), cache update (off-screen rendering), and interactive feedback are separated, making it impossible to achieve collaborative work based on the same runtime state, resulting in resource waste and inconsistent experience. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of the adaptive rendering optimization method according to an embodiment of the present invention.

[0020] Figure 2 This is a flowchart illustrating the event interaction process based on the LOD state of a node proxy object in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0022] This invention proposes a workflow rendering architecture based on a node proxy state machine and viewport-driven architecture. By creating an "intelligent node proxy," which serves not only as a lightweight data mapping mechanism but also as an execution unit for rendering strategies, an off-screen cache management unit, and a relay unit for interaction time, all core rendering optimization operations, such as LOD decision-making, off-screen updates, and interaction hits, revolve around this "intelligent node proxy" and its maintained dynamic runtime state, forming a tightly coordinated adaptive closed loop.

[0023] In some embodiments of the present invention, the adaptive rendering optimization system comprises: The node proxy pool module is used to create, store, and manage all node proxy objects, build the node proxy pool, and maintain a global space index, which adopts a quadtree structure. The viewport awareness and interval calculation module is used to listen for canvas transformations (such as canvas scaling, panning, etc.), calculate the visible interval, query the node proxy pool, and output a set of node proxy objects to be rendered. The adaptive LOD scheduling module is used to calculate the current LOD level of each node proxy object to be rendered based on its scaling ratio and the node proxy object's own attributes, and generate corresponding rendering instructions. The tiled off-screen rendering engine manages virtual tiles and their off-screen canvases; it receives rendering instructions generated by the adaptive LOD scheduling module, executes drawing to the specified tiles, and maintains the "dirty areas" and validity of the tile content. The event proxy and synchronization module is used to capture global events, use the global space index to hit the corresponding node proxy object, and determine the corresponding response rules based on the current LOD level and business status of the node proxy object, determine the granularity of the corresponding node interaction feedback, and synchronize it back to the workflow engine.

[0024] In some embodiments of the present invention, reference is made to Figure 1 The adaptive rendering optimization method includes the following steps: Step 1: Build a node proxy pool, create and initialize node proxies. Create a unique node proxy object Proxy_i for each original workflow node N_i.

[0025] Raw workflow nodes refer to business data objects defined internally by the workflow engine. Each raw workflow node represents a specific task or step and includes business attributes such as ID, name, type, coordinates, input / output ports, execution status (waiting / running / success / failure), icon, and text description. These nodes are the data source for the workflow editor and are typically passed from the backend to the frontend as JSON arrays. In this invention, these raw workflow nodes are not directly rendered but are used as input for creating node proxy objects.

[0026] Each node's proxy object contains: Static metadata: ID, location (x, y), width / height, port definition, etc.; ID represents a unique identifier for the original workflow node; The position (x, y) represents the coordinates (in pixels) of the top-left corner of the node in the world coordinate system; The width and height (in pixels) of a node are used to determine the occupied area; The port definition represents the definition of input / output ports, including port ID, name, and type (data / trigger).

[0027] Example as follows: { inputs: [{ id: "in1", name: "Data Input"}], outputs: [{ id: "out1", name: "Result"}]}; These data correspond one-to-one with the original workflow nodes, but the node proxy object only retains the parameters related to rendering and interaction: id, x, y, width, and width ports.

[0028] Dynamic runtime state: lodLevel, the current rendering level (0 / 1 / 2), initially null; `lastRenderedBounds` represents the screen / world boundary occupied during the last render. It stores the rectangular area occupied by the node in the world coordinate system during the last successful render, in the format {x:number, y:number, w:number, h:number}. For example, a node with position (100, 200) and width / height (200, 80) might have `lastRenderedBounds` as {x: 100, y: 200, w: 200, h: 80}. This field is primarily used for determining dirty regions during incremental updates. When a node's position, size, or LOD level changes, the system marks the union of the old and new boundaries as dirty, thus accurately redrawing the affected area. Furthermore, during the compositing phase, if the `lastRenderedBounds` of a node within a tile perfectly matches the tile boundary of the current view, the regeneration instruction can be skipped, and the off-screen cache can be reused directly, avoiding global redraws caused by minor displacements. `dirtyFlags` indicates whether a change has occurred due to changes in location, state, or appearance. `dirtyFlags` is an object containing three boolean fields, each indicating a different type of change. The data format is as follows: javascript { pos: false, / / Whether the position or size has changed state: false, / / Whether the business status (running, success, failure) has changed. style: false / / Whether the appearance (LOD level, theme color, etc.) has changed. } For example, when a user drags a node, the system sets pos = true; when the workflow engine notifies a node that execution is complete, it sets state = true; and when a user zooms in, causing the LOD level to change from 1 to 2, it sets style = true. The tile manager checks these flags in each frame, and if any one of them is true, the tile containing the node's proxy object is added to the dirty tile set. `cacheRef` is a weak reference (if applicable) pointing to the off-screen tile and its local coordinates within the tile. `cacheRef` is a weak reference object containing two pieces of information: `tileId` (the unique identifier of the tile) and `localX`, `localY` (the coordinates of the node's position within the tile, relative to the top-left corner of the tile). The purpose of using weak references is to prevent the tile from being garbage collected due to the node proxy object holding a long-term reference to the tile. When the tile is destroyed, the node proxy object's `cacheRef` automatically becomes `undefined`. "If applicable" means that not all proxy objects are required to have a cacheRef. For example, a node may span multiple tile boundaries, and the system only selects the tile with the largest coverage area as its primary tile; other secondary tiles are not backreferenced. Additionally, the cacheRef of a node that has not yet been rendered (i.e., has never entered the viewport) is null; this field is only valid after the node has been rendered at least once. Behavioral Interfaces: These include multiple interfaces that call the following functions: updateLOD(zoom), markDirty(type), getRenderCommand(zoom, lod), etc. The functions called by each interface are described below: updateLOD (zoom) Definition: Receives the current canvas zoom level (zoom(float)). Internally, it calculates the new LOD level of the proxy object to be rendered based on a preset threshold and the node's own attributes, and compares it with the current LOD level of the proxy object. If a change occurs, it updates the current LOD level of the proxy object and calls markDirty('style').

[0029] Function: As the entry point for LOD decision-making, it transforms scaling changes into changes in the agent's internal state and triggers subsequent dirty marking.

[0030] markDirty(type) Definition: Receives a dirty flag type string 'pos' / 'state' / 'style'. Sets the corresponding dirtyFlags field to true and notifies the tile manager (via callback or event bus) of the tile ID where the node's proxy object resides.

[0031] Function: To achieve precise incremental updates, that is, only the smallest unit that has changed will trigger a redraw, avoiding irrelevant redraws.

[0032] getRenderCommand(zoom, lod) Definition: Receives the current scaling factor and the current LOD level of the proxy object to be rendered (usually the proxy's own lodLevel). Based on the static metadata and the current LOD level of the proxy object to be rendered, it returns an array of drawing instructions (e.g., [{type:'fillRect', params:...}, {type:'fillText', params:...}]).

[0033] Purpose: To decouple "how to draw" from "when to draw". Node proxy objects know their own visual representation, but the actual drawing is performed uniformly by the tile manager.

[0034] By creating a corresponding node proxy object for each original workflow node, the original workflow node is completely abstracted into a control proxy with state and behavior. Since the node proxy object does not contain any drawing logic or graphics object references, the node proxy object has a very low memory footprint. Each node proxy object occupies 2kB of memory, and 2000 node proxy objects only occupy 40MB.

[0035] A global spatial index is constructed for the node proxy object. The global spatial index adopts a quadtree structure to spatialize the location of the node proxy object.

[0036] The global spatial index is constructed for each node proxy object during node proxy pool initialization based on its position (x, y) and dimensions (width, height) in the world coordinate system. The method for constructing the global spatial index is as follows: Create a quadtree instance, set the world range covered by the root node (e.g., the entire workflow canvas range, such as [-50000, -50000] to [50000, 50000]), and set the maximum number of node proxy objects that each leaf node can hold (e.g., 4); then, traverse all node proxy objects, call the quadtree's insertion method, and insert the bounding boxes of the node proxy objects into the quadtree; during the insertion process, if a node exceeds its capacity limit, it will automatically split into four child nodes and the proxy objects will be redistributed.

[0037] A global spatial index is a mapping from spatial locations to node proxy objects; it stores the node proxy object itself (or its ID). The global spatial index does not contain business node data; it is only used for quickly finding node proxy objects within a specified region. Therefore, the essence of a global spatial index is "spatial region → collection of node proxy objects".

[0038] The mapping between node proxy objects and original workflow nodes is maintained separately as a one-to-one hash table. The global spatial index only cares about the spatial location of the node proxy object, not the business attributes of the original workflow node.

[0039] The structure of a quadtree node is as follows (in JSON representation): json { "bounds": { "x": -10000, "y": -10000, "width": 20000, "height":20000}, "capacity": 4, "points": [ proxy1, proxy2, proxy3, proxy4 ], "children": null / / When the number of points exceeds the capacity and a split occurs, children will have 4 child nodes. } Leaf nodes store proxy objects that fall directly within that area; non-leaf nodes do not store objects and are only used to guide queries.

[0040] Using a quadtree structure reduces the time complexity of viewport queries from O(N) (traversing all proxies) to O(log N) (only visiting branches of nodes intersecting with the viewport). For example, with 2000 nodes, traditional traversal requires 2000 comparisons, while the quadtree structure only requires about 20-30 node visits, significantly improving the efficiency of viewport pruning. Furthermore, the quadtree structure supports dynamic updates (when a node is moved, it is simply deleted from the original node and re-inserted), ensuring real-time performance during translation and dragging.

[0041] Step 2: Visualize the interval calculation and output the set of proxy objects for the nodes to be rendered. Using a global spatial index, quickly query the node proxy objects that intersect with the current viewport from the node proxy pool.

[0042] "The set of node proxy objects to be rendered" is a combination of node proxy objects that need to be processed, denoted as Set. <proxy>.

[0043] This "collection of proxy objects for nodes to be rendered" provides the operational basis for subsequent operations such as LOD decision-making, off-screen rendering, and interactive hits, so as to achieve lightweight operation.

[0044] Step 3: Adaptive LOD rendering (dynamic decision-making based on proxy state) S031. Iterate through each node proxy object in the collection of node proxy objects to be rendered, call the updateLOD(zoom) interface corresponding to the node proxy object to be rendered, and use the updateLOD(zoom) method to calculate the new LOD level of the node proxy object to be rendered based on the current canvas scaling ratio and translation.

[0045] For example, the LOD level can be set as follows: LOD 0 (Macro): zoom < 0.3 -> rectangular color block; LOD 1 (Overview): 0.3 ≤ zoom < 0.8 -> rectangle + title (8 characters); LOD 2 (Details): zoom ≥ 0.8 -> Full Details.

[0046] S032. Construct a "tile-proxy" mapping table to represent the mapping relationship between each node proxy object and the tiles. For example, each node proxy object corresponds to which tile(tileID).

[0047] The node proxy object checks whether its own LOD level has changed. If it has changed, such as from LOD1 to LOD2, the tile to which the node proxy object belongs is marked as a dirty tile, triggering the local redraw in step 4. If there is no change, no operation is performed, and the existing off-screen cache is reused directly.

[0048] The process of establishing the mapping relationship between node proxy objects and tiles is as follows: During system initialization, the index range of all tiles is calculated based on the world range of the canvas (e.g., [-100000, -100000] to [100000, 100000]) and the preset tile size (e.g., 256×256 pixels). For each node proxy object, calculate the range of tile row and column numbers it covers (from floor(x / tileSize) to floor((x+width) / tileSize)) based on its (x, y, width, height). Then, add the ID of the node proxy object to the Set of these tiles. <proxyid>middle; When a node moves, the set of old and new tiles is recalculated and the mapping table is updated.

[0049] The original workflow nodes are not directly associated with tiles; tiles are only directly associated with node proxy objects, which act as an intermediary layer between the original workflow nodes and the tiles. The original workflow nodes exist indirectly within a tile only through the node proxy object. This design ensures that business data does not intrude into the rendering system, and when business data changes, only the dirty flag of the proxy object needs to be updated, without manipulating the tile mapping.

[0050] Step 4: Incremental Off-Screen Rendering and Compositing Based on Tiles and Dirty Markers The off-screen rendering process is as follows: S041. Poll or receive dirty tile notifications from step 3, triggered by scaling, panning, or the node proxy object's own markDirty. The "trigger" here refers to the source of the dirty tile notification. The dirty tile notification can be generated by three situations: (1) the user zooms the canvas, (2) the user pans the canvas, and (3) the node proxy object itself calls the markDirty(type) method (e.g., business status change or position movement). All three situations will cause a tile to be marked as dirty and trigger subsequent off-screen rendering. "Its own markDirty": This refers to the markDirty(type) behavior interface implemented internally by the node proxy object. When the proxy object detects a change in its own attributes (such as a change in LOD level in step 3, or an external event causing a business state update), it will actively call this method to mark its own tile as dirty; S042. For each dirty tile, obtain a list of all node proxy objects that need to be rendered for that tile; this list of node proxy objects is the intersection of the set of node proxy objects to be rendered in step 2 and the node proxy objects corresponding to that tile. The specific process is as follows: When the LOD level of a node proxy object to be rendered changes, the node proxy object notifies the tile manager via markDirty, marking the tile it is located on as a dirty tile. In the rendering loop of the next frame, the tile manager iterates through all the dirty tiles; For each dirty tile, obtain all node proxy objects within that tile (via the forward index tile.proxySet) to form a complete list of node proxy objects; For each of the node proxy objects in the list to be rendered (including those whose LOD level has not changed), call getRenderCommand to regenerate the drawing instructions and redraw the entire tile.

[0051] The purpose of this step is to ensure that even though only a few proxy objects change, the entire tile must be redrawn to maintain the integrity of the graphics within the tile (e.g., to avoid remnants of old and new rendering). However, since the tile size is small (256×256), it typically contains only a few to a few dozen nodes, so the redrawing overhead remains extremely low.

[0052] S043. For each node proxy object in the list of node proxy objects to be rendered, call its getRenderCommand(zoom, lod) interface. The getRenderCommand(zoom, lod) method will dynamically generate a series of drawing instructions, such as fillRect, fillText, drawImage, etc., based on the current LOD level and stored metadata of the node proxy object to be rendered. The "stored metadata" here refers to static metadata, including ID, position (x, y), width / height, port definition, title, icon resource path, etc. When generating drawing commands, it is necessary to obtain information such as the node's title text, port coordinate offset, and icon drawing area based on the static metadata. Therefore, getRenderCommand internally accesses properties such as this.x, this.y, this.title, and this.ports, which are precisely the static metadata.

[0053] Specifically, the following is an example of generating drawing instructions based on the current LOD level and metadata of the proxy object to be rendered: Suppose we have a node proxy object with the following static metadata: { id: "node_abc123", x: 1200, / / World coordinates X y: 800, / / World coordinates Y width: 200, height: 80, title: "Data Cleaning Task" bizState: "running", / / Running ports: { inputs: [{ id: "in1", name: "Upstream Data"}], outputs: [{ id: "out1", name: "Cleaning Results"}] }, iconPath: " / icons / clean.png } Scenario 1: LOD Level 0 (Macro mode, zoom < 0.3) At this point, the node is rendered as a shadowed rectangular block of color, without displaying any text, icons, or ports.

[0054] The array of commands returned by getRenderCommand: [ { type: "fillRect", x: 1200, y: 800, w: 200, h: 80, fillStyle: "#9e9e9e", shadowBlur: 4, shadowColor: "rgba(0,0,0,0.3)" } ] Note: Only one rectangle fill instruction, extremely simple, with minimal GPU overhead.

[0055] Scenario 2: LOD Level 1 (Overview mode, 0.3 ≤ zoom < 0.8) Nodes are rendered as rectangular color blocks plus a node title (maximum 8 characters), without drawing ports or icons. [ / / Background rectangle { type: "fillRect", x: 1200, y: 800, w: 200, h: 80, fillStyle: "#bbdef5", shadowBlur: 2 }, / / Title text (maximum 8 Chinese characters) { type: "fillText", text: "Data cleaning...", / / Original 8-character truncation x: 1210, y: 840, font: "14px sans-serif", fillStyle: "#000000" } ] Note: Only two instructions, no port, no icon. Text position is calculated from coordinates in metadata (usually centered or offset).

[0057] Scenario 3: LOD Level 2 (Detailed mode, zoom ≥ 0.8) The node renders the complete style: rounded rectangle background, title, status icon, input / output port, description text, etc. [ / / 1. Rounded background rectangle { type: "fillRoundRect", x: 1200, y: 800, w: 200, h: 80, radius: 8, fillStyle: "#e3f2fd", strokeStyle: "#1976d2", lineWidth: 1 }, / / 2. Title Text { type: "fillText", text: "Data Cleaning Task" x: 1220, y: 830, font: "bold 14px sans-serif", fillStyle: "#0d47a1" }, / / 3. Status icon (image determined by bizState) { type: "drawImage", src: " / icons / running.gif", / / From metadata x: 1350, y: 810, width: 20, height: 20 }, / / 4. Input port (circle + port name) { type: "fillCircle", cx: 1200, cy: 830, r: 6, fillStyle: "#4caf50" }, { type: "fillText", text: "Upstream Data", x: 1212, y: 835, font: "10px sans-serif", fillStyle: "#333" }, / / 5. Output Port { type: "fillCircle", cx: 1400, cy: 850, r: 6, fillStyle: "#ff9800" }, { type: "fillText", text: "Cleaning Results", x: 1380, y: 855, font: "10px sans-serif", fillStyle: "#333" } ] Note: The number of instructions has increased significantly, including rounded rectangles, multi-segment text, images, circles, etc. Each instruction carries all the parameters required for rendering, which are derived from the static metadata of the node proxy object and the current business state (such as bizState determining the icon path).

[0059] S044. Apply the drawing instructions to the off-screen Canvas context corresponding to the tile for drawing; S045. During the compositing stage, drawImages of all clean tiles located in the viewport off-screen onto the main canvas in sequence.

[0060] Compared to the method of "redrawing only the visible area", this invention achieves redrawing only the smallest tile that has changed within the visible area by using dirty marking of tiles and node proxy objects; the update granularity is reduced from the entire visible area to a single tile (256x256 pixels, usually containing several to dozens of nodes). Taking a scene with 2000 nodes as an example, a state update only needs to redraw 1-2 tiles, and the time taken is reduced from 15ms to less than 2ms.

[0061] Step 5: Event delegation and synchronization based on proxy hit and LOD state When the canvas receives a click event, the world position is calculated based on the coordinates, and the target node proxy object Proxy_target is quickly found in the proxy pool through the global spatial index; The coordinates here refer to the screen pixel coordinates of the mouse pointer on the browser canvas (Canvas element), that is, (mouseX, mouseY) relative to the top-left corner of the Canvas. These coordinates are usually derived from the clientX and clientY properties of the click event, minus the position of the Canvas element relative to the viewport.

[0062] World position refers to the position in the workflow canvas that is mapped from screen coordinates back to the world coordinate system using the current canvas's transformation matrix (translation, zoom). The transformation formulas are: worldX = (mouseX - viewportX) / zoom, worldY = (mouseY - viewportY) / zoom, where (viewportX, viewportY) are the coordinates of the top-left corner of the current viewport in the world coordinate system.

[0063] After obtaining the world position (worldX, worldY) of the mouse click, the system calls the quadtree's queryPoint(worldX, worldY) method. The quadtree recursively starts from the root node: If the current node does not contain the point, return null; If the current node is a leaf node, iterate through all the node proxy objects stored for that node and check if the point falls within the bounding box of the node proxy object (x <= worldX <= x + width and y <= worldY <= y + height); return the first matching node proxy object (usually a point can match at most one node because nodes do not overlap). If the current node is a non-leaf node, then recursively search among the four child nodes that may contain the child node of this node.

[0064] Due to the spatial partitioning of the quadtree, the time complexity of each hit query is O(log N + M), where N is the total number of node proxy objects stored in the quadtree (global spatial index), that is, the number of all created proxies in the current workflow, and M is the number of node proxy objects in the leaf node (usually less than the capacity limit, such as 4), thus enabling fast hits.

[0065] Upon hitting the target node proxy object, the event proxy and synchronization module reads the current LOD level (lodLevel) of the target proxy object and implements the corresponding interactive response based on the current LOD level (lodLevel) of the target proxy object. When lodLevel = LOD0 (macro), only a floating tooltip will be displayed, showing the node name; When lodLevel=LOD1 (Overview), node highlighting is triggered, and clicking to select a node will trigger a selection, but the port will not be displayed. When lodLevel = LOD2 (details), full highlighting is triggered, displaying all ports and responding to connection operations, opening the details panel.

[0066] Through the above operations, the interactive feedback is consistent with the current user's visual perception, avoiding the problem of "seeing details but not being able to click on them" or "only seeing color blocks but popping up complex menus."

[0067] At the same time, the event is synchronized back to the workflow engine (updating the original workflow node state) and triggers markDirty in step 1, thus forming a complete data-driven closed loop.

[0068] The state updates here are triggered by user interactions (selection, dragging, connecting) or asynchronous messages from the engine itself. In this step, the event delegate module synchronizes the user's click / edit behavior back to the workflow engine. The engine modifies the state of the node according to the business logic (e.g., marking the node as "selected", or changing the node's association relationship due to connecting). Then, the workflow engine re-issues the data change notification. After receiving the notification, the delegate object calls markDirty, thereby driving step 4 to re-render.

[0069] Once the event is synchronized back to the workflow engine, the workflow engine may modify certain properties of the original workflow nodes (such as position, state, and port connections). To ensure these modifications are reflected on the canvas in real time, the workflow engine triggers a data change event. Upon receiving this event, the node proxy pool module identifies the affected node proxy object and calls its `markDirty(type)` method (where `type` could be `pos`, `state`, or `style`). This marks the corresponding tile as dirty, ultimately triggering an off-screen redraw in the next frame. This forms a closed loop: user action → event proxy → engine update → proxy marking dirty → tile redraw → user sees the result. This closed loop ensures that data, state, and rendering remain synchronized at all times, and that each step is executed with minimal granularity and maximum efficiency.

[0070] like Figure 2 The diagram shown is a flowchart of intelligent event interaction based on LOD state. The core feature of this step is that event processing is not separated from rendering details, but directly depends on the LOD level in the node proxy object.

[0071] The specific process is as follows: The user clicks on a graphic area on the canvas; The system quickly locates the node proxy object corresponding to the clicked node using a global spatial index based on the click coordinates. The system reads the lodLevel field maintained inside the node's proxy object. This lodLevel field is updated in real time by step 3 according to the current scaling ratio. Based on the lodLevel value, the system automatically selects different granularities of interactive responses: LOD0 (Macro Mode): Users can only see color blocks, and only simple name prompts are provided during interaction to avoid accidental operation; LOD1 (Overview Mode): Users can select nodes, but ports are not displayed, ensuring a clear interface; LOD2 (Detailed Mode): Users can perform fine-grained editing like a traditional workflow editor, such as connecting lines, viewing ports, and modifying properties; Finally, the event is synchronized back to the workflow engine to complete the business operation.

[0072] The above process ensures that users can interact with the content at the level of granularity they see, avoiding issues such as "accidentally clicking on a complex panel when viewing the entire screen" or "failing to accurately connect lines after zooming in."

[0073] Table 1 shows the performance comparison data between the adaptive rendering optimization method of this invention and the traditional full-scale rendering scheme and the simple viewport clipping scheme.

[0074] Table 1

[0075] The adaptive rendering optimization method of the present invention will be described in detail below with reference to specific embodiments.

[0076] Initial scene: The workflow engine outputs 2000 nodes, randomly distributed on a 10000×10000 pixel canvas. Each node contains a title, status, 2 input ports, and 2 output ports.

[0077] Traditional approach: The page attempts to render all 2000 nodes upon initialization, which takes more than 3 seconds for the browser to draw. The frame rate drops to single digits when scrolling or zooming, making it almost impossible to operate.

[0078] The process of using the adaptive rendering optimization method of this invention is as follows: Create node proxy objects: Create lightweight node proxy objects for each of the 2000 nodes, with a total memory usage of only about 40MB.

[0079] Initial rendering (default scaling 0.5): Calculates the world region corresponding to the current viewport (1920×1080), retrieving approximately 120 nodes using spatial indexing. Enters LOD1 level (overview mode), rendering only node rectangles and titles; initial screen rendering takes approximately 80ms. User zoom operation (zoom in to 1.2x): The viewport area shrinks, and the number of visible nodes is reduced to 45. The system automatically switches to LOD2 (detail mode) to render the complete node style.

[0080] By using incremental tile updates, only the 6 affected tiles are redrawn, with a single frame taking less than 16ms, resulting in a completely smooth user experience.

[0081] User drag-and-drop canvas operation: viewport pans, new tile enters the viewport; the system asynchronously renders the off-screen Canvas of the new tile in the background, the main thread is unblocked, and the panning operation frame rate is stable at 60FPS.

[0082] Node status update: After a node in the workflow engine completes execution, its status changes from "Running" to "Successful". The system locates the tile corresponding to the node through the agent, redraws only that tile (256×256), and performs a partial update on the main canvas, taking less than 2ms.

[0083] Using the method of this invention, users can obtain a near-native application-like smooth zooming, panning, and editing experience when editing a workflow containing 2000 nodes.

[0084] On the other hand, the present invention also provides an electronic device, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to execute the adaptive rendering optimization method for large-scale workflow engines by executing the executable instructions.

[0085] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned adaptive rendering optimization method for large-scale workflow engines.

[0086] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.< / proxyid> < / proxy>

Claims

1. An adaptive rendering optimization method for large-scale workflow engines, characterized in that, Includes the following steps: A unique node proxy object is created for each original workflow node to build a node proxy pool. The node proxy object includes static metadata, dynamic runtime state data and behavior interface. The static metadata includes the node's attribute data. The dynamic runtime state data includes the node proxy object's current rendering level, the screen / world boundary occupied during the last rendering, dirty flag, weak references pointing to its off-screen tile and local coordinates within the off-screen tile. Construct a global space index for the node proxy object, and based on the global space index, retrieve the node proxy object corresponding to the current viewport from the node proxy pool to obtain a set of node proxy objects to be rendered; Iterate through the collection of proxy objects for the nodes to be rendered, and calculate the current LOD level of the proxy objects for the nodes to be rendered based on the current canvas scaling ratio and the attributes of the proxy objects themselves. Establish a mapping relationship between node proxy objects and tiles. When the LOD level of a node proxy object changes, mark the tile corresponding to that node proxy object as a dirty tile. Poll or receive notifications of dirty tile markings, obtain the node proxy objects to be rendered corresponding to the tiles marked as dirty tiles, obtain all node proxy objects to be rendered, and form a list of node proxy objects; for each node proxy object in the list of node proxy objects, call the behavior interface of the node proxy object, and generate drawing instructions based on the current LOD level and static metadata of the node proxy object to be rendered. The corresponding tiles are rendered off-screen according to the drawing instructions.

2. The adaptive rendering optimization method for large-scale workflow engines according to claim 1, characterized in that, The behavior interface includes interfaces for calling the following functions, which are updateLOD(zoom), markDirty(type), and getRenderCommand(zoom, lod); The updateLOD(zoom) method is used to receive the current zoom level, calculate the new LOD level of the proxy object of the node to be rendered based on the preset threshold and the node's own attributes, and compare it with the current LOD level of the proxy object of the node to be rendered. If there is a change, the current LOD level of the proxy object of the node to be rendered is updated. The markDirty(type) is used to receive the dirty mark type string, set the corresponding dirty mark field to true, and notify the tile manager of the tile ID where the node proxy object is located; The getRenderCommand(zoom, lod) function receives the current zoom level and the current LOD level of the proxy object to be rendered. Based on the static metadata and the current LOD level of the proxy object to be rendered, it returns an array of drawing commands.

3. The adaptive rendering optimization method for large-scale workflow engines according to claim 1, characterized in that, The global spatial index uses a quadtree structure.

4. The adaptive rendering optimization method for large-scale workflow engines according to claim 1, characterized in that, The steps for off-screen rendering of the corresponding tiles according to drawing instructions include: Apply the drawing commands to the off-screen Canvas context of the corresponding tile for drawing; Composite the off-screen Canvas tiles located within the viewport onto the main canvas.

5. The adaptive rendering optimization method for large-scale workflow engines according to claim 1, characterized in that, When the current LOD level of the proxy object of the node to be rendered does not change, the corresponding off-screen cache is directly reused during rendering and compositing.

6. The adaptive rendering optimization method for large-scale workflow engines according to claim 1, characterized in that, After rendering the corresponding tiles off-screen according to the drawing instructions, the process also includes event delegation and synchronization steps, including: When the canvas receives a click event, it calculates the world position based on the coordinates and looks up the corresponding target node proxy object through the global spatial index. Get the current LOD level of the target node proxy object, and output the interaction response of the original workflow node corresponding to the target node proxy object based on the current LOD level of the target node proxy object and the corresponding response rules.

7. The adaptive rendering optimization method for large-scale workflow engines according to claim 6, characterized in that, The event proxy and synchronization steps include synchronizing events back to the workflow engine, updating the original workflow node state, and updating the data of the node proxy object.

8. An adaptive rendering optimization system for large-scale workflow engines, characterized in that, The adaptive rendering optimization method for large-scale workflow engines according to any one of claims 1-7 includes: The node proxy pool module is used to create node proxy objects, build the node proxy pool, and maintain a global space index. The viewport awareness and interval calculation module is used to listen for canvas changes, calculate the visible interval, query the node proxy pool, and output a set of node proxy objects to be rendered. The adaptive LOD scheduling module is used to calculate the current LOD level of each node proxy object to be rendered based on its scaling ratio and the node proxy object's own attributes, and generate corresponding rendering instructions. The tiled off-screen rendering engine manages virtual tiles and their off-screen canvases; it receives rendering instructions generated by the adaptive LOD scheduling module and executes drawing to the specified tiles. The event proxy and synchronization module is used to capture global events, query the corresponding node proxy object using the global space index, and determine the granularity of the interaction response of the corresponding original workflow node based on the current LOD level and response rules of the node proxy object, and synchronize it back to the workflow engine.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the adaptive rendering optimization method for a large-scale workflow engine as described in any one of claims 1-7 by executing the executable instructions.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the adaptive rendering optimization method for large-scale workflow engines as described in any one of claims 1-7.

Images