Mirror-inverted navigation view area synchronous correction method, device and storage medium

Abstract

This application discloses a method, device, and storage medium for synchronous correction of navigation viewports via mirror flipping. The method includes: identifying a window tracking controller component within the navigation thumbnail viewport; performing low-level rendering isolation processing on the window tracking controller component; separating the window tracking controller component from the nested stacking structure of the original 2D layers and pushing it to the graphics processor process, and storing the window tracking controller component in a 3D tile video memory isolated storage space; and performing coordinate realignment and correction on the window tracking controller component based on the spatial inverse matrix transformation rules corresponding to the mirror flipping control command, projecting it into the navigation thumbnail viewport to achieve synchronous following with spatial position. This application separates the navigation component from the nested structure through low-level rendering isolation processing, and realigns its coordinates in an independent 3D video memory space based on the spatial inverse matrix, achieving a radical correction with zero CPU dependency, avoiding main thread blocking and screen tearing.

Description

Technical Field

[0001] This application relates to the technical field of medical digital applications, and in particular to a method, device and storage medium for synchronous correction of navigation view area by mirror flipping. Background Technology

[0002] In medical digital pathology systems (Whole Slide Image) or microscopy client applications, users frequently need to use the horizontal or vertical mirroring function of pathological images to achieve field-of-view alignment under different slide mounting orientations. Currently, the industry typically relies on front-end 2D spatial transformation commands to synchronously flip the main canvas area and associated subordinate objects (such as the viewport following the red box in the global navigation thumbnail). However, in special scenarios such as large medical screens and embedded medical devices, the devices often use outdated browser kernels that have not been updated for a long time (such as the QtWebEngine kernel based on Chromium 83), making it impossible to solve rendering defects by upgrading the underlying framework.

[0003] When performing a 2D mirror flip transformation on nodes with a deep parent-child nested document object model structure within such a restricted kernel environment, and these nodes contain absolutely positioned tracking elements (i.e., the navigation red box), existing solutions suffer from a serious and fatal flaw. The underlying rendering engine of older kernels, during the merging of traditional 2D graphics trees, causes a misalignment between the geometric matrix and the physical pixel location of absolutely positioned floating objects. Specifically, after the main frame is flipped, the navigation red box cannot follow correctly, becoming completely offset or detached from its original area. This results in the system losing its ability to accurately guide the user, severely impacting the continuity and reliability of image viewing and diagnostics.

[0004] To address the aforementioned offset phenomenon, existing industry-standard compensation methods primarily involve deploying a high-frequency timer interception mechanism at the front-end code layer. This mechanism corrects the offset by real-time reverse redrawing and intercepting the coordinate variables of the view matrix. However, in smooth, rapid scaling and dragging operations involving massive medical slices (hundreds of megabytes in size), this high-frequency interception scheme directly triggers massive main thread blocking and page reflow, severely causing screen tearing and unwarranted hardware resource lag and power consumption. Therefore, how to fundamentally resolve the issue of uncontrolled offset in the navigation view area after flipping, without relying on energy-intensive main thread reverse calculation logic, has become a pressing technical challenge in this field.

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

[0006] The main objective of this application is to provide a method, device, and storage medium for synchronous correction of navigation view area during mirror flipping, aiming to solve the technical problem of performance loss caused by high-frequency interception when synchronous correction of navigation view area during mirror flipping of existing digital pathology images.

[0007] To achieve the above objectives, this application proposes a navigation view area synchronous correction method based on mirror flipping, comprising:

[0008] In response to the mirror flip control command, a window tracking controller component within the navigation thumbnail view area is identified. The window tracking controller component includes an absolute positioning attribute. The mirror flip control command is issued to the high-definition main image view area and the associated navigation thumbnail view area.

[0009] After performing low-level rendering isolation processing on the viewfinder controller component, the viewfinder controller component is stripped from the nested stacking structure of the original two-dimensional layers;

[0010] The stripped window tracking controller component is pushed to the graphics processor process, and the window tracking controller component is stored in a pre-divided 3D tile video memory isolation storage space;

[0011] In the isolated storage space of the three-dimensional tile display memory, the coordinate realignment and correction of the window tracking controller component are performed based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command;

[0012] The corrected window tracking controller component is projected into the navigation thumbnail view area to achieve spatial synchronization with the flipped high-definition main image view area.

[0013] In one embodiment, after the step of identifying the window tracking controller component within the navigation thumbnail view area in response to the mirror flip control command, the method further includes:

[0014] The underlying rendering engine kernel version of the current digital pathology imaging system is detected. When it is determined that the underlying rendering engine kernel belongs to a preset restricted kernel library, the vulnerability adaptation switch is enabled.

[0015] Based on the enabled state of the vulnerability adaptation switch, in response to the mirror flip control command issued to the high-definition main image view area and the associated navigation thumbnail view area, it detects whether the navigation thumbnail view area contains a window tracking controller component with absolute positioning attributes.

[0016] If it is determined that the vulnerability adaptation switch has been turned on, the mirror flip control command has been issued, and the window tracking controller component exists, then the step of performing low-level rendering isolation processing on the window tracking controller component is executed.

[0017] In one embodiment, the step of performing low-level rendering isolation processing on the window tracing controller component includes:

[0018] By sending a forced dimensionality reduction isolation instruction set to the window tracking controller component, the underlying rendering isolation processing is performed. The forced dimensionality reduction isolation instruction set includes at least the following: instructions for forcibly enabling the graphics processor's underlying 3D rendering pipeline, instructions for locking the current node's entity structure in 3D space to prevent coordinate merging, and instructions for depriving the node of its coordinate cache update mechanism in the 2D hierarchy.

[0019] In one embodiment, the step of performing low-level rendering isolation processing on the window tracing controller component includes:

[0020] Apply a drawing isolation constraint rule to the container node of the navigation thumbnail view area. The drawing isolation constraint rule is used to force the rendering context of the window tracking controller component to be separated from the rendering context of the parent container.

[0021] A floating rendering layer is created independently for the window tracking controller component, and the stacking order of the floating rendering layer is set to be higher than the stacking order of all other layers in the navigation thumbnail view area;

[0022] The coordinate system of the floating rendering layer is locked to be directly mapped to the screen coordinate system, and the floating rendering layer is prohibited from inheriting any nested transformation matrix inside the navigation thumbnail view area;

[0023] Based on the mirror flip control command, coordinate transformation is performed independently on the window tracking controller component in the floating rendering layer, and the transformed result is overlaid onto the corresponding position of the navigation thumbnail view area.

[0024] In one embodiment, the step of stripping the window tracking controller component from the nested stacking structure of the original two-dimensional layers includes:

[0025] The underlying rendering engine interrupts the two-dimensional coordinate compression and two-dimensional coordinate merging and recalculation process between the viewport tracking controller component and its parent layer.

[0026] Release the parent-child cascade binding relationship of the window tracking controller component in the nested stacking structure of the original two-dimensional layer, so that the window tracking controller component becomes an independent free node;

[0027] The free nodes and their carried absolute positioning attribute data and focus identifier tracking feature data are extracted to form the stripped window tracking controller component.

[0028] In one embodiment, the step of storing the window tracking controller component into a pre-divided 3D tile memory isolation storage space includes:

[0029] A contiguous 3D tile video memory address space is requested from the underlying graphics processor driver layer of the operating system. The video memory address space is physically isolated from the original video memory space of the high-definition main image view area and the navigation thumbnail view area.

[0030] An independent coordinate base plate is established for the window tracking controller component in the video memory address space, and the origin of the coordinate base plate is associated with the origin of the display coordinate system of the navigation thumbnail view area through a preset offset.

[0031] The absolute positioning attribute data, focus marker tracking feature data, and current visual state data of the window tracking controller component are written into the isolated storage space of the 3D tile display memory.

[0032] In one embodiment, the step of realigning and correcting the window tracking controller component based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command includes:

[0033] Obtain the flip axis identifier carried in the mirror flip control command, wherein the flip axis identifier includes a horizontal axis identifier or a vertical axis identifier;

[0034] In the isolated storage space of the three-dimensional tile display memory, a three-dimensional spatial inverse transformation matrix is ​​constructed according to the flip axis mark. The three-dimensional spatial inverse transformation matrix is ​​used to map the spatial position coordinates of the window tracking controller component in the original coordinate system to the corrected coordinates in the flipped coordinate system.

[0035] The current spatial position coordinates of the window tracking controller component are multiplied with the three-dimensional spatial inverse transformation matrix to generate the corrected spatial position coordinates.

[0036] Based on the corrected spatial coordinates, the positioning data of the window tracking controller component in the coordinate base plate is updated.

[0037] In one embodiment, the step of projecting the corrected window tracking controller component onto the navigation thumbnail view area to complete the spatial position synchronization and following with the flipped high-definition main image view area includes:

[0038] Obtain the corrected spatial position coordinates of the window tracking controller component in the isolated storage space of the three-dimensional tile display memory;

[0039] The corrected spatial position coordinates are back-calculated into the display coordinate system of the navigation thumbnail view area using a preset offset between the coordinate base plate and the display coordinate system of the navigation thumbnail view area to obtain the projected coordinates;

[0040] Using the projection coordinates as anchor points, the window tracking controller component is redrawn in a floating overlay manner at the corresponding position in the navigation thumbnail view area;

[0041] In real time, in response to the scrolling or zooming operation of the high-definition main image view area, the spatial position coordinates of the window tracking controller component are synchronously updated in the isolated storage space of the three-dimensional tile display memory, and the projection steps are repeated so that the window tracking controller component continuously follows the field of view changes of the high-definition main image view area.

[0042] In addition, to achieve the above objectives, this application also proposes a navigation view area synchronous correction device with mirror flipping, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the navigation view area synchronous correction method with mirror flipping as described above.

[0043] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the navigation view area synchronization correction method with mirror flipping as described above.

[0044] One or more technical solutions proposed in this application have at least the following technical effects:

[0045] This application responds to a mirror flip control command by identifying a window tracking controller component within the navigation thumbnail view area. The window tracking controller component includes an absolute positioning attribute. The mirror flip control command is issued to the high-definition main image view area and the associated navigation thumbnail view area. After performing low-level rendering isolation processing on the window tracking controller component, it is peeled from the nested stacking structure of the original two-dimensional layers. The peeled window tracking controller component is pushed to the graphics processor process and stored in a pre-divided three-dimensional tile video memory isolation storage space. In the three-dimensional tile video memory isolation storage space, based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command, the window tracking controller component undergoes coordinate realignment and correction. The corrected window tracking controller component is projected onto the navigation thumbnail view area to achieve synchronized spatial positioning with the flipped high-definition main image view area.

[0046] The technical solution of this application, without upgrading the underlying kernel or relying on high-frequency CPU back calculation, fundamentally solves the problem of uncontrolled offset of the navigation red box after mirror flipping in the environment of deep nested layers of old kernel. It achieves a technical leap from passive compensation to active isolation, from CPU intensive interception to GPU independent space zero-dependency realignment, and from single correction to continuous dynamic following, which significantly improves the smoothness of image reading and diagnostic reliability in the environment of limited medical equipment. Attached Figure Description

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

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

[0049] Figure 1 This is a flowchart illustrating the first embodiment of the navigation view area synchronous correction method for mirror flipping according to this application;

[0050] Figure 2 This is a detailed process diagram based on step S20 in the first embodiment;

[0051] Figure 3 This is a detailed schematic diagram of step S30 in the first embodiment;

[0052] Figure 4 This is a detailed schematic diagram of step S40 based on the first embodiment;

[0053] Figure 5 This is a detailed process diagram based on step S50 in the first embodiment;

[0054] Figure 6 This is a flowchart illustrating the second embodiment of the navigation view area synchronous correction method for mirror flipping according to this application;

[0055] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the navigation view area synchronous correction method of mirror flipping in the embodiments of this application.

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

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

[0058] In related technologies, synchronous correction of navigation viewports by mirror flipping mainly relies on compensatory technical paths such as front-end shader texture coordinate mapping, coordinate reverse remapping, or high-frequency timer interception and reverse calculation. However, these methods have inherent defects and are difficult to achieve a radical correction without performance loss under old browser kernels (such as the QtWebEngine kernel of Chromium 83) and deep parent-child DOM nesting structures.

[0059] These methods typically employ a "correction" or "compensation" approach within the existing layer structure, such as by altering texture sampling coordinates or intercepting redraw coordinate variables in real time to correct offsets. However, when applied to smooth, rapid scaling and dragging operations on massive medical slices (hundreds of megabytes in size), high-frequency interception schemes trigger massive main thread blocking and page reflow, causing screen tearing and hardware resource lag. Furthermore, shader mapping schemes, when faced with deep nested transformations of absolutely positioned elements, suffer from defects in the 2D coordinate merging of their underlying rendering engine, causing the navigation red box to completely shift or detach from its original area, making it impossible to restore correct following. Existing solutions lack the ability to actively intervene in the underlying rendering pipeline, and cannot fundamentally resolve the offset problem without upgrading the kernel or relying on continuous CPU back-calculation.

[0060] Based on the aforementioned deficiencies in related technologies, this application proposes a mirror-flipped navigation view area synchronous correction method. This method addresses the core pain point that existing compensation schemes cannot achieve zero CPU dependency and radical correction in an environment with an old kernel nested layer structure. It achieves a shift from passive compensation to active isolation control mode through deep integration of low-level rendering isolation processing, stripping of nested structures, independent 3D video memory isolation storage, and spatial inverse matrix coordinate realignment. Specifically, the method first responds to the mirror flip control command and identifies the window tracking controller component with absolute positioning attributes within the navigation thumbnail view area. Then, it performs low-level rendering isolation processing on the component by sending a forced dimensionality reduction isolation command set (including forcibly enabling the GPU's low-level 3D rendering pipeline, locking the 3D spatial entity structure to prevent coordinate merging, and depriving nodes of the coordinate caching update mechanism in the 2D layer) or by using a CSS container isolation and floating rendering layer alternative scheme to peel the component from the nested stacking structure of the original 2D layers. The peeled component is pushed to the graphics processor process, and a 3D tile video memory isolation storage space is allocated for it. In this independent space, the component's coordinates are realigned and corrected based on the spatial inverse matrix transformation rules corresponding to the mirror flip control command. Finally, the corrected component is projected back into the navigation thumbnail view area to achieve synchronous tracking with the spatial position of the flipped high-definition main image view area, and continuous dynamic tracking is achieved by responding to scrolling and scaling operations in real time.

[0061] Through the above-mentioned technical means, this application fundamentally solves the problem of uncontrolled offset of the navigation red box after mirror flipping in the environment of deep nested layers of old kernel without upgrading the underlying kernel or relying on high-frequency CPU back calculation. It achieves a technical leap from passive compensation to active isolation, from CPU intensive interception to GPU independent space zero-dependency realignment, and from single correction to continuous dynamic following, which significantly improves the smoothness of image reading and diagnostic reliability in the environment of limited medical equipment.

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

[0063] Based on this, embodiments of this application provide a navigation view area synchronization correction method for mirror flipping, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the navigation view area synchronization correction method for mirror flipping according to this application. This embodiment includes steps S10-S30:

[0064] Step S10: In response to the mirror flip control command, identify the window tracking controller component in the navigation thumbnail view area. The window tracking controller component includes an absolute positioning attribute. The mirror flip control command is issued to the high-definition main image view area and the associated navigation thumbnail view area.

[0065] In this embodiment, in response to the mirror flip control command, the window tracking controller component within the navigation thumbnail view area first needs to be identified. This mirror flip control command is issued by the user via an external device such as a mouse, touchscreen, or keyboard, and is a spatial transformation command targeting the high-definition main image view area and the associated navigation thumbnail view area. In a digital pathology imaging system, the high-definition main image view area is used to display high-resolution pathological slide tile images, while the navigation thumbnail view area displays a miniature map of the entire slide in a low-magnification panoramic mode, facilitating quick location of the current observation area by the user. The window tracking controller component is a rectangular frame superimposed on the navigation thumbnail view area, typically presented with a red border, used to indicate the corresponding position of the high-definition main image view area in the global thumbnail in real time. This component has an absolute positioning attribute, meaning its position coordinates are set using the absolute positioning method in the Cascading Style Sheet, independent of the normal document flow layout. Therefore, it is prone to coordinate calculation deviations when nested transformations occur in the parent layer.

[0066] In actual execution, the system first captures the mirror flip control command issued by the user through an event response mechanism. This command typically includes flip axis information, such as horizontal or vertical flip. Upon receiving the command, the system does not immediately transform the image but first performs a scan and recognition of the navigation thumbnail view area. The system traverses the document object model tree structure of the navigation thumbnail view area, searching for element nodes with specific class names, identifiers, or custom attributes; these nodes are the view tracking controller components. During recognition, the system verifies whether the component truly carries absolute positioning attributes and whether it possesses focus marker tracking capabilities. This verification step ensures that subsequent correction operations target only the actual component requiring correction, avoiding unnecessary intervention in ordinary layer elements.

[0067] After recognition, the system temporarily stores the component's reference, absolute positioning attribute data, and current coordinates within the navigation thumbnail view in a memory buffer for later use. At this point, the system has completed its response to the mirror flip control command and the identification and location of the target component, preparing for the execution of underlying rendering isolation processing. The entire recognition process is completed within milliseconds, without causing any perceptible delay to the user's operational smoothness.

[0068] Step S20: After performing the underlying rendering isolation processing operation on the window tracking controller component, the window tracking controller component is stripped from the nested stacking structure of the original two-dimensional layer.

[0069] The core purpose of performing low-level rendering isolation processing on the aforementioned viewfinder controller component is to isolate it from the nested stacking structure of the original two-dimensional layers, thereby preventing the contamination of the component's coordinate calculations caused by the parent layer's flip transformation. In older browser kernel environments, when the high-definition main image viewport and its associated navigation thumbnail viewport are simultaneously mirrored, the underlying rendering engine performs two-dimensional coordinate compression and merging recalculation on all nested layers. Because the viewfinder controller component has absolute positioning properties, its coordinate calculations depend on the transformation matrix of the parent layer, making it highly susceptible to offsets under such nested transformations. This application fundamentally changes the rendering hierarchy of this component by performing low-level rendering isolation processing.

[0070] This low-level rendering isolation process can be achieved through several technical approaches. The first approach involves sending a forced dimensionality reduction isolation instruction set to the low-level rendering nodes of the viewfinder tracking controller component. This instruction set contains three key instructions. The first instruction forces the activation of the graphics processor's low-level 3D rendering pipeline, elevating coordinate calculations originally handled by the 2D rendering engine to 3D space. The second instruction locks the current node's solid structure in 3D space, preventing it from interacting with the parent layer's coordinate system during subsequent layer merging. The third instruction deprives the node of its 2D coordinate caching update mechanism, preventing it from passively receiving transformation parameters from the parent layer. When the low-level rendering engine parses this set of instructions, it interrupts the 2D coordinate compression and merging recalculation process originally designed for this component's parent-child node interaction, forcibly extracting the component from the nested stacking structure.

[0071] The second implementation method is suitable for web-based digital pathology systems, which achieves underlying rendering isolation through CSS container isolation and floating rendering layers. Specifically, the system applies drawing isolation constraints to the container nodes in the navigation thumbnail viewport, forcibly separating the rendering context of the viewfinder controller component from the rendering context of its parent container. Simultaneously, the system creates an independent floating rendering layer for this component, forcibly setting its stacking order above all other layers in the navigation thumbnail viewport. The coordinate system of the floating rendering layer is locked to a direct mapping to the screen coordinate system, and the system explicitly prohibits this floating rendering layer from inheriting any nested transformation matrices within the navigation thumbnail viewport. Based on mirror flip control instructions, the system independently performs coordinate transformations on the component within the floating rendering layer and overlays the transformed results onto the corresponding positions in the navigation thumbnail viewport. This alternative also achieves the effect of separating components from the original nested structure, without relying on underlying GPU instructions, and is suitable for different technical architectures.

[0072] Regardless of the implementation method used, after the underlying rendering isolation processing is completed, the viewport tracking controller component becomes an independent, detached node, no longer affected by the coordinate merging errors of the original nested stacked structure of 2D layers. All coordinate linkages between this component and its parent layer have been forcibly released, creating the prerequisite for subsequent coordinate realignment in independent video memory space.

[0073] In specific implementation, the steps for performing low-level rendering isolation processing on the window tracking controller component include:

[0074] By sending a forced dimensionality reduction isolation instruction set to the window tracking controller component, the underlying rendering isolation processing is performed. The forced dimensionality reduction isolation instruction set includes at least the following: instructions for forcibly enabling the graphics processor's underlying 3D rendering pipeline, instructions for locking the current node's entity structure in 3D space to prevent coordinate merging, and instructions for depriving the node of its coordinate cache update mechanism in the 2D hierarchy.

[0075] Based on the underlying rendering isolation processing operation, this embodiment provides a first specific implementation method, namely, to complete the stripping by sending a forced dimensionality reduction isolation instruction set to the underlying rendering node of the window tracing controller component. This forced dimensionality reduction isolation instruction set is a data packet containing multiple underlying rendering control parameters. Its design goal is to forcibly change the processing path of the underlying rendering engine for this component, switching from the conventional two-dimensional coordinate compression and merging process to an independent three-dimensional space processing process.

[0076] In actual execution, the first step is to obtain the handle of the underlying rendering node of the viewfinder controller component in the document object model tree. This handle is a unique identifier assigned to each rendering element by the operating system's graphics subsystem, and control commands can be directly issued to the rendering engine through this handle. After obtaining the handle, the system constructs a forced dimensionality reduction and isolation instruction set according to a preset instruction format. This instruction set contains at least three independent control commands, each corresponding to a specific rendering behavior intervention.

[0077] The first instruction forces the activation of the underlying 3D rendering pipeline of the graphics processor. In older browser engines, the default rendering pipeline is a 2D graphics pipeline, whose coordinate calculations rely on traditional graphics tree merging algorithms. When the system sends this instruction to the underlying rendering node, the graphics processor driver layer initializes a separate 3D rendering context for the viewfinder controller component. The origin of the coordinate system of this 3D rendering context is set to the top-left corner of the screen, and the default value of the depth buffer is set to zero. The purpose of enabling the 3D rendering pipeline is to allow subsequent coordinate calculations to be decoupled from the merging logic of the 2D engine and instead utilize the homogeneous coordinate transformation mechanism in 3D graphics. Since the matrix operations of the 3D pipeline are completely independent of the 2D layer tree, any nested flip transformation of the parent layer will not affect the coordinate values ​​of this component in 3D space.

[0078] The second instruction locks the current node's solid structure in 3D space to prevent coordinate merging. In a normal rendering process, when a parent layer transforms, the underlying engine automatically multiplies the local coordinates of all child nodes by the parent's global transformation matrix to obtain the final screen coordinates. This mechanism of parent-child node coordinate linkage is the root cause of offset problems. The locking instruction sets an isolation flag in the graphics processor's transformation matrix stack. When the engine traverses to the viewfinder controller component, this flag prevents the engine from multiplying the parent layer's transformation matrix into the component's local coordinates. In other words, the component's coordinates become an absolutely independent quantity, no longer associated with the coordinate system of any parent layer. The locking operation is achieved by modifying the uniform variable binding relationship in the graphics processor shader; specifically, it forcibly replaces the register address originally bound to the parent model-view matrix with the address of an identity matrix.

[0079] The third instruction is used to deprive a node of its coordinate cache update mechanism in the two-dimensional hierarchy. In older kernels, each rendering node maintains a coordinate cache to store the final screen coordinates calculated by the parent transformation matrix. When the parent layer changes, the engine automatically triggers a refresh of the coordinate cache. The purpose of the deprivation instruction is to remove the viewfinder controller component from the coordinate cache refresh queue, preventing it from responding to any update events from the parent layer. The system achieves this by modifying the dirty mark propagation path of the rendering engine. Specifically, an empty callback function is inserted into the node's event response chain. This function returns directly without performing any coordinate recalculation. In this way, even if the parent layer undergoes multiple mirror flips or scaling transformations, the values ​​in the component's coordinate cache will not be automatically overwritten.

[0080] When the underlying rendering engine parses the combination of the three instructions mentioned above, it interrupts the original 2D coordinate compression and merging recalculation process designed for the parent-child node linkage of this component. The system then forcibly extracts the component from the nested stacking structure, making it a free-floating rendering unit. At this point, the component has successfully broken free from the control of the original 2D layer, preparing it for subsequent pushing to the graphics processor's independent video memory space. The entire instruction sending and parsing process is completed within a single frame rendering cycle, without introducing any additional latency.

[0081] Additionally, the step of performing low-level rendering isolation processing on the window tracing controller component includes:

[0082] Apply a drawing isolation constraint rule to the container node of the navigation thumbnail view area. The drawing isolation constraint rule is used to force the rendering context of the window tracking controller component to be separated from the rendering context of the parent container.

[0083] A floating rendering layer is created independently for the window tracking controller component, and the stacking order of the floating rendering layer is set to be higher than the stacking order of all other layers in the navigation thumbnail view area;

[0084] The coordinate system of the floating rendering layer is locked to be directly mapped to the screen coordinate system, and the floating rendering layer is prohibited from inheriting any nested transformation matrix inside the navigation thumbnail view area;

[0085] Based on the mirror flip control command, coordinate transformation is performed independently on the window tracking controller component in the floating rendering layer, and the transformed result is overlaid onto the corresponding position of the navigation thumbnail view area.

[0086] For performing low-level rendering isolation processing, this embodiment provides a second specific implementation method. This method is suitable for digital pathology system architectures based on web technologies, and achieves component separation through CSS container isolation and floating rendering layer technology. Unlike the first method, which relies on low-level GPU instructions, this method intervenes at the browser rendering engine level, utilizing the rendering isolation characteristics of Cascading Style Sheets to block the propagation of nested transformations.

[0087] First, a drawing isolation constraint rule is applied to the container node of the navigation thumbnail viewport. The navigation thumbnail viewport itself is a container node, containing the thumbnail canvas and the viewfinder controller widget overlaid on it. The system dynamically modifies the Cascading Style Sheets (CSS) properties of the container node, adding a "Container Isolation" style declaration with a value of "Independent." This declaration forces the browser to create an independent cascading context for the container and its internal content, isolating all rendering operations within the container from the external page. Simultaneously, the system also forces the container's rendering context to be separated from its parent context. This means that any element inside the container will not actively inherit or merge the transformation matrix of its parent layer when performing coordinate transformations. This operation is equivalent to severing the coordinate linkage between the navigation thumbnail viewport and its external parent elements at the rendering tree level.

[0088] Next, the system creates a separate floating rendering layer for the viewfinder tracking controller widget. A floating rendering layer is an independent rendering surface detached from the normal document flow, typically achieved by setting fixed or absolute positioning values ​​for the element and a stacking order value greater than other elements. The system sets the stacking order value of the newly created floating rendering layer to a value significantly higher than all other layers in the navigation thumbnail viewport, such as 9999, ensuring that this layer is always displayed on top and not obscured by other layers. The size and position of this floating rendering layer are exactly the same as the original viewfinder tracking controller widget, but its rendering context is completely new and does not contain any historical transformation state from the parent container.

[0089] After creating the floating rendering layer, its coordinate system is locked to be directly mapped to the screen coordinate system. By default, the coordinate system of a web page element is established relative to its nearest ancestor element with a positioning attribute. This relative positioning mechanism can lead to a cumulative effect from nested transformations. To completely eliminate this effect, a coordinate system locking style is set for the floating rendering layer. This style forces the element's coordinate reference system to change to the viewport coordinate system, that is, directly using the top-left corner of the screen as the origin. At the same time, the system explicitly prohibits the floating rendering layer from inheriting any nested transformation matrices within the navigation thumbnail viewport by setting the transformation style to "no transformation" and setting the transformation origin style to the initial value. This means that even if the navigation thumbnail viewport container itself is mirrored, its transformation matrix will not be passed to the floating rendering layer.

[0090] After completing the above isolation settings, coordinate transformation is performed independently on the viewport tracking controller component within the floating rendering layer based on the mirror flip control command. Since the coordinate system of the floating rendering layer is locked to the screen coordinate system, it is only necessary to calculate the target screen coordinates that the original component's position in screen space should move to after mirror flipping. This calculation is a purely two-dimensional geometric transformation and does not involve any multiplication of nested layer matrices. After calculating the target coordinates, the horizontal and vertical offset values ​​of the floating rendering layer are directly modified to move it to the new position.

[0091] Finally, the transformed floating rendering layer is overlaid onto the corresponding position in the navigation thumbnail viewport. Since the floating rendering layer has the highest stacking order, it naturally appears above all other layers in the navigation thumbnail viewport, and the user's visual effect is completely consistent with the original floating follower red frame. Throughout this process, the original viewfinder controller component remains in its original layer, but because of its lower stacking order and complete coverage by the floating rendering layer, the user is unaware of its existence. When the mirroring operation is complete or the default state needs to be restored, simply remove the floating rendering layer and restore the display of the original component. This alternative solution achieves the same technical effect of separating components from the original nested structure and independently correcting their coordinates without relying on underlying GPU instructions, providing a flexible option for digital pathology systems with different technology stacks.

[0092] Step S30: Push the stripped window tracking controller component to the graphics processor process and store the window tracking controller component in a pre-divided 3D tile video memory isolation storage space.

[0093] The stripped-off window tracking controller component is pushed to the graphics processor process and stored in a pre-allocated 3D tile video memory isolated storage space. The core technical concept of this step is to transfer the coordinate calculation and rendering tasks originally handled by the central processing unit to the graphics processor for execution, and to allocate a separate physically isolated video memory area for this component, so that it is completely free from the merging error impact of the main rendering framework.

[0094] First, a request needs to be sent to the graphics processor driver layer at the operating system level to allocate a contiguous block of 3D tile video memory address space. This video memory address space is physically isolated from the original video memory space of the high-definition main image viewport and the navigation thumbnail viewport, meaning that the graphics processor will not encounter data conflicts or address overlaps with other rendering tasks when accessing this address space. The system needs to specify the size, alignment, and access permissions of the video memory space during the request. Since the window tracking controller component is only a rectangular graphic element, its required video memory space is relatively small, typically between a few hundred kilobytes and a few megabytes. However, to ensure the accuracy of coordinate calculations, the system will still request a contiguous address block with sufficient redundancy.

[0095] After successful allocation of video memory address space, an independent coordinate base plate is established within this space for the window tracking controller component. This coordinate base plate is a virtual three-dimensional coordinate system, with its origin linked to the origin of the display coordinate system of the navigation thumbnail view area via a preset offset. This linkage is a mapping relationship; that is, the coordinate values ​​in the independent coordinate base plate can be converted to their corresponding positions in the display coordinate system of the navigation thumbnail view area after offset conversion. The advantage of this operation is that all coordinate operations of the window tracking controller component in the independent video memory space will not be affected by the original nested layer transformation matrix, while the offset can achieve final docking with the display interface.

[0096] After establishing the coordinate base, the absolute positioning attribute data, focus marker tracking feature data, and current visual state data of the window tracking controller component are written into the aforementioned 3D tile's isolated video memory space. The absolute positioning attribute data records the component's positioning method in the original coordinate system; the focus marker tracking feature data indicates whether the component is currently under user attention; and the current visual state data includes visual style parameters such as the component's border color, line width, and transparency. After writing, the system transfers control of this video memory space to the graphics processing unit (GPU). Subsequent coordinate calculations and rendering operations are performed independently by the GPU, no longer relying on the CPU's main thread. This process achieves a shift from CPU-intensive computation to GPU-zero CPU dependency, laying the hardware foundation for completely eliminating main thread blocking.

[0097] Step S40: In the isolated storage space of the three-dimensional tile display memory, the coordinate realignment and correction of the window tracking controller component is performed based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command.

[0098] Within the aforementioned isolated storage space of the 3D tile's video memory, the coordinate realignment and correction of the viewfinder tracking controller component are performed based on the spatial inverse matrix transformation rules corresponding to the mirror flip control command. This step is primarily a core algorithmic step to address the offset problem, thereby recalculating the correct spatial position of the component after flipping in an independent 3D coordinate system unaffected by the original rendering defects.

[0099] First, the flip axis identifier is extracted from the previously captured mirror flip control command. This flip axis identifier clearly indicates whether the current flip is horizontal or vertical. In digital pathology imaging systems, users may need to enable horizontal or vertical flip because the slide mounting orientation is inconsistent with the actual observation orientation, and in some complex cases, both flips may need to be enabled simultaneously. The flip axis identifier is recorded as an enumerated value; for example, a value of 0 corresponds to a horizontal axis identifier, a value of 1 corresponds to a vertical axis identifier, and a value of 2 corresponds to both flips.

[0100] After obtaining the flip axis identifier, a 3D spatial inverse transformation matrix is ​​constructed in the aforementioned 3D tile memory isolation storage space. This inverse transformation matrix differs from a conventional 2D flip matrix; it is a fourth-order 3D homogeneous transformation matrix that not only includes the mirror mapping of the flip axis but also compensation parameters for rendering defects in older kernels. The specific construction rules of the inverse transformation matrix are as follows: for horizontal flips, the horizontal coordinate mapping coefficients in the matrix are negative, while the vertical and depth coordinate mapping coefficients are positive; for vertical flips, the vertical coordinate mapping coefficient is negative; for simultaneous flips, both the horizontal and vertical coordinate mapping coefficients are negative. Furthermore, the matrix also includes a translation component to correct the origin drift caused by absolutely positioned elements in nested transformations.

[0101] After constructing the 3D inverse transformation matrix, the spatial position coordinates of the window tracking controller component at the current moment are read. These coordinates were acquired and saved from its original coordinate system before the stripping operation. A matrix multiplication operation is performed between these current spatial position coordinates and the aforementioned 3D inverse transformation matrix to obtain a new four-dimensional vector, which is then converted into corrected spatial position coordinates in 3D space using homogeneous division. This multiplication operation is entirely performed within the graphics processing unit (GPU), utilizing its superior parallel floating-point computing capabilities, resulting in extremely fast processing speeds without placing any burden on the main thread.

[0102] After obtaining the corrected spatial coordinates, these coordinates are updated in the positioning data of the window tracking controller component within the aforementioned independent coordinate base plate. The update of the positioning data is not a simple overwrite, but rather ensures consistency through atomic operations, avoiding tearing or flickering during the update process. At this point, the component has completed coordinate realignment and correction in its independent 3D video memory space, and its current position accurately reflects the thumbnail area that should correspond to after the high-definition main image viewport is flipped. The entire correction process does not involve any inverse calculations or interception logic on the central processing unit (CPU) side; it relies entirely on the matrix operation capabilities of the graphics processing unit's underlying hardware, thus achieving precise correction with zero CPU dependency.

[0103] Step S50: Project the corrected window tracking controller component onto the navigation thumbnail view area to complete the spatial position synchronization with the flipped high-definition main image view area.

[0104] The calibrated window tracking controller component is projected onto the navigation thumbnail view area to synchronize its spatial position with the flipped high-definition main image view area. This step is the process of ultimately presenting the calibration results in the independent video memory space to the user interface, while establishing a continuous dynamic tracking mechanism after flipping.

[0105] First, the corrected spatial coordinates of the window tracking controller component are read from the isolated storage space of the aforementioned 3D tile video memory. These coordinates are obtained through a 3D spatial inverse transformation matrix operation, with the reference frame being an independent coordinate base plate. Since there is a preset offset between the origin of the independent coordinate base plate and the origin of the display coordinate system of the navigation thumbnail view area, the corrected spatial coordinates need to be inverted to the display coordinate system of the navigation thumbnail view area using the preset offset. The inversion process includes projecting the 3D coordinates in the independent coordinate base plate onto a 2D plane and adding offset compensation, ultimately obtaining a projected coordinate in pixels.

[0106] After obtaining the projection coordinates, the viewfinder tracking controller component is redrawn in a floating overlay manner at the corresponding position in the navigation thumbnail view area, using these coordinates as anchor points. The drawing operation is also performed by the graphics processor process, directly reading the component's visual style data, including border color, line width, and transparency, from the isolated storage space of the 3D tile video memory, and then rendering a rectangle at the projection coordinates. Because the rendering context of this rectangle is completely isolated from other layers in the navigation thumbnail view area, it is not affected by transformations of other layers. After drawing, the user can see in the navigation thumbnail view area that the red tracking box has accurately moved to the area it should correspond to after flipping, perfectly matching the pathological tissue image displayed in the high-definition main image view area.

[0107] To ensure the navigation red frame continues to follow correctly when the user continues scrolling or zooming after a flip operation, a continuous dynamic following mechanism is established. An event responder responds in real-time to scrolling or zooming operations in the high-definition main image viewport. Whenever a scrolling or zooming event is received, the change in the current viewport's position within the global slice is obtained, and then the spatial coordinates of the viewfinder controller component are synchronously updated in the aforementioned 3D tile memory isolation storage space. After the update is complete, the projection and rendering steps are repeated, redrawing the updated component onto its new position in the navigation thumbnail viewport. This closed-loop logic allows the navigation red frame to continuously follow changes in the user's field of view, preventing lag or offset even during frequent zooming and dragging operations after a flip.

[0108] Throughout the projection and tracking process, the central processing unit (CPU) is only responsible for responding to user operation events and triggering coordinate update requests. All coordinate calculations and rendering are completed by the graphics processor (GPU) in its dedicated video memory space, completely avoiding the main thread blocking and screen tearing issues caused by high-frequency script interception in traditional solutions. Users will not experience any visual gaps or delays during use, and the system achieves the same smooth tracking experience as in the non-flipped state.

[0109] Furthermore, you can also view Figure 2 , Figure 2 This is a detailed process diagram based on step S20 in the first embodiment. Figure 2 The step of stripping the window tracking controller component from the nested stacking structure of the original two-dimensional layers includes S21-23:

[0110] Step S21: Interrupt the underlying rendering engine's two-dimensional coordinate compression process and two-dimensional coordinate merging and recalculation process between the viewport tracking controller component and its parent layer;

[0111] Step S22: Release the parent-child cascade binding relationship of the window tracking controller component in the nested stacking structure of the original two-dimensional layer, so that the window tracking controller component becomes an independent free node;

[0112] Step S23: Extract the free node and its carried absolute positioning attribute data and focus identifier tracking feature data to form the stripped window tracking controller component.

[0113] In the aforementioned underlying rendering isolation process, a key step is to separate the viewport tracing controller component from the nested stacking structure of the original 2D layers. This process ensures that the component is completely freed from the control of the original layers by interrupting the coordinate calculation process of the underlying rendering engine, releasing the parent-child node binding relationship, and extracting node data.

[0114] Specifically, this interrupts the underlying rendering engine's 2D coordinate compression and 2D coordinate merging / recalculation processes between the viewfinder controller component and its parent layer. In older browser kernels, the underlying rendering engine maintains a layer tree, where each layer node contains its own local coordinates and a cumulative transformation matrix from the root node to the current node. When a parent layer is mirrored, the engine initiates a coordinate compression process, multiplying the parent's transformation matrix with the child node's local coordinates to generate the child node's final coordinates in screen space. Subsequently, the engine executes a coordinate merging / recalculation process, writing all transformed node coordinates to the corresponding positions in the framebuffer. These two processes are the root cause of the offset in the absolutely positioned component. This step forces the engine to skip these two processes when traversing the viewfinder controller component by inserting a high-priority termination command into the rendering engine's message queue. In practice, the system sets a breakpoint flag in the rendering engine's rendering pipeline. When the engine detects that the currently processed node is the viewfinder controller component, it no longer calls the default coordinate compression and merging / recalculation functions, but instead directly returns a null operation. In this way, the flip transformation matrix of the parent layer will not be multiplied into the local coordinates of the component, and the original coordinates of the component can be fully preserved.

[0115] The parent-child cascading binding of the viewfinder controller component within the nested stacking structure of the original 2D layers is removed, making the component an independent, detached node. In a typical layer tree structure, each child node holds a reference to its parent node, while the parent node maintains a list of child nodes. This two-way binding ensures unidirectional propagation of transform events. To completely isolate the component, the system needs to remove the reference relationship between the node and its parent node from the layer tree. The system first obtains the layer node object corresponding to the viewfinder controller component, then sets the parent node reference field stored in that node object to null. Simultaneously, the system traverses the list of child nodes of the original parent node, finds the list item pointing to the component, and deletes it. After these two steps, the component no longer has any parent association in the layer tree, becoming an isolated, detached node. It is important to note that this removal operation is merely a logical reference clearing; it does not release the node from memory or affect its visual presentation on the screen, as subsequent steps will move the node to a separate rendering path for processing.

[0116] The aforementioned detached nodes and their carried absolute positioning attribute data and focus marker tracking feature data are extracted to form the stripped-off window tracking controller component. Even after becoming a detached node, this component still retains various attribute data required for rendering. The system needs to extract this data for subsequent coordinate realignment and re-rendering in independent 3D video memory space. The absolute positioning attribute data includes the component's horizontal and vertical offset values ​​in the original coordinate system, the positioning reference system type, and positioning anchor point information. This data is the basic input for subsequent coordinate correction, determining which area the component should appear in after flipping. The focus marker tracking feature data includes whether the component is selected or focused by the user, the tracking number, and its historical position trajectory. This data is used to maintain the consistency of the component's interactive state during continuous tracking; for example, when the user is tracking a lesion area, the tracking marker for that area should not be lost after flipping. By calling the node object's attribute reading interface, this data is copied to a temporary data structure, and then the memory occupied by the original detached node is released. After extraction, the system obtains a clean data package that does not depend on any layer tree structure. This data package is the stripped window tracking controller component, which can be directly pushed to the graphics processor process for further processing.

[0117] Through coordinated execution, the viewfinder tracking controller component was successfully extracted from the nested stacking structure of the original 2D layers. This component is no longer affected by the coordinate contamination from the parent layer's flip transformations; its original absolute positioning data is fully preserved and encapsulated into independent data units, laying a clean data foundation for subsequent storage in independent 3D video memory and spatial inverse matrix coordinate realignment. The entire extraction process is completed entirely within the control flow of the underlying rendering engine, without relying on any high-level script interception or coordinate inversion, thus introducing no additional performance overhead.

[0118] Furthermore, you can also view Figure 3 , Figure 3 This is a detailed process diagram based on step S30 in the first embodiment. Figure 3 The step of storing the window tracking controller component into a pre-divided 3D tile display memory isolated storage space includes S31~33:

[0119] Step S31: Request a contiguous 3D tile video memory address space from the underlying graphics processor driver layer of the operating system. The video memory address space is physically isolated from the original video memory space of the high-definition main image view area and the navigation thumbnail view area.

[0120] Step S32: Establish an independent coordinate base plate for the window tracking controller component in the video memory address space. The origin of the coordinate base plate is associated with the origin of the display coordinate system of the navigation thumbnail view area through a preset offset.

[0121] Step S33: Write the absolute positioning attribute data, focus marker tracking feature data, and current visual state data of the window tracking controller component into the 3D tile display memory isolated storage space.

[0122] In this embodiment, during the process of storing the stripped window tracking controller component into the pre-divided 3D tile video memory isolation storage space, the application of video memory space, the establishment of coordinate base plate and the writing of attribute data are realized through three sub-steps, ensuring that the component obtains a completely independent and undisturbed hardware rendering environment.

[0123] Specifically, the system requests a contiguous 3D tile-based video memory address space from the underlying graphics processing unit (GPU) driver layer of the operating system. This address space is physically isolated from the original video memory spaces of the high-definition main image viewport and the navigation thumbnail viewport. In digital pathology imaging systems, the high-definition main image viewport and the navigation thumbnail viewport each occupy specific video memory regions within the GPU, which are typically managed automatically by the browser kernel or graphics framework. To ensure that the window tracking controller component is not interfered with by other rendering tasks in these regions, the system needs to actively initiate a video memory allocation request to the GPU driver layer. This request is implemented by calling the video memory allocation function in the graphics application programming interface (API), which, for example, can be accomplished through an extended or custom GPU buffer object interface in web-based systems. The system explicitly specifies in the request that the requested video memory space is of the 3D tile type, meaning that this space supports 3D texture mapping and depth buffering, rather than a regular 2D image buffer. The requirement for a contiguous address space is to ensure data access efficiency during matrix operations and avoid memory page switching overhead caused by non-contiguous addresses. The system also sets an isolation flag in the allocation request, requiring the driver layer to place the newly allocated video memory area on different physical memory pages or memory channels from the video memory areas of existing rendering tasks, thereby achieving true physical isolation. After successful allocation, the system obtains a handle pointing to that video memory space, and all subsequent read and write operations on that space are performed through this handle.

[0124] An independent coordinate baseboard is established for the window tracking controller component within the aforementioned video memory address space. The coordinate baseboard is a virtual three-dimensional reference system that defines the component's origin, axial direction, and scaling factor in three-dimensional space. Since subsequent coordinate correction needs to be performed in a space unaffected by the original nested transformation, a controllable association is established between the coordinate baseboard and the display coordinate system of the navigation thumbnail view area. The system writes a coordinate baseboard header information structure at the beginning of the video memory address space. This structure contains three fields: origin offset, axial unit vector, and scaling factor. The origin offset is a two-dimensional vector that records the horizontal and vertical offset values ​​of the coordinate baseboard origin relative to the origin of the navigation thumbnail view area's display coordinate system. The axial unit vector defines the horizontal and vertical axes of the coordinate baseboard, which by default align with the axes of the display coordinate system. The scaling factor is used to handle the resolution difference between the high-definition main image view area and the navigation thumbnail view area, as the pixel size of the main image view area is typically much larger than that of the thumbnail view area. By associating with preset offsets, the system can perform arbitrary coordinate calculations on an independent coordinate base plate, and finally obtain the actual position in the display coordinate system through offset conversion, without requiring the component to re-inherit any transformation matrix of the original layer.

[0125] The absolute positioning attribute data, focus marker tracking feature data, and current visual state data of the viewport tracking controller component are written to the aforementioned 3D tile's isolated video memory storage space. After the stripping operation, the component has become a free node, and its attribute data has been extracted into a temporary data structure. The system now needs to persist this data to an independent video memory space so that the graphics processor process can directly access it. The absolute positioning attribute data includes the component's horizontal offset value, vertical offset value, positioning anchor point type, and margin value in the original coordinate system. This data is written to the attribute data area in the video memory space and formatted into a fixed-length data structure for fast parsing by the graphics processor shader program. The focus marker tracking feature data includes the component's unique identifier, whether it is currently in an active tracking state, the point set of the tracking history trajectory, and the tracking timestamp. This data is written to the tracking data area in the video memory space to maintain the component's interactive state during continuous tracking. The current visual state data includes visual style parameters such as border color value, border line width, fill transparency, corner radius, and whether to display shadows. This data is written to the style data area in the video memory space for use during rendering. After the write operation is complete, the system completely transfers control of the video memory space to the graphics processing unit (GPU) process. The central processing unit (CPU) no longer participates in the coordinate calculation and rendering of this component. At this point, the window tracking controller component has been successfully migrated to a physically isolated, logically isolated 3D tile video memory storage space, preparing the hardware for subsequent coordinate realignment and correction.

[0126] Furthermore, you can also view Figure 4 , Figure 4 This is a detailed process diagram based on step S40 in the first embodiment. Figure 4 The step of realigning and correcting the coordinates of the window tracking controller component based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command includes S41~44:

[0127] Step S41: Obtain the flip axis identifier carried in the mirror flip control command, wherein the flip axis identifier includes a horizontal axis identifier or a vertical axis identifier.

[0128] Step S42: In the isolated storage space of the three-dimensional tile display memory, a three-dimensional spatial inverse transformation matrix is ​​constructed according to the flip axis mark. The three-dimensional spatial inverse transformation matrix is ​​used to map the spatial position coordinates of the window tracking controller component in the original coordinate system to the corrected coordinates in the flipped coordinate system.

[0129] Step S43: Multiply the current spatial position coordinates of the window tracking controller component with the three-dimensional spatial inverse transformation matrix to generate the corrected spatial position coordinates;

[0130] Step S44: Based on the corrected spatial coordinates, update the positioning data of the window tracking controller component in the coordinate base plate.

[0131] During the process of coordinate realignment and correction of the window tracking controller component in the aforementioned 3D tile memory isolation storage space, four sub-steps are used to obtain the flip axis mark, construct the 3D space inverse transformation matrix, perform matrix multiplication, and update the positioning data, ensuring that the component obtains accurate correction coordinates after flipping.

[0132] The process involves retrieving the flip axis identifier carried in the mirror flip control command. This flip axis identifier can be either a horizontal axis identifier or a vertical axis identifier. When a user issues a mirror flip control command via an external device, the command is typically transmitted as an event object, which contains a flip type parameter. The system parses the value of this parameter from the event object; this value can be an integer enumeration or a string identifier. For example, the horizontal axis identifier can correspond to the value 0 or the string "horizontal," the vertical axis identifier to the value 1 or the string "vertical," and simultaneous horizontal and vertical flips correspond to the value 2 or the string "bidirectional." The flip axis identifier directly determines the subsequent construction method of the inverse transformation matrix, as the mapping rules for horizontal and vertical flips are different. The system temporarily stores the obtained flip axis identifier in a constant buffer accessible to the graphics processor for use in the shader program.

[0133] In the aforementioned 3D tile memory-isolated storage space, a 3D spatial inverse transformation matrix is ​​constructed based on the flip axis identifier. This inverse transformation matrix is ​​a 4x4 homogeneous transformation matrix, whose element values ​​are determined by the flip axis identifier and preset correction parameters. The construction process is executed in the graphics processor's compute shader, or pre-calculated by the central processing unit and then uploaded to video memory. For horizontal flips only, the coefficients corresponding to the x-coordinates on the diagonal of the matrix are negative, while the coefficients corresponding to the y-coordinates and depth coordinates are positive, and the translation component remains unchanged. For vertical flips only, the coefficient corresponding to the y-coordinate is negative, and the others are positive. For simultaneous flips, the coefficients corresponding to both the x-coordinate and y-coordinate are negative. In addition to the basic mirror mapping coefficients, the matrix also contains an additional correction translation component, which is used to compensate for the origin drift caused by nested transformations of absolutely positioned elements in older kernels. The value of the correction translation component is obtained by pre-calibrating the rendering behavior of a specific device and stored in the system's device adaptation configuration table. The constructed inverse transformation matrix is ​​written to the matrix buffer in the video memory space for use in the next step of the calculation.

[0134] The current spatial coordinates of the window tracking controller component are multiplied with the aforementioned 3D inverse transformation matrix to generate the corrected spatial coordinates. The current spatial coordinates are acquired from the component's original layer when it is stripped, and are represented in homogeneous coordinates, i.e., x-coordinate, y-coordinate, depth coordinate, and homogeneous components. These coordinates have been pre-written into the coordinate buffer in the video memory. The graphics processor executes a single instruction multiple data thread, reading the current coordinate vector from the coordinate buffer and the inverse transformation matrix from the matrix buffer, and then performing a multiplication operation between the four-dimensional vector and the fourth-order matrix. The rule for the multiplication operation is that each component of the corrected coordinates is equal to the dot product of the current coordinate vector and the corresponding column of the matrix. After the operation, a four-dimensional homogeneous coordinate vector is obtained. The homogeneous components are then normalized using homogeneous division to obtain the corrected coordinates in 3D space, i.e., the new x-coordinate, y-coordinate, and depth coordinates. The entire multiplication operation is performed by the graphics processor's floating-point unit, typically completed within a single clock cycle, without the need for central processing unit (CPU) involvement.

[0135] Based on the corrected spatial coordinates, the positioning data of the window tracking controller component in the independent coordinate base plate is updated. The positioning data is stored in the coordinate base plate area of ​​the video memory space, containing the component's position information in the current 3D space. The generated corrected coordinates are written to the current position field in the coordinate base plate, replacing the original old coordinate values. The write operation is completed through atomic swap instructions, ensuring that no data inconsistencies occur during the update process. After the update, the component's positioning data reflects the correct spatial position after mirror flip correction. Since the origin of the coordinate base plate is associated with the origin of the display coordinate system of the navigation thumbnail view area through a preset offset, the corrected coordinates, after subsequent offset conversion, can accurately correspond to the screen position that should appear in the navigation thumbnail view area after flipping. The entire coordinate realignment and correction process does not involve any modification to the original layer tree, nor does it rely on the main thread calculation of the central processing unit; it is completed autonomously entirely in the independent video memory space of the graphics processor, thus achieving precise correction with zero central processing unit dependence.

[0136] You can also view Figure 5 , Figure 5 This is a detailed process diagram based on step S50 in the first embodiment. Figure 5 The step of projecting the corrected window tracking controller component onto the navigation thumbnail view area to complete the spatial position synchronization and following with the flipped high-definition main image view area includes S51~54:

[0137] Step S51: Obtain the corrected spatial position coordinates of the window tracking controller component in the three-dimensional tile video memory isolation storage space;

[0138] Step S52: The corrected spatial position coordinates are back-calculated into the display coordinate system of the navigation thumbnail view area using a preset offset between the coordinate base plate and the display coordinate system of the navigation thumbnail view area to obtain the projected coordinates;

[0139] Step S53: Using the projection coordinates as anchor points, redraw the window tracking controller component in a floating overlay manner at the corresponding position in the navigation thumbnail view area;

[0140] Step S54: In real time response to the scrolling or zooming operation of the high-definition main image view area, the spatial position coordinates of the window tracking controller component are synchronously updated in the isolated storage space of the three-dimensional tile display memory, and the projection step is repeated so that the window tracking controller component continuously follows the field of view changes of the high-definition main image view area.

[0141] In this embodiment, during the process of projecting the corrected window tracking controller component onto the navigation thumbnail view area to complete synchronous following, the corrected coordinates are obtained, the projected coordinates are calculated in reverse, the floating overlay is redrawn, and continuous dynamic following is implemented to ensure that the component can be correctly displayed after flipping and updated in real time with user operation.

[0142] The system acquires the corrected spatial coordinates of the viewfinder tracking controller component within the isolated 3D tile memory. After updating, the component's current spatial coordinates are stored in the current position field of the coordinate base plate region in the video memory. The system needs to read these coordinate values ​​from the graphics processor process for subsequent coordinate transformations. The read operation is implemented through a readback buffer from the graphics processor to the central processing unit. Since the amount of coordinate data is extremely small, the latency of the readback operation is negligible. The corrected spatial coordinates acquired by the system are a 3D vector containing the x-coordinate, y-coordinate, and depth coordinates within the isolated coordinate base plate. While the depth coordinates are typically fixed in the current application scenario because the navigation thumbnail view area is a 2D plane, retaining the depth coordinates helps to address potential future needs for browsing 3D pathological images.

[0143] The corrected spatial coordinates are then used to calculate the projected coordinates in the navigation thumbnail viewport's display coordinate system using a preset offset between the independent coordinate base and the navigation thumbnail viewport's display coordinate system. A preset offset exists between the origin of the independent coordinate base and the origin of the navigation thumbnail viewport's display coordinate system. The calculation process includes two sub-operations. First, the coordinate base header information structure is read from the video memory to obtain the horizontal and vertical components of the origin offset. Then, the horizontal component of the origin offset is added to the horizontal coordinate value of the corrected spatial coordinates, and the vertical component of the origin offset is added to the vertical coordinate value to obtain the pixel coordinates in the display coordinate system. It's important to note that since the coordinate units in the independent coordinate base and the pixel units in the display coordinate system may have a scaling relationship, a scaling factor is also needed during the calculation. This scaling factor is also stored in the coordinate base header information structure. After the above calculations, the system obtains a projected coordinate in pixels, which precisely indicates the position where the window tracking controller component should be displayed in the navigation thumbnail viewport.

[0144] Using the aforementioned projection coordinates as anchor points, the viewfinder tracking controller component is redrawn in a floating overlay manner at its corresponding position within the navigation thumbnail viewport. The drawing operation is performed independently by the graphics processing unit (GPU) process, without CPU intervention. The system first reads the component's visual state data from the style data area in video memory, including parameters such as border color, line width, transparency, and corner radius. Then, the GPU's fragment shader renders a rectangle at the projection coordinates based on these parameters. The size of the rectangle is determined by the proportion of the high-definition main image viewport within the navigation thumbnail viewport; this proportion information is also pre-stored in video memory. Because the component's rendering context is completely independent of other layers in the navigation thumbnail viewport, and its stacking order is set to highest, the drawn rectangle floats over the thumbnail canvas, unaffected by changes in other layers. The user visually sees a red navigation box that precisely follows the current main viewport position.

[0145] In real-time response to scrolling or zooming operations in the high-definition main image viewport, the spatial coordinates of the window tracking controller component are synchronously updated in the aforementioned 3D tile video memory isolated storage space, and the projection steps described above are repeated to ensure that the component continuously follows the field of view changes in the high-definition main image viewport. After the mirror flip is completed, the user usually continues to perform viewing operations, including dragging the main image viewport to browse different areas, scrolling the mouse wheel to zoom, etc. To ensure that the navigation red box always follows correctly in these operations, the system registers scroll event responders and zoom event responders in the main thread. When a scroll event is received, the system calculates the change in the offset of the main image viewport's field of view in the tile global coordinate system, converts this change into the corresponding pixel offset in the navigation thumbnail viewport, and then updates the current spatial coordinates of the component in the video memory space through the graphics processor application programming interface. When a zoom event is received, the system calculates the impact of the zoom level change on the field of view and updates the rectangular frame size parameters in the video memory space accordingly. After each update, the process of acquiring the calibration coordinates, recalculating the projected coordinates, redrawing the floating overlay, and continuously dynamically following is automatically repeated, reprojecting the updated components back into the navigation thumbnail viewport. This closed-loop logic allows the navigation red box to follow every user action with extremely low latency, without any stuttering or lag even during high-speed continuous scrolling or zooming. Throughout the following process, the central processing unit (CPU) is only responsible for event response and simple calculations of coordinate increments; all redrawing operations are completed by the graphics processor in its dedicated video memory space, completely avoiding the main thread blocking and screen tearing problems caused by high-frequency script interception in traditional solutions.

[0146] Furthermore, you can also view Figure 6 , Figure 6This is a flowchart illustrating a second embodiment of the navigation view area synchronization correction method for mirror flipping according to this application. In this embodiment, after the step of identifying the window tracking controller component within the navigation thumbnail view area in response to the mirror flipping control command, steps S60-80 are further included:

[0147] Step S60: Detect the underlying rendering engine kernel version of the current digital pathology imaging system. When it is determined that the underlying rendering engine kernel belongs to a preset restricted kernel library, enable the vulnerability adaptation switch.

[0148] Step S70: Based on the open state of the vulnerability adaptation switch, in response to the mirror flip control command issued to the high-definition main image view area and the associated navigation thumbnail view area, detect whether the navigation thumbnail view area contains a window tracking controller component with absolute positioning attributes.

[0149] Step S80: If it is determined that the vulnerability adaptation switch has been turned on, the mirror flip control command has been issued, and the window tracking controller component exists, then perform the step of performing low-level rendering isolation processing operation on the window tracking controller component.

[0150] After responding to the mirror flip control command and identifying the window tracking controller component within the navigation thumbnail viewport, an environment detection and condition triggering mechanism is further introduced to ensure that the above-mentioned underlying rendering isolation processing operations are only executed in defective environments where they are truly needed, avoiding unnecessary interference with the normal environment.

[0151] The system detects the underlying rendering engine kernel version of the current digital pathology imaging system. When the kernel is determined to belong to a pre-defined restricted kernel library, a vulnerability adaptation switch is activated. Different medical devices have significantly different underlying rendering engine kernel versions. Some older devices use browser kernels that haven't been updated in a long time, such as the QtWebEngine kernel based on Chromium 83. These kernels have inherent defects in the 2D coordinate merging algorithm for deeply nested layers, which is the core problem this application aims to solve. During initialization or before receiving the mirror flip control command for the first time, the system obtains the kernel version string of the current rendering engine by calling the underlying platform interface. This string typically contains information such as the kernel name, major version number, minor version number, and build number. The system compares the obtained version information with the restricted kernel library pre-stored in a configuration file. The restricted kernel library is a list of kernel versions known to have nested transformation coordinate offset defects, such as Chromium 83 and earlier versions, and certain customized embedded browser kernels. If the current kernel version matches any item in the list, the system determines that the device belongs to a restricted environment and immediately activates a global vulnerability adaptation switch. This switch is a Boolean flag stored in the system's runtime configuration object, and all subsequent conditional judgments are based on this flag.

[0152] Based on the enabled / disabled state of the vulnerability adaptation switch, the system responds to mirror flip control commands issued to the high-definition main image viewport and the associated navigation thumbnail viewport, and detects whether the navigation thumbnail viewport contains a window tracking controller component with absolute positioning attributes. When the vulnerability adaptation switch is disabled, the system employs a standard mirror flip processing procedure, directly executing front-end 2D spatial transformation commands without enabling any underlying intervention mechanisms. Once the vulnerability adaptation switch is enabled, the system enters an enhanced response mode. In this mode, the system not only captures regular user interaction events but also performs in-depth analysis of the event's target object and parameters. When responding to a mirror flip control command, the system first verifies whether the command's target scope simultaneously includes both the high-definition main image viewport and the associated navigation thumbnail viewport. Only when both areas are flipped simultaneously will the navigation red box offset issue occur. If the command targets only a single viewport, subsequent isolation processing is not triggered. Simultaneously, the system traverses the child nodes of the navigation thumbnail viewport using a Document Object Model (DOM) query method, searching for an element node with an absolute positioning attribute that carries a specific class name or custom attribute marker indicating it is a viewfinder component. The checks include verifying whether the node's positioning style attribute value is absolute or fixed positioning, and whether it has an identifier to indicate following the red box. Only when both conditions are met does the system confirm that the current operation poses a risk of offset.

[0153] If it is determined that the vulnerability adaptation switch is enabled, the mirror flip control command has been issued, and the window tracking controller component exists, the step of performing low-level rendering isolation processing on the window tracking controller component is executed. These three conditions are indispensable and constitute a logical AND gate. The vulnerability adaptation switch ensures that the current device environment does indeed have a defect; the issuance of the mirror flip control command ensures that the user has indeed performed the flip operation; and the existence of the window tracking controller component ensures that the target correction object is ready. When all three conditions are met, the system calls the entry function of the low-level rendering isolation processing operation, guiding the control flow to step S20 and its subsequent sub-steps. If any condition is not met, for example, if the vulnerability adaptation switch is not enabled, or the user issues a zoom command instead of a flip command, or there is no absolutely positioned follow red box in the navigation thumbnail viewport, the system skips the low-level rendering isolation processing operation and uses conventional 2D space transformation commands to complete the mirror flip. This condition-triggered design avoids performing complex low-level interventions unnecessarily, reduces the waste of computing resources, and ensures compatibility under normal devices or normal operating scenarios. The entire detection and judgment process is completed in milliseconds, and users will not perceive any additional delay.

[0154] This embodiment achieves accurate identification of defective environments and on-demand activation of correction mechanisms, enabling the above correction methods to adaptively run on medical devices with different kernel versions, ensuring stability on older devices without affecting the native performance on newer devices.

[0155] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the navigation view synchronization correction method of mirror flipping in this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0156] This application provides a navigation view area synchronization correction device with mirror flipping. The navigation view area synchronization correction device with mirror flipping includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the navigation view area synchronization correction method with mirror flipping in the first embodiment described above.

[0157] The following is for reference. Figure 7This document illustrates a schematic diagram of a navigation view area synchronization correction device suitable for implementing the mirror flipping method in the embodiments of this application. The mirror flipping navigation view area synchronization correction device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The mirror-flipped navigation view synchronization correction device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

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

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

[0160] The mirror-flipped navigation view area synchronous correction device provided in this application, employing the mirror-flipped navigation view area synchronous correction method described in the above embodiments, can solve the technical problem of performance loss caused by high-frequency interception during navigation view area synchronous correction in existing digital pathology image mirror flipping. Compared with the prior art, the beneficial effects of the mirror-flipped navigation view area synchronous correction device provided in this application are the same as those of the mirror-flipped navigation view area synchronous correction method provided in the above embodiments, and other technical features in this mirror-flipped navigation view area synchronous correction device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0163] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the navigation view area synchronization correction method for mirror flipping in the above embodiments.

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

[0165] The aforementioned computer-readable storage medium may be included in a mirror-flipped navigation view area synchronization correction device; or it may exist independently and not be assembled into a mirror-flipped navigation view area synchronization correction device.

[0166] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the mirror-flipped navigation view area synchronization correction device, the mirror-flipped navigation view area synchronization correction device implements the technical content of the mirror-flipped navigation view area synchronization correction method embodiment shown above.

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

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

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

[0170] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described navigation view area synchronization correction method for mirror flipping. This solves the technical problem of performance degradation caused by high-frequency interception during navigation view area synchronization correction in existing digital pathology image mirror flipping. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the navigation view area synchronization correction method for mirror flipping provided in the above embodiments, and will not be repeated here.

Claims

1. A method for mirror flipping navigation viewport synchronization rectification, characterized in that, The navigation view area synchronization correction method for mirror flipping includes the following steps: In response to the mirror flip control command, a window tracking controller component within the navigation thumbnail view area is identified. The window tracking controller component includes an absolute positioning attribute. The mirror flip control command is issued to the high-definition main image view area and the associated navigation thumbnail view area. After performing low-level rendering isolation processing on the viewfinder controller component, the viewfinder controller component is stripped from the nested stacking structure of the original two-dimensional layers; The stripped window tracking controller component is pushed to the graphics processor process, and the window tracking controller component is stored in a pre-divided 3D tile video memory isolation storage space; In the isolated storage space of the three-dimensional tile display memory, the coordinate realignment and correction of the window tracking controller component are performed based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command; The corrected window tracking controller component is projected into the navigation thumbnail view area to achieve spatial synchronization with the flipped high-definition main image view area.

2. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, After the step of identifying the window tracking controller component within the navigation thumbnail view area in response to the mirror flip control command, the method further includes: The underlying rendering engine kernel version of the current digital pathology imaging system is detected. When it is determined that the underlying rendering engine kernel belongs to a preset restricted kernel library, the vulnerability adaptation switch is enabled. Based on the enabled state of the vulnerability adaptation switch, in response to the mirror flip control command issued to the high-definition main image view area and the associated navigation thumbnail view area, it detects whether the navigation thumbnail view area contains a window tracking controller component with absolute positioning attributes. If it is determined that the vulnerability adaptation switch has been turned on, the mirror flip control command has been issued, and the window tracking controller component exists, then the step of performing low-level rendering isolation processing on the window tracking controller component is executed.

3. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, The steps of performing low-level rendering isolation processing on the window tracing controller component include: By sending a forced dimensionality reduction isolation instruction set to the window tracking controller component, the underlying rendering isolation processing is performed. The forced dimensionality reduction isolation instruction set includes at least the following: instructions for forcibly enabling the graphics processor's underlying 3D rendering pipeline, instructions for locking the current node's entity structure in 3D space to prevent coordinate merging, and instructions for depriving the node of its coordinate cache update mechanism in the 2D hierarchy.

4. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, The step of performing low-level rendering isolation processing on the window tracing controller component includes: Apply a drawing isolation constraint rule to the container node of the navigation thumbnail view area. The drawing isolation constraint rule is used to force the rendering context of the window tracking controller component to be separated from the rendering context of the parent container. A floating rendering layer is created independently for the window tracking controller component, and the stacking order of the floating rendering layer is set to be higher than the stacking order of all other layers in the navigation thumbnail view area; The coordinate system of the floating rendering layer is locked to be directly mapped to the screen coordinate system, and the floating rendering layer is prohibited from inheriting any nested transformation matrix inside the navigation thumbnail view area; Based on the mirror flip control command, coordinate transformation is performed independently on the window tracking controller component in the floating rendering layer, and the transformed result is overlaid onto the corresponding position of the navigation thumbnail view area.

5. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, The step of stripping the window tracking controller component from the nested stacking structure of the original two-dimensional layers includes: The underlying rendering engine interrupts the two-dimensional coordinate compression and two-dimensional coordinate merging and recalculation process between the viewport tracking controller component and its parent layer. Release the parent-child cascade binding relationship of the window tracking controller component in the nested stacking structure of the original two-dimensional layer, so that the window tracking controller component becomes an independent free node; The free nodes and their carried absolute positioning attribute data and focus identifier tracking feature data are extracted to form the stripped window tracking controller component.

6. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, The step of storing the window tracking controller component into a pre-allocated 3D tile memory isolation storage space includes: A contiguous 3D tile video memory address space is requested from the underlying graphics processor driver layer of the operating system. The video memory address space is physically isolated from the original video memory space of the high-definition main image view area and the navigation thumbnail view area. An independent coordinate base plate is established for the window tracking controller component in the video memory address space, and the origin of the coordinate base plate is associated with the origin of the display coordinate system of the navigation thumbnail view area through a preset offset. The absolute positioning attribute data, focus marker tracking feature data, and current visual state data of the window tracking controller component are written into the isolated storage space of the 3D tile display memory.

7. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, The step of realigning and correcting the coordinates of the window tracking controller component based on the spatial inverse matrix transformation rule corresponding to the mirror flip control command includes: Obtain the flip axis identifier carried in the mirror flip control command, wherein the flip axis identifier includes a horizontal axis identifier or a vertical axis identifier; In the isolated storage space of the three-dimensional tile display memory, a three-dimensional spatial inverse transformation matrix is ​​constructed according to the flip axis mark. The three-dimensional spatial inverse transformation matrix is ​​used to map the spatial position coordinates of the window tracking controller component in the original coordinate system to the corrected coordinates in the flipped coordinate system. The current spatial position coordinates of the window tracking controller component are multiplied with the three-dimensional spatial inverse transformation matrix to generate the corrected spatial position coordinates. Based on the corrected spatial coordinates, the positioning data of the window tracking controller component in the coordinate base plate is updated.

8. The navigation view area synchronization correction method for mirror flipping as described in claim 1, characterized in that, The step of projecting the corrected window tracking controller component onto the navigation thumbnail view area to complete the spatial position synchronization and following with the flipped high-definition main image view area includes: Obtain the corrected spatial position coordinates of the window tracking controller component in the isolated storage space of the three-dimensional tile display memory; The corrected spatial position coordinates are back-calculated into the display coordinate system of the navigation thumbnail view area using a preset offset between the coordinate base plate and the display coordinate system of the navigation thumbnail view area to obtain the projected coordinates; Using the projection coordinates as anchor points, the window tracking controller component is redrawn in a floating overlay manner at the corresponding position in the navigation thumbnail view area; In real time, in response to the scrolling or zooming operation of the high-definition main image view area, the spatial position coordinates of the window tracking controller component are synchronously updated in the isolated storage space of the three-dimensional tile display memory, and the projection steps are repeated so that the window tracking controller component continuously follows the field of view changes of the high-definition main image view area.

9. A navigation view area synchronization correction device with mirror flipping, characterized in that, The mirror-flipped navigation view synchronization correction device stores a computer program, which, when executed by a processor, implements the mirror-flipped navigation view synchronization correction method according to any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the navigation view area synchronization correction method for mirror flipping as described in any one of claims 1-8.

Images