Adaptive editing and synchronization control method and system for material overlay elements

Abstract

The application discloses a kind of material superimposed element's adaptive editing and synchronous control method and system, the method specifically includes: according to superimposed element data and mapping relationship initialization superimposed element's display state, layer state and container constraint rule;Based on the operation area after locking, receive superimposed element operation, display coordinate is converted into base map coordinate, and combined with container constraint rule, judge whether there is range conflict, level conflict and mutual exclusion conflict, if there is conflict, then intercept original operation and generate the correction operation limited in corresponding container;According to correction operation or unconflict operation, update superimposed element data, and operation before and after state, element identification, position size and layer information are packaged as operation instruction.The application realizes the accurate adaptive editing of superimposed element under different size materials, conflict automatic correction and the real-time synchronization of multi-person collaborative editing, with high precision, low conflict and operation retroactivity.

Description

Technical Field

[0001] This invention relates to the field of game asset configuration technology, and in particular to an adaptive editing and synchronization control method and system for overlaying asset elements. Background Technology

[0002] In scenarios such as game operation, advertising, and event page configuration, it is often necessary to overlay elements such as logos, recommendation tags, event badges, and status indicators on game asset base images to achieve mixed text and image layouts and personalized visual presentation. Existing solutions mostly use fixed coordinates, fixed sizes, or simple drag-and-drop plugins to edit overlaid elements, but these methods present the following technical problems in practical applications: First, when the original sizes of different materials differ significantly, the size of the operation container is inconsistent with the actual display size of the material. In addition, the lack of a dynamic coordinate mapping mechanism leads to deviations in coordinate conversion, scaling ratio, and the final landing point of elements during the dragging process, affecting editing accuracy.

[0003] Secondly, initializing the operation area before the source images have finished loading can easily lead to the height, width, and aspect ratio of the operation area being calculated based on incorrect or temporary rendering dimensions, resulting in inaccurate operation boundaries and incorrect element positioning during subsequent editing.

[0004] Third, when multiple overlapping elements coexist, the lack of systematic management of the range constraints, hierarchical relationships, and mutual exclusion rules between elements can easily lead to problems such as dragging beyond the editable area, abnormal hierarchical coverage, and multiple mutually exclusive elements being displayed simultaneously, causing mutual interference between elements and increasing the probability of editing errors.

[0005] Fourth, there is a lack of a unified and traceable operation instruction recording mechanism for each user's drag, zoom, style modification, and other operations. It is difficult to achieve stable undo and redo functions based on the state changes before and after the operation, which affects the editing experience and the operation's fault tolerance.

[0006] Fifth, in scenarios involving collaborative editing by multiple people, existing solutions typically only synchronize the final screen or overall editing data, failing to detect and handle conflicts in specific operational processes, making it difficult to guarantee real-time synchronization and consistency between the operations of multiple collaborators. Summary of the Invention

[0007] The purpose of this invention is to provide an adaptive editing and synchronization control method and system for overlaying elements of materials, which realizes accurate adaptive editing of overlaying elements under materials of different sizes, automatic conflict correction and real-time synchronization of multi-person collaborative editing, and has the advantages of high precision, low conflict and operation traceability, so as to solve at least one of the above-mentioned problems of the prior art.

[0008] In a first aspect, the present invention provides an adaptive editing and synchronization control method for material overlay elements, the method specifically comprising: In response to the user selecting a background image, the system obtains the original size of the background image, the size of the operation container, and the data of the overlaid elements. Based on the original size and the size of the operation container, it calculates a dynamic scale and establishes a mapping relationship between the background image coordinate system and the display coordinate system. Initialize the display state, layer state, and container constraint rules of the overlay elements based on the overlay element data and mapping relationship. Before loading the material image, set the operation area to an unlocked state and clear the historical operation boundary. After the material image is loaded, reset the operation area and lock the ratio according to the actual rendering size. Based on the locked operation area, the operation of the overlay element is received, the display coordinates are converted into the base map coordinates, and the container constraint rules are combined to determine whether there are range conflicts, hierarchical conflicts and mutual exclusion conflicts. If there are conflicts, the original operation is intercepted and a correction operation limited to the corresponding container is generated. Update the overlay element data based on the correction operation or non-conflicting operation, and encapsulate the state before and after the operation, element identifier, position size and layer information into operation instructions; The canvas is rendered in real time based on operation commands, collaborators are synchronized via WebSocket, and when receiving remote operations or undo / redo, merge, reverse or replay operations are performed in combination with OT or CRDT rules and operation command stack.

[0009] Secondly, the present invention provides an adaptive editing and synchronization control system for material overlay elements, the system specifically comprising: The material acquisition module is used to respond to the user's selection of a background image material, obtain the original size of the background image material, the size of the operation container, and the data of the overlay elements, calculate the dynamic scale based on the original size and the size of the operation container, and establish the mapping relationship between the background image coordinate system and the display coordinate system. The material loading module is used to initialize the display state, layer state, and container constraint rules of the overlay elements based on the overlay element data and mapping relationship. Before loading the material images, the operation area is set to an unlocked state and the historical operation boundaries are cleared. After the material images are loaded, the operation area is reset according to the actual rendering size and the ratio is locked. The conflict detection module is used to receive operations of overlay elements based on the locked operation area, convert the display coordinates into base map coordinates, and determine whether there are range conflicts, hierarchical conflicts and mutual exclusion conflicts in combination with container constraint rules. If there are conflicts, the original operation is intercepted and a correction operation limited to the corresponding container is generated. The instruction encapsulation module is used to update the overlay element data according to the correction operation or non-conflicting operation, and encapsulate the state before and after the operation, element identifier, position size and layer information into operation instructions; The operation execution module is used to render the canvas in real time based on operation instructions, synchronize collaborators via WebSocket, and perform merge, reverse, or replay operations in combination with OT or CRDT rules and operation instruction stack when receiving remote operations or undo / redo.

[0010] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements an adaptive editing and synchronization control method for material overlay elements as described in any of the above methods.

[0011] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the adaptive editing and synchronization control method for material overlay elements as described in any of the above methods.

[0012] Compared with the prior art, the present invention has at least one of the following technical effects: 1. It achieves precise adaptive editing of overlaid elements under different sized materials, automatic conflict correction, and real-time synchronization of multi-person collaborative editing, combining high precision, low conflict, and operational traceability.

[0013] 2. By calculating the dynamic scale based on the original size of the base image material and the size of the operation container, and establishing a two-way mapping relationship between the base image coordinate system and the display coordinate system, the position and size of the overlaid elements can be accurately converted between the two coordinate systems. No matter how the material size changes, the drag coordinates, scaling ratio and final landing point can be accurately matched with the base image, avoiding deviation.

[0014] 3. Before loading the source images, the operation area is set to an unlocked state and the historical operation boundaries are cleared. After the source images are loaded, the operation area is reset according to the actual rendering size and the ratio is locked. This effectively avoids size calculation errors caused by incomplete image loading and ensures that the boundaries, ratios, and control point positions of the operation area are consistent with the actual display of the base image, thus improving operation accuracy.

[0015] 4. Generate container constraint rules based on the container to which the overlay element belongs, editing permissions, and layer status. When receiving editing operations, convert the display coordinates to base map coordinates and determine whether there are range conflicts, hierarchy conflicts, and mutual exclusion conflicts based on the container constraint rules. When a conflict occurs, intercept the original operation and generate a correction operation that is limited to the corresponding container, so that the element always moves within the allowed area and automatically maintains the correct hierarchy and mutual exclusion relationships, avoiding mutual interference between elements.

[0016] 5. Encapsulate the state before and after the operation, element identification, position size, and layer information into a unified atomic operation instruction, and build a traceable operation record. This enables stable support for undo and redo functions through the operation instruction stack, making the editing process more fault-tolerant and traceable.

[0017] 6. The local canvas is rendered in real time based on operation commands and collaborators are synchronized via WebSocket. When receiving remote operations or performing undo / redo, the merge, reverse or replay operations are performed in combination with OT or CRDT rules and operation command stack. This achieves effective conflict handling and real-time status synchronization for concurrent operations, ensuring the consistency and smoothness of operations under multi-person collaborative editing. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, 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.

[0019] Figure 1 This is a flowchart illustrating an adaptive editing and synchronization control method for material overlay elements provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the conflict interception and correction operation generation process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the operation instruction rendering, synchronization, merging, and undo / redo process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an adaptive editing and synchronous control system for material overlay elements provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0022] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating an adaptive editing and synchronization control method for overlay elements of materials, as disclosed in an embodiment of the present invention, is shown below in detail: S101, in response to the user selecting the background image material, obtain the original size of the background image material, the size of the operation container and the data of the overlay elements, calculate the dynamic scale based on the original size and the size of the operation container, and establish the mapping relationship between the background image coordinate system and the display coordinate system; S102: Initialize the display state, layer state and container constraint rules of the overlay elements according to the overlay element data and mapping relationship. Before the material image is loaded, set the operation area to an unlocked state and clear the historical operation boundary. After the material image is loaded, reset the operation area according to the actual rendering size and lock the ratio. S103, based on the locked operation area, receive the operation of the overlay element, convert the display coordinates into the base map coordinates, and combine the container constraint rules to determine whether there is a range conflict, hierarchical conflict and mutual exclusion conflict. If there is a conflict, the original operation is intercepted and a correction operation limited to the corresponding container is generated. S104, Update the overlay element data according to the correction operation or non-conflicting operation, and encapsulate the state before and after the operation, element identifier, position size and layer information into operation instructions; S105 renders the canvas in real time based on operation commands, synchronizes collaborators via WebSocket, and performs merge, reverse, or replay operations in combination with OT or CRDT rules and operation command stack when receiving remote operations or undo / redo.

[0023] In one embodiment, the method of this application can be applied to a game operation backend, an advertising material configuration platform, or an activity page visual editing system. After a user selects a game material background image in the editing interface, the system responds to the selection operation by obtaining the original width and height of the background image material, the width and height of the current operation container, and reading the overlay element data associated with the background image material. The overlay elements may include logos, recommendation tags, activity badges, status indicators, operation copy indicators, etc. The system determines a dynamic scaling ratio adapted to the current operation container based on the original size of the background image material and the size of the operation container, so that the background image material can be fully displayed within the operation container while maintaining its original aspect ratio; at the same time, it determines the display offset of the background image material relative to the operation container based on the scaled actual display size, thereby establishing a mapping relationship between the background coordinate system and the display coordinate system. Through this mapping relationship, the overlay elements can use standard coordinates under the background coordinate system when stored, and can be converted to position and size under the display coordinate system when displayed and interacted with, thereby avoiding deviations in element placement due to different material sizes or different display container sizes.

[0024] After establishing the mapping relationship, the system reads information from the overlay element data, including element identifier, element type, base map coordinate position, base map coordinate size, container identifier, layer order, and operable attributes. Based on the mapping relationship, the system converts the base map coordinate position and size of the overlay element into the current display coordinate position and size to generate the display state of the overlay element in the editing interface. Simultaneously, the system binds the overlay element to the corresponding editable container based on its container identifier and initializes the layer state and container constraint rules according to the element type, editing permissions, and layer order. The container constraint rules may include whether elements are allowed to exceed container boundaries, the hierarchical relationship between different types of elements, and whether multiple mutually exclusive elements are allowed to exist simultaneously within the same container.

[0025] To avoid inaccurate calculations of the operation area size before the background image has finished loading, the system first locks the operation area upon detecting a user's selection of a new background image and clears the historical operation boundaries, display size, boundary offsets, and control point positions of the previous background image. In the unlocked state, the system pauses boundary detection, snapping control, and dragging control of overlay elements to prevent them from using incorrect boundaries from the previous image. Simultaneously, the system retains the original data and layer data of the overlay elements in the background image coordinate system. Once the background image has finished loading, the system obtains the actual rendered width and height of the image within the operation container and resets the operation area boundaries, starting position, and boundary offsets based on the actual rendered size. Subsequently, the system verifies whether the display ratio corresponding to the actual rendered size matches the original ratio of the background image; if they match, this ratio is determined as the locked ratio of the operation area; if there is a discrepancy, the operation area size is corrected based on the original ratio of the background image before locking the ratio. After the operation area enters the locked state, the system refreshes the display position, display size, and interactive control points of each overlay element based on the new boundaries and locked ratio.

[0026] When a user moves, scales, rotates, adjusts the layer, or modifies the style of an overlay element, the system receives the editing operation within the locked operation area and collects the overlay element's position, size, control point positions, and layer changes in the display coordinate system before and after the operation. The system normalizes the above display coordinate parameters by combining the operation area boundary and display offset, and then converts the normalized display coordinate parameters into base map coordinate parameters according to the established mapping relationship. Subsequently, the system determines the base map boundary and target layer state after the overlay element operation based on the converted base map coordinate parameters, and calls the container constraint rules corresponding to the container to which the overlay element belongs for judgment.

[0027] Specifically, the system determines whether the boundary of the background image after the operation on the overlay element exceeds the editable range of its container to identify any range conflicts; it determines whether the target layer state conforms to the preset hierarchical relationship to identify any hierarchical conflicts; and it determines whether the current operation conflicts with the mutual exclusion conditions of existing elements within the same container to identify any mutual exclusion conflicts. When the system determines that there are no conflicts, it treats the current operation as a conflict-free operation and proceeds to the subsequent data update process. When the system determines that at least one conflict exists, it intercepts the original operation, preventing it from directly writing to the overlay element data, while retaining the operation's direction, target position, target size, or target layer. Subsequently, the system invokes the corresponding correction strategy based on the conflict type. For example, for range conflicts, the system corrects the target position or target size based on the editable boundary of the container to keep the overlay element within the container's range; for hierarchical conflicts, the system corrects the target layer according to the preset layer order; and for mutual exclusion conflicts, the system adjusts the operation state based on the mutual exclusion relationship or refuses the coexistence of mutually exclusive objects. After the correction is completed, the system verifies the correction result again according to the container constraint rules. If the verification passes, the correction result is determined as the correction operation to replace the original operation. If the verification fails, the state of the stacked elements before the operation is restored.

[0028] After determining that the current operation is a non-conflicting or corrective operation, the system reads the pre-operation state of the corresponding overlay element and identifies the operation as valid. Based on the valid operation, the system updates the position, size, angle, container, and layer state of the overlay element in the base map coordinate system, and simultaneously generates a display state corresponding to the current display coordinate system. After completing the data update, the system reads the post-operation state of the overlay element and associates the pre-operation and post-operation states with the element identifier. Then, the system encapsulates the operation type, element identifier, container identifier, pre-operation state, post-operation state, position and size information, layer information, operator identifier, and time sequence identifier of this valid operation into an operation command. Through this operation command, the system can clearly record the changes of each editing operation, providing a unified data basis for subsequent real-time rendering, undo, redo, and collaborative synchronization.

[0029] During local editing, the system updates the local overlay element data based on the element identifiers in the operation instructions and the post-operation state. It then converts this data into a display state based on the current mapping relationship and renders the canvas in real time. Simultaneously, the system writes the operation instructions into the local operation instruction stack and sends the instructions, along with operator identifiers, version identifiers, and timing identifiers, to other collaborators in the collaborative editing session via WebSocket. Upon receiving the operation instructions, the remote client can replay the corresponding editing results based on the same instruction, thus maintaining synchronization between the remote and local canvases.

[0030] In collaborative editing scenarios, when the system receives a remote operation command, it first determines whether there is a concurrent relationship between the remote operation command and any unconfirmed local operations based on the version and timing identifiers. If no concurrent relationship exists, the system directly replays the remote operation command and updates the canvas. If a concurrent relationship exists, the system converts operation parameters such as position, size, and layer according to OT rules, or performs deterministic merging of element states according to CRDT rules to obtain the merged operation result. Based on this, the system updates the overlay element data and refreshes the canvas. Therefore, even if multiple collaborators are editing the same material or adjacent elements simultaneously, the risks of operation overlap, inconsistent states, or screen conflicts can be reduced.

[0031] When a user triggers an undo operation, the system reads the most recently undone operation instruction from the operation instruction stack and generates a reverse operation based on the pre-operation state in that instruction, restoring the overlaid elements to their state before the operation. When a user triggers a redo operation, the system reads the corresponding undone operation instruction and generates a replay operation based on the post-operation state in that instruction, restoring the overlaid elements to their state after the operation. In collaborative editing scenarios, reverse or replay operations are also encapsulated as new operation instructions and synchronized to other collaborators via WebSocket, ensuring consistent editing states across clients.

[0032] Through the above implementation methods, this application can establish a stable dynamic coordinate mapping relationship between materials of different sizes and different operation containers, avoiding misalignment of the operation area boundary before material loading, and uniformly managing the range, hierarchy, and mutual exclusion relationships of overlay elements through container constraint rules. Simultaneously, this application encapsulates each editing action as a traceable operation instruction, enabling real-time rendering, undo / redo, and multi-person collaborative synchronization to be executed based on a unified mechanism, thereby improving the accuracy, stability, and collaborative consistency of editing overlay elements.

[0033] In some embodiments, step S101 above, which involves calculating the dynamic scale based on the original size and the size of the operating container, and establishing the mapping relationship between the base map coordinate system and the display coordinate system, specifically includes: Based on the original size of the base image material and the size of the operation container, determine the width scaling reference value and the height scaling reference value respectively, and select the scaling reference value that allows the base image material to be displayed completely without distortion from the width scaling reference value and the height scaling reference value as the dynamic scale; The actual display size of the base image material within the operation container is determined based on the dynamic scale, and the display offset of the base image material is determined based on the actual display size and the size of the operation container. A bidirectional mapping relationship between the base map coordinate system and the display coordinate system is established based on the dynamic scale and the display offset. This bidirectional mapping relationship is used to convert the position and size of the overlay element in the base map coordinate system into the display state.

[0034] In this embodiment, after the user selects a background image to be edited, the system first obtains the original size of the background image and the size of the operation container in the current editing interface. The original size of the background image may include the original width and height recorded in the background image file itself, and the size of the operation container may include the width and height of the editing area that can be used to display the background image in the current page layout. Since the original aspect ratios of different background images may differ, and the display area of ​​the operation container is usually fixed or changes with the page window, a dynamic scaling ratio, i.e., dynamic scaling, needs to be determined before the image is displayed to fit the current operation container.

[0035] The dynamic scale characterizes the scaling degree of the background image material when it is converted from its original size to the display size. This dynamic scale is not a pre-configured constant, nor is it a fixed ratio set only for a specific background image material or a specific page layout. Instead, it is redefined based on the original width and height of the background image material, the width and height of the operation container, changes in the page window, or changes in the terminal display environment. By employing dynamic scale, the system can ensure that the background image material fits the operation container as closely as possible and is displayed completely while maintaining its original aspect ratio.

[0036] Specifically, the system determines a width scaling reference value based on the original width of the base image material and the width of the operation container, and a height scaling reference value based on the original height of the base image material and the height of the operation container. The width scaling reference value represents the degree of scaling required for the base image material to fit the operation container in the width direction, and the height scaling reference value represents the degree of scaling required for the base image material to fit the operation container in the height direction. The system then selects a scaling reference value from the width and height scaling reference values ​​that allows the base image material to be fully displayed within the operation container without changing the original aspect ratio of the base image material as the dynamic scale. In other words, the system does not use different scaling ratios for the width and height, but uses a uniform dynamic scale to scale the base image material proportionally, thereby avoiding stretching, compression, or deformation of the base image material.

[0037] After determining the dynamic scale, the system determines the actual display size of the background image material within the operation container based on this dynamic scale. The actual display size refers to the width and height actually occupied by the background image material in the editing interface after being scaled proportionally. Since the background image material usually needs to be displayed centered within the operation container or according to a preset alignment, there will be blank areas within the operation container when the actual display size of the background image material is smaller than the size of the operation container. To ensure accurate subsequent coordinate conversion, the system further determines the display offset of the background image material relative to the operation container based on the actual display size and the size of the operation container. The display offset can include horizontal and vertical offsets, used to represent the distance between the starting position of the actual display area of ​​the background image material and the starting position of the operation container. For example, when the background image material is centered within the operation container, the horizontal offset corresponds to the width of one side of the left and right blank areas, and the vertical offset corresponds to the height of one side of the top and bottom blank areas.

[0038] After obtaining the dynamic scale and display offset, the system establishes a bidirectional mapping relationship between the base map coordinate system and the display coordinate system. The base map coordinate system is a coordinate system established based on the original size of the base map material, used to store the position and size of the overlay element relative to the original image of the base map material; the display coordinate system is a coordinate system established based on the operation container or the current display page, used to present the position, size, and interactive control points of the overlay element in the editing interface. Through this bidirectional mapping relationship, the system can convert the position and size of the overlay element in the base map coordinate system to the position and size in the display coordinate system during initial display; after the user drags, scales, or moves the overlay element, it can also convert the operation results in the display coordinate system back to the data in the base map coordinate system for saving.

[0039] Furthermore, when converting the base map coordinates to display coordinates, the system scales the position and size of the overlay element in the base map coordinate system proportionally based on dynamic scaling, and determines its display position within the operation container by combining this with the display offset. Thus, the overlay element can change synchronously with the scaling and offset of the base map material, maintaining its visual position relative to the base map content. When converting the display coordinates to base map coordinates, the system first deducts the display offset of the base map material relative to the operation container, restoring the display position of the overlay element to the actual display area of ​​the base map, and then restores its position and size to the original size of the base map material based on dynamic scaling. In this way, even if the size of the operation container changes, the page scaling ratio changes, or the display sizes of different user terminals differ, the system can still maintain consistent data results based on the base map coordinate system.

[0040] In a specific application scenario, a game operator selects a game character poster as the background image on the ad creative editing page. The original size of the poster differs from the aspect ratio of the operating container on the editing page. When loading the background image, the system first determines the scaling based on width and height, then selects a scaling reference value that ensures the poster is displayed completely as the dynamic scale. Subsequently, the system determines the actual display area of ​​the poster within the operating container and records the horizontal and vertical offsets of this display area relative to the boundaries of the operating container. When the operator adds a "Limited-Time Event" badge to the upper right corner of the poster, the system converts the background coordinates of the badge into display coordinates based on the dynamic scale and display offset, ensuring the badge is correctly displayed on the current canvas. When the operator drags the badge, the system reverses the dragged display coordinates back to background coordinates and saves them. Thus, when changing the display terminal or reopening the ad creative, simply recalculating the dynamic scale and display offset under the current operating container will accurately restore the badge to its corresponding position in the upper right corner of the poster.

[0041] Through the above implementation methods, this application can accurately determine the proportional scaling state and display offset position of the material when the original size of the base map material is inconsistent with the size of the operation container. Based on this, a two-way mapping relationship between the base map coordinate system and the display coordinate system is established, thereby solving the problems of coordinate conversion deviation caused by material size differences and display area changes, inaccurate element landing points, and difficulty in reproducing editing results in existing fixed coordinate or simple drag solutions.

[0042] In some embodiments, step S102 above, which involves initializing the display state, layer state, and container constraint rules of the overlay elements based on the overlay element data and mapping relationship, specifically includes: Read the element identifier, element type, base map coordinate position and size, container identifier, layer order and operable attributes from the overlay element data, and generate the corresponding overlay element instance based on the element identifier and element type; Based on the mapping relationship, the coordinate position and size of the base map are converted into the display coordinate position and size, forming the display state of the overlay element instance; The stacked element instance is bound to the corresponding container based on its container identifier, and the corresponding editing permissions are determined by combining the element type and operable attributes. Sort multiple overlay element instances based on layer order to generate layer states used to determine coverage relationships and selection priorities; Generate container constraint rules based on the corresponding container, editing permissions, and layer status.

[0043] In this embodiment, after the system establishes the mapping relationship between the base map coordinate system and the display coordinate system, it further initializes each overlay element based on the overlay element data associated with the current base map material. The overlay element data can be pre-distributed by the server or obtained from local editing records, and includes at least information such as element identifier, element type, base map coordinate position and size, container identifier, layer order, and operable attributes. Specifically, the element identifier uniquely identifies an overlay element; the element type distinguishes different elements such as logos, recommendation tags, activity badges, status icons, and text icons; the base map coordinate position and size describes the position and size of the overlay element in the original coordinate system of the base map material; the container identifier indicates the editing area to which the element is defined or belongs; the layer order indicates the stacking order of the element among multiple overlay elements; and the operable attributes limit whether the element can be moved, scaled, rotated, deleted, or have its style modified.

[0044] Specifically, after reading the data of each overlay element, the system generates a corresponding overlay element instance based on the element identifier and element type. Different element types can correspond to different instance representations and interactive capabilities. For example, logo elements are typically represented as image instances, activity badges can be represented as images or combinations with fixed styles, recommendation tags can be represented as image-text combination instances, and status icons can be represented as icon instances with preset status styles. By generating corresponding instances based on element types, the system can load appropriate rendering methods, control point styles, and operation rules for different types of elements during subsequent editing.

[0045] After generating an overlay element instance, the system converts the position and size of the overlay element in the base map coordinate system to the position and size in the display coordinate system based on the established mapping relationship, thus forming the display state of the overlay element instance. The display state can include display coordinates, display width, display height, rotation angle, visibility status, and control point positions. Since the base map coordinate system is a stable coordinate system corresponding to the original size of the base map material, while the display coordinate system changes with the size of the operation container, dynamic scaling ratio, and display offset, generating the display state through the mapping relationship during initialization ensures that the position of the overlay element in the current editing interface is consistent with its actual relative position on the base map material.

[0046] Furthermore, the system binds the corresponding overlay element instance to the appropriate container based on the container identifier in the overlay element data. The container can be the entire editable area of ​​the background image material, or a local area on the background image material, such as a cover area, corner mark area, status display area, or text display area. Container binding is used to limit the editing scope and rules of overlay elements, allowing different overlay elements to be constrained by their respective containers. After completing container binding, the system also determines the editing permissions of the overlay element based on the element type and operable attributes. For example, some logo elements can be moved and scaled but their styles cannot be modified; some status markers can be switched but cannot be dragged out of a specified area; and some system-fixed corner marks can only be shown or hidden but cannot be deleted. By determining editing permissions, the system can clearly define which operations can be performed and which operations should be restricted or blocked in subsequent interactions.

[0047] When multiple overlapping elements exist simultaneously, the system sorts the overlapping element instances based on the layer order in the data of each overlapping element and generates layer states. These layer states are used to determine the coverage relationship and selection priority between multiple overlapping elements. When multiple elements overlap in the display area, the element with the higher layer order is displayed on top of the element with the lower layer order. When a user clicks or selects an overlapping area, the system can prioritize selecting the overlapping element located on the upper layer and with operable permissions, based on the layer state. This avoids problems such as uncertain selection objects, chaotic coverage relationships, or users being unable to accurately operate on target elements when multiple elements overlap.

[0048] After completing container binding, determining editing permissions, and generating layer states, the system further generates container constraint rules based on the corresponding container, editing permissions, and layer states. These container constraint rules are not limited to the container's geometric boundaries; they can also include range constraints, permission constraints, hierarchy constraints, and element coexistence constraints associated with the container. Range constraints limit that overlay elements, after being moved or scaled, must not exceed the editable boundaries of their respective containers, or are only allowed to be displayed close to the edge within a preset tolerance range. Permission constraints limit the types of operations that users can perform on the element. Hierarchical constraints limit that certain types of elements must be located above or below specific elements. Element coexistence constraints limit whether mutually exclusive elements within the same container are allowed to coexist. For example, in the same badge container, the "New Server Recommendation" badge and the "Limited-Time Event" badge can be configured to be mutually exclusive; when one is displayed, the other is not allowed to be displayed simultaneously or needs to be replaced.

[0049] In a specific application scenario, after a game operator opens a game advertisement, the system reads the corresponding Logo element, Recommendation tag element, and Activity badge element. Based on the identifier and type of each element, the system generates an image-based Logo instance, a tag-based Recommendation instance, and a badge-based Activity instance, converting their base image coordinates and dimensions to their display state on the current editing page. Subsequently, the system binds the Logo instance to the brand display container in the lower left corner of the base image, the Recommendation tag to the top tag container, and the Activity badge to the upper right badge container. Based on the operable attributes of each element, the system determines that the Logo can be moved and scaled, the Recommendation tag's text can be modified, and the Activity badge can only be moved within its own container. Then, based on the layer order, the system determines that the Activity badge appears above the Recommendation tag, and the Recommendation tag appears above the Logo, generating corresponding container constraint rules. Therefore, when the user subsequently edits these elements, the system can accurately control them based on the initialized display state, layer state, and container constraint rules.

[0050] Through the above implementation methods, this application can uniformly complete element instantiation, coordinate display transformation, container binding, permission determination, layer sorting, and constraint rule generation before the overlay elements enter the editing state. This enables multiple overlay elements of different types to be displayed and edited in an orderly manner on the same base image material, thereby reducing problems such as element out-of-bounds, misselection, layer confusion, and coexistence of mutually exclusive elements, and improving the stability and accuracy of the material editing process.

[0051] In some embodiments, step S102 above, which involves setting the operation area to an unlocked state and clearing historical operation boundaries before loading the source image, specifically includes: After detecting that the user has selected a new background image, a material switching event is generated, and the operation area is marked as unlocked in response to the material switching event; In the unlocked state, pause the boundary detection and interactive control of the overlay elements based on the display coordinate system, and clear the display size, boundary offset, editable area range and control point position information of the previous base image material; Set the interactive state of the overlay element to the waiting initialization state to preserve the base map coordinate data and layer data of the overlay element, and prevent it from performing move, scale or snap operations using the historical operation boundary until the operation area boundary is redefined after the material image is loaded.

[0052] In this embodiment, when the system detects that a user selects a new background image in the material editing interface, a material switching event is generated first. This event indicates that the current editing object is about to switch from the previous background image to a new one, but the new background image has not yet completed image loading, size resolution, and display adaptation. In response to the material switching event, the system marks the operation area as unlocked. This unlocked state does not mean that the user is allowed to arbitrarily manipulate overlaid elements, but rather that the boundaries, scaling ratio, and display offset of the current operation area have not yet been redefined, and the system does not currently use the operation boundaries corresponding to the previous background image as the basis for the current operation.

[0053] While the operation area is unlocked, the system pauses boundary detection and interactive control of overlay elements based on the display coordinate system. Boundary detection based on the display coordinate system can include determining whether overlay elements exceed the background image display area, whether they exceed the range of their respective containers, whether they meet the snapping distance, and whether further dragging or scaling is allowed. Since the actual display size, display offset, and editable area of ​​a new background image cannot be accurately determined before loading, continuing to use the display coordinate boundaries of the previous background image could lead to incorrect restriction, incorrect snapping, or incorrect cropping of overlay elements. Therefore, during this stage, the system no longer performs interactive judgments based on the old display boundaries.

[0054] Simultaneously, the system clears the historical operation boundary information corresponding to the previous base image. This historical operation boundary information may include the display size, boundary offset, editable area range, and control point position information of the previous base image within the operation container. Specifically, the display size indicates the actual width and height of the previous base image in the operation area after scaling; the boundary offset indicates the offset position of the previous base image relative to the boundary of the operation container; the editable area range defines the area within the previous base image or its partial container where overlay elements can be placed; and the control point position information supports dragging, scaling, rotating, or selecting operations on overlay elements. By clearing this information, the system avoids using the boundary parameters of the old image before the new image has finished loading, thus preventing coordinate misalignment, element jumping, or errors in operation range judgment.

[0055] Furthermore, after clearing historical operation boundaries, the system sets the interactive state of the overlay elements to a pending initialization state. This pending initialization state temporarily prevents the overlay elements from performing interactive operations that depend on display coordinate boundaries, but does not delete the overlay element's own data. In other words, the system retains basic information such as the overlay element's position and size data in the base map coordinate system, element identifier, element type, layer order, and operable attributes. This information is used to regenerate the overlay element's display state based on the recalculated dynamic scale, display offset, and operation area boundaries after the new base map material is loaded. This approach avoids the misuse of historical display boundaries and ensures that the configured overlay element data is not lost during material switching.

[0056] While awaiting initialization, the system prevents overlay elements from performing move, scale, or snap operations using historical operation boundaries. For example, if the display area of ​​the previous background image is large, and the new background image has not yet finished loading, allowing overlay elements to continue moving along the previous display area might result in them being in the wrong position after the new image is displayed. Similarly, if the previous background image has a specific index container or snap boundary, and the actual display area and container position of the new background image have not yet been determined, performing a snap operation at this time might snap the overlay elements to an old boundary that does not belong to the new image. Therefore, the system intercepts or suspends such operations before the new image is fully loaded and the operation area boundaries are redefined.

[0057] In a specific application scenario, a user switches from a horizontal game poster to a vertical game poster on the ad creative editing page. Upon detecting this selection, the system generates a creative switch event and immediately unlocks the operation area. At this point, the system clears the display size, center offset, editable area, and control point positions of each overlay element corresponding to the horizontal poster, and sets overlay elements such as the logo and activity badges to a pending initialization state. Because the vertical poster has not yet finished loading, the system will not allow these overlay elements to continue to be dragged, scaled, or snapped according to the boundaries of the horizontal poster. Once the vertical poster has finished loading, the system redetermines its display size, display offset, and editable area within the operation container, and then reinitializes the display state of each overlay element based on the retained base map coordinate data and layer data.

[0058] Through the above implementation method, this application can actively release the constraints of the old boundary and clear the historical boundary data before the new material is loaded during the background image material switching process, while retaining the necessary data such as the background image coordinates and layers of the overlaid elements. This avoids the misuse of the old boundary, element misalignment, abnormal snapping and chaotic interaction state caused by differences in image loading time or inconsistencies in the size of the new and old materials, thereby improving the stability of the material switching and editing initialization process.

[0059] In some embodiments, step S102 above, which involves resetting the operation area and locking the ratio according to the actual rendering size after the material image is loaded, specifically includes: In response to the image loading completion event, obtain the actual rendering width and actual rendering height of the image in the operation container, and update the display boundary, starting position and boundary offset of the operation area according to the actual rendering width and actual rendering height; After the display boundary is updated, the display ratio corresponding to the actual rendering width and actual rendering height is verified with the original width and height ratio of the base image material. If the verification result meets the preset error conditions, the display ratio is determined as the locking ratio of the operation area. If the verification result does not meet the preset error conditions, the operation area size is corrected according to the original width and height ratio and then the locking ratio is determined. Switch the operation area from an unlocked state to a locked state, and refresh the display position, display size, and interactive control points of the overlay elements based on the boundary of the locked operation area and the locking ratio.

[0060] In this embodiment, after the base image file has been loaded and rendered in the operation container of the editing interface, the system generates or receives a material image loading completion event. In response to this event, the system obtains the actual rendering width and actual rendering height of the base image material in the operation container. The actual rendering width and actual rendering height refer to the final display size of the image within the operation container after page layout, adaptive scaling, centering, or other display adaptation processing, and not just the original size of the base image file itself. Since the actual display size of the image may differ depending on the terminal, window size, or aspect ratio of the material, the operation area needs to be reset based on the actual rendering result after the image is loaded.

[0061] After obtaining the actual rendering width and height, the system updates the display boundary, starting position, and boundary offset of the operation area based on these actual rendering dimensions. The display boundary defines the visible and operable range of the base image material within the current editing interface; the starting position can be the initial coordinates of the base image material's display area relative to the top left corner of the operation container or other reference points; and the boundary offset represents the horizontal or vertical offset of the base image material relative to the operation container due to proportional adaptation, centering, or whitespace. By updating this information, the system can reposition the operation area from the previous base image material or its temporary state before loading to the actual display area of ​​the current base image material.

[0062] Furthermore, after the display boundary is updated, the system verifies the display ratio corresponding to the actual rendered width and height against the original aspect ratio of the background image material. This verification determines whether the material maintains its original aspect ratio during rendering, preventing the background image material from being scaled non-proportionally due to page styles, container stretching, or abnormal layouts. The preset error condition can be set to allow a certain range of display errors according to business needs, such as minor deviations caused by pixel rounding, browser rendering precision, or terminal scaling. If the verification result meets the preset error condition, it indicates that the current actual rendered size basically maintains the original aspect ratio of the background image material, and the system determines the display ratio corresponding to this actual rendered size as the locked ratio of the operation area.

[0063] If the verification result does not meet the preset error conditions, it indicates that there is a significant deviation between the current actual rendered size and the original aspect ratio of the base image material. Continuing to use this size as the basis for operation may cause deformation or positional deviation of the overlay elements when converting between display coordinates and base image coordinates. In this case, the system corrects the size of the operation area based on the original aspect ratio of the base image material. For example, without exceeding the usable range of the operation container, the height can be corrected based on the actual rendered width, or the width can be corrected based on the actual rendered height, so that the corrected operation area size is consistent with the original aspect ratio of the base image material. After the correction is completed, the system determines the corrected display ratio as the locked ratio of the operation area. Through this process, even if the initial rendering result of the base image material has an abnormal ratio, it can be ensured that subsequent editing operations are still based on the original aspect ratio. Figure 1 Above the proportional relationship.

[0064] After determining the locking ratio, the system switches the operation area from an unlocked state to a locked state. The locked state indicates that the display boundaries, starting position, boundary offset, and display ratio of the current base map material have been determined, serving as the basis for displaying and interacting with overlay elements. At this time, based on the locked operation area boundaries and locking ratio, the system refreshes the display position, display size, and interactive control points of each overlay element. Specifically, the system converts the position and size data of the overlay elements stored in the base map coordinate system into their display position and size within the currently locked operation area, and updates the selection box, scaling control points, rotation control points, drag response area, and snapping reference position of the overlay elements accordingly. Thus, the overlay elements can accurately match the actual display effect of the current base map material.

[0065] In a specific application scenario, after a user switches to a vertical advertisement background image, the system locks the operation area before the image finishes loading. Once the image is loaded and displayed in the operation container, the system obtains the actual rendered width and height of the image and calculates its starting position and boundary offset relative to the operation container. Then, the system verifies whether the actual rendered ratio matches the original aspect ratio of the vertical advertisement background image. If there is only a minor deviation due to pixel rounding, the current display ratio is directly used as the locked ratio. If the image is found to be stretched by the page style, causing an abnormal ratio, the operation area size is corrected according to the original aspect ratio of the background image before determining the locked ratio. Finally, the system locks the operation area and refreshes the display position, size, and control point position of overlapping elements such as the logo, badges, and text labels.

[0066] Through the above implementation methods, this application can reset the operation area based on the actual rendering size after the material image is loaded, and determine a reliable locking ratio through ratio verification and necessary size correction, so that the display area of ​​the base image material, the coordinate transformation of the overlay element, and the interactive control points are consistent, avoiding element misalignment, scaling deformation, and operation boundary errors caused by abnormal rendering size, ratio distortion, or loading sequence differences.

[0067] In some embodiments, in step S103 above, receiving overlay element operations based on the locked operation area, converting display coordinates to base map coordinates, and determining whether there are range conflicts, hierarchy conflicts, and mutual exclusion conflicts in conjunction with container constraint rules, specifically includes: After the operation area is locked, the bounds of the locked operation area, the display offset, and the mapping relationship are written into the editing context, and the user's editing operations on the overlay elements are received. In response to the editing operation, the display coordinate parameters of the overlay elements in the display coordinate system are collected, and the coordinates are normalized by combining the operation area boundary and the display offset. The display coordinate parameters include the position size before and after the operation, the position of the control point, and the layer change information. After completing the coordinate normalization process, the normalized display coordinate parameters are converted into base map coordinate parameters according to the mapping relationship. Based on the base map coordinate parameters, the base map boundary and target layer state after the overlay element operation are determined. Call the container constraint rules corresponding to the container to which the overlay element belongs, determine whether the boundary of the base image exceeds the container to which the overlay element belongs to determine the range conflict, determine whether the target layer state meets the preset hierarchical relationship to determine the hierarchical conflict, and determine whether the editing operation conflicts with the mutual exclusion conditions of existing elements in the same container to determine the mutual exclusion conflict.

[0068] In this embodiment, after the source image is loaded and the operation area is locked, the system writes the locked operation area boundary, display offset, and mapping relationship between the display coordinate system and the base image coordinate system into the editing context. The editing context can be understood as the set of states of the current editing task during its execution, used for subsequent dragging, scaling, rotation, layer adjustment, snapping, and conflict detection operations. By uniformly writing these parameters into the editing context, it ensures that each processing module uses the same operation area boundary and coordinate conversion basis during the same editing process, avoiding inconsistencies in judgment results caused by different modules reading old or temporary parameters.

[0069] The locked operation area boundary represents the effective operable range of the current background image material within the editing interface. The display offset represents the offset position of the background image material's display area relative to the operation container, such as horizontal and vertical offsets caused by centering, proportional scaling, or whitespace. The mapping relationship represents the positional and dimensional correspondence between the display coordinate system and the background image coordinate system. The display coordinate system is typically based on the actual operation container displayed on the current page, while the background image coordinate system is based on the original size of the background image material. When finally saving and verifying overlay elements, the background image coordinate parameters are preferably used to ensure consistent relative positions across different terminals, window sizes, or display scaling ratios.

[0070] After the operation area is locked, the system receives editing operations initiated by the user on the overlay elements. These editing operations can include moving, scaling, rotating, changing layer order, switching containers, snapping, or resizing the elements. When the user performs these operations, the system first collects the display coordinate parameters of the overlay elements in the display coordinate system. These display coordinate parameters can include the position and size of the overlay elements before the operation, the position and size after the operation, the position of the selection box or control points, and layer change information caused by layer adjustments. By simultaneously collecting parameters before and after the operation, the system can not only determine the target state after editing but also judge the direction and magnitude of the change, and whether specific constraints are triggered.

[0071] Furthermore, the system combines the operation area boundary and display offset to perform coordinate normalization on the collected display coordinate parameters. This normalization process converts the display position of the overlay element relative to the page or operation container into a valid display position relative to the starting position of the locked operation area itself. In other words, the system excludes display factors unrelated to the base image material itself, such as operation container whitespace, center offset, page scrolling, or border spacing, ensuring that the position and size used in subsequent processing fall within the display range of the current base image material. This step avoids offset errors caused by directly using page display coordinates, and is especially suitable for scenarios where the base image material does not fill the entire operation container or where the operation area has whitespace on the left, right, or top and bottom.

[0072] After completing the coordinate normalization process, the system converts the normalized display coordinate parameters into base map coordinate parameters based on the mapping relationship in the editing context. The converted base map coordinate parameters describe the position, width, and height of the overlay element relative to the original size of the base map material, as well as rotation or control point status if necessary. Based on these base map coordinate parameters, the system determines the base map boundary and target layer state after the overlay element operation. The base map boundary can be understood as the area occupied by the overlay element in the base map coordinate system, and the target layer state can include the adjusted layer number of the overlay element, its occlusion relationship, its layer group, or its hierarchical relationship with other elements.

[0073] Subsequently, the system invokes the container constraint rules corresponding to the container to which the overlay element belongs to determine any conflicts in the current editing operation. The container can be the entire background image area or a local editable area within the background image, such as a badge area, logo area, text area, button area, or other preset material containers. Different containers can have different constraint rules, such as different types of elements that can be placed, different maximum allowed sizes, different layer orders, or different mutual exclusion relationships. By invoking the corresponding rules according to the container to which the overlay element belongs, conflict determination can be more tailored to specific business scenarios, rather than applying the same universal restrictions to all elements.

[0074] Specifically, the system first determines whether a range conflict exists based on the boundary of the base map after the overlay element operations. If the base map boundary exceeds the editable range defined by its container in the base map coordinate system, or exceeds the safe margin range allowed by the container, a range conflict is determined to exist. Range conflicts can include situations such as elements partially exceeding the boundary, completely moving out of the container, exceeding the container's upper limit after scaling, or control point operations causing the element boundary to enter a prohibited area. Because this determination is based on the base map coordinate parameters, the consistency of the range determination can be maintained even if the current page display ratio changes.

[0075] Secondly, the system determines whether a layer conflict exists based on the target layer's state. The preset layer relationships can be used to specify the order of different types of overlay elements, such as decorative badges not covering core text, background decoration layers not being above main buttons, and watermark layers being within a specified layer range. If the user's editing operation causes the target layer state of the overlay elements to not meet the above preset layer relationships—for example, by promoting an element that should be on the lower layer to a layer where it is prohibited from covering other elements, or by moving an element that must be on top to an invisible layer—the system determines that a layer conflict exists.

[0076] Next, the system determines whether the current editing operation conflicts with the mutual exclusion conditions of existing elements within the same container to identify any mutual exclusion conflicts. These mutual exclusion conditions can include mutual exclusion of element types, mutual exclusion of position / area, mutual exclusion of quantity, or mutual exclusion of function. For example, only one active badge is allowed within the same badge container; two main buttons are not allowed to exist simultaneously within the same button container; if placeholder text already exists in a text area, no additional text elements with the same function are allowed to be added; or overlapping of one type of element with another type of element in the same area would affect the display effect and are therefore set as mutually exclusive. If the current editing operation causes the newly added or adjusted overlapping element to satisfy the above mutual exclusion conditions with existing elements, the system determines that a mutual exclusion conflict exists.

[0077] In a specific application scenario, a user drags an active badge within a locked ad background image operation area. The system first reads the current operation area boundary, display offset, and mapping relationship from the editing context. It then collects the display position, size, and control point position of the badge before and after dragging, and normalizes the display position to eliminate offset caused by the background image being centered within the operation container. Subsequently, the system converts the normalized display coordinates to background image coordinates, obtaining the target boundary of the badge within the original background image size, and calls the constraint rules corresponding to the badge container. If the badge target boundary exceeds the badge container, a range conflict is determined; if the badge is adjusted to a level higher than the prohibited level of the core text, a level conflict is determined; if another mutually exclusive badge already exists within the badge container, a mutual exclusion conflict is determined.

[0078] Through the above implementation methods, this application can accurately convert the user's editing behavior in the display interface into the target state in the base map coordinate system after the operation area is locked, and perform range, hierarchy, and mutual exclusion conflict judgment in combination with container constraint rules. Therefore, it can avoid problems such as out-of-bounds placement, incorrect occlusion, and duplicate configuration caused by display scaling, operation area offset, or inconsistent layer rules, thus improving the accuracy and stability of the overlay element editing process.

[0079] In some embodiments, step S103 above, which involves intercepting the original operation and generating a corrective operation confined to the corresponding container if a conflict exists, specifically includes: After determining that there is at least one conflict among range conflict, hierarchical conflict and mutual exclusion conflict in the overlay element operation according to the container constraint rules, prevent the overlay element operation from being directly written to the overlay element data, and retain the corresponding operation direction, target position, target size or target layer as the overlay element operation to be corrected. The corresponding correction strategy is invoked based on the conflict type to perform the correction and obtain the correction result. The correction strategies include: for range conflicts, correcting the target position or target size based on the editable boundary of the container to which the overlay element belongs; for layer conflicts, correcting the target layer based on the preset layer order; and for mutual exclusion conflicts, correcting the operation state or refusing the coexistence of mutually exclusive objects based on the mutual exclusion relationship of elements within the same container. The correction result is validated based on container constraint rules. If the validation passes, the correction result is determined as the correction operation to replace the original operation, so that the correction operation is limited to the corresponding container and enters the subsequent data update process. Alternatively, if the validation fails, the state of the superimposed elements before the operation is restored.

[0080] In this embodiment, after a user performs operations such as moving, scaling, adjusting layers, or other editing operations on an overlay element, the system judges the operation based on the aforementioned container constraint rules. When it is determined that the overlay element operation has at least one conflict among range conflict, layer conflict, and mutual exclusion conflict, the system does not directly write the operation into the overlay element data, but instead intercepts the operation. The interception means preventing the current editing operation from immediately changing the position, size, layer, or state of the overlay element in the data layer, thereby preventing results that do not conform to the constraint rules from being saved or entering the subsequent rendering process.

[0081] After intercepting the original operation, the system temporarily retains the operation on the overlay element as an operation to be corrected. The operation to be corrected includes at least the operation intent information such as the operation direction, target position, target size, or target layer. For example, when a user drags an element, the system retains its drag direction and desired target position; when a user scales an element, the system retains its target size and the dragged control point information; when a user adjusts a layer, the system retains its target layer order. By retaining these operation intents, the system does not simply revert the user's operation during subsequent corrections, but rather limits the operation result to the range allowed by the corresponding container while trying to satisfy the user's editing intent as much as possible.

[0082] Furthermore, the system invokes the corresponding correction strategy based on the conflict type to obtain the correction result. If a range conflict is determined, the system invokes the range correction strategy to correct the target position or target size based on the editable boundary of the container to which the overlay element belongs. Specifically, when an overlay element moves beyond the container boundary, its target position can be adjusted to the nearest available position within the container boundary; when an overlay element scales beyond the container's allowed range, its maximum size can be limited, or the target size can be clipped or snapped while maintaining the operation direction, ensuring its boundary does not exceed the editable area of ​​the container. The editable boundary of the container here can include the outer boundary of the container, safety margins, prohibited areas, and the boundary positions where snapping is allowed.

[0083] If a layer conflict is identified, the system invokes a layer correction strategy to correct the target layer according to a preset layer order. This preset layer order specifies the display priority and occlusion relationships between different types of overlay elements. For example, background decorative elements should be located below text elements, corner elements should not obscure core buttons, and watermark elements are only allowed within specified layer ranges. If the user adjusts an overlay element to a position that does not conform to the preset layer relationships, the system can correct it to the nearest valid layer or restore it to the default layer allowed for its type, thus ensuring that the corrected layer state conforms to the layer constraints within the container.

[0084] If a mutual exclusion conflict is identified, the system invokes a mutual exclusion correction strategy to adjust the operation state or refuse the coexistence of mutually exclusive objects based on the mutual exclusion relationships of existing elements within the same container. These mutual exclusion relationships may include allowing only one element of the same type within the same container, prohibiting two elements with the same function from being displayed simultaneously, and prohibiting elements of specific types from overlapping or being enabled simultaneously. For mutual exclusion conflicts, the system can adjust the operation according to business rules, such as replacing an existing element, disabling one of the elements, canceling the new operation, or directly refusing the coexistence of mutually exclusive objects. This approach avoids duplicate badges, duplicate buttons, or mutually obscuring and functionally conflicting elements within the same container.

[0085] After obtaining the correction result, the system verifies it again based on the container constraint rules. This second verification confirms whether the corrected target position, target size, target layer, and operation status all satisfy the range constraints, hierarchy constraints, and mutual exclusion constraints of the corresponding container. If the verification passes, the system determines the correction result as the replacement for the original operation and allows this correction operation to enter the subsequent data update process. At this point, the data written to the overlay elements is not the conflicting operation initially generated by the user, but a legal operation restricted by the container constraint rules, thus ensuring that the overlay elements are always confined within the corresponding container.

[0086] If the corrected result still fails verification after re-verification, it indicates that the conflict cannot be resolved using the current correction strategy, or that further correction would lead to a significant discrepancy with the user's intended action. In this case, the system restores the overlay element to its pre-operation state, that is, the position, size, layer, and interaction state of the overlay element are restored to their valid state before the operation occurred, and the system may prompt the user that the operation is not permitted if necessary. This rollback mechanism prevents abnormal operation results from entering the data layer, ensuring the consistency and reliability of the edited data.

[0087] In a specific example, a user drags an active badge outside its badge container. After determining a range conflict based on container constraints, the system intercepts the drag, preserving the user's drag direction and target position. Subsequently, the system invokes a range correction strategy to adjust the badge's target position to a legal location within the badge container boundary, close to the user's drag direction. Then, the system re-verifies whether the corrected position is still within the badge container. If the verification passes, the corrected position is written to the data; if the verification fails, the badge's original position is restored. Similarly, if a user attempts to elevate a badge to a layer that covers the core text, the system can adjust it to the highest allowed layer based on a layer correction strategy. If a user adds another badge that is mutually exclusive with an existing badge within the same container, the system can either refuse their coexistence or retain one of the badges according to the rules.

[0088] Through the above implementation method, this application does not directly discard user operations when a conflict is detected. Instead, it first intercepts the original operation and retains the operation intent, and then makes targeted corrections based on the conflict type, so that the corrected operation result is restricted to the container and its constraint rules. This improves the continuity of the user editing process and avoids problems such as boundary violations, erroneous occlusion, and coexistence of mutually exclusive elements, thereby enhancing the legality and stability of the editing results of overlaid elements.

[0089] like Figure 2 As shown, Figure 2 The diagram illustrates the process of intercepting the original operation and generating a corrective operation when a conflict exists. First, the system receives the original operation generated by the user, which may include position, size, or layer intent. Then, the system determines whether the operation conflicts with at least one of these parameters. If no conflict exists, the conflict-free operation directly enters the data update process.

[0090] If the system determines that a conflict exists, it intercepts the operation, preventing the original operation from directly writing data. Afterward, the system retains the operation intent, including the operation direction, target location, size, or layer information. Based on the identified conflict type, the system applies the corresponding correction strategy: for range conflicts, a range correction strategy is used to trim or snap the container according to its boundaries; for hierarchical conflicts, a hierarchical correction strategy is used to adjust the hierarchy according to a preset order; for mutual exclusion conflicts, a mutual exclusion correction strategy is used to adjust the operation state or prevent mutually exclusive objects from coexisting.

[0091] The results of each correction strategy are aggregated into a correction result, which is confined to its corresponding container. The system then re-verifies the correction result. If the re-verification passes, a correction operation is generated to replace the original operation, and the subsequent data update process begins; if the re-verification fails, the pre-operation state of the overlay elements is restored. Figure 2 The overall process embodies a closed-loop processing logic of "conflict detection - operation interception - intent retention - classification correction - re-verification - update or recovery".

[0092] In some embodiments, in step S104 above, updating the overlay element data according to the correction operation or non-conflicting operation, and encapsulating the state before and after the operation, element identifier, position size, and layer information into an operation instruction, specifically includes: After determining that the current operation is a correction operation or a non-conflicting operation, read the pre-operation state of the corresponding overlay element, and determine the non-conflicting operation or correction operation as a valid operation; Update the position, size, angle, container and layer status of the overlay element in the base map coordinate system based on the valid operations, and synchronously generate the display status corresponding to the current display coordinate system; After updating the data of the overlay elements, read the post-operation state of the overlay elements and associate the pre-operation state and post-operation state with the element identifier; The effective operation type, element identifier, container identifier, state before operation, state after operation, position and size information, layer information, and time sequence identifier are encapsulated into operation instructions.

[0093] In this embodiment, after a user initiates an editing operation on an overlay element and undergoes conflict detection and necessary correction, the system determines that the current operation is either a non-conflicting operation or a corrective operation. A non-conflicting operation refers to an operation that, after being judged by container constraint rules, does not reveal any range conflict, hierarchy conflict, or mutual exclusion conflict. A corrective operation refers to a valid alternative operation formed after the original operation had a conflict, but was processed by the corresponding correction strategy and passed re-verification. The system only allows the current operation to enter the overlay element data update process when it is determined to be one of the above valid operations.

[0094] Before performing a data update, the system reads the pre-operation state of the corresponding overlay element. This pre-operation state indicates the valid state of the overlay element within the edited data before the current valid operation occurs. It can include the overlay element's position, size, angle, container, layer status, and necessary display or interactive states in the base map coordinate system. By reading and retaining the pre-operation state before the update, a basis can be provided for subsequent undo, redo, operation tracing, conflict rollback, and collaborative editing synchronization. The overlay element can be uniquely identified by its element identifier to avoid data association errors in scenarios involving continuous or concurrent operations on multiple elements.

[0095] Subsequently, the system identifies non-conflicting or corrective operations as valid operations and updates the data of the overlay elements in the base map coordinate system based on these valid operations. Specifically, when the valid operation is a move operation, the system updates the position of the overlay element in the base map coordinate system; when the valid operation is a scaling operation, the system updates its size and boundary information related to the size change; when the valid operation is a rotation operation, the system updates its angle; when the valid operation involves switching containers, the system updates its container; and when the valid operation involves adjusting layers, the system updates its layer state. Since the base map coordinate system is based on the original size of the base map material, storing the core editing data of the overlay elements in the base map coordinate system ensures that the position and size of the elements relative to the base map remain consistent across different display sizes, different terminals, or different scaling ratios.

[0096] After updating the data in the base map coordinate system, the system synchronously generates a display state corresponding to the current display coordinate system. This display state is used for the real-time rendering of the current editing interface and can include the display position, size, and angle of overlaid elements within the operation area, the position of the selection box, the position of control points, and the layer display order. The display state is generated based on the updated base map coordinate parameters and the mapping relationship in the current editing context. By simultaneously maintaining both the base map coordinate data and the display state, consistency in data storage and cross-platform display is ensured, and the user interface can promptly present the results of the current effective operation, avoiding asynchrony between the data layer and the display layer.

[0097] After updating the overlay element data, the system reads the post-operation state of the overlay element. The post-operation state refers to the new state of the overlay element after a valid operation writes data and the display state is synchronized. The system associates both the pre-operation state and the post-operation state with the element identifier of the overlay element, thus forming a traceable record of state changes. For cases where multiple operations occur consecutively on the same overlay element, each operation can correspond to an independent set of pre-operation and post-operation states, with the order distinguished by a time sequence identifier.

[0098] Furthermore, the system encapsulates valid operations into operation instructions. These operation instructions include at least the operation type, element identifier, container identifier, pre-operation state, post-operation state, position and size information, layer information, and time sequence identifier. Specifically, the operation type identifies whether the operation is a move, scale, rotate, layer adjustment, container switch, state change, or combination operation; the element identifier identifies the overlay element being operated on; the container identifier identifies the constraint region and business container corresponding to the element; the pre-operation and post-operation states describe the data changes caused by the operation; the position and size information records the boundary, position, width, and height of the overlay element in the base map coordinate system; the layer information records the layer order or hierarchy before and after the operation; and the time sequence identifier marks the order of the operation within the operation sequence.

[0099] In one optional implementation, when the valid operation originates from a correction operation, the operation instruction may also record that the valid operation was obtained by correcting a conflicting operation, as well as the corresponding conflict type or correction method, for subsequent operation auditing, user prompts, or data playback. However, this record does not affect the correction operation from entering the data update process as a valid operation.

[0100] Through the above implementation methods, this application can synchronously update the base map coordinate data and display status of the overlaid elements after confirming the legality of the operation, and encapsulate the state before and after the operation, element identification, position size, and layer information into structured operation instructions. This not only ensures the consistency between edited data and interface display, but also provides a reliable data foundation for undo / redo, history recording, collaborative synchronization, and anomaly recovery.

[0101] In some embodiments, step S105 above, which involves rendering the canvas in real time based on operation instructions, synchronizing collaborators via WebSocket, and performing merge, reverse, or replay operations in conjunction with OT or CRDT rules and the operation instruction stack upon receiving remote operations or undo / redo, specifically includes: Update the local overlay element data according to the element identifier in the operation instruction and the state after the operation, and combine the mapping relationship to convert it into the display state for real-time rendering of the canvas; Write the operation instructions into the local operation instruction stack, attach the operator identifier, version identifier, and timing identifier, and then send them to the collaborator in the collaborative editing session via WebSocket. When a remote operation instruction is received, the version identifier and timing identifier are used to determine whether the remote operation instruction and the local unconfirmed operation are concurrent. If they are not concurrent, the remote operation instruction is replayed directly. If they are concurrent, the operation parameters are converted according to the OT rule or the element state is merged according to the CRDT rule before the canvas is updated. When an undo or redo is triggered, the corresponding operation instruction is read from the operation instruction stack. A reverse operation is generated based on the pre-operation state of the corresponding operation instruction, or a replay operation is generated based on the post-operation state of the corresponding operation instruction. The reverse operation or replay operation is then executed as a new operation instruction for local rendering and synchronized to the collaborator.

[0102] In this embodiment, after the valid operations of the overlaid elements are encapsulated into operation instructions, the system performs local canvas rendering, collaborative synchronization, and undo / redo processing based on these operation instructions. The operation instructions may include operation type, element identifier, container identifier, pre-operation state, post-operation state, position and size information, layer information, operator identifier, version identifier, and timing identifier. By uniformly abstracting user editing behaviors into operation instructions, local rendering, remote synchronization, conflict merging, and historical playback can all utilize a consistent data foundation.

[0103] During local rendering, the system locates the overlay element being manipulated based on the element identifier in the operation command and updates the local overlay element data according to the post-operation state. The post-operation state can include the overlay element's position, size, angle, container, and layer state in the base map coordinate system. After updating, the system, based on the mapping relationship in the current editing context, converts the overlay element data in the base map coordinate system into its display state in the current display coordinate system and refreshes the canvas accordingly. The display state can include the element's display position, size, rotation angle, selection box position, control point position, and layer display order on the canvas. Therefore, users can immediately see the canvas changes after completing an operation, ensuring real-time editing interaction.

[0104] Furthermore, the system writes the operation instruction into the local operation instruction stack. This local operation instruction stack is used to save executed operation instructions in the order they occurred, providing a basis for subsequent undo, redo, replay, and collaborative conflict handling. When writing to the operation instruction stack, the system attaches an operator identifier, a version identifier, and a timing identifier to the operation instruction. The operator identifier distinguishes operations initiated by different collaborators; the version identifier indicates the document or canvas data version on which the operation is based; and the timing identifier records the order of the operation in the local or collaborative session. Subsequently, the system sends the operation instruction with the attached synchronization identifier to other collaborator clients in the collaborative editing session via WebSocket. Because WebSocket can maintain long-term communication between clients, it is suitable for low-latency synchronization of canvas editing results.

[0105] When a local client receives a remote operation instruction, the system first reads the version identifier and timing identifier carried in the remote operation instruction and compares them with a local unconfirmed operation to determine whether they are concurrent operations. A local unconfirmed operation refers to an operation that has been executed and sent locally but has not yet been confirmed by the collaborative session or has not yet achieved consistency merging with the remote state. If the remote operation instruction and the local unconfirmed operation do not constitute a concurrent relationship—for example, if the remote operation is generated after the current known local version, or if their timing relationship can be clearly determined—the system can directly replay the remote operation instruction. During replay, the system updates the corresponding overlay element data according to the element identifier and post-operation state in the remote operation instruction and refreshes the local canvas.

[0106] If a concurrent relationship is determined between a remote operation command and a local unconfirmed operation, the system invokes concurrency handling rules to merge them. Concurrency can manifest as multiple collaborators performing editing operations on the same overlay element or related elements within the same container within a short timeframe. Examples include simultaneously moving the same element, simultaneously adjusting the size of the same element, or one party adjusting a layer while another moves an element. For implementations using OT rules, the system can transform remote operation parameters based on the impact of local unconfirmed operations on remote operations, ensuring that remote operations achieve execution results consistent with the collaborative order in the current local state. For instance, if an element has already been moved locally, remote adjustments to the same element's position can be transformed based on the changed local baseline state before application. For implementations using CRDT rules, the system can merge concurrent states according to preset element state merging rules, such as version priority, time priority, operator priority, or field-level merging rules, to determine the final state of fields like position, size, and layer. After OT transformation or CRDT merging, the system updates the local overlay element data and refreshes the canvas, gradually converging all clients to a consistent canvas state.

[0107] The OT rule, or Operation Transformation Rule, is used to transform the parameters or target of one of the operations when multiple clients concurrently perform operations based on the same or different historical states. This allows the operation to continue execution in a state where another concurrent operation has already been applied, while preserving the original editing intent of each operation as much as possible. In other words, the OT rule does not simply overwrite the operation results according to the order of receipt, but rather adapts the later-arriving operation based on the influence relationship between concurrent operations. For example, when a local client has moved an overlay element a certain distance to the right, and a remote client moves the same overlay element downwards based on its previous position, the system can transform the target position or displacement of the remote movement operation based on the new position of the local move, so that the remote operation still exhibits the editing intent of "moving downwards" in the current local state. As another example, when a local operation changes the element size, and a remote operation adjusts the element position based on the original size, the position parameters of the remote operation can be transformed accordingly based on the boundary or anchor point after the size change. Therefore, the OT rule is suitable for scenarios where collaborative processing is centered around "operations," and its focus is on transforming concurrent operations before execution.

[0108] The CRDT rule refers to a conflict-free copy data type rule, which enables multiple clients to achieve consistent results through a preset data state merging method, even without a strict global execution order. Unlike OT rules, which focus on transformation operations, CRDT rules emphasize merging element states. Specifically, in the scenario of editing overlay elements, the system can use the position, size, angle, container, and layer state of overlay elements as mergeable state fields and set deterministic merging rules for each field. For example, for the position field of the same element, the state with the newer version identifier can be prioritized, or the state with the later time sequence identifier can be prioritized; for the layer field, the final layer can be determined according to preset layer priority and container constraint rules; for concurrent modifications of different fields, field-level merging can be used, meaning that when a local operation modifies the position and a remote operation modifies the layer, the final state retains both the position modification and the layer modification. Because all clients use the same merging rules, even if the remote operations arrive in different orders, they can converge to the same overlay element state.

[0109] During undo processing, the system reads the operation instruction to be undone from the local operation instruction stack and generates a reverse operation based on the state of the operation instruction before the operation. The reverse operation restores the overlaid elements from their current state to their state before the operation occurred. For example, if the original operation was to move an element, the reverse operation restores the element to its previous position; if the original operation was to scale an element, the reverse operation restores its previous size; if the original operation was to adjust a layer, the reverse operation restores the layer's previous state. The generated reverse operation is executed as a new operation instruction, rather than simply deleting the historical operation record. This ensures that the undo action itself can be recorded, synchronized, and audited, and can be correctly perceived by other collaborators in collaborative editing scenarios.

[0110] During redo processing, the system reads the corresponding operation instruction from the operation instruction stack or redo record, and generates a replay operation based on the post-operation state of that operation instruction. The replay operation is used to reapply previously undone edits. The replay operation is also encapsulated as a new operation instruction and performs local rendering and collaborative synchronization. By converting both undo and redo into new operation instructions, the system can maintain the continuity of the operation sequence and avoid inconsistencies in state between different clients due to local deletion or rearrangement of historical records.

[0111] In one optional implementation, for undo operations in collaborative scenarios, the system can restrict users to only undoing their own operation commands, or, with access control, allow the undoing of operation commands from designated collaborators. When other concurrent or subsequent operations exist after the undone operation, the system can adjust the reverse operation using OT transformation or CRDT merging rules to avoid disrupting the results of subsequent legitimate operations when undoing earlier operations. This ensures stable convergence of the canvas state even during multi-user collaborative editing.

[0112] Through the above implementation methods, this application can complete local real-time rendering, WebSocket collaborative synchronization, remote operation merging, and undo / redo processing based on unified operation commands. This approach not only ensures real-time feedback for single-end editing but also maintains the consistency of the canvas state of each client during concurrent editing across multiple ends, and provides a reliable basis for historical playback and anomaly recovery.

[0113] like Figure 3 As shown, Figure 3 The flowchart illustrates the process structure for local rendering, remote synchronization, and concurrent processing based on operation commands. Figure 3The left side represents the local client. After generating an operation command, the local client sends it to the local rendering queue to refresh the canvas in real time. Simultaneously, it writes the operation command stack as the basis for undo and redo. When the user triggers undo or redo, the local client generates a reverse operation or replay operation based on the operation command stack and executes it as a new operation command.

[0114] Figure 3 A synchronization identifier is shown at the top center, which includes an operator identifier, a version identifier, and a timing identifier. After the operation instruction is appended with the above synchronization identifier, it is transmitted via… Figure 3 The WebSocket module in the middle handles sending and receiving. It's used to transmit commands between the local client and collaborating clients, enabling each end to receive editing results from other collaborators in a timely manner.

[0115] Figure 3 The right side of the image shows the collaborator client. After receiving a remote operation command, the collaborator client can perform remote replay rendering and return the remote operation result. For operations with concurrent relationships, Figure 3 The concurrency processing module in the lower right corner determines whether there is concurrency based on the version identifier and timing identifier: if there is no concurrency, the remote operation is directly replayed; if there is concurrency, the canvas is updated after processing through OT conversion or CRDT merging.

[0116] Figure 3 The "Consistent Canvas Status Across Clients" message at the bottom center indicates the final result, meaning that after synchronization, concurrent merging, reverse engineering, or replay processing of operation commands, the local client and collaborator clients maintain consistent data on overlay elements and canvas display status. Figure 3 Overall, it embodies a collaborative editing closed loop of "local execution - instruction stacking - WebSocket synchronization - remote replay / concurrency merging - undo / redo synchronization - multi-terminal state consistency".

[0117] Reference Figure 4 An embodiment of the present invention provides an adaptive editing and synchronization control system 4 for material overlay elements, the system specifically including: The material acquisition module 401 is used to respond to the user's selection of the background image material, acquire the original size of the background image material, the size of the operation container and the data of the overlay elements, calculate the dynamic scale based on the original size and the size of the operation container, and establish the mapping relationship between the background image coordinate system and the display coordinate system. The material loading module 402 is used to initialize the display state, layer state and container constraint rules of the overlay elements according to the overlay element data and mapping relationship. Before loading the material image, the operation area is set to an unlocked state and the historical operation boundary is cleared. After the material image is loaded, the operation area is reset according to the actual rendering size and the ratio is locked. The conflict judgment module 403 is used to receive the operation of the overlay element based on the locked operation area, convert the display coordinates into the base map coordinates, and judge whether there are range conflicts, hierarchical conflicts and mutual exclusion conflicts in combination with the container constraint rules. If there are conflicts, the original operation is intercepted and a correction operation limited to the corresponding container is generated. The instruction encapsulation module 404 is used to update the overlay element data according to the correction operation or non-conflicting operation, and encapsulate the state before and after the operation, element identifier, position size and layer information into operation instructions. The operation execution module 405 is used to render the canvas in real time based on operation instructions, synchronize collaborators via WebSocket, and perform merge, reverse, or replay operations in combination with OT or CRDT rules and operation instruction stack when receiving remote operations or undo / redo.

[0118] It is understandable that, such as Figure 1 The content of the adaptive editing and synchronization control method embodiment for overlay elements shown is applicable to the adaptive editing and synchronization control system embodiment for overlay elements. The specific functions implemented by the adaptive editing and synchronization control system embodiment for overlay elements are as follows: Figure 1 The adaptive editing and synchronization control method for the overlay elements of the shown material is the same as that implemented in this example, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the embodiment of the adaptive editing and synchronization control method for overlaying material elements shown are also the same.

[0119] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0120] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0121] Reference Figure 5 The present invention also provides a computer device 5, including: a memory 502 and a processor 501, and a computer program 503 stored in the memory 502. When the computer program 503 is executed on the processor 501, it implements the adaptive editing and synchronous control method for material overlay elements as described in any of the above methods.

[0122] The computer device 5 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 5 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will understand that... Figure 5 The computer device 5 is merely an example and does not constitute a limitation on the computer device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0123] The processor 501 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0124] In some embodiments, the memory 502 may be an internal storage unit of the computer device 5, such as a hard disk or memory of the computer device 5. In other embodiments, the memory 502 may be an external storage device of the computer device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 5. Further, the memory 502 may include both internal and external storage units of the computer device 5. The memory 502 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0125] This invention also provides a computer-readable storage medium storing a computer program thereon. When the computer program is run by a processor, it implements the adaptive editing and synchronization control method for material overlay elements as described in any of the above methods.

[0126] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0127] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0128] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0129] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. An adaptive editing and synchronization control method for overlaying material elements, characterized in that, The method specifically includes: In response to the user selecting a background image, the system obtains the original size of the background image, the size of the operation container, and the data of the overlaid elements. Based on the original size and the size of the operation container, it calculates a dynamic scale and establishes a mapping relationship between the background image coordinate system and the display coordinate system. Initialize the display state, layer state, and container constraint rules of the overlay elements based on the overlay element data and mapping relationship. Before loading the material image, set the operation area to an unlocked state and clear the historical operation boundary. After the material image is loaded, reset the operation area and lock the ratio according to the actual rendering size. Based on the locked operation area, the operation of the overlay element is received, the display coordinates are converted into the base map coordinates, and the container constraint rules are combined to determine whether there are range conflicts, hierarchical conflicts and mutual exclusion conflicts. If there are conflicts, the original operation is intercepted and a correction operation limited to the corresponding container is generated. Update the overlay element data based on the correction operation or non-conflicting operation, and encapsulate the state before and after the operation, element identifier, position size and layer information into operation instructions; The canvas is rendered in real time based on operation commands, collaborators are synchronized via WebSocket, and when receiving remote operations or undo / redo, merge, reverse or replay operations are performed in combination with OT or CRDT rules and operation command stack.

2. The method according to claim 1, characterized in that, The process of calculating the dynamic scale based on the original dimensions and the dimensions of the operating container, and establishing the mapping relationship between the base map coordinate system and the display coordinate system, specifically includes: Based on the original size of the base image material and the size of the operation container, determine the width scaling reference value and the height scaling reference value respectively, and select the scaling reference value that allows the base image material to be displayed completely without distortion from the width scaling reference value and the height scaling reference value as the dynamic scale; The actual display size of the base image material within the operation container is determined based on the dynamic scale, and the display offset of the base image material is determined based on the actual display size and the size of the operation container. A bidirectional mapping relationship between the base map coordinate system and the display coordinate system is established based on the dynamic scale and the display offset. This bidirectional mapping relationship is used to convert the position and size of the overlay element in the base map coordinate system into the display state.

3. The method according to claim 1, characterized in that, The initialization of the display state, layer state, and container constraint rules of the overlay elements based on the overlay element data and mapping relationship specifically includes: Read the element identifier, element type, base map coordinate position and size, container identifier, layer order and operable attributes from the overlay element data, and generate the corresponding overlay element instance based on the element identifier and element type; Based on the mapping relationship, the coordinate position and size of the base map are converted into the display coordinate position and size, forming the display state of the overlay element instance; The stacked element instance is bound to the corresponding container based on its container identifier, and the corresponding editing permissions are determined by combining the element type and operable attributes. Sort multiple overlay element instances based on layer order to generate layer states used to determine coverage relationships and selection priorities; Generate container constraint rules based on the corresponding container, editing permissions, and layer status.

4. The method according to claim 1, characterized in that, The step of setting the operation area to an unlocked state and clearing historical operation boundaries before loading the source image specifically includes: After detecting that the user has selected a new background image, a material switching event is generated, and the operation area is marked as unlocked in response to the material switching event; In the unlocked state, pause the boundary detection and interactive control of the overlay elements based on the display coordinate system, and clear the display size, boundary offset, editable area range and control point position information of the previous base image material; Set the interactive state of the overlay element to the waiting initialization state to preserve the base map coordinate data and layer data of the overlay element, and prevent it from performing move, scale or snap operations using the historical operation boundary until the operation area boundary is redefined after the material image is loaded.

5. The method according to claim 1, characterized in that, The process of resetting the operation area and locking the aspect ratio according to the actual rendering size after the source image is loaded specifically includes: In response to the image loading completion event, obtain the actual rendering width and actual rendering height of the image in the operation container, and update the display boundary, starting position and boundary offset of the operation area according to the actual rendering width and actual rendering height; After the display boundary is updated, the display ratio corresponding to the actual rendering width and actual rendering height is verified with the original width and height ratio of the base image material. If the verification result meets the preset error conditions, the display ratio is determined as the locking ratio of the operation area. If the verification result does not meet the preset error conditions, the operation area size is corrected according to the original width and height ratio and then the locking ratio is determined. Switch the operation area from an unlocked state to a locked state, and refresh the display position, display size, and interactive control points of the overlay elements based on the boundary of the locked operation area and the locking ratio.

6. The method according to claim 1, characterized in that, The operation based on the locked operation area receives overlay element operations, converts the display coordinates to base map coordinates, and determines whether there are range conflicts, hierarchy conflicts, and mutual exclusion conflicts based on container constraint rules, specifically including: After the operation area is locked, the bounds of the locked operation area, the display offset, and the mapping relationship are written into the editing context, and the user's editing operations on the overlay elements are received. In response to the editing operation, the display coordinate parameters of the overlay elements in the display coordinate system are collected, and the coordinates are normalized by combining the operation area boundary and the display offset. The display coordinate parameters include the position size before and after the operation, the position of the control point, and the layer change information. After completing the coordinate normalization process, the normalized display coordinate parameters are converted into base map coordinate parameters according to the mapping relationship. Based on the base map coordinate parameters, the base map boundary and target layer state after the overlay element operation are determined. Call the container constraint rules corresponding to the container to which the overlay element belongs, determine whether the boundary of the base image exceeds the container to which the overlay element belongs to determine the range conflict, determine whether the target layer state meets the preset hierarchical relationship to determine the hierarchical conflict, and determine whether the editing operation conflicts with the mutual exclusion conditions of existing elements in the same container to determine the mutual exclusion conflict.

7. The method according to claim 6, characterized in that, The step of intercepting the original operation and generating a corrective operation limited to the corresponding container if a conflict exists specifically includes: After determining that there is at least one conflict among range conflict, hierarchical conflict and mutual exclusion conflict in the overlay element operation according to the container constraint rules, prevent the overlay element operation from being directly written to the overlay element data, and retain the corresponding operation direction, target position, target size or target layer as the overlay element operation to be corrected. The corresponding correction strategy is invoked based on the conflict type to perform the correction and obtain the correction result. The correction strategies include: for range conflicts, correcting the target position or target size based on the editable boundary of the container to which the overlay element belongs; for layer conflicts, correcting the target layer based on the preset layer order; and for mutual exclusion conflicts, correcting the operation state or refusing the coexistence of mutually exclusive objects based on the mutual exclusion relationship of elements within the same container. The correction result is validated based on container constraint rules. If the validation passes, the correction result is determined as the correction operation to replace the original operation, so that the correction operation is limited to the corresponding container and enters the subsequent data update process. Alternatively, if the validation fails, the state of the superimposed elements before the operation is restored.

8. The method according to claim 1, characterized in that, The step of updating the overlay element data based on the correction operation or the non-conflicting operation encapsulates the state before and after the operation, element identifier, position and size, and layer information into operation instructions, specifically including: After determining that the current operation is a correction operation or a non-conflicting operation, read the pre-operation state of the corresponding overlay element, and determine the non-conflicting operation or correction operation as a valid operation; Update the position, size, angle, container and layer status of the overlay element in the base map coordinate system based on the valid operations, and synchronously generate the display status corresponding to the current display coordinate system; After updating the data of the overlay elements, read the post-operation state of the overlay elements and associate the pre-operation state and post-operation state with the element identifier; The effective operation type, element identifier, container identifier, state before operation, state after operation, position and size information, layer information, and time sequence identifier are encapsulated into operation instructions.

9. The method according to claim 1, characterized in that, The process of rendering the canvas in real time based on operation commands, synchronizing collaborators via WebSocket, and performing merge, reverse, or replay operations in conjunction with OT or CRDT rules and the operation command stack upon receiving remote operations or undo / redo, specifically includes: Update the local overlay element data according to the element identifier in the operation instruction and the state after the operation, and combine the mapping relationship to convert it into the display state for real-time rendering of the canvas; Write the operation instructions into the local operation instruction stack, attach the operator identifier, version identifier, and timing identifier, and then send them to the collaborator in the collaborative editing session via WebSocket. When a remote operation instruction is received, the version identifier and timing identifier are used to determine whether the remote operation instruction and the local unconfirmed operation are concurrent. If they are not concurrent, the remote operation instruction is replayed directly. If they are concurrent, the operation parameters are converted according to the OT rule or the element state is merged according to the CRDT rule before the canvas is updated. When an undo or redo is triggered, the corresponding operation instruction is read from the operation instruction stack. A reverse operation is generated based on the pre-operation state of the corresponding operation instruction, or a replay operation is generated based on the post-operation state of the corresponding operation instruction. The reverse operation or replay operation is then executed as a new operation instruction for local rendering and synchronized to the collaborator.

10. An adaptive editing and synchronization control system for overlaying material elements, characterized in that, The system specifically includes: The material acquisition module is used to respond to the user's selection of a background image material, obtain the original size of the background image material, the size of the operation container, and the data of the overlay elements, calculate the dynamic scale based on the original size and the size of the operation container, and establish the mapping relationship between the background image coordinate system and the display coordinate system. The material loading module is used to initialize the display state, layer state, and container constraint rules of the overlay elements based on the overlay element data and mapping relationship. Before loading the material images, the operation area is set to an unlocked state and the historical operation boundaries are cleared. After the material images are loaded, the operation area is reset according to the actual rendering size and the ratio is locked. The conflict detection module is used to receive operations of overlay elements based on the locked operation area, convert the display coordinates into base map coordinates, and determine whether there are range conflicts, hierarchical conflicts and mutual exclusion conflicts in combination with container constraint rules. If there are conflicts, the original operation is intercepted and a correction operation limited to the corresponding container is generated. The instruction encapsulation module is used to update the overlay element data according to the correction operation or non-conflicting operation, and encapsulate the state before and after the operation, element identifier, position size and layer information into operation instructions; The operation execution module is used to render the canvas in real time based on operation instructions, synchronize collaborators via WebSocket, and perform merge, reverse, or replay operations in combination with OT or CRDT rules and operation instruction stack when receiving remote operations or undo / redo.

Images