Node programming debugging method and system based on time axis, medium and product

Abstract

The invention discloses a node programming debugging method and system based on a time axis, a medium and a product, and relates to the technical field of computer software debugging, and the method comprises the steps: based on a registered monitor, collecting port change event data and rendering picture data of each node port, and according to a preset key frame interval strategy, obtaining a preset key frame interval; the method comprises the steps of generating a frame snapshot array composed of key frame snapshots and incremental snapshots, constructing a time axis index, determining historical state data corresponding to a target frame from the frame snapshot array in response to a time axis jump instruction, and reconstructing and visually displaying a node graph complete state of the target frame. Based on non-intrusive monitoring data acquisition, hybrid storage, time axis index positioning and accurate reconstruction, three technical problems that the state cannot be traced back, the observation dimension is single and the time sequence problem is difficult to position in the existing node programming debugging are solved; free jump, frame-level synchronous visualization and port-level efficient tracing of a complete state at any historical moment are realized.

Description

Technical Field

[0001] This application relates to the field of computer software debugging technology, and in particular to a time-axis-based node programming debugging method, system, medium, and product. Background Technology

[0002] In the field of visual programming technology, node-based programming, as a paradigm that expresses program logic through graphical nodes and connections, has been widely applied in many scenarios such as game development, audio and video processing, and data stream computing due to its intuitiveness, low programming threshold, and support for real-time preview. For example, in game engines, developers use blueprints or visual scripting systems to build complex game logic.

[0003] Currently, traditional techniques for debugging node programs mainly include: First, breakpoint debugging, where developers set breakpoints at specific nodes, pausing program execution at those points to allow viewing the current state. This method is essentially "one-way forward," meaning that once the program resumes, the previous state cannot be viewed again, and the program must be run again. For intermittent issues, developers often need to repeatedly start and stop the program, resulting in extremely low debugging efficiency. Furthermore, for asynchronously executed or concurrently triggered nodes, breakpoint debugging makes it difficult to observe their timing relationships. Second, log output debugging, as a supplement to breakpoint debugging, requires developers to manually add log output code (such as printing strings) at nodes of interest, which is labor-intensive and prone to omissions. Developers must also anticipate potential problem nodes and variables, and if insufficient information is found afterward, logs must be added and the program run again. In addition, the log information output by breakpoint debugging is in plain text format, making it difficult to correlate with the visual representation of the scene, hindering intuitive location of the problem's occurrence. Moreover, once the log is output, it cannot be modified; if different combinations of variables need to be viewed, the log must be reconfigured and the program rerun.

[0004] Therefore, existing node programming and debugging tools are fundamentally inadequate in terms of state backtracking capabilities, multi-node state synchronization observation capabilities, and the ability to correlate internal states with visual representations. Summary of the Invention

[0005] The purpose of this application is to provide a time-axis-based node programming debugging method, system, medium, and product that solves three major technical problems in existing node programming debugging: inability to trace back the state, single observation dimension, and difficulty in locating timing issues. It enables free jump to the complete state at any historical moment, frame-level synchronous visualization, and efficient port-level tracing.

[0006] To achieve the above objectives, this application provides the following solution: In a first aspect, this application provides a time-axis-based node programming debugging method, comprising: responding to user debugging configuration parameters, during the execution of a node graph program, collecting port change event data of each node port based on a registered listener, and capturing rendering screen data corresponding to the node graph program; generating a frame snapshot array composed of keyframe snapshots and incremental snapshots according to a preset keyframe interval strategy and the port change event data; wherein, the keyframe snapshot contains complete port state data of all nodes in the node graph, and the incremental snapshot records port data that has changed relative to the previous keyframe snapshot; constructing a time axis index for frame-by-frame positioning based on the frame snapshot array; responding to a time axis jump command generated by user operation, determining historical state data corresponding to the target frame from the frame snapshot array according to the time axis index; and reconstructing and visually displaying the complete state of the node graph of the target frame based on the determined historical state data.

[0007] Optionally, the listener includes a port update listener; the collection of port change event data of each node port includes: registering the port update listener when the node graph program is running; and collecting the port change event data in response to the port change events of each node port through the port update listener.

[0008] Optionally, the listener includes a rendering frame listener; capturing the rendering screen data corresponding to the node graph program includes: registering the rendering frame listener when the node graph program is running; using the rendering frame listener, when the rendering frame is completed, determining whether the current frame needs to perform a screenshot operation according to a preset rendering screenshot configuration; if so, obtaining the image data of the current frame through an asynchronous reading mechanism provided by the graphics interface; performing screen change detection on the image data of the current frame; when the screen change detection meets a preset change, compressing the image data of the current frame through an independent image compression thread and using it as the rendering screen data; when the screen change detection does not meet the preset change, discarding the image data of the current frame and reusing the image data of the previous screenshot frame as the rendering screen data.

[0009] Optionally, the screen change detection includes: comparing whether the hash value of the current frame is the same as the hash value of the previous screenshot frame; if they are the same, the screen change detection conforms to a preset change; if they are not the same, the screen change detection does not conform to the preset change.

[0010] Optionally, generating a frame snapshot array consisting of keyframe snapshots and incremental snapshots based on a preset keyframe interval strategy and the port change event data includes: in response to a port change event, creating a snapshot object corresponding to the current frame, and determining whether the current frame is a key frame based on the current frame index and the keyframe interval strategy; if the current frame is a key frame, creating and recording keyframe snapshot data in the snapshot object, the keyframe snapshot data containing complete port status data of all nodes in the node graph program; if the current frame is not a key frame, creating and recording incremental snapshot data in the snapshot object, the incremental snapshot data containing only the port data that changed in the port change event; and storing the snapshot objects in a memory snapshot buffer in frame index order to form the frame snapshot array.

[0011] Optionally, it further includes: monitoring the storage status of the memory snapshot buffer; when the number of snapshot objects stored in the memory snapshot buffer reaches a preset threshold, packaging, serializing and archiving all data in the frame snapshot array to a local file; after archiving is completed, clearing the memory snapshot buffer and updating the timeline index to record the archived position of the data.

[0012] Optionally, the step of reconstructing and visualizing the complete node graph state of the target frame based on the determined historical state data includes: locating the most recent keyframe snapshot before the target frame from the frame snapshot array to obtain a baseline complete state; obtaining all corresponding incremental snapshots from the frame snapshot array between the most recent keyframe snapshot and the target frame, and constructing an incremental snapshot sequence in sequence; and applying the port data changes recorded in the incremental snapshot sequence in chronological order based on the baseline complete state to obtain the complete node graph state of the target frame.

[0013] Secondly, this application provides a time-axis-based node programming debugging system, including a runtime monitoring layer, a debugging engine layer, a storage layer, and a user interface layer. The runtime monitoring layer is used to monitor node port value change events and rendering frame completion events during the execution of the node graph program. The debugging engine layer is connected to the runtime monitoring layer, storage layer, and user interface layer, and is used to: respond to user debugging configuration parameters, collect port change event data and rendering screen data of each node port based on the runtime monitoring layer; generate a frame snapshot array consisting of keyframe snapshots and incremental snapshots according to a preset keyframe interval strategy and the port change event data, and control the storage layer to store the snapshots; wherein, the keyframe snapshots... The incremental snapshot records port data that has changed relative to the previous keyframe snapshot, based on the complete port status data of all nodes in the node graph. A timeline index for frame-by-frame positioning is constructed based on the frame snapshot array. In response to a timeline jump command issued by the interface layer, historical state data corresponding to the target frame is determined from the storage layer according to the timeline index, and the complete node graph state of the target frame is reconstructed. The storage layer stores the frame snapshot array and the timeline index. The interface layer provides a debugging configuration interface, a timeline control interface, receives user operations to generate the timeline jump command, and visually displays the complete node graph state reconstructed by the debugging engine layer and the rendered screen.

[0014] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the time-axis-based node programming and debugging method described above.

[0015] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the time-axis-based node programming and debugging method described above.

[0016] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a time-axis-based node programming debugging method, system, medium, and product. It uses a registered listener for non-intrusive data acquisition, completely recording port change event data and rendered screen data during runtime. Efficient storage is achieved using a frame snapshot array composed of keyframe snapshots and incremental snapshots. When a user selects a target frame via a time-axis jump command, the system can quickly determine the historical state data corresponding to the target frame based on the time-axis index and reconstruct the complete state of the node graph for that target frame. This allows developers to freely backtrack to any frame before the problem occurred and directly view the precise internal state of all nodes at that moment, without repeatedly running the program to try to reproduce the problem. Traditional debugging tools (such as breakpoints) can only observe the instantaneous state of isolated nodes, making it difficult to understand cross-node and cross-time sequence data flow and causal relationships. This application addresses this by synchronously acquiring port change event data and rendered... The system displays video data and visualizes it during backtracking. It precisely binds the internal data flow with the external visual presentation through a timeline index. In the debugging interface, developers can simultaneously see the rendered video of the target historical frame, as well as the specific value of each port in the node graph at that moment, and can intuitively identify which ports have changed in this frame. Traditional debugging relies on pre-set points, single-step execution, and analysis of log text, which is lengthy and easy to get lost in a large amount of information. This application constructs a timeline index for frame-by-frame positioning. Developers can first quickly browse the continuous historical rendered video to determine the precise frame number where the problem occurred, and then instantly switch to that frame using the timeline jump command. Without inserting a large number of logs or setting multiple breakpoints in the code, they can immediately obtain the global context of the moment the problem occurred, which can shorten the investigation process that originally took several hours or even longer to within a few minutes. Attached Figure Description

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

[0018] Figure 1 A schematic diagram of the functional modules of a node programming and debugging system based on a time axis provided in an embodiment of this application; Figure 2 A complete flowchart illustrating a time-axis-based node programming and debugging method provided in one embodiment of this application; Figure 3 for Figure 2 A detailed flowchart of step S1 in the middle section; Figure 4 for Figure 2 A detailed flowchart of step S2 in the middle section; Figure 5 for Figure 2 A detailed flowchart of step S3 in the middle section; Figure 6 for Figure 2 A detailed flowchart of step S4 in the middle section; Figure 7 for Figure 2 A detailed flowchart of step S6 in the middle section; Figure 8 for Figure 2 A detailed flowchart of step S7 in the middle. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] System Implementation Examples Reference Appendix Figure 1 This embodiment provides a time-axis-based node programming and debugging system. The system's logical architecture includes a runtime monitoring layer, a debugging engine layer, a storage layer, and a user interface layer. These layers communicate with each other through predefined interfaces or an event bus.

[0022] The runtime listener layer serves as a non-intrusive data acquisition interface, dynamically registering listeners during the runtime of the node graph program. Specifically, this includes: Port Update Listener: This listener is registered with the Node Engine's runtime environment when debug starts. The Node Engine triggers this listener whenever the input or output port value of any node changes. The port update listener captures port change event data, which includes at least the changed node identifier, port identifier, new value, and timestamp, and transmits this port change event data to the data collector in the debug engine layer in real time.

[0023] Render Frame Listener: This listener registers with the rendering engine when debugging starts. Whenever a frame is rendered, the rendering engine triggers the listener. The listener captures trigger data related to the rendered frame. This data includes at least the rendering buffer, frame index, and rendering completion timestamp of the current frame. This data is transmitted in real time to the data collector in the debugging engine layer for subsequent generation of rendered frame data.

[0024] The debugging engine layer is the core processing unit, containing multiple cooperating components responsible for data acquisition, management, reconstruction, and control. Specifically, the debugging engine layer includes: Data collector: Works in conjunction with the runtime listening layer to receive and process data from the listener. For port change event data, the data collector records the port change and determines whether to generate a keyframe snapshot or an incremental snapshot based on the configured keyframe interval strategy (e.g., one keyframe every 10 frames), providing input to the snapshot manager. For trigger data related to rendering, the data collector determines whether a screenshot is needed based on the configured screenshot interval ratio. If so, it initiates the GPU asynchronous read-back process: First, the rendering buffer is downsampled on the GPU according to the preset screenshot scaling ratio. Then, the pixel data is asynchronously read back to memory through a graphics interface (such as OpenGL's PBO or WebGPU's mapAsync). After the read-back is complete, the image change detection module in the data collector calculates the hash value of the current frame image and compares it with the hash value of the previous saved frame to perform image change detection. If the image has not changed, it is marked as reusing the previous frame image. If the image has changed, the pixel data is sent to an independent image compression thread (such as Web Worker) to encode the pixel data into JPEG format. The compressed JPEG data, frame index, and image size are encapsulated to form the rendering image data. After compression, the rendering image data is associated with the corresponding snapshot object through the frame index.

[0025] Snapshot Manager: Responsible for the storage, compression, archiving, and indexing management of snapshot data. Specifically, the Snapshot Manager receives input from the data collector and the keyframe interval strategy, and creates a snapshot object for the current frame. If the current frame is determined to be a keyframe, the complete port status data of all nodes is recorded in the object, i.e., a keyframe snapshot; if it is not a keyframe, only the port data that has changed in this frame is recorded in the object, i.e., an incremental snapshot. These snapshot objects form a frame snapshot array in sequence. In addition, the Snapshot Manager manages the memory snapshot buffer, storing newly created snapshot objects in the order of frame index, and continuously monitors the storage status of the memory snapshot buffer; when the number of snapshot objects stored in the buffer reaches a preset threshold (i.e., the upper limit of the number of frames to be retained in memory), the Snapshot Manager performs memory management and data archiving steps: all data in the current frame snapshot array is packaged, serialized, and optionally compressed, and then archived to a local archive file; after archiving is completed, the memory buffer is cleared, and the timeline index is updated to record the data archiving position.

[0026] State Reconstructor: Responsible for reconstructing the complete state of the target frame based on historical snapshots. It is invoked when the user performs timeline backtracking to perform the steps of reconstructing the complete state of the node graph of the target frame.

[0027] Timeline Controller: Responds to timeline jump commands generated by user actions. Specifically, the timeline controller receives user commands from the interface layer, such as slider dragging, play, and pause, verifies the validity of the target frame, and coordinates the work of the snapshot manager, state restorer, and interface layer. For example, when the user jumps, the controller instructs the snapshot manager to check and load the required data (reading from disk if the data is in an archive file), then calls the state restorer to restore the state, and finally notifies the interface layer to update the display.

[0028] The storage layer provides efficient data access for the system. The storage layer includes: Memory snapshot buffer: Used to cache currently being acquired or recently accessed historical snapshot objects, providing instant access to "hot data". Additionally, an archive data cache can be set up as an intermediate cache to temporarily store data loaded on demand from local archive files.

[0029] Local archive files: A "cold data" repository stored on disk in the form of files, used to persistently store historical frame snapshot array data that exceeds the memory buffer capacity, supporting offline saving and analysis of long-term debugging sessions.

[0030] Timeline Index: This is a data structure built and maintained by the snapshot manager. For each frame, it records information such as its frame index, timestamp, whether it is a keyframe, data storage location (in the memory snapshot buffer or in the local archive file), number of changed ports, and screenshot status. The timeline index is built based on the frame snapshot array and is the core data structure for achieving fast frame-by-frame location.

[0031] The interface layer provides users with an intuitive graphical user interface for visual presentation. Specifically, it includes: Node Graph Editor Panel: Displays nodes and connections graphically. In backtracking mode, this panel shows the complete node graph state of the target frame provided by the state reconstructor, i.e., the values ​​of all ports at that historical moment. Simultaneously, the system highlights ports that changed during that frame.

[0032] Timeline Control Panel: Provides a visual timeline, typically represented as a draggable slider with keyframe positions marked. The panel includes control buttons for play, pause, previous frame, next frame, and jump to previous / next keyframes. Users generate timeline navigation commands by manipulating this panel.

[0033] Scene Preview Window: Used to display the rendered screen data corresponding to the currently selected frame, i.e. the rendered screenshot, which is strictly synchronized with the node graph state.

[0034] Method Implementation Examples A preferred embodiment of the time-axis-based node programming and debugging method described in this application is described in detail below with reference to the accompanying drawings. This embodiment is executed by a computer device configured as the system described above.

[0035] The complete process of node programming and debugging methods based on timelines, such as Figure 2 As shown, the method specifically includes: S1, in response to the user's debug configuration parameters, initializes the debug environment and establishes a listening channel.

[0036] S2, based on the registered port update listener, collects port change event data of each node port, and generates a frame snapshot array consisting of key frame snapshots and incremental snapshots according to the preset key frame interval strategy.

[0037] S3, based on a registered render frame listener, captures the render screen data corresponding to the node graph program.

[0038] S4, data acquisition complete. Construct a time axis index for frame-by-frame positioning based on the frame snapshot array.

[0039] S5, in response to the timeline jump command, determines the historical state data corresponding to the target frame.

[0040] S6 reconstructs and visualizes the complete state of the node graph of the target frame.

[0041] S7 displays the target frame rendering screenshot and debug node graph interface.

[0042] The process of each stage is explained in detail below.

[0043] For step S1, such as Figure 3 As shown, it specifically includes: S11 receives the user's debugging configuration parameters.

[0044] Specifically, the debug engine's data collector receives user-configured debug settings and verifies their validity. Debug settings include: Node data acquisition configuration: includes target acquisition frame rate (e.g., 20 frames per second) and key frame interval (e.g., one key frame every 10 frames).

[0045] Rendering screenshot configuration: includes screenshot scaling ratio (e.g., 1:4, 1:2, 1:1) and screenshot interval ratio (e.g., 3:1, i.e., take a screenshot once every 3 frames).

[0046] Memory management configuration: Includes an optional upper limit on the number of frames that can be kept in memory (e.g., 1000 frames).

[0047] After receiving the debug configuration parameters configured by the user, verify the validity of the parameters. If the parameters are missing or invalid, use the system default configuration.

[0048] S12: Initialize the snapshot storage data structure.

[0049] Specifically, the system debugging environment is initialized based on the verified configuration parameters. Initialization includes: calculating the acquisition time interval based on the target acquisition frame rate, such as time interval = 1000 milliseconds ÷ target frame rate; creating a memory snapshot buffer; initializing a frame snapshot array to store the acquired snapshot data, used to sequentially store each subsequent frame snapshot; initializing the current frame index to 0; and creating a timeline index data structure for recording metadata for each frame. This ultimately forms the initialized snapshot storage data structure.

[0050] S13: Register a listener with the node engine runtime to build a listening channel.

[0051] Specifically, the system registers listener callback functions with the node engine and rendering engine in a non-intrusive manner to establish a non-intrusive data acquisition channel. This includes registering a port update listener to monitor node port value changes and a rendering frame listener to monitor rendering completion events for each frame. After successful listener registration, the system enters a real-time data acquisition loop. Furthermore, during the registration process, the system verifies successful listener registration; if registration fails, an error message is returned.

[0052] For step S2, such as Figure 4 As shown, it specifically includes: S21, responds to the port update listener trigger event.

[0053] Specifically, when the port value changes, the port update listener is triggered, and the data collector receives the event data, which is the port change event data, and includes at least: node identifier, port identifier, new value, and timestamp.

[0054] S22, Create / Get the current snapshot object.

[0055] Specifically, the data collector checks whether a corresponding snapshot object already exists for the current frame index; if not, it creates a new snapshot object and records the current frame index and timestamp; then, based on the keyframe interval strategy, it determines whether the current frame is a keyframe. The keyframe interval strategy calculates the remainder of "current frame index divided by keyframe interval," and if the remainder is 0, it is marked as a keyframe.

[0056] S23, record port data changes to an incremental snapshot.

[0057] Specifically, regardless of whether it is a keyframe, the system records the port change event data of this time through deep copy processing into the change data container of the current snapshot object. This container is used to store incremental snapshot data.

[0058] S24: If the current frame is determined to be a keyframe, record the complete state to the keyframe snapshot.

[0059] Specifically, if the current frame is determined to be a keyframe, the system traverses all nodes in the node graph, reads and deeply copies the current value of each port, performs a deep copy of each port value, uses the node identifier as the first-level index and the port identifier as the second-level index, stores the complete data of all ports to construct complete state data, and records the complete state data as a keyframe snapshot in the snapshot object of the current frame.

[0060] S25: Store the snapshot object of the current frame into the memory snapshot buffer and manage the memory.

[0061] Specifically, after data recording is completed, the snapshot object of the current frame is stored in the frame snapshot array. 2. The current frame index is updated, and the index value is incremented by 1. If the current frame is a keyframe, the most recent keyframe cache is updated. The system continuously monitors the storage status of the memory snapshot buffer. When the memory snapshot buffer reaches the preset upper limit of the number of frames to be retained in memory, memory management and data archiving are triggered. This involves serializing the entire frame snapshot array (e.g., converting it to JSON), optionally compressing it, and writing it to a local archive file. Subsequently, the array in memory is cleared to receive new data, and the data position information of the relevant frames in the timeline index is updated.

[0062] For step S3, such as Figure 5 As shown, it specifically includes: S31: Responds to the render frame listener and determines whether a screenshot is needed.

[0063] Specifically, when a frame is rendered, the rendering frame listener is triggered, and the data collector receives trigger event data related to the rendered screen. This data includes the rendering buffer, frame index, and rendering completion timestamp. Based on the configured screenshot interval ratio, it is determined whether the current frame needs to be captured. For example, when the interval is 3:1, a screenshot is only performed when the frame index is 0, 3, 6, etc. If the screenshot condition is met, step S32 continues; if the screenshot condition is not met, the current frame's snapshot object is marked as reusing the image data of the previous screenshot frame as the rendered screen data.

[0064] S32: Obtain the image data of the current frame through the asynchronous reading mechanism provided by the graphics interface.

[0065] Specifically, if a screenshot is required, the system executes an asynchronous read mechanism. First, the target resolution is determined on the GPU based on the screenshot scaling ratio. If the target resolution is smaller than the original resolution, scaling is performed on the GPU to avoid full-resolution data transmission, significantly reducing data transfer volume. Then, an asynchronous readback request is initiated by calling a graphics API to transfer image data from GPU memory to CPU memory in a non-blocking manner. This process does not block the main rendering thread. This involves calling graphics APIs such as WebGPU's `mapAsync` and Unity's `AsyncGPUReadback.Request`.

[0066] S33: Image change detection and compression processing.

[0067] Specifically, after the GPU finishes reading back, the scaled image data is obtained in the callback, and the system performs screen change detection: calculates the hash value of the current frame image and compares it with the hash value of the saved image of the previous frame.

[0068] If the hash values ​​are the same, it means that the screen change detection does not meet the preset change, the current image data is discarded, and it is marked as "reuse the previous screenshot frame" in the current frame snapshot object.

[0069] If the hash values ​​are different, it means that the image change detection matches the preset change. The new hash value is saved, and the image data along with the frame index is submitted to a separate image compression thread (such as a Web Worker) for JPEG encoding. The main thread does not wait for compression to complete and continues to process subsequent rendering frames.

[0070] S34: Asynchronous data alignment and association.

[0071] Specifically, once the image compression thread is complete, it returns the compressed rendered image data (JPEG format) and the corresponding frame index. The system uses the frame index as the key to accurately locate the snapshot object of the corresponding frame in the frame snapshot array, and stores the rendered image data in the snapshot object, recording image-related metadata (such as image data size, original image resolution, and image compression completion timestamp), thus completing the three-dimensional synchronization of frame-data-image.

[0072] S35: Render screenshot data and archive it to a local file.

[0073] Specifically, to manage the ever-increasing image data, the system continuously monitors the number of frames containing rendered screenshot data. When this number reaches the preset upper limit for the number of frames to be retained in memory, an archiving process for the rendered screenshot data is automatically triggered. This archiving process involves: uniformly packaging the rendered screen data within all snapshot objects in the memory snapshot buffer by frame index and then writing it to a local archive file; recording the image archive index, which includes information such as file path, frame range, number of images, and file size; simultaneously, replacing the original image data in the corresponding snapshot object with a lightweight archive file reference (including the file path and data offset within the file); and finally, clearing the archived original image data from memory to release memory space.

[0074] This mechanism allows frequently accessed recent data to be stored in memory as "hot data," while historical data, as "cold data," is loaded from the disk on demand, achieving efficient hierarchical storage management.

[0075] For step S4, such as Figure 6 As shown, it specifically includes: S41, stop real-time data acquisition and wait for the asynchronous task to complete.

[0076] Specifically, when the user pauses or the node graph program ends, real-time data acquisition stops, the system stops receiving new listening events, and waits for all initiated GPU asynchronous readback and image compression tasks to complete, ensuring data integrity.

[0077] S42: Batch build timeline indexes.

[0078] Specifically, the system iterates through the complete array of frame snapshots, generating a record for each frame in the timeline index. The record information includes: frame index, timestamp, whether it is a keyframe, data location (memory / archive file), number of changed ports, screenshot status, and data size. This index supports quick location by frame number.

[0079] S43: Render the timeline interface and switch modes.

[0080] Specifically, the system renders a timeline slider on the timeline control panel in the interface layer, ranging from frame 0 to the last frame, and marks the positions of all keyframes. Subsequently, the system state officially switches from "acquisition mode" to "backtracking mode".

[0081] Step S5 specifically includes: When a user drags a slider or clicks a jump button on the timeline control panel, the interface layer generates a timeline jump instruction and passes it to the debugging engine layer. The timeline controller receives this instruction, extracts the target frame index, and queries the timeline index to verify its validity (e.g., whether it is within the valid frame range) and obtains the target frame's metadata (e.g., whether it is a keyframe, data storage location). If the timeline index indicates that the data required for the target frame (e.g., keyframe snapshots, incremental snapshot sequences) is already stored in a local archive file, the system loads the required data range from that file into memory for subsequent reconstruction. This timeline index indicates the data required for the target frame, which is the historical state data corresponding to the target frame used for reconstruction in subsequent steps.

[0082] For step S6, such as Figure 7 As shown, it specifically includes: S61: Locate the nearest keyframe corresponding to the target frame.

[0083] Specifically, firstly, based on the target frame index and the keyframe interval strategy, the index of the nearest keyframe preceding the target frame is calculated. The calculation method is as follows: the nearest keyframe index equals the target frame index divided by the keyframe interval, then rounded down, and finally multiplied by the keyframe interval. For example, if the target frame index is 47 and the interval is 10, then the nearest keyframe index is 40. This step determines the accurate baseline for state reconstruction.

[0084] S62: Obtain the complete state data of the most recent keyframe.

[0085] Specifically, the snapshot object of the frame corresponding to the most recent keyframe index is retrieved from memory (the data was loaded in step five or already exists), and the keyframe snapshot data is extracted from it, which is the complete port status data of all nodes in the node graph at that moment. This data will serve as the baseline complete state for reconstruction. The system will verify the integrity of this data. If the data is incomplete or corrupted, an error message will be returned, and the backtracking operation will be terminated.

[0086] S63: Obtain the incremental snapshot sequence before the target frame.

[0087] Specifically, the frame range starting from the nearest keyframe index + 1 and ending at the target frame index is determined. From the frame snapshot array, the frame snapshot object corresponding to each frame within this range is sequentially retrieved, and its recorded incremental snapshot data is extracted. These incremental snapshots are arranged in order of frame index to form an incremental snapshot sequence. If the target frame is the keyframe, this sequence is empty.

[0088] S64: Apply incremental snapshots to reconstruct the complete state of the node graph of the target frame.

[0089] Specifically, a deep copy is performed on the acquired baseline complete state data to generate an independent state copy. This operation aims to avoid modifying the original snapshot data and ensure the purity of the data source. Next, each incremental snapshot in the incremental snapshot sequence is traversed in chronological order. For each incremental snapshot, every port change record in its change data container is traversed. Based on the node identifier and port identifier in the record, the corresponding port is located in the state copy, and the value in the state copy is updated with the new port value from the record. When all changes from the incremental snapshots in the sequence have been applied, the resulting state copy is the complete state of the node graph of the target frame. The reconstructor can perform a final verification, such as checking whether the necessary ports have values, and then output it, indicating that the complete state of the node graph of the target frame has been successfully reconstructed and is ready for visualization in the next step.

[0090] For step S7, such as Figure 8 As shown, it specifically includes: S71: Get and display a rendered screenshot of the target frame.

[0091] Specifically, the storage status of the rendered image data is determined based on the screenshot status field in the snapshot object of the current frame. There are three statuses: data in memory, marked as "reusing the previous screenshot frame," and data missing. If the data is in memory (or has been loaded from an archive file), the rendered image data (JPEG format) is read directly. If marked as "reusing the previous screenshot frame," the corresponding frame's snapshot object is located based on the recorded reused frame index, and its rendered image data is obtained. If the data is missing, a "screenshot data missing" message or placeholder image is prepared for display. Then, the current content of the scene preview window is cleared, the acquired compressed image data is decoded, and the decoded image is rendered onto the window's canvas. Simultaneously, a "backtracking mode" identifier can be overlaid on the screen to distinguish it from the real-time running screen.

[0092] S72: Update the node graph interface and highlight the changed ports.

[0093] Specifically, the complete state data of the node graph of the target frame provided by the state reconstructor is traversed, and the value of each port at that historical moment is updated to the port display area of ​​the corresponding node in the interface. From the change data container (which stores incremental snapshot data) of the snapshot object of the current frame, the ports whose values ​​have changed in this frame are identified. On the node graph interface, highlighting effects (such as changing colors or adding borders) are added to the visual elements of these ports to highlight the ports that have changed, making the key changes in the data flow immediately apparent. After completing the above updates, the rendering of the entire node graph editor panel is refreshed to ensure that all changes are visible to the user.

[0094] S73: Provides backtracking interaction functionality.

[0095] Specifically, after visualizing the target frame, the system maintains full backtracking interactivity, allowing users to continue exploring historical states. Users can continue to drag sliders or use buttons (previous / next frame, jump to keyframe) to generate new timeline jump commands. Control options such as exiting backtracking mode and adjusting backtracking playback speed are provided. View operations (such as zoom and pan) in the node graph editor panel remain available, facilitating detailed viewing of complex node networks.

[0096] To demonstrate the practical effects of this application, two application scenario examples are provided below: Application Scenario Example 1: In the development of a role-playing game (RPG), the skill damage calculation system is implemented using a node graph consisting of 18 nodes. Node functions cover base damage calculation, attribute bonuses, critical hit determination, critical hit coefficient calculation, and target defense reduction. During testing, it was found that skill damage would occasionally become abnormally high (e.g., base damage of 290 points could result in 5800 points), severely disrupting game balance. Because this was a low-probability, random occurrence, the problem was difficult to reproduce reliably, and traditional debugging methods were extremely inefficient.

[0097] The debugging process using the method and system described in this application is as follows: 1. Enable debugging and configure parameters: The developer starts the debugging mode of the node graph program, responds to the user's debugging configuration parameters, sets the target acquisition frame rate to 30fps, the key frame interval to 10 frames, the screenshot scaling ratio to 1:4, the screenshot interval ratio to 1:1 (i.e., screenshot every frame), and sets the upper limit of the number of frames retained in memory.

[0098] 2. Non-intrusive Operation and Data Acquisition: Based on registered listeners, including port update listeners and rendering frame listeners, the system automatically collects port change event data of each node port during game operation and skill release testing, and synchronously captures the rendered screen data of the game scene. According to the keyframe interval strategy, the system generates a frame snapshot array in memory consisting of keyframe snapshots and incremental snapshots.

[0099] 3. Locating the problem frame: During the 12th skill release test, abnormal damage (5800 points) was reproduced in the game screen. The developers immediately paused the program. After the system completed all asynchronous tasks, it automatically built a timeline index based on the frame snapshot array and rendered the timeline interface.

[0100] 4. Timeline Backtracking and Visual Analysis: Developers can quickly pinpoint the visual anomaly (sudden increase in damage numbers) at frame 168 by observing continuous rendering screenshots in the scene preview window on the timeline control panel.

[0101] 5. Port-level historical traceability: Developers jump back a few frames on the timeline and observe the changes in the input port values ​​of the nodes. They find that the "critical hit coefficient" value received by the node suddenly changes from the normal 2.0 to 20.0 at frame 165.

[0102] 6. Locating the root cause of the error: Jump to frame 165 and check the input port of the critical hit coefficient calculation node. It was found that the original value read from the configuration was 200 (stored as a percentage of 200% in the configuration file).

[0103] 7. Root cause of the problem: The critical hit coefficient calculation node should divide the percentage value by 100 to convert it into a multiple (200% → 2.0), but the code logic incorrectly divides it by 10 (200 ÷ 10 = 20.0).

[0104] 8. Fix and Verification: The developers fixed the division logic inside the node, re-run the game and conducted multiple tests. The abnormally high damage no longer occurred, and the problem was resolved.

[0105] Technical Results: Using the system and method described in this application, developers can pinpoint the root cause of the problem (incorrect division denominator) within approximately 3 minutes through rapid visual localization based on a timeline and precise historical backtracking of port-level data. In contrast, using traditional methods, developers would need to guess which node might be causing the error among 18 nodes, repeatedly add logs, restart the game, trigger low-probability critical hits, and manually link log text with game visuals. This entire process typically takes 1-2 hours or even longer.

[0106] Application Scenario Example 2: In a physics simulation system, the node graph contains approximately 30 nodes for collision detection, force calculation, position updating, etc., used to simulate the motion of an object. During testing, it was found that the object undergoes an abnormal instantaneous displacement, jumping to an incorrect position, three seconds after the simulation begins.

[0107] Debugging process using the method and system described in this application: 1. Configuration and Acquisition: Developers enable timing debugging mode and set a high acquisition precision; the target acquisition frame rate is 60fps (to capture rapid changes), the key frame interval is 10 frames, and the screenshot interval is 1:1 for detailed analysis.

[0108] 2. Run and record: When the physics simulation starts, the system automatically records 180 frames (3 seconds × 60fps) of the complete running history within 3 seconds, including the internal data of all physical nodes and the scene rendering screenshots at each moment.

[0109] 3. Locating abnormal moments through visual observation: After the simulation ends, the developers manipulate the timeline and quickly browse the rendered screenshot sequence in the scene preview window. Through visual observation, they can clearly and intuitively confirm that the abnormal displacement of the object first appears on the screen at frame 178.

[0110] 4. Analyzing Abnormal Frame States: The developers jumped to frame 178 and first checked the input ports of the position update node. They found that the historical value of its "velocity" input port was abnormally high, reaching 1000 (units / second), while normal movement speed should be around 10. This directly explains why the position changed abruptly.

[0111] 5. Tracing the source of the speed anomaly: In order to find out why the speed suddenly changed, the developers jumped forward on the timeline and found that the speed value suddenly jumped from the normal 10 to 1000 at frame 175; then they jumped back to frame 175 and checked the input of the speed update node and found that the collision detection node misjudged a collision.

[0112] 6. Collision False Detection: By examining the input data of the collision detection node, a floating-point precision issue was found at a specific angle.

[0113] 7. Problem Solving: The developers optimized the collision detection node algorithm and added floating-point tolerance processing, thus solving the problem.

[0114] Technical Impact: By synchronously recording and correlating continuous visual performance with internal data streams of millisecond precision, developers can analyze every step of the physics simulation as if watching a high-definition slow-motion replay. The entire debugging process, from discovering visual anomalies to locating the root data error five frames prior, takes approximately five minutes. With traditional debugging methods, developers would need to repeatedly simulate, taking over an hour, and finding the microscopic cause of floating-point precision errors would be extremely difficult.

[0115] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0116] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0117] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0118] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0119] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Furthermore, any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory.

[0120] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0121] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A node programming and debugging method based on a time axis, characterized in that, include: In response to the user's debugging configuration parameters, during the operation of the node graph program, based on the registered listeners, port change event data of each node port is collected, and rendering screen data corresponding to the node graph program is captured. Based on the preset keyframe interval strategy and the port change event data, a frame snapshot array consisting of keyframe snapshots and incremental snapshots is generated; wherein, the keyframe snapshot contains the complete port status data of all nodes in the node graph, and the incremental snapshot records the port data that has changed relative to the previous keyframe snapshot. A timeline index for frame-by-frame positioning is constructed based on the frame snapshot array; In response to a timeline jump command generated by a user operation, historical state data corresponding to the target frame is determined from the frame snapshot array based on the timeline index. Based on the determined historical state data, the complete state of the node graph of the target frame is reconstructed and visualized.

2. The node programming and debugging method based on a time axis according to claim 1, characterized in that, The listener includes a port update listener; the collection of port change event data for each node's ports includes: Register the port update listener when the node graph program runs; The port update listener, in response to port change events of each node, collects the port change event data.

3. The node programming and debugging method based on a time axis according to claim 1, characterized in that, The listener includes a render frame listener; The capture of the rendered screen data corresponding to the node graph program includes: Register the rendering frame listener during the execution of the node graph program; The rendering frame listener determines whether a screenshot operation needs to be performed on the current frame when the rendering frame is completed, based on the preset rendering screenshot configuration. If so, the image data of the current frame is obtained through the asynchronous reading mechanism provided by the graphics interface. The image data of the current frame is subjected to screen change detection. When the screen change detection meets the preset change, the image data of the current frame is compressed through an independent image compression thread and used as the rendering screen data. When the screen change detection does not meet the preset change, the image data of the current frame is discarded and the image data of the previous screenshot frame is reused as the rendering screen data.

4. The node programming and debugging method based on a time axis according to claim 3, characterized in that, The image change detection includes: Compare the hash value of the current frame with the hash value of the previous screenshot frame to see if they are the same; If they are the same, then the image change detection conforms to the preset change; If they are not the same, then the image change detection does not conform to the preset change.

5. The node programming and debugging method based on a time axis according to claim 1, characterized in that, The step of generating a frame snapshot array consisting of key frame snapshots and incremental snapshots based on a preset key frame interval strategy and the port change event data includes: In response to a port change event, a snapshot object corresponding to the current frame is created, and the current frame index and the key frame interval strategy are used to determine whether the current frame is a key frame. If the current frame is a key frame, then create and record key frame snapshot data in the snapshot object. The key frame snapshot data contains complete port status data of all nodes in the node graph program. If the current frame is not a keyframe, then incremental snapshot data is created and recorded in the snapshot object. The incremental snapshot data only contains the port data that has changed in the port change event. The snapshot objects are stored in the memory snapshot buffer in frame index order to form the frame snapshot array.

6. The node programming and debugging method based on a time axis according to claim 5, characterized in that, Also includes: Monitor the storage status of the memory snapshot buffer; When the number of snapshot objects stored in the memory snapshot buffer reaches a preset threshold, all data in the frame snapshot array is packaged, serialized, and archived to a local file. After archiving is complete, the memory snapshot buffer is cleared and the timeline index is updated to record the archived location of the data.

7. The node programming and debugging method based on a time axis according to claim 1, characterized in that, The process of reconstructing and visualizing the complete state of the node graph of the target frame based on the determined historical state data includes: From the frame snapshot array, locate the most recent key frame snapshot before the target frame to obtain the baseline complete state; From the frame snapshot array, obtain all corresponding incremental snapshots from the most recent keyframe snapshot to the target frame, and arrange them in order to form an incremental snapshot sequence; Based on the baseline complete state, the port data changes recorded in the incremental snapshot sequence are applied sequentially in chronological order to obtain the node graph complete state of the target frame.

8. A time-axis-based node programming and debugging system, characterized in that, It includes a runtime monitoring layer, a debugging engine layer, a storage layer, and a user interface layer; The runtime listening layer is used to listen for node port value change events and rendering frame completion events during the execution of the node graph program. The debugging engine layer is connected to the runtime monitoring layer, storage layer, and interface layer, respectively, and is used for: In response to the user's debugging configuration parameters, the runtime listening layer collects port change event data and rendering screen data of each node port. Based on the preset keyframe interval strategy and the port change event data, a frame snapshot array consisting of keyframe snapshots and incremental snapshots is generated, and the storage layer is controlled to store it; wherein, the keyframe snapshot contains the complete port status data of all nodes in the node graph, and the incremental snapshot records the port data that has changed relative to the previous keyframe snapshot. A timeline index for frame-by-frame positioning is constructed based on the frame snapshot array; In response to the timeline jump command issued by the interface layer, the historical state data corresponding to the target frame is determined from the storage layer according to the timeline index, and the complete state of the node graph of the target frame is reconstructed. The storage layer is used to store the frame snapshot array and the time axis index; The interface layer is used to provide a debugging configuration interface, a timeline control interface, receive user operations to generate the timeline jump command, and visually display the complete state and rendering screen of the node graph reconstructed by the debugging engine layer.

9. 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 time-axis-based node programming and debugging method according to any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the time-axis-based node programming and debugging method according to any one of claims 1-7.

Images