Graphical rendering method, device and storage medium of table component

Abstract

The application discloses a graphical rendering method and device of a table component and a storage medium, and relates to the technical field of electronic information.The application limits the rendering range through a virtual grid and a visible area, greatly reduces the grid data processing amount and drawing calculation overhead, and improves the rendering efficiency.Combining the dirty matrix marking with the double-event listening of scrolling and pattern change, the application accurately triggers the repainting and reduces the invalid full refresh, effectively reducing the CPU occupation.Based on the cache state, the application realizes the conditional repainting and the direct mapping display of the cache image, reduces the repeated drawing, improves the interface response speed and the sliding fluency.In this way, the application can well adapt to the rendering requirements of the special-shaped combined table, realizes the efficient and stable rendering without relying on the underlying graphics acceleration, reduces the lag and delay of the interface, and improves the graphical rendering performance of the table component.

Description

Technical Field

[0001] This application relates to the field of electronic information technology, specifically to a graphical rendering method, apparatus, and storage medium for a table component. Background Technology

[0002] The flight day schedule is a core visual management tool in flight training, air traffic control, and mission scheduling. It typically employs a streamlined table panel design, requiring a high-density, dynamic display of multi-dimensional information within a single interface, including tower instructions, flight missions, aircraft, crew, airspace altitude, departure and arrival airports, and flight time. To ensure real-time flight monitoring and operational safety, the flight day schedule places extremely high demands on interface responsiveness, scrolling smoothness, and dynamic refresh latency. Any interface lag, operational delay, or rendering latency can negatively impact scheduling decisions and flight safety.

[0003] Currently, in mainstream commercial operating system environments, graphics rendering systems are mature. Systems can achieve hardware acceleration through graphics interfaces such as DirectX and Vulkan, automatically offloading intensive drawing tasks to the Graphics Processing Unit (GPU) and supporting optimization mechanisms such as batch rendering, drawing command merging, and partial refresh. In this environment, using conventional technologies such as the Visual Basic for Applications (VBA) language accompanying Microsoft Excel, the Qt graphical user interface development framework, and the Java graphical user interface toolkit Swing, smooth rendering of the spreadsheet interface can be achieved, meeting the high-frequency interaction, high-density display, and real-time refresh requirements of flight schedules.

[0004] However, with the widespread adoption of open-source operating systems based on the Linux kernel, traditional rendering technologies have exhibited severe performance deficiencies on these platforms. On one hand, these open-source operating systems are incompatible with Windows-specific components and graphics interfaces, making technologies like VBA, which rely on Microsoft's underlying libraries, unusable directly. On the other hand, the graphics stack of these operating systems lacks system-level hardware acceleration and batch rendering optimization. Cross-platform solutions such as Qt with QML+JS and Java Swing commonly suffer from excessive CPU usage, low rendering efficiency, and uneven CPU / GPU resource allocation in general-purpose hardware environments.

[0005] Especially in complex table scenarios like flight schedules, which involve irregularly shaped non-standard grids, numerous merged cells, frequent scrolling refreshes, and high-density component stacking, traditional techniques typically employ a full-render mode. This means that regardless of the visible area of ​​the interface, all cells and grid lines of the entire table are traversed and drawn. This approach results in extremely high CPU resource consumption for table rendering, leading to noticeable interface lag, drag-and-drop delays, and scrolling jumps. Even simple scrolling or layout changes can trigger a full redraw, further exacerbating the system load.

[0006] Meanwhile, traditional table rendering solutions generally lack targeted optimization mechanisms. Some technologies only implement simple loading of the visible area and are not compatible with irregularly shaped merged cells. Some technologies use caching mechanisms but do not combine them with dirty area marking for precise refreshing. Other solutions rely on underlying graphics driver optimizations, which ordinary application layer developers cannot adjust or adapt, making them difficult to implement in open-source operating environments. Therefore, in a Linux kernel-based operating system environment, how to achieve lightweight, efficient, and low-latency rendering of complex irregularly shaped tables without relying on underlying modifications or hardware acceleration has become a key technical problem restricting the cross-platform deployment of flight training management systems. Summary of the Invention

[0007] The purpose of this application is to provide a graphical rendering method, apparatus and storage medium for table components, in order to solve the problems of low full-scale rendering efficiency, large amount of irregular mesh rendering, lag during refresh and high CPU usage of traditional table components.

[0008] To achieve the above objectives, the first aspect of this application provides a graphical rendering method for a table component, comprising: Construct a virtual grid class for irregularly shaped merged tables, obtain the coordinate range of the visible area of ​​the table component in the display interface, assign values ​​to the virtual grid class according to the coordinate range of the visible area, and only load and calculate the grid data contained in the visible area. Define a dirty matrix marking method to monitor interface scrolling events and table layout change events in real time. If any event is detected, call the dirty matrix marking method to mark the current cached image as dirty and obtain the current cached image object. If the current cached image object is empty, or if the current cached image object is not empty but is marked as dirty, then the cache is reinitialized according to the size of the visible area, the drawing method is called to redraw the background mesh and store the result in the cache, and the cache state is marked as non-dirty. If the current cached image object is not empty and is not marked as dirty, the current cached image is drawn to the display device directly in one go, and the redrawing step is skipped.

[0009] The second aspect of this application provides a graphical rendering device for a table component, a construction module for constructing a virtual grid class for irregularly shaped merged tables, obtaining the coordinate range of the visible area of ​​the table component in the display interface, assigning values ​​to the virtual grid class according to the coordinate range of the visible area, and loading and calculating only the grid data contained within the visible area. The monitoring module is used to define the dirty matrix marking method, which monitors the interface scrolling event and table layout change event in real time. If any event is detected, the dirty matrix marking method is called to mark the current cached image as dirty and obtain the current cached image object. The redraw module is used to reinitialize the cache according to the size of the visible area if the current cached image object is empty, or if the current cached image object is not empty but is marked as dirty, call the drawing method to redraw the background mesh and store the result in the cache, and mark the cache state as non-dirty. The caching module is used to directly draw the current cached image to the display device at once and skip the redrawing step if the current cached image object is not empty and is not marked as dirty.

[0010] A third aspect of this application provides a computer-readable storage medium storing a program that can be loaded by a processor and executed using the graphical rendering method for the table component described above.

[0011] The beneficial effects of this application are: This application significantly reduces the amount of mesh data processing and drawing computation overhead by limiting the rendering range through virtual meshes and visible areas, thereby improving rendering efficiency. It employs dirty matrix marking combined with dual event listeners for scrolling and pattern changes to precisely trigger redraws, reduce invalid full refreshes, and effectively lower CPU usage. Conditional redrawing and direct texturing of cached images are implemented based on cached states, reducing repetitive drawing and improving interface responsiveness and scrolling smoothness. Thus, this application can well adapt to the rendering requirements of irregularly shaped merged tables, achieving efficient and stable rendering without relying on underlying graphics acceleration, reducing interface lag and latency, and improving the graphical rendering performance of table components.

[0012] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a graphical rendering method for a table component provided in an embodiment of this application. Figure 2 This is a flowchart illustrating a graphical rendering method for a table component provided in a specific embodiment of this application; Figure 3This is a schematic diagram of the structure of a graphical rendering device for a table component provided in an embodiment of this application. Detailed Implementation

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

[0015] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified. Details are set forth in the following description for illustrative purposes. It should be understood that those skilled in the art will recognize that this application can be implemented without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid unnecessarily obscuring the description of this application. Therefore, this application is not intended to be limited to the embodiments shown, but rather to be consistent with the broadest scope of the principles and features disclosed herein.

[0016] Figure 1 This is a flowchart illustrating a graphical rendering method for a table component provided in an embodiment of this application. Figure 1 As shown, this graphical rendering method can include steps 101-104, which will be described in detail below.

[0017] Step 101: Construct a virtual grid class for irregularly shaped merged tables, obtain the coordinate range of the visible area of ​​the table component in the display interface, assign values ​​to the virtual grid class according to the coordinate range of the visible area, and only load and calculate the grid data contained in the visible area.

[0018] Irregularly shaped merged tables refer to tables with arbitrary row and column spans and irregular merging patterns, as opposed to standard regular tables. Virtual grid classes are lightweight data structures that do not actually render the entire table, but only maintain its structure information in memory. Traditional standard regular tables typically involve full traversal and full rendering, resulting in high computational overhead and low efficiency. This application's embodiments pre-construct a virtual grid class specifically designed to hold the layout information of irregularly shaped tables, which can include row and column indices, cell sizes, border styles, and attributes such as the starting row, starting column, horizontal span, and vertical span of merged cells.

[0019] During interface display, the system obtains the coordinate range of the visible area of ​​the table component's current display interface in real time. This range is determined by the container size and scroll bar position and does not change with the overall size of the table. The visible area refers to the area currently visible on the screen and serves as the boundary for efficient rendering. Using the visible area as the effective boundary, the system traverses and merges cell information, determining whether it intersects with the visible area. Only cells falling within the visible area are processed for data loading, coordinate calculation, and drawing preparation; cells outside the visible area are completely skipped. This reduces data processing at the source, keeps the rendering scale within a fixed range, reduces computational explosion caused by large tables, significantly lowers CPU load, and improves rendering efficiency.

[0020] Step 102: Define a dirty matrix marking method to monitor the interface scrolling event and table layout change event in real time. If any event is detected, call the dirty matrix marking method to mark the current cached image as dirty and obtain the current cached image object.

[0021] The dirty matrix marking method refers to the state determination mechanism that identifies whether the cached image needs to be redrawn. This step implements an event-driven, precise redraw triggering mechanism. A dirty matrix marking method is predefined, using state bits to indicate whether the current cached image is invalid. The system registers two types of listeners. The first type listens for UI scrolling events, including horizontal scrolling, vertical scrolling, and wheel scrolling. The second type listens for table layout change events. Table layout change events refer to all operations that cause changes in the table layout structure and cache invalidation, including size changes, column width adjustments, row height adjustments, and changes in cell merging relationships. When either type of event is triggered, the system immediately calls the dirty marking method, forcibly marking the current cached image as dirty. A dirty state indicates that the cached image is invalid and must be redrawn. The redraw process is only initiated when there is a real change in the UI, reducing invalid refreshes and periodic wasted time, significantly reducing CPU usage, and improving system response speed.

[0022] Step 103: If the current cached image object is empty, or if the current cached image object is not empty but is marked as dirty, then reinitialize the cache according to the size of the visible area, call the drawing method to redraw the background mesh and store the result in the cache, and mark the cache state as non-dirty.

[0023] A cached image object refers to an off-screen drawing buffer allocated in memory to store rendered images. When the current cached image object is empty (indicating the first launch), or not empty but in a dirty state (indicating the interface has changed), the cached object can be reinitialized according to the width and height of the visible area. Initializing the cache means recreating the buffer according to the size of the visible area, so that the cache size perfectly matches the real area.

[0024] Then, the background drawing method is invoked. Based on the merged cell information in the virtual grid, only the background, borders, and merged areas within the visible region are drawn. After drawing, the image is stored in the cache, and the cache state is reset to a non-dirty state. A non-dirty state means that the cached image is valid, indicating that the cache has been updated with the latest valid image and can be reused directly without redrawing. Redrawing is only performed when necessary, reducing the repeated drawing of the same background, significantly reducing drawing commands, lowering GPU / CPU overhead, and making the rendering of irregularly shaped tables smoother.

[0025] Step 104: If the current cached image object is not empty and is not marked as dirty, then the current cached image is drawn to the display device all at once, and the redrawing step is skipped.

[0026] One-time rendering refers to rendering the entire image at once, rather than rendering row by row or cell by cell. This step achieves the most efficient UI refresh. When the current cached image is valid and not marked as dirty, it means the UI content has not changed and there is no need to recalculate and redraw. The system directly calls the graphics interface to copy the current cached image as a whole bitmap and render it to the display device's graphics context at once, completely skipping all time-consuming steps such as grid traversal, coordinate calculation, and border drawing, directly reusing the cache and omitting all calculation and drawing processes. UI scrolling and dragging operations are extremely smooth, without lag, delay, or ghosting, maintaining stability and fluidity even in complex irregularly shaped tables and high-frequency interaction scenarios, significantly improving the user experience.

[0027] This application's embodiments limit the rendering range through virtual meshes and visible areas, significantly reducing mesh data processing and drawing computation overhead, thus improving rendering efficiency. It employs dirty matrix marking combined with dual event listeners for scrolling and pattern changes to precisely trigger redraws, reducing invalid full refreshes and effectively lowering CPU usage. Conditional redrawing and direct texturing of cached images are implemented based on cached states, reducing repetitive drawing and improving interface responsiveness and scrolling smoothness. Therefore, this application can well adapt to the rendering requirements of irregularly shaped merged tables, achieving efficient and stable rendering without relying on underlying graphics acceleration, reducing interface lag and latency, and improving the graphical rendering performance of table components.

[0028] In step 101, a virtual grid class can be constructed first, and a list of merged cell attributes can be defined within the virtual grid class. The virtual grid class is a dedicated data structure designed for rendering irregularly shaped tables. It is used to maintain table layout information in memory, does not directly perform interface drawing, and is only used for data organization and coordinate calculation, which can significantly reduce the data processing overhead before rendering.

[0029] The merged cell attribute list is the core data set in the virtual grid class, used to uniformly store the layout parameters of all merged cells in the table. For example, the merged cell attribute list can be used to store the starting row index, starting column index, vertical span value, and horizontal span value of all merged cells in the table. These parameters allow for the accurate positioning, size, and coverage of any merged cell within the table.

[0030] As an example, we first construct a Virtual Grid class, and then build a dedicated data structure and function within the Virtual Grid class to adapt to the merging of cells in irregularly shaped tables. Specifically, we set the property 'm' and the data structure to a List.<Integer[][]> This is used to store the coordinate information of all merged cells. The `combineColumnList` property has a `List` data structure. <integer>This is used to store the collection of column numbers for which column merging needs to be performed. The `combineRowList` property has a `List` data structure. <integer>This is used to store the set of row numbers that need to be merged. When the visible area contains merged cells that span multiple rows and columns, the coordinate data of the corresponding merged area is added to mergeList, combineColumnList, and combineRowList for maintenance. The virtual grid class also defines visible area boundary properties, including the minimum and maximum row numbers [minRow, maxRow] and the minimum and maximum column numbers [minColumn, maxColumn] of the visible area, and grid coordinates that are not involved in merging are visible by default.

[0031] Meanwhile, the virtual grid class provides dedicated functions for precise determination and calculation of merged cells. Specifically, it provides a function `visibleCellRowNum(row, column)` to determine the starting row number of the merged cell containing the passed coordinates. If the current coordinates do not belong to any merged cell, it returns the current row number `row`. It also provides functions `spanV(row, column)` and `spanH(row, column)` to determine the vertical span (number of rows) and horizontal span (number of columns) of the merged cell containing the passed coordinates. If the current coordinates do not belong to any merged cell, it returns the default span value of 1 (i.e., the default span of a cell not involved in merging is 1).

[0032] Subsequently, the visible area coordinates of the table component in the display interface are obtained. These coordinates are determined by the size of the table display area and the scroll bar offset, representing the boundary of the table area that can be displayed on the current interface. The row visible area of ​​the table is defined as the interval [r1, r2], where r1 is the starting row and r2 is the ending row. The column visible area of ​​the table is defined as the interval [c1, c2], where c1 is the starting column and c2 is the ending column. Finally, the virtual grid class is assigned values ​​using the visible area coordinate parameters: the obtained visible area parameters r1, r2, c1, and c2 are assigned to the minRow, maxRow, minColumn, and maxColumn properties of the virtual grid class, respectively, completing the binding between the visible area and the virtual grid. This ensures that the virtual grid class only loads, calculates, and processes the grid data contained within the [r1, r2] row range and the [c1, c2] column range, completely skipping the grid traversal and calculation process for non-visible areas.

[0033] Iterate through the list of merged cell attributes. For each merged cell, perform a geometric comparison between its coordinate range and the coordinate range of the department area to determine whether each merged cell intersects with the coordinate range of the visible area.

[0034] If the coordinates of the merged cell intersect with the visible area, it indicates that the merged cell belongs to the content that needs to be displayed. In this case, the relative coordinates of the merged cell within the visible area are calculated, and the relative coordinates and the corresponding merged cell information are mapped and assigned to the virtual grid class. Only the grid data falling within the visible area is loaded and processed, completing the loading of the grid data for the visible area. If there is no intersection, the loading and calculation process for the merged cell is skipped.

[0035] By using the above method, the virtual grid class only carries the valid grid data within the visible area, and no longer performs full traversal and full assignment of the entire table area. This reduces the amount of data loading, coordinate calculation, and drawing preparation work from the source, making the rendering workload independent of the overall table size and only related to the size of the visible area. This significantly reduces the CPU's computing load and improves the efficiency of table initialization and interface refresh, especially suitable for irregular table scenarios with a large number of cell merging operations.

[0036] In step 102, scroll event listeners can be added to the horizontal and vertical scrollbars of the table component. When a change in the scrollbar value is detected, a scroll event is triggered. The scroll event listener is an event capture program attached to the scrollbar settings, specifically designed to identify changes in the visible area position caused by the user scrolling the table. For example, define the table canvas scroll listener time as OnScrollEvent(). The trigger source for this event is the table component's scrollbar component JScrollBar, and event binding and listener mounting are completed through the underlying intercept point addAdjustmentListener. During operation, continuous monitoring of changes in the horizontal and vertical scrollbar values ​​is performed. When the listener detects changes in the scrollbar value such as offset, increase, or decrease, it immediately determines that the current operation triggers a scroll event, triggering the OnScrollEvent() scroll event. Immediately after the event is triggered, the preset MarkDirty() dirty matrix marking method is called. This listening method can accurately capture all scroll behaviors with visible area position offsets, covering all scrolling interaction scenarios of the table.

[0037] Simultaneously, a component listener is added to the table component. When a change in the size of the table component, or a change in the column width or row height attributes of the table is detected, a table layout change event is triggered. The component listener is a state monitoring program bound to the table body, used to identify layout structure changes such as the overall size of the table and the row and column dimensions of cells. For example, a table layout change listener event, ComponentListener, is defined. The trigger source of this event is the table body component JComponent, which achieves full-dimensional layout monitoring through four underlying interception points: componentResized (component size change), componentMoved (component position movement), componentShown (component display), and componentHidden (component hiding). When the listener detects a change in the overall outer outline size of the table, or an adjustment in the column width or row height parameters of the cells within the table, it determines that the current operation has triggered a table layout change event, which will trigger the ComponentListener event. After the event is triggered, the MarkDirty() dirty matrix marking method is called synchronously. This listening mechanism can fully cover all scenarios of changes in table layout structure and size state, solving the problems of incomplete monitoring and missed detection of layout changes in traditional listening methods.

[0038] After establishing the two types of monitoring mechanisms, the dirty matrix determination logic is defined. First, it checks whether the current cache has been actively marked as dirty, defining this state as 'd'. Second, it defines a method `MarkDirty()` to mark the dirty matrix. This method internally sets a global boolean variable `isDirty` to uniformly identify the valid state of the cached image. When an external event is triggered, calling this method sets `isDirty` to `true`, and after the new buffered image is drawn, `isDirty` is reassigned to `false`.

[0039] As soon as any of the following events is triggered, such as UI scrolling events or table layout change events, the preset dirty matrix marking method is immediately invoked to mark the entire cached image generated in memory as globally dirty. At the same time, the cached image objects that are currently in effect in the system are retrieved to provide a basis for subsequent redraw determination.

[0040] In step 102, after marking the current cached image as dirty, multiple local dirty regions marked as dirty can be obtained in the current cached image based on the dirty matrix marking results. Local dirty regions are independent small areas within the cached image where content deviations occur due to interface changes, requiring image correction. Geometric range integration operations are performed on the selected independent local dirty regions to calculate the minimum bounding rectangle of the multiple local dirty regions. This minimum bounding rectangle is used as the final redraw area. The minimum bounding rectangle is the smallest rectangular range that can completely enclose all scattered local dirty regions; it is the unified and regularized drawing area after integrating the scattered redraw areas. After determining the final redraw area, the dirty status markings of the local dirty regions are cleared, retaining only the redraw marker of the minimum bounding rectangle. The redraw marker is a status identification marker used to distinguish whether a specified area needs to undergo a redraw operation, used to quickly distinguish whether a specified image area needs to undergo a redraw operation.

[0041] This step involves simultaneously setting up the basic background cache configuration to provide underlying support for efficient rendering. First, the current cached graphics object is obtained; this object type is BufferedImage, uniformly labeled 'i'. This buffered image is created during program startup, occupies a fixed amount of memory, and its memory usage is only related to the width and height of the visible screen area, not the total size of the table. Next, the data object storing the complete table merging rules is obtained and denoted as 'm'. This object provides the basis for merging cell drawing in subsequent background grid rendering. Then, two types of drawing and devices are configured: the graphics drawing device used to output the final image to the display device is denoted as g1, and the pen device specifically used to complete drawing operations within the background buffered image is denoted as g2. Off-screen drawing is achieved using g2, without interfering with the real-time display of the front-end interface. Relying on the above cache and drawing devices, the background grid can be drawn once and reused multiple times, reducing CPU resource consumption caused by repeated drawing from the source.

[0042] This step, through the categorization and setting of dual-type event listeners, can accurately distinguish between table browsing and scrolling behaviors and table layout modification behaviors, enabling precise determination of cache invalidation in different scenarios and reducing indiscriminate triggering of redraw operations. Furthermore, it abandons the traditional full-screen uniform redraw mode, extracting local dirty areas and integrating them into the smallest bounding rectangle for targeted redrawing, significantly reducing the actual redraw area and data computation load. By cleaning up redundant local dirty state markers and retaining only valid redraw area identifiers, the system state recognition logic is simplified, reducing the computational resources occupied by state determination. While ensuring accurate table interface refresh effects, it further reduces resource consumption during graphics rendering, improving the overall response speed and smoothness of table interface scrolling and layout adjustment. By balancing global cache state management and the need for precise local refresh, it adapts to the diverse interface interaction scenarios of irregularly shaped merged tables, resulting in stronger rendering optimization adaptability.

[0043] In step 103, when a redraw operation is required, the dynamic initialization and adaptation steps of the mixed-use object are first completed. First, the display parameters of the current interface of the current table component are obtained in real time, and the actual width and actual height of the visible area are obtained. This size is the actual visible size of the table interface on the current screen, and it is updated in real time as the window is scaled and the column width and row height are adjusted.

[0044] Secondly, based on the actual width and height of the visible area, buffered image objects in memory are created or reset, dynamically matching the size of the visible area to ensure the size of the buffered image object matches the size of the visible area. If no buffered image object exists in memory, a new buffered image of the corresponding size is created. If a buffered image object already exists but its size does not match the current visible area, the image size is directly reset, ultimately ensuring that the size of the buffered image object is completely consistent with the screen's visible area size. This design ensures that the cached image always fits the current display interface, reducing abnormal issues such as image stretching, white space, and truncation, achieving dynamic adaptive cache size, always matching the latest visible area interface specifications, and ensuring the integrity of the rendered image.

[0045] Finally, the graphics drawing context of the buffered image object is obtained, namely the background off-screen pen device g2. This drawing context is independent of the screen display device and is specifically used to perform subsequent off-screen drawing operations for the background mesh. Off-screen drawing refers to a rendering method in which all graphics drawing operations are completed in the memory buffered image, rather than drawing directly on the display screen in real time. The graphics drawing context refers to the core pen device that carries drawing instructions and executes line and color block drawing. All mesh drawing actions are completed in background memory and will not directly refresh the front-end screen interface, effectively reducing flickering and jittering issues during the drawing process. By isolating the drawing process through an independent off-screen drawing context, the interface flickering problem is avoided, while the cached drawing range is fixed to reduce unnecessary memory overhead.

[0046] In step 103, the built-in optimized rendering algorithm entry method PaintGrid(g1,g2,m,r1,r2,c1,c2,i) is used, and the background grid of the visible area is redrawn through the core grid drawing method DrawGrid(g,m,r1,r2,c1,c2). The entire process relies on the judgment function of the virtual grid class to adapt to the drawing of irregularly shaped merged cells.

[0047] Specifically, in the step of calling the drawing method to redraw the background mesh, the sequence of mesh units to be drawn in the visible area can be extracted based on the coordinate range of the visible area [r1,r2] and [c1,c2]. Only all mesh units falling within the boundary of the visible area are selected, and mesh data outside the visible area is completely eliminated, thus limiting the rendering range from the source.

[0048] Secondly, the `DrawGrid` method is called to traverse the sequence of grid cells to be drawn, using a nested loop. The outer loop traverses the row intervals r1 to r2, defining a local traversal variable `row`. The inner loop traverses the column intervals c1 to c2, defining a local traversal variable `column`. Each group (row, column) corresponds to a unique grid cell coordinate within the visible area. During the traversal, for the currently traversed target grid cell, the merged cell attribute list of the virtual grid class is retrieved for matching and retrieval to determine whether the current grid coordinates belong to a merged cell.

[0049] To accurately identify the attributes of merged cells, this step reuses the three core determination functions of the virtual grid class: obtaining the starting row number of the merged cell through visibleCellRowNum(row,column), obtaining the vertical merge span through spanV(row,column), and obtaining the horizontal merge span through spanH(row,column), thus accurately determining the merged status and coverage of the current cell.

[0050] If the target grid cell has corresponding merged cell data, the merged drawing area of ​​the merged cell on the display device is calculated based on the starting row index, starting column index, vertical span value, and horizontal span value of the merged cell data, and background filling and border drawing are performed within the merged drawing area.

[0051] To address the issues of overlapping borders and redundant lines in merged cells, a differentiated drawing strategy for the primary cell is adopted. As an example, the starting grid cell can be determined as the primary cell of the merged drawing area based on the starting row and column indices of the merged cell data. The remaining covered grid cells are considered secondary cells. The primary cell refers to the starting coordinate cell of the irregularly shaped merged cell, serving as the sole reference unit for drawing the outline of the merged area. Secondary cells are those cells that are merged and covered, and do not require separate outer border drawing.

[0052] The algorithm iterates through all grid cells within the merged drawing area, determining the cell type for each. It then checks if the currently visited grid cell is a primary cell. If so, it draws a uniform closed border around the merged drawing area, ensuring a complete and regular overall outline. If the currently visited grid cell is not a primary cell (i.e., a subordinate cell), it skips drawing the border for that cell or only draws non-overlapping border segments to connect adjacent standard drawing areas. These non-overlapping border segments are auxiliary border lines used only to connect adjacent grids without overlapping. This reduces the problem of multiple overlapping borders and uneven line thickness.

[0053] Simultaneously, the drawing is adapted based on the underlying algorithm rules. If the cell is merged to the right in a row, the drawing of the right-side line segment of the current cell is ignored. If the cell is merged to the bottom in a column, the drawing of the bottom line segment of the current cell is ignored. Based on the function's judgment result, redundant borders are adaptively trimmed to accurately restore various irregularly shaped merged grid shapes that span rows and columns. After the border drawing is completed, a uniform background fill is applied to the merged drawing area.

[0054] If no corresponding merged cell data is found for the target grid cell, the current cell is determined to be a standard independent cell. The preset row and column size of the target grid cell is obtained. Within the preset drawing area defined by the preset row and column size, the four border lines of the cell (top, bottom, left, and right) are drawn completely. Background filling and border drawing are performed to ensure that the standard grid is neat and uniform.

[0055] By employing a double-loop traversal and precise merging function determination, adaptive rendering of irregularly shaped merged meshes is achieved, perfectly adapting to various irregular merging scenarios. Through differentiated rendering of master and slave cells and trimming of redundant line segments, the problems of overlapping, misaligned, and redundant borders in traditional table merging are completely resolved, significantly improving mesh rendering accuracy. Only visible area cells are drawn, eliminating the overhead of full-scale rendering and significantly reducing the computational load on the central processing unit.

[0056] Once the background fill and border drawing of all grid cells within the visible area are complete, the finished background grid image is stored in the buffer image object, completing the cache update. Simultaneously, the global dirty state variable `isDirty` is set to `false`, marking the cache state as non-dirty, indicating that the current cached image is up-to-date and valid, and can be used for subsequent fast reuse rendering.

[0057] In step 104, a smart rendering mechanism is implemented by defining a cached image rendering scheduling method, which enables fast image rendering when the cache is valid and redrawing when the cache is invalid. First, the method DragBg(g,i) for drawing the cached image to the display device is defined as the main scheduling entry point for the overall rendering process. Its execution logic is as follows: if the cached image object i is not empty and the dirty state flag d is false, then DrawBg(g1,i) is executed directly to output the cached image to the display device and return. If the cached image object i is empty, or the dirty state flag d is true, then the cached image object i is reinitialized, its width and height are set to the latest size of the visible area, the graphics device g2 is reassigned as the new pen for the cached image, DrawGrid(g2,m,r1,r2,c1,c2) ​​is called to complete the background grid redraw, and after the drawing is completed, DrawBg(g1,i) is executed again to output the latest cached image to the display device and return.

[0058] When executing cached image rendering output, the screen graphics drawing context corresponding to the display device is first obtained. The screen graphics drawing context refers to the graphics drawing runtime environment bound to the terminal display device. It is used to receive graphics drawing instructions and carry image drawing data. It is the underlying device carrier for realizing screen output, which is different from the background off-screen caching drawing context.

[0059] Subsequently, the image copy function of the graphics drawing interface is called. This function is a batch bitmap copy utility provided by the graphics drawing interface, supporting the complete mapping and copying of the cached image to the screen canvas without drawing pixel-by-pixel or cell-by-cell. Using the current cached image object as the source image, and starting from the top-left corner of the visible area, the current cached image object is copied to the screen graphics drawing context of the display device in one go. One-time bitmap copy refers to a rendering method that treats the cached image as a complete, independent resource and copies it to the screen drawing context in batches. This is a lightweight refresh mechanism that requires no computation and no iteration. The starting coordinates of the top-left corner of the visible area are the reference coordinates of the table's visible area within the interface container, used to ensure that the cached image is accurately aligned with the screen display position, reducing screen offset and misalignment.

[0060] This step drastically simplifies the rendering process, completely skipping redraw calculations and mesh rendering while the cache is active. Interface refresh is achieved through a single bitmap copy, significantly reducing the computational load and number of instructions in graphics rendering, and greatly improving the refresh frame rate and response speed of the table interface. The use of a one-time copy of the entire image reduces resource consumption from drawing cell by cell and line by line, significantly lowering the CPU's computational load and effectively solving stuttering, latency, and screen jump issues during scrolling and interaction with large amounts of irregularly shaped tables. Texture mapping is completed based on the coordinates of the top-left corner of the visible area, ensuring precise alignment between the cached image and the visible screen area. The rendered image has no offset, misalignment, or blank space, ensuring both high-efficiency rendering and high accuracy and display quality of the table interface. Lightweight rendering is achieved through a cache reuse mechanism, eliminating the need for hardware graphics acceleration. High-frequency, smooth table interface refreshes can be achieved at the pure application layer, adapting to various complex, irregularly shaped, merged table interactive rendering scenarios, offering greater versatility and stability.

[0061] Figure 2 This is a flowchart illustrating a graphical rendering method for a table component provided in a specific embodiment of this application. Figure 2 As shown, the method specifically includes the following steps.

[0062] First, create a virtual table. Obtain the visualization area range and dynamically assign values ​​to the virtual table.

[0063] Construct a virtual grid class and define a list of merged cell attributes, row and column merging information, and visible area boundary attributes within the class to prepare for loading only visible area data later. Then, obtain the visible area coordinates of the table component and dynamically assign this range to the virtual grid class, ensuring that the virtual grid class only maintains grid data within the visible area. Proceed to the listening phase.

[0064] At the same time, a background caching mechanism is established to cache the background grid image.

[0065] Create an off-screen buffer image object, setting its memory size to be related only to the visible area size, independent of the total table size, to provide a carrier for subsequent cache reuse. Call the drawing method to draw the background grid within the visible area in the off-screen buffer image, and store the drawn image into the buffer image object to form a reusable background cache. Enter the listening phase.

[0066] Secondly, listen to JTable. Configure two types of listeners for the table component to capture two types of UI changes: Scroll event listener: listens for changes in the horizontal / vertical scroll bar values ​​to identify visible area position shifts. Component listener: listens for changes in table component size, column width, row height, and other attributes to identify table layout changes.

[0067] Next, a dirty matrix is ​​created. A dirty matrix marking method MarkDirty() is defined, and a global boolean variable isDirty is maintained to indicate whether the cached image needs to be redrawn.

[0068] During the branch determination and rendering phase, the following branch determination is performed.

[0069] Canvas scrolling detection. This involves determining whether a scrolling event is detected. If canvas scrolling is detected (the visible area position changes), the dirty matrix marking method is called to mark the current cached image as dirty.

[0070] Layout change detection. This involves determining whether a table layout change event has been detected. If a table layout / size change is detected, the dirty matrix marking method is called to mark the current cached image as dirty.

[0071] After calling the dirty matrix marker, the redraw process begins. If the cached image is empty or marked as dirty, the cached image is reinitialized according to the visible area size, the drawing method is called to redraw the background mesh, and the result is stored in the cache. After the cached state is marked as non-dirty, the updated cached image is output to the display device, completing this rendering.

[0072] The technical effects of the solutions in the embodiments of this application will be illustrated below using experimental data.

[0073] In a specific experiment, the equipment used was as follows: System: Galaxy Kylin GFB V10 JICAI; Hardware: D2000 / 8, 16g, JM9100; JDK: 1.8.0_431. Using flight planning software, a 12-hour flight schedule was created (one cell every 10 minutes, 6 cells per hour), with the default initialization of 30 aircraft positions (one aircraft occupies 2 rows). The core flight panel area occupied 4320 (12*6*60) cells; 60 typical flight components were created. With native rendering technology, mouse lag was noticeable. In calm mode, the average CPU usage was 90%. After slight mouse movement or starting flight schedule timing, the peak CPU usage exceeded 100%, and scrolling the screen resulted in ghosting and lag. After adopting virtual table rendering technology, regardless of changes in the flight time range and number of rows, the area to be rendered remained fixed, and the performance was stable (only related to screen resolution), accounting for only about 15-23% of the original rendering task. After adopting cache reuse technology, the flight count bar can closely follow the mouse movement, eliminating the previous ghosting, pauses, and delays. CPU usage decreased to 33%-65%, with an average of 40%, showing a significant performance improvement in static mode. With all flight operations initiated, CPU usage ranged from 63%-76%, averaging 68%. When dragging six components simultaneously, the peak CPU usage was less than 70%, resulting in very smooth operation.

[0074] Figure 3 This is a schematic diagram of the structure of a graphical rendering device for a table component provided in an embodiment of this application. Figure 3 As shown, the graphical rendering device 300 of the table component may include a building module 301, a listening module 302, a redrawing module 303, and a caching module 304.

[0075] The construction module 301 is used to construct a virtual grid class for irregularly shaped merged tables, obtain the coordinate range of the visible area of ​​the table component in the display interface, assign values ​​to the virtual grid class according to the coordinate range of the visible area, and only load and calculate the grid data contained in the visible area.

[0076] The listening module 302 is used to define the dirty matrix marking method, which listens for interface scrolling events and table layout change events in real time. If any event is detected, the dirty matrix marking method is called to mark the current cached image as dirty and obtain the current cached image object.

[0077] The redraw module 303 is used to reinitialize the cache according to the size of the visible area if the current cached image object is empty, or if the current cached image object is not empty but is marked as dirty, call the drawing method to redraw the background mesh and store the result in the cache, and mark the cache state as non-dirty.

[0078] The caching module 304 is used to directly draw the current cached image to the display device at once and skip the redrawing step if the current cached image object is not empty and is not marked as dirty.

[0079] Among them, the construction module 301, the listening module 302, the redrawing module 303 and the caching module 304 can be used to execute steps 101-104 in the embodiment corresponding to the graphical rendering method of the above table component. For the specific implementation of these modules and more details, please refer to the corresponding method section, which will not be elaborated here.

[0080] This application also provides a computer-readable storage medium storing a program that can be loaded by a processor and executed as a graphical rendering method for any of the table components in this application.

[0081] Those skilled in the art will understand that all or part of the functions of the various methods in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to achieve the above functions. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be achieved. In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the program can also be stored in a server, another computer, disk, optical disk, flash drive, or external hard drive, etc., and can be downloaded or copied to the memory of a local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be achieved.

[0082] The above examples illustrate this application only to aid understanding and are not intended to limit its scope. Those skilled in the art to which this application pertains can make various simple deductions, modifications, or substitutions based on the ideas presented.< / integer> < / integer>

Claims

1. A graphical rendering method for a table component, characterized in that, include: Construct a virtual grid class and define a merged cell attribute list in the virtual grid class. The merged cell attribute list is used to store the starting row index, starting column index, vertical span value, and horizontal span value of all merged cells in the table. Iterate through the list of merged cell attributes and determine whether each merged cell intersects with the coordinate range of the visible area; If the coordinate range of the merged cell intersects with that of the visible area, the relative coordinates of the merged cell in the visible area are calculated, and the relative coordinates and the corresponding merged cell information are mapped and assigned to the virtual grid class to complete the loading of the grid data of the visible area. Define a dirty matrix marking method to monitor interface scrolling events and table layout change events in real time. If any event is detected, call the dirty matrix marking method to mark the current cached image as dirty and obtain the current cached image object. If the current cached image object is empty, or if the current cached image object is not empty but is marked as dirty, then the cache is reinitialized according to the size of the visible area, the drawing method is called to redraw the background mesh and store the result in the cache, and the cache state is marked as non-dirty. If the current cached image object is not empty and is not marked as dirty, the current cached image is drawn to the display device directly in one go, and the redrawing step is skipped.

2. The graphical rendering method according to claim 1, characterized in that, The method of calling the drawing method to redraw the background mesh includes: Based on the coordinate range of the visible area, extract the sequence of grid cells to be drawn within the visible area; Traverse the sequence of grid cells to be drawn, and for the target grid cell currently traversed, perform a matching search based on the merged cell attribute list; If the target grid cell has corresponding merged cell data, then the merged drawing area of ​​the merged cell on the display device is calculated based on the starting row index, starting column index, vertical span value and horizontal span value of the merged cell data, and background filling and border drawing are performed within the merged drawing area; If no corresponding merged cell data is found for the target grid cell, the preset row and column size of the target grid cell is obtained, and background filling and border drawing are performed within the preset drawing area defined by the preset row and column size.

3. The graphical rendering method according to claim 2, characterized in that, The process of performing background filling and border drawing within the merged drawing area includes: Based on the starting row index and starting column index of the merged cell data, the starting position grid is determined as the main cell of the merged drawing area; Traverse all grid cells within the merged drawing area and determine whether the currently traversed grid cell is the main cell; If the currently traversed grid cell is the main cell, then draw the outer closed border of the merged drawing area; If the currently traversed grid cell is not the main cell, then skip drawing the border of the current grid cell, or only draw the non-overlapping border segments used to connect adjacent standard drawing areas.

4. The graphical rendering method according to claim 1, characterized in that, The real-time monitoring of interface scrolling events and table layout change events includes: Add scroll event listeners to the horizontal and vertical scrollbars of the table component. When a change in the scrollbar value is detected, trigger the interface scroll event. Add a component listener to the table component. When the size of the table component changes, or the column width and row height properties of the table change, determine that a table layout change event is triggered.

5. The graphical rendering method according to claim 1, characterized in that, After the step of marking the current cached image as dirty, the method further includes: Based on the dirty matrix labeling results, obtain multiple local dirty regions in the current cached image that are labeled as dirty. Calculate the minimum bounding rectangle of the multiple local dirty regions, and use the minimum bounding rectangle as the final redraw area; After determining the final redraw area, clear the dirty status markers of the local dirty areas, and retain only the redraw marker of the smallest bounding rectangle.

6. The graphical rendering method according to claim 1, characterized in that, The step of re-initializing the cache according to the size of the visible area includes: Get the actual width and height of the visible area of ​​the current table component in real time; Based on the actual width and actual height of the visible area, create or reset the buffered image object in memory so that the size of the buffered image object matches the size of the visible area; Obtain the graphics rendering context of the buffered image object for performing subsequent off-screen rendering operations of the background mesh.

7. The graphical rendering method according to claim 1, characterized in that, The step of directly drawing the current cached image to the display device includes: Obtain the screen graphics drawing context corresponding to the display device; Call the image copy function of the graphics drawing interface, take the current cached image object as the source image, and copy the current cached image object to the screen graphics drawing context of the display device in one go, starting from the upper left corner coordinates of the visible area.

8. A graphical rendering device for a table component, characterized in that, include: A construction module is used to construct a virtual grid class and define a list of merged cell attributes in the virtual grid class. The list of merged cell attributes is used to store the starting row index, starting column index, vertical span value, and horizontal span value of all merged cells in the table. Iterate through the list of merged cell attributes and determine whether each merged cell intersects with the coordinate range of the visible area; If the coordinate range of the merged cell intersects with that of the visible area, the relative coordinates of the merged cell in the visible area are calculated, and the relative coordinates and the corresponding merged cell information are mapped and assigned to the virtual grid class to complete the loading of the grid data of the visible area. The monitoring module is used to define the dirty matrix marking method, which monitors the interface scrolling event and table layout change event in real time. If any event is detected, the dirty matrix marking method is called to mark the current cached image as dirty and obtain the current cached image object. The redraw module is used to reinitialize the cache according to the size of the visible area if the current cached image object is empty, or if the current cached image object is not empty but is marked as dirty, call the drawing method to redraw the background mesh and store the result in the cache, and mark the cache state as non-dirty. The caching module is used to directly draw the current cached image to the display device at once and skip the redrawing step if the current cached image object is not empty and is not marked as dirty.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that can be loaded by a processor and executed as a graphical rendering method for a table component as described in any one of claims 1 to 7.

Images