An intelligent code completion optimization method based on texture pre-rendering and multi-level cache

Abstract

The application discloses an intelligent completion code optimization method based on texture pre-rendering and multi-level caching, previously establishes a syntax rule set and a GPU cache characteristic database, saves a syntax style table, generates a font atlas and loads current GPU cache parameters when a code editor starts, divides candidate code segments into data blocks after a candidate code segment list is popped out, analyzes a syntax type in parallel, determines a character style, generates candidate code segment textures through instantiation rendering and fragment shader, then according to current GPU cache parameters, a selected priority of the candidate code segments and a volume after compression, the textures are distributed to a first-level cache, a second-level cache or global memory according to rules, metadata is recorded and added to a global texture cache table, when a user selects a candidate code segment, texture data is read from a corresponding GPU cache, display coordinates are calculated in combination with a cursor row and column index, editor basic style parameters and a DPI scaling ratio, rendering and drawing of the textures are completed, and optimized display of the intelligent completion code is realized.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to an intelligent code completion optimization method based on texture pre-rendering and multi-level caching. Background Technology

[0002] Intelligent code completion is a core feature of modern code editors. It analyzes the current code context, such as syntax structure, variable types, and function definitions, to generate candidate code segments, helping programmers improve coding efficiency. Current intelligent code completion uses a dynamic generation of rendering data after selection. The specific process is as follows: the user selects a target code segment from the candidate list; the code editor's UI thread calls the CPU to parse the code segment's syntax structure, such as keywords, comments, and variables; then, based on the editor's theme, it generates style rules, including colors, fonts, and line heights; and calculates the code segment's width, height, indentation, and other display layout. This layout is then converted into pixel data and transmitted to the GPU's video memory via the PCIe bus. The GPU receives the pixel data, performs rendering, and outputs the result to the screen. In this process, there are unavoidable delays in the CPU parsing, style calculation, and data transmission stages. Especially when the candidate code segment exceeds 50 lines, the CPU needs to handle a large number of syntax analysis and layout calculation tasks, with data transmission volumes reaching tens of KB to several MB, resulting in rendering delays as high as 200ms to 500ms. Programmers can clearly perceive the stuttering after selection.

[0003] However, the existing intelligent completion rendering process has significant technical flaws, specifically as follows: it fails to utilize the idle time during the candidate list display to prepare rendering data in advance, instead waiting for the user to select a candidate before starting the rendering process, resulting in a delay in rendering timing; it uniformly transmits all rendering data to the GPU's general-purpose video memory, without allocating it to GPU storage areas of different speeds, such as GPU cache and medium-speed unified memory, based on the probability of the candidate code segment being selected, resulting in the high-priority candidate reading speed not reaching the optimal level; the rendering process relies on the CPU to complete the entire chain of processing from code text to pixel data, with the GPU only serving as the final display terminal, failing to fully utilize the GPU's parallel rendering and high-speed storage capabilities.

[0004] In summary, existing code editors' intelligent completion methods still suffer from performance bottlenecks and hardware compatibility issues in complex scenarios. Summary of the Invention

[0005] In view of this, the present invention provides an intelligent code completion optimization method based on texture pre-rendering and multi-level caching, which realizes the fast display of intelligent code completion.

[0006] This invention provides an intelligent code completion optimization method based on texture pre-rendering and multi-level caching, which specifically includes the following steps:

[0007] Establish a set of syntax rules and a GPU cache feature database; when the editor starts, it creates a syntax style sheet with syntax type as index and style as value, renders the printable characters of the font as textures to form a font atlas, and loads cache parameters from the GPU cache feature database according to the current GPU.

[0008] After intelligent code completion displays a list of candidate code segments, the candidate code segments are divided into data blocks. The syntax type of the characters in each data block is parsed in parallel according to the syntax rule set to obtain a character tag array. Based on the character tag array and the syntax style table, the style of the characters in the candidate code segments is determined. The vertex shader determines the height and width of the candidate code segment texture to be generated based on the number of lines and the number of characters in the longest line of the candidate code segment. Using the character's syntax type and its coordinates in the font atlas as instance data, the screen coordinates of the character in the candidate code segment texture are generated. The fragment shader generates the pixel data of the character based on the font atlas and the character's style. The pixel data of all characters constitutes the candidate code segment texture.

[0009] Get the selection priority of the candidate code segment and compress the candidate code segment. If the selection priority is greater than the maximum threshold and the compressed size is not greater than the single-level capacity of the first-level cache, it is uploaded to the first-level cache. If the selection priority is greater than or equal to the minimum threshold and less than the maximum threshold, it is uploaded to the second-level cache. If the selection priority is less than the minimum threshold, it is uploaded to the global video memory.

[0010] After the user selects a candidate code segment, the target texture is read from the corresponding cache, the cursor pixel position is calculated, the texture screen coordinates of the target texture are determined, the texture screen coordinates are modified according to the DPI scaling ratio, and the fragment shader completes the rendering of the target texture based on the texture screen coordinates.

[0011] Furthermore, the method of rendering the printable characters of the font as textures to form a font atlas is as follows: the printable characters of the current font are rendered as textures of a set size of pixels, occupying a rectangular area of ​​a fixed size; for character combinations, they are stored as a single super character in an additional area of ​​the font atlas; and a hash table containing the mapping relationship between characters and character combinations and the coordinates of the font atlas is established.

[0012] Furthermore, when the selected priority is greater than the maximum threshold and the compressed size is not greater than the single-level capacity of the first-level cache, if the remaining capacity of the first-level cache is greater than the compressed size, the candidate code segment texture is uploaded to the first-level cache; otherwise, textures that have not been accessed within a set time in the first-level cache are first evicted. If such textures do not exist, the texture with the lowest selected priority is evicted, and then the candidate code segment texture is uploaded to the first-level cache. The first texture metadata is recorded and added to the global texture cache table. The first texture metadata includes the cache level, selected priority, texture format, last access time, and texture object.

[0013] Furthermore, when the selected priority is greater than or equal to the minimum threshold and less than the maximum threshold, or when the selected priority is greater than the maximum threshold and the compressed size is greater than the single-level capacity of the first-level cache, if the remaining capacity of the second-level cache is greater than the compressed size, the candidate code segment texture is uploaded to the second-level cache; otherwise, the texture with the earliest last access time and the largest time interval between the last two accesses in the second-level cache is evicted, and the candidate code segment texture is uploaded to the second-level cache; the second texture metadata is recorded and added to the global texture cache table, wherein the second texture metadata includes cache level, selected priority, texture format, timestamps of the last two accesses, last access time and texture object.

[0014] Furthermore, when the selected priority is less than the minimum threshold or the compressed size is greater than the capacity threshold, if the candidate code segment texture occupancy rate in the global video memory is not greater than the threshold, the candidate code segment texture is uploaded to the global video memory; otherwise, after eliminating textures in the global video memory with a priority less than the set threshold, the candidate code segment texture is uploaded to the global video memory. The third texture metadata is recorded and added to the global texture cache table. The third texture metadata includes cache level, selected priority, texture format, creation time, last access time, and release flag.

[0015] Furthermore, the selection priority of candidate code segments is assigned by the editor.

[0016] Furthermore, the selection priority of candidate code segments is calculated using the following formula:

[0017] Priorityᵢ=(0.3×P h + 0.3×P_c + 0.2×P_p + 0.1×P_l + 0.1×P_t) ×100

[0018] Where Priorityᵢ is the priority score of candidate code segment i, and its value ranges from [0, 100]; P h P_c is the historical selection probability, P_p is the context matching degree, P_l is the candidate popularity, P_l is the code length factor, and P_t is the type factor.

[0019] Furthermore, if the number of lines of code selected by the user in the candidate code segment is less than the threshold, the method for determining the screen coordinates of the target texture after calculating the cursor pixel position is as follows: calculate the screen coordinates of the top left vertex of the texture display area, the horizontal coordinate is the same as the horizontal coordinate of the cursor pixel position, and the calculation method of the vertical coordinate Y_display is as follows:

[0020] Y_display= Math.floor (Y_cursor / h) × h

[0021] In this function, Math.floor() is the floor function, Y_cursor is the vertical coordinate of the cursor's pixel position, and h is the height of the code line.

[0022] Furthermore, if the number of lines of code selected by the user in the candidate code segment is not less than the threshold, the method for determining the texture screen coordinates of the target texture after calculating the cursor pixel position is as follows: calculate the screen coordinates of the top left vertex of the texture display area, and add the calculation of the screen coordinates of the bottom right vertex. The horizontal coordinate of the bottom right vertex screen coordinate is the sum of the horizontal coordinate of the top left vertex screen coordinate and the width of the target code segment texture, and the vertical coordinate is the sum of the vertical coordinate of the top left vertex screen coordinate and the height of the target code segment texture.

[0023] Furthermore, the fragment shader completes the rendering and drawing of the target texture based on the texture screen coordinates as follows:

[0024] The area in the target texture that is occluded by existing code is recorded as the occluded area. The first depth value of the existing displayed code in the editor and the second depth value of the occluded area are calculated. When the second depth value is greater than the first depth value, the pixels in the occluded area are invalid pixels; the pixels in the blank area of ​​the target texture are invalid pixels.

[0025] Invalid pixels in the fragment shader are removed, and for the remaining pixels, the source alpha blending mode is used to render the target code segment texture based on the texture screen coordinates.

[0026] Beneficial effects:

[0027] This invention pre-establishes a syntax rule set and a GPU cache feature database. Upon code editor startup, it saves the syntax style sheet, generates a font atlas, and loads the current GPU cache parameters. After the intelligent code completion candidate code segment list pops up, it divides the candidate code segments into data blocks, parses the syntax type in parallel, determines the character style, and generates candidate code segment textures through instantiation rendering and fragment shaders. Then, based on the current GPU cache parameters, the selection priority of the candidate code segment, and the compressed size, the textures are allocated to the first-level cache, second-level cache, or global video memory according to rules, and metadata is recorded and added to the global texture cache table. When the user selects a candidate code segment, the texture data is read from the corresponding GPU cache, and the display coordinates are calculated by combining the cursor row and column index, the editor's basic style parameters, and the DPI scaling ratio to complete the texture rendering. This achieves optimized display of intelligent code completion and is applicable to mainstream code editing tools such as Visual Studio Code, JetBrains IDEs, and Sublime Text. Attached Figure Description

[0028] Figure 1This is a flowchart illustrating an intelligent code completion optimization method based on texture pre-rendering and multi-level caching provided by the present invention. Detailed Implementation

[0029] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0030] This invention provides an intelligent code completion optimization method based on texture pre-rendering and multi-level caching. The core idea is as follows: By pre-establishing a syntax rule set and a GPU cache characteristic database, the syntax style sheet is saved, a font atlas is generated, and the current GPU cache parameters are loaded when the code editor starts. After the intelligent code completion candidate code segment list pops up, the candidate code segments are divided into data blocks, and the syntax type and character style are parsed in parallel. Candidate code segment textures are generated through instantiation rendering and fragment shaders. Then, based on the current GPU cache parameters, the selection priority of the candidate code segment, and the compressed size, the textures are allocated to the first-level cache, second-level cache, or global memory according to rules, and metadata is recorded and added to the global texture cache table. When the user selects a candidate code segment, the texture data is read from the corresponding GPU cache, and the display coordinates are calculated by combining the cursor row and column index, the editor's basic style parameters, and the DPI scaling ratio to complete the texture rendering and achieve optimized display of intelligent code completion.

[0031] This invention provides an intelligent code completion optimization method based on texture pre-rendering and multi-level caching, the process of which is as follows: Figure 1 As shown, the specific steps include:

[0032] Step 1: Pre-establish a set of syntax rules for different programming languages, including lexical regular expressions and priorities. Lexical regular expressions are used to identify syntax types such as keywords, operators, and comment symbols in the code, and priorities are used to mark the importance of syntax types. Construct a GPU cache feature database containing cache parameters for different GPU models. Cache parameters include cache level, single-level cache capacity, access latency, bandwidth, etc.

[0033] When the code editor starts, it saves the current style rules as a syntax style sheet indexed by syntax type and style as value. It renders all printable characters of the current font as textures to form a font atlas, where style is color and the coordinates of characters in the font atlas are represented by vertex position, width and height. It loads cache parameters from the GPU cache feature database according to the model of the GPU currently being used.

[0034] Specifically, the set of syntax rules established for the C++ language includes lexical regular expressions describing template<...> as a template marker, #define as a macro definition marker, and / ... / as a multi-line comment marker, etc.

[0035] This involves rendering all printable characters of the current font as textures to form a font atlas, including:

[0036] The printable characters of the current font are rendered as textures of a set pixel size, with each character occupying a fixed-size rectangular area. For character combinations such as ligatures, they are stored as individual supercharacters in an additional area of ​​the font atlas. A hash table is created containing the mapping relationship between characters and character combinations and coordinates in the font atlas. For characters in candidate code segments, their coordinates in the font atlas can be retrieved using the hash table.

[0037] Furthermore, to avoid the time-consuming process of repeated generation, this invention uses the RGBA8888 format natively supported by the GPU to store the font atlas in the GPU's permanent memory.

[0038] The current method for obtaining the GPU model is as follows: the GPU model is detected through a graphics interface, which can be OpenGL's glGetString(GL_RENDERER) or DirectX's ID3D11Device::GetDeviceCaps, etc.

[0039] Step 2: After the candidate code segment list for intelligent code completion pops up in the code editor and before the user selects a candidate code segment, the candidate code segment is divided into data blocks. According to the syntax rule set, the syntax type of the characters in each data block is parsed in parallel to obtain a tag array composed of the character position and its syntax type. The tag arrays of all data blocks are combined to form the character tag array of the candidate code segment. Based on the character tag array and the syntax style table, the style of each character in the candidate code segment is determined.

[0040] The vertex shader determines the height and width of the candidate code segment texture to be generated based on the number of lines of the candidate code segment and the number of characters in the longest line. Then, using the syntax type of the character and its coordinates in the font atlas as instance data, and the four vertices of the character as base vertices, it uses instantiation rendering to generate the screen coordinates of the character in the candidate code segment texture.

[0041] The fragment shader determines the character style in parallel based on the character tag array and the syntax style sheet, and then generates the pixel data of the character based on the font atlas and the character style. The pixel data of all characters constitute the candidate code segment texture.

[0042] The method for determining the texture height and width based on the number of lines N of the candidate code segment and the number of characters in the longest line M is as follows: texture height = N × line height + 2 × margin, texture width = M × character width + 2 × margin, where the margin is the width of the blank area between the characters in the texture and the edge of the texture.

[0043] Furthermore, to improve the storage efficiency of candidate code segment textures, the native GPU compression format is selected based on the editor's runtime environment. Specifically, the ASTC 4x4 format is preferred for discrete graphics cards on PCs, while the ETC2 format is used for integrated graphics cards and mobile devices. The compression process is accelerated by GPU hardware, and the compressed texture is stored in the GPU's temporary video memory area. The texture information, including width, height, compression format, and syntax style sheet, is recorded, and an index table containing the mapping relationship between the hash value of the candidate code segment and the texture information is established.

[0044] Furthermore, to ensure the rendering quality of candidate code segment textures and avoid problems such as blurriness and jagged edges in texture rendering, this invention optimizes rendering parameters for the visual requirements of programming scenarios:

[0045] Enable anisotropic filtering at levels of 4x to 8x, with the filtering level automatically adjusted based on GPU performance; enable 4xMSAA for texture edge pixels, with the sampling buffer automatically managed by the GPU; and calibrate texture colors using GPU color space conversion for different display color gamuts.

[0046] Step 3: Determine the single-level capacity of L1 cache, L2 cache and global video memory based on the cache parameters of the currently used GPU, obtain the selection priority of candidate code segments, compress candidate code segments and record the compression format, compressed data and compressed size;

[0047] When the selected priority is greater than the maximum threshold and the compressed size is not greater than the single-level capacity of the first-level cache, if the remaining capacity of the first-level cache is greater than the compressed size, the candidate code segment texture is uploaded to the first-level cache in write-through mode. Otherwise, textures that have not been accessed within a set time in the first-level cache are evicted first. If such textures do not exist, the texture with the lowest selected priority is evicted, and then the candidate code segment texture is uploaded to the first-level cache. The first texture metadata is recorded and added to the global texture cache table. The first texture metadata includes cache level, priority, texture format, last access time, and texture object.

[0048] When the selected priority is greater than or equal to the minimum threshold and less than the maximum threshold, or when the selected priority is greater than the maximum threshold and the compressed size is greater than the single-level capacity of the first-level cache, if the remaining capacity of the second-level cache is greater than the compressed size, the candidate code segment texture is uploaded to the second-level cache; otherwise, the texture with the earliest last access time and the largest time interval between the last two accesses in the second-level cache is evicted, and the candidate code segment texture is uploaded to the second-level cache; the second texture metadata is recorded and added to the global texture cache table, where the second texture metadata includes cache level, priority, texture format, timestamps of the last two accesses, last access time, and texture object;

[0049] When the selected priority is less than the minimum threshold or the compressed size is greater than the capacity threshold, if the candidate code segment texture occupancy rate in the global video memory is not greater than the threshold, the candidate code segment texture is uploaded to the global video memory; otherwise, textures with a priority less than the set threshold in the global video memory are eliminated, and then the candidate code segment texture is uploaded to the global video memory. The third texture metadata is recorded and added to the global texture cache table. The third texture metadata includes cache level, priority, texture format, creation time, last access time, and release flag.

[0050] The selection priority of candidate code segments is assigned by the code editor.

[0051] Furthermore, this invention constructs a multi-dimensional priority model to calculate the probability of a candidate code segment being selected, and uses this probability as the selection priority of the candidate code segment. The specific formula is as follows:

[0052] Priorityᵢ=(0.3×P h + 0.3×P_c + 0.2×P_p + 0.1×P_l + 0.1×P_t) ×100

[0053] Where Priorityᵢ is the priority score of candidate code segment i, and its value ranges from [0, 100]; P h P_c is the historical selection probability, P_p is the context matching degree, P_l is the candidate popularity, P_l is the code length factor, and P_t is the type factor.

[0054] Step 4: Record the candidate code segment selected by the user as the target code segment, and read the texture data of the target code segment from the GPU cache level corresponding to the target code segment as the target code segment texture, including texture width and height, compression format, etc.

[0055] The cursor's row and column index in the code is obtained through the editor API. Based on the editor's basic style parameters, including line height and character width, the cursor's pixel position in the screen coordinate system is calculated. The texture screen coordinates of the target code segment's texture display area are then calculated based on the cursor's pixel position.

[0056] The DPI scaling ratio of the editor window is obtained through the operating system interface. The texture screen coordinates are modified according to the DPI scaling ratio. The texture screen coordinates are set to integer pixels and matched with the line alignment requirements of the GPU memory. The fragment shader completes the rendering and drawing of the target code segment texture according to the texture screen coordinates.

[0057] Specifically, the texture screen coordinates of the target code segment's texture display area are calculated based on the cursor's pixel position. The method is as follows: if the number of lines of code in the target code segment is less than a threshold, the screen coordinates of the top-left vertex of the texture display area are calculated. The horizontal coordinate is the same as the horizontal coordinate of the cursor's pixel position. The calculation method for the vertical coordinate Y_display is as follows:

[0058] Y_display = Math.floor(Y_cursor / row height) × row height

[0059] Here, Math.floor() is the floor function, and Y_cursor is the vertical coordinate of the cursor's pixel position;

[0060] If the number of lines of code contained in the target code segment is not less than the threshold, the screen coordinates of the top left vertex of the texture display area are calculated in the above manner, while the screen coordinates of the bottom right vertex of the texture display area are also calculated. Its horizontal coordinate is the sum of the horizontal coordinate of the top left vertex screen coordinate and the width of the target code segment texture, and its vertical coordinate is the sum of the vertical coordinate of the top left vertex screen coordinate and the height of the target code segment texture. Subsequent blank lines are covered without obscuring the existing code.

[0061] To further reduce GPU load, this invention reduces unnecessary rendering computations based on the hardware characteristics of the GPU rendering pipeline before the fragment shader completes the rendering of the target code segment texture according to the texture screen coordinates. The specific process is as follows:

[0062] Obtain the area in the target code segment texture that is occluded by existing code and record it as the occluded area. Calculate the first depth value of the currently displayed code in the editor and the second depth value of the occluded area. When the second depth value is greater than the first depth value, the pixels in the occluded area are invalid pixels. Obtain the blank area in the target code segment texture. The pixels in the blank area are invalid pixels.

[0063] Invalid pixels in the fragment shader are removed, and for the remaining pixels, the source alpha blending mode is used to render the target code segment texture based on the texture screen coordinates.

[0064] Furthermore, when a user selects multiple related target code segments simultaneously, the textures of these multiple target code segments are merged into a single draw call to reduce GPU drawing state switching. In addition, a GPU state cache is used to store the drawing state, allowing for direct reuse of the drawing state during repeated drawing, avoiding the time-consuming process of repetitive configuration.

[0065] To ensure that GPU rendering latency does not exceed a threshold, this invention proposes a method for measuring latency and dynamically adjusting rendering parameters based on latency data, specifically:

[0066] Define the time T1 when the user triggers the selection event, the time T2 when the GPU starts reading the texture data, and the time T3 when the texture is fully displayed on the screen. The total latency is the difference between T3 and T1. Calculate the total latency at set intervals and record the distribution of the total latency.

[0067] When the total latency in a single rendering exceeds the threshold, rendering degradation is triggered, such as reducing the anti-aliasing level. The degradation measures only last for the current rendering, and subsequent renderings will automatically restore the original parameters.

[0068] When the total latency exceeds the threshold for more than a certain number of times, the rendering parameters adapted to the current GPU state are regenerated.

[0069] Step 5: When the editor configuration or code context changes, mark invalid candidate code segment textures and reclaim video memory; dynamically adjust pre-rendering based on the editor's idle state and user behavior predictions.

[0070] The method for marking invalid candidate code segment textures is as follows:

[0071] When a user modifies the editor theme, causing a change in syntax highlighting colors; when a user modifies the font type or font size, causing the font size and mapping relationship to become invalid; when the programming language of the current file in the editor changes, causing the syntax rules and style mapping to become invalid, all generated candidate code segment textures will be marked as invalid in the above situations.

[0072] When the user continues to type, causing the completion candidate list to refresh, candidate code snippet textures that do not appear in the new list are marked as invalid.

[0073] The method for reclaiming video memory after marking as invalid is as follows: when the GPU is idle, all textures marked as invalid are released through the GPU's batch deletion interface, and then the GPU's memory defragmentation interface is called to merge the scattered video memory space.

[0074] Specifically, the pre-rendering is dynamically adjusted based on the editor's idle state and user behavior predictions, as follows:

[0075] When the editor is in an idle state, it predicts subsequent high-probability candidate code segments based on the current code context, generates textures for these candidate code segments, and saves the textures to the corresponding cache. If the user does not input any keyboard, click any mouse in the editor area, or switch files within a set time, the editor is determined to be in an idle state.

[0076] Monitor GPU memory. When the proportion of GPU memory occupied by candidate code segments exceeds a threshold, prioritize releasing low-priority textures that have not been accessed for a set time. If the GPU is still overloaded after release, pause the idle pre-rendering function until the proportion is less than the safe threshold.

[0077] Furthermore, when the editor is closed, the texture information of the high-frequency candidate code segment textures is saved to a local cache file. When the editor is restarted, the texture information in the local cache file is loaded first, and only the texture data is regenerated.

[0078] Example:

[0079] This embodiment uses an IDE as an example, employing a smart code completion optimization method based on texture pre-rendering and multi-level caching provided by this invention to achieve fast display of smart code completion. The specific process includes:

[0080] S1. GPU texture pre-generation of candidate code segments. After the smart completion candidate list pops up and before the user makes a selection, the efficient conversion from code segments to GPU textures is completed by utilizing CPU SIMD instructions and GPU parallel rendering capabilities.

[0081] S1.1 Hardware-accelerated parsing of syntax features aims to convert code text into structured data containing syntax types and style rules, providing a clear basis for GPU rendering. The specific implementation is as follows:

[0082] S1.1.1 Build a lightweight parser: Predefine LL syntax rule sets for each programming language. For example, for Python, define rules for indentation markers to spaces or tabs, statement termination markers to newline characters, and comment markers to #, etc. Handle indentation-sensitive features, such as increasing the syntax tree level by 1 for every 4 spaces increase in indentation depth. The syntax rule set is stored as lexical regular expressions and syntax precedence tables, avoiding real-time parsing of complex syntax files, with loading time not exceeding 0.1ms.

[0083] S1.1.2, SIMD Parallel Lexical Analysis: Utilizing the CPU's AVX2 / SSE4.2 instruction set (Single Instruction Multiple Data) to accelerate lexical tag generation:

[0084] The code text is divided into data blocks using either 256-bit AVX2 or 128-bit SSE4.2. For each data block, token matching is performed in parallel. SIMD comparison instructions quickly identify keywords such as `if` and `for`, operators such as `+` and `==`, comment symbols, etc., generating a token array containing character positions and syntax types, such as `[(0,KEYWORD),(2,VARIABLE),(5,COMMENT)]`. Compared to traditional serial lexical analysis, SIMD accelerates post-processing speed by 6 to 8 times, with lexical analysis of 100 lines of code taking no more than 0.3ms.

[0085] S1.1.3, Quick mapping of style rules: pre-compile a mapping table between syntax types and styles to avoid reading JSON theme configuration in real time.

[0086] When the editor starts, it stores the style rules of the current theme, such as the keyword color #FF5555, as an array of StyleTable, with the index corresponding to the syntax type and the value being the RGBA color value. After lexical analysis, it directly queries the StyleTable through the syntax type index to generate the style color for each character. The mapping time is less than 0.05ms per segment, without the need to parse nested JSON structures.

[0087] S1.2, Atlasization and Fast Mapping of Programming Fonts. For the monospace characteristics and special symbols of programming fonts, such as λ, a pre-optimized font atlas is constructed to reduce the number of character samples during GPU rendering.

[0088] S1.2.1 Generation of programming-specific font atlases.

[0089] When the editor loads for the first time, it renders all printable characters of the current font, such as Fira Code, as a 256×256 pixel texture atlas. Each character occupies a rectangular area of ​​a fixed size, such as 16×24 pixels at a font size of 14px, with a 2-pixel margin reserved to avoid character overlap. For ligature characters, such as <=, -> is mapped to atlas coordinates, such as x:200, y:100, w:32, h:24, and a hash table of character combinations and atlas coordinates is created.

[0090] S1.2.2 Fast mapping from characters to atlas coordinates. For each character in a candidate code segment, its coordinates in the atlas are queried using a hash table, such as x, y, width, and height, resulting in low query time complexity. For fixed-width fonts, the width of characters is pre-calculated; for example, the width is always 14px for a 14px font size. This avoids dynamically calculating the width offset of each character; the horizontal position of the character can be determined simply by its column number, such as the horizontal offset of the character in column 5 being 5 × 14px.

[0091] S1.3, GPU parallel rendering pipeline.

[0092] By working together with GPU vertex shaders and fragment shaders, character-to-style data is batch rendered into textures, and the core uses instantiation rendering to reduce the number of draw calls.

[0093] S1.3.1 Batch generation of vertex data.

[0094] Calculate the texture size. Based on the number of lines N of the candidate code segment and the number of characters M of the longest line, determine the texture width and height. For example, if M=30, character width 14px, and margin 2px, then the width = 30×14+4=424px; texture height, for example, if N=20, line height 21px, and margin 2px, then the height = 20×21+4=424px.

[0095] Generate an instantiated vertex cache, with each character corresponding to a quadrilateral, i.e., 4 vertices. Through instantiation rendering, only one set of basic vertices, i.e. 4 vertices, needs to be submitted, followed by N×M instance data. Each instance contains the character's coordinates in the atlas, the character's target coordinates in the texture, and the syntax type index.

[0096] Instance data is stored in GPU cache objects, avoiding frequent data transfer between CPU and GPU. The generation time of instance data for 100 lines of code is less than 0.2ms.

[0097] S1.3.2 Parallel shading with fragment shaders: A custom CodeHighlightShader fragment shader is used to achieve parallel processing of glyph sampling and style shading. The fragment shader is executed in parallel through the GPU's CUDA Cores or stream processors. The shading calculation for each pixel is completed independently, and the texture shading time for 1024×1024 pixels is less than 0.5ms.

[0098] S1.3.3 Texture compression and storage: The compression process is accelerated by GPU hardware, such as NVIDIA's texture compression unit and AMD's texture compression engine, avoiding CPU involvement. The compression time for a 1024×1024 pixel texture is less than 0.1m.

[0099] S2, Priority-based GPU multi-level cache allocation.

[0100] Based on the GPU cache hardware architecture, L1, L2 and global video memory, and the probability of candidate code segments being selected, a dynamic cache allocation mechanism is constructed to maximize texture reading speed.

[0101] S2.1 Differentiated Adaptation to GPU Cache Architectures: Different manufacturers, such as NVIDIA, AMD, or Intel, have significantly different GPU cache architectures, requiring targeted caching strategies. A GPU cache characteristic database is built, pre-collecting cache parameters for mainstream GPU models, including cache levels, single-level cache capacity, access latency, bandwidth, etc. Examples of GPU model cache parameters are shown in the table below:

[0102] Table 1. Examples of cache parameters for different GPU models.

[0103] GPU Model Cache level Single-level cache capacity Access delay bandwidth NVIDIA RTX 4090 L1 Cache 64KB / SM <10ns 1.1TB / s L2 Cache 64MB ≈30ns - Global video memory 24GB ≈100ns - AMD RX 7900 XT L1 Cache 16KB / computing unit <10ns 960GB / s L2 Cache 32MB ≈40ns - Global video memory 20GB ≈120ns - Intel Iris Xe (integrated) L1 Cache 16KB / execution unit <15ns 51.2GB / s Unified Memory (UM) 16 GB ≈60ns -

[0104] When the editor starts, it detects the GPU model through the graphics interface and loads the corresponding cache parameters from the database. The adaptation time is less than 0.05ms.

[0105] Cache access patterns are optimized. For NVIDIA GPUs, the L1 Cache is privately configured according to SM (Streaming Multiprocessor) characteristics, and high-priority textures are evenly distributed to the L1 Cache of each SM to avoid excessive load on a single SM. For AMD GPUs, the L2 Cache is globally shared, and frequently accessed textures are prioritized for storage in the L2 Cache to reduce cache access across compute units. For Intel integrated graphics cards, textures are stored in the GPU memory area accessible to the CPU to avoid latency caused by memory page migration.

[0106] S2.2 Priority Quantization Model for Candidate Code Segments

[0107] A multi-dimensional priority model is constructed to accurately predict the probability of candidate code segments being selected. The model formula and parameter definitions are as follows:

[0108] Priorityᵢ = (0.3×P h + 0.3×P_c + 0.2×P_p + 0.1×P_l + 0.1×P_t) ×100

[0109] Among them, P h Based on the user's local completion history over the past three months, the number of times candidate i was selected under the same context is divided by the total number of selections. For example, if the user selected "import numpy as np" 15 times when inputting "imp" and the total number of selections was 20, then P... h =15 / 20=0.75; If there is no historical data, the default value is P. h =0.2.

[0110] P_c compares the compatibility of candidate i with the current code using the abstract syntax tree. For example, function parameter completion matches parameter types. If the current function requires an int type parameter, and candidate i's parameter type is int, then P_c = 1.0; if it's float, then P_c = 0.6. Class inheritance completion matches parent class method overriding. If candidate i contains all parent class abstract methods, then P_c = 1.0; if one is missing, then P_c = 0.8. The value of P_c ranges from 0 to 1 and is calculated in real time by the editor's completion engine.

[0111] P_p is based on all user selection data collected by the plugin backend. It calculates the percentage of users who selected candidate i or the total percentage of users who selected the same type of candidate. For example, if the percentage of users who selected the candidate i is 90% after print() completion, then P_p = 0.9. Popularity data is updated every 24 hours, and local caching avoids frequent network requests.

[0112] P_l prioritizes long code segments with more than 30 lines. The calculation formula is P_l=1+0.1×min((number of lines - 30) / 30, 1). For example, P_l=1.0 for 30 lines of code and P_l=1.1 for 60 lines of code. For short code segments with no more than 30 lines of code, P_l=1.0 to avoid short code segments occupying too much cache.

[0113] P_t adjusts the priority based on the candidate type. For structural candidates, such as function definitions, class declarations, and framework templates, P_t is set to 1.1; for ordinary candidates, such as variable names and simple expressions, P_t is set to 1.0; for low-value candidates, such as redundant comments and empty statements, P_t is set to 0.95; the type factor is automatically determined by the syntax structure of the candidate code segment, such as those containing the keywords def or class, which are considered structural candidates.

[0114] Priority dynamic update mechanism: A sliding window with a window size equal to the last 50 completion events is used to update the priority. Each time a new completion event is added, the oldest event in the window is removed, and P is recalculated. h With P_p; when the user manually modifies the completed code, such as deleting the completed function parameters, the candidate is marked as low fit, and P_c is temporarily reduced by 0.2 to avoid repeated recommendations in the future.

[0115] S2.3 Dynamic allocation rules for multi-level caches: Based on priority scores and GPU cache characteristics, textures are allocated to the corresponding cache levels. The allocation logic and management strategy for each level are as follows:

[0116] The L1 Cache is the fastest cache. Allocation is based on a selection priority of at least 90 and a texture size after compression that does not exceed the capacity of a single L1 Cache (e.g., no more than 64KB for NVIDIA GPUs and no more than 16KB for AMD GPUs). It uses a write-through mode to write texture data directly to the L1 Cache.

[0117] Because the L1 Cache has limited capacity, when a new texture needs to be allocated but the capacity is insufficient, textures that have not been accessed in the last 72 hours are prioritized for eviction. If all textures have been accessed, the texture with the lowest priority is evicted. This is suitable for short code candidates that are frequently selected, such as print() and import os, with a read latency of no more than 10ns and the fastest access speed.

[0118] The secondary cache, L2 Cache, is medium-speed. The allocation conditions are as follows: either 70 ≤ Priorityᵢ < 90 regardless of the texture size; or Priorityᵢ ≥ 80 but the texture volume is greater than the capacity of the single-level L1 Cache, such as long code segment textures. It adopts the Write-Back mode, which synchronizes to the global video memory only when the texture is replaced, reducing data transfer, and can be implemented using WebGL. The LRU-2 algorithm is implemented, recording the timestamps t1 and t2 of the last two accesses of each texture, where t1 < t2. When eliminating, select the texture with the earliest t2 and the largest t2 - t1, that is, the texture that has not been frequently accessed for a long time. Compared with the traditional LRU algorithm, the cache hit rate of LRU-2 is increased by 15% to 20%. It is applicable to candidate scenarios with medium to high frequency selections, such as the for i in range () try-except structure, and the read latency is about 30 to 40 ns, balancing speed and capacity.

[0119] The tertiary cache, global video memory, is low-speed. The allocation conditions are Priorityᵢ < 70, or the texture volume is greater than 10% of the total capacity of the L2 Cache. The storage mechanism enables GPU-native lossless compression, such as NVIDIA's BC4 format and AMD's ATI1N format, with a compression ratio of 1:4. The volume of a single 100-line code texture after compression is no more than 50 KB. The elimination strategy is implemented using a dual mechanism of timeout elimination and capacity threshold. For timeout elimination, if a texture has not been accessed for 72 hours, it is marked as releasable and the video memory is released when the GPU is idle. For the capacity threshold, when the occupancy rate of the filled textures in the global video memory is not less than 20%, textures with Priorityᵢ < 50 are preferentially eliminated. The applicable scenarios are candidates for low-frequency selections, such as import statements of冷门 libraries and code templates for special scenarios, and the read latency is about 100 to 120 ns, with the largest capacity.

[0120] S2.4. Intelligent migration mechanism for cache levels. When the priority of the candidate code segment changes or the access frequency increases, the texture is automatically migrated from the lower-level cache to the higher-level cache without blocking the UI thread. The specific implementation is as follows:

[0121] S2.4.1. Set the migration trigger conditions, including:

[0122] Priority jump: Priorityᵢ rises from less than 70 to not less than 70, or from less than 90 to not less than 90;

[0123] High-frequency access: If a texture is accessed no less than 3 times within 10 seconds, it is determined as a recent high-frequency requirement;

[0124] Hardware switch: When the user externally connects an independent graphics card, such as a laptop switching from an integrated graphics card to an NVIDIA dedicated graphics card, the cache capacity is re-evaluated and the migration is triggered.

[0125] S2.4.2 Migration Process.

[0126] Pre-migration preparation: Create a texture copy of the target cache in a background thread and completely copy the original texture data to the target cache, such as migrating from global memory to L2 cache;

[0127] Data verification: Verify that the copy data is consistent with the original data through GPU texture integrity check interfaces, such as OpenGL's glGetTexParameteriv;

[0128] Address update: Modify the texture cache address in the index table of candidate hash values ​​to the target cache copy;

[0129] Release original cache: After a 1-second delay, and ensuring that there are no ongoing read operations, release the texture data in the original cache.

[0130] S2.4.3, Migration Frequency Control.

[0131] Limit the maximum number of migrations per second to less than 5 to avoid frequent migrations consuming too much PCIe bus bandwidth. For example, if the PCIe 4.0 bandwidth is 8GB / s, a single migration of 100KB of data takes about 0.1ms, and 5 migrations per second only consume 0.5% of the bandwidth. When the GPU load is not less than 80%, if games and rendering software are running at the same time, pause non-critical migrations, such as migrating from L2 Cache to L1 Cache, and prioritize core rendering tasks.

[0132] GPU hardware architecture differentiation strategy: Build a cache feature database to adapt to different cache parameters of NVIDIA, AMD and Intel, avoid performance waste caused by one-size-fits-all cache allocation, and reduce the read latency of high-priority textures by 60%; LRU-2 eviction algorithm and dual cache migration: Compared with traditional LRU, the cache hit rate is improved by 15% to 20%, and dual cache migration ensures data consistency with no perceptible latency during the migration process; Multi-dimensional priority model: Introduce length factor and type factor to accurately identify high-demand scenarios such as long code and structural candidates, and improve priority prediction accuracy by 25%.

[0133] S3. Quick blending and display of selected textures. After the user selects a candidate code segment, the texture is directly read from the GPU cache and blended into the editor's current display area, ensuring that it is displayed immediately upon selection.

[0134] S3.1 Precise calculation and hardware alignment of display coordinates. Based on the editor cursor position and texture size, the display coordinates of the texture are calculated to ensure seamless integration with the original code.

[0135] S3.1.1, Cursor position and texture coordinate mapping.

[0136] Get the pixel position (X_cursor, Y_cursor) of the editor cursor in the screen coordinate system. For example, if the cursor is located in the 5th row and 10th column, the editor row height is 21px and the character width is 14px, then X_cursor=10×14=140px, Y_cursor=5×21=105px.

[0137] Calculate the coordinates of the top-left corner of the texture display area, including:

[0138] The horizontal coordinate (X_display) = X_cursor, which is horizontally aligned with the cursor to avoid indentation misalignment;

[0139] Vertical coordinate (Y_display) = Math.floor(Y_cursor / line height) × line height, aligned with the editor's line height, ensuring the top of the texture is aligned with the top of the line where the cursor is located;

[0140] If the candidate code segment contains 20 lines, the coordinates of the lower right corner of the texture display area are (X_display + texture width, Y_display + texture height), covering subsequent blank lines without obscuring the original code.

[0141] S3.1.2, Adaptive scaling for high DPI screens.

[0142] Obtain the DPI scaling ratio of the editor window, such as 100%, 125%, or 200%, using GetDpiForWindow in Windows or [NSScreenmainScreen].backingScaleFactor in macOS. Adjust the texture display coordinates and size according to the scaling ratio. For example, at 200% scaling, X_display = 140px × 2 = 280px, and texture width = 424px × 2 = 848px. Utilize the GPU's viewport transformation capabilities, such as OpenGL's glViewport and DirectX's RSSetViewports, to achieve hardware-level scaling, avoiding latency caused by CPU calculations. The scaling time is no more than 0.05ms.

[0143] S3.1.3, pixel-level alignment guarantee.

[0144] Force texture display coordinates to be integer pixels. For example, if X_display=140.5px is calculated, it will be automatically rounded to 140px to avoid texture blurring caused by subpixel offset. Enable the GPU's pixel alignment function, such as WebGL's glPixelStorei(GL_UNPACK_ALIGNMENT,1), to ensure that each row of pixels in the texture data matches the row alignment requirements of the GPU memory and avoid data offset during reading.

[0145] S3.2 Rendering Pipeline Trimming and Load Optimization. By leveraging the hardware characteristics of the GPU rendering pipeline, unnecessary rendering calculations are reduced, thereby lowering the GPU load.

[0146] S3.2.1, Pre-test depth.

[0147] Before the fragment shader is executed, the depth test function is enabled, and the depth function is set to less than or equal to (GL_LESS_EQUAL). For areas in the texture that are occluded by existing code, such as when the texture covers an existing line of code, the GPU determines in advance that the depth value of the area is greater than the depth value of the original code, and directly discards the fragment shading calculation for that area, reducing invalid pixel processing by 30% to 50%. The depth buffer uses the 16-bit depth format GL_DEPTH_COMPONENT16 to balance precision and memory usage.

[0148] S3.2.2, Alpha Testing and Hybrid Strategies.

[0149] For blank areas in the texture, i.e., pixels with Alpha < 0.1, such as margins outside the code segment, Alpha testing is enabled, and the pixels are discarded directly without further blending calculations. For valid pixels, i.e., pixels with Alpha ≥ 0.1, the source Alpha blending mode glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA) is used to ensure that the texture and the original code colors blend naturally, such as keeping the annotation color consistent after being superimposed with the original annotation color. The blending calculation is accelerated by the GPU's blending unit hardware, avoiding CPU involvement, and the blending time is no more than 0.1ms.

[0150] S3.2.3 Optimization of drawing call.

[0151] A batch drawing strategy is adopted: if the user selects multiple associated candidates at the same time, such as function definitions and call examples, multiple textures are merged into a single drawing call, reducing GPU drawing state switching, such as texture binding and shader switching; drawing states, such as texture addresses, blending modes, and depth test configurations, are stored through the GPU's state cache and can be reused directly when drawing repeatedly, avoiding the time-consuming process of repeated configuration.

[0152] S3.3 Quantitative control and degradation strategy for rendering latency. Establish a hard real-time constraint, with a total latency of ≤8ms, and ensure that the latency meets the target through real-time monitoring and dynamic degradation.

[0153] S3.3.1 Delay monitoring indicators and measurements.

[0154] Define three key timestamps:

[0155] T1: The time when the user triggers the selection event, such as the moment the mouse clicks on the candidate list; T2: The time when the GPU starts reading the texture data, obtained through the drawing start callback of the graphics interface; T3: The time when the texture is fully displayed on the screen, obtained through the screen refresh completion event of the operating system; The total latency is T3-T1, and the total latency is required to be no more than 8ms, that is, a latency threshold that is imperceptible to the human eye.

[0156] A delay report is generated every 10 selected events, recording the delay distribution, such as minimum delay of 3ms, average delay of 5ms, and maximum delay of 7ms.

[0157] S3.3.2 Degradation strategy when delay exceeds limit.

[0158] When a single delay exceeds 8ms, the following degradation measures will be automatically triggered and executed according to priority:

[0159] Reduce the anti-aliasing level: from 4xMSAA to 2xMSAA, or turn off MSAA;

[0160] Reduce the anisotropic filtering level: from 8x to 4x, or turn off anisotropic filtering;

[0161] Temporarily disable texture compression for this rendering only to reduce compression and decompression time;

[0162] The downgrade measures will only last for this rendering, and subsequent renderings will automatically restore the original configuration to avoid long-term impact on visual quality.

[0163] If the delay is greater than 8ms for three consecutive times, hardware adaptation will be re-evaluated, and rendering parameters more suitable for the current GPU will be selected. For example, MSAA will be turned off by default for integrated graphics cards.

[0164] Hard real-time latency control: By using depth testing to crop invalid pixels and hardware-level DPI scaling, combined with latency monitoring and degradation strategies, it ensures that 99% of selected events meet imperceptible latency, significantly improving the user experience; Pixel-level alignment and alpha optimization: Forced coordinate integerization and alpha testing eliminate texture blur and invalid blending calculations, reducing GPU load by 30% to 50%; Batch drawing and state caching: Reduce drawing calls and state switching, reducing the drawing time of a single multi-texture fusion to less than 0.5ms.

[0165] S4. Full lifecycle management of textures and caches. To cope with dynamic scenarios such as changes in editor configuration and updates to the candidate list, a full lifecycle management mechanism for textures and caches is established to ensure system stability and efficient resource utilization.

[0166] S4.1 Texture validity detection and batch recycling: When editor configuration or code context changes, invalid textures are marked and video memory is recycled in a timely manner. Specific implementation details are as follows:

[0167] S4.1.1 Texture failure trigger event.

[0168] Theme switching event: When a user changes the editor theme, such as switching from Monokai to Solarized, the syntax highlighting color changes, and all generated texture styles become invalid.

[0169] Font configuration changes: When users modify the font type, such as switching from Fira Code to Consolas, or the font size, such as adjusting it from 14px to 16px, the font size and mapping relationship will become invalid.

[0170] Programming language switching: Changing the programming language of the current file in the editor, such as switching from Python to Java, causes syntax rules and style mapping to fail.

[0171] Candidate list update: As the user continues to input, such as from pr to pri, the candidate list is updated and the textures corresponding to invalid candidates that did not appear in the new list are invalidated.

[0172] S4.1.2, Failure Texture Marking and Recycling Process.

[0173] Batch marking: After listening to the above events, traverse the index table of candidate hash values ​​to texture information and mark all textures that meet the failure conditions, such as marking all textures as failure when switching themes;

[0174] Idle GPU Reclamation: Reclamation is performed only when the GPU is idle, such as when the editor's frame rate is greater than 60fps and there are no other drawing tasks, to avoid affecting the current editing experience;

[0175] Batch release: Release all invalid textures at once through the GPU's batch deletion interface, such as OpenGL's glDeleteTextures and DirectX's ID3D11Device::DeleteTextures, reducing the number of API calls;

[0176] Memory defragmentation: After the recycling is completed, the GPU's memory defragmentation interface, such as NVIDIA's cudaMemTrimToSize, is called to merge the scattered video memory space and control the fragmentation rate to within 5%.

[0177] S4.2 Dynamic scheduling of pre-rendered resources: Based on the editor's idle state and user behavior prediction, the allocation of pre-rendered resources is dynamically adjusted to balance performance and resource consumption.

[0178] S4.2.1, Pre-rendering strategy during idle time:

[0179] Define the editor's idle state as follows: if the user does not input any keyboard data, click any mouse in the editor area, or perform any file switching operations within 3 seconds;

[0180] When idle, predict the next batch of high-probability candidates based on the current code context. For example, after inputting "def", predict the next batch of candidates as "def function_name():def init(self):", generate textures in advance and allocate them to the cache.

[0181] The number of pre-rendered items is limited to 5 to 10 to avoid consuming too much video memory, and only candidates with Priority ≥ 70 are pre-rendered to ensure the utilization of pre-rendered resources.

[0182] S4.2.2, Memory overload protection mechanism:

[0183] Real-time monitoring of GPU memory usage: Obtain total and used video memory through graphics interfaces such as NVIDIA's nvmlDeviceGetMemoryInfo and AMD's amdgpu_query_memory_info;

[0184] When the video memory used for completing the texture is ≥10% of the total GPU video memory, or ≥5% of the unified memory of the integrated graphics card, overload protection is triggered:

[0185] Prioritize releasing low-priority textures that have not been accessed within 72 hours (Priorityᵢ<50);

[0186] If the load remains excessive after release, pause the idle pre-rendering function until the video memory usage drops to a safe threshold, which is no more than 8%.

[0187] Overload protection does not affect the texture currently in use, such as the candidate texture that the user just selected, ensuring that the editing experience is not affected.

[0188] S4.2.3, Cross-session resource reuse:

[0189] When the editor is closed, the high-frequency candidate texture information with Priorityᵢ≥80, such as the syntax type mapping table and atlas coordinates, is stored in a local cache file in JSON format.

[0190] When the editor is launched again, it will prioritize loading the locally cached texture information and only regenerate the texture data. There is no need to re-parse the syntax and build the atlas. The time taken to generate the texture for the first completion after the startup is reduced by 50%.

[0191] Multi-event triggered failure detection: Covers theme, font, and language switching scenarios, batches and recycles failed textures, keeps fragmentation rate below 5%, and improves VRAM utilization by 40%; Idle pre-rendering and overload protection: Utilizes idle time to pre-generate high-frequency candidates while avoiding VRAM overload, and improves the first completion speed after editor startup by 50%; Cross-session resource reuse: Locally caches high-frequency texture information, reduces redundant calculations after restart, and improves plugin cold start performance by 30%.

[0192] The experiments yielded the following results: A significantly improved user experience, achieving seamless, instant display upon selection, eliminating the waiting time for programmers after selecting autocomplete candidates, especially when writing long code snippets such as function definitions and class declarations, improving coding fluency by over 90%; optimized system performance, shifting code segment rendering tasks from the CPU to the GPU background, reducing editor UI thread CPU usage by 30% to 50%, avoiding editor lag caused by autocomplete rendering; reduced data transfer between the CPU and GPU, lowering PCIe bus load by 99%; strong compatibility and scalability, adapting to mainstream IDEs, including VS Code, IntelliJ IDEA, and Sublime Text, requiring only adjustments to the graphics interface adaptation layer; support for 20+ programming languages ​​such as C++, Python, and JavaScript, with adaptation to new languages ​​achieved by extending the syntax highlighting rules of GLSL shaders.

[0193] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for intelligent code completion optimization based on texture pre-rendering and multi-level caching, characterized in that, Specifically, the following steps are included: Establish a set of syntax rules and a GPU cache feature database; when the editor starts, it creates a syntax style sheet with syntax type as index and style as value, renders the printable characters of the font as textures to form a font atlas, and loads cache parameters from the GPU cache feature database according to the current GPU. After intelligent code completion displays a list of candidate code segments, the candidate code segments are divided into data blocks. The syntax type of the characters in each data block is parsed in parallel according to the syntax rule set to obtain a character tag array. Based on the character tag array and the syntax style table, the style of the characters in the candidate code segments is determined. The vertex shader determines the height and width of the candidate code segment texture to be generated based on the number of lines and the number of characters in the longest line of the candidate code segment. Using the character's syntax type and its coordinates in the font atlas as instance data, the screen coordinates of the character in the candidate code segment texture are generated. The fragment shader generates the pixel data of the character based on the font atlas and the character's style. The pixel data of all characters constitutes the candidate code segment texture. Get the selection priority of the candidate code segment and compress the candidate code segment. If the selection priority is greater than the maximum threshold and the compressed size is not greater than the single-level capacity of the first-level cache, it is uploaded to the first-level cache. If the selection priority is greater than or equal to the minimum threshold and less than the maximum threshold, it is uploaded to the second-level cache. If the selection priority is less than the minimum threshold, it is uploaded to the global video memory. After the user selects a candidate code segment, the target texture is read from the corresponding cache, the cursor pixel position is calculated, the texture screen coordinates of the target texture are determined, the texture screen coordinates are modified according to the DPI scaling ratio, and the fragment shader completes the rendering of the target texture based on the texture screen coordinates.

2. The intelligent code completion optimization method according to claim 1, characterized in that, The method of rendering the printable characters of a font into a texture to form a font atlas is as follows: the printable characters of the current font are rendered into a texture of a set size of pixels, occupying a rectangular area of ​​a fixed size; for character combinations, they are stored as a single super character in an additional area of ​​the font atlas; and a hash table containing the mapping relationship between characters and character combinations and the coordinates of the font atlas is established.

3. The intelligent code completion optimization method according to claim 1, characterized in that, When the selected priority is greater than the maximum threshold and the compressed size is not greater than the single-level capacity of the first-level cache, if the remaining capacity of the first-level cache is greater than the compressed size, the candidate code segment texture is uploaded to the first-level cache; otherwise, textures that have not been accessed within a set time in the first-level cache are first evicted. If such textures do not exist, the texture with the lowest selected priority is evicted, and then the candidate code segment texture is uploaded to the first-level cache. The first texture metadata is recorded and added to the global texture cache table. The first texture metadata includes the cache level, selection priority, texture format, last access time, and texture object.

4. The intelligent code completion optimization method according to claim 1, characterized in that, When the selected priority is greater than or equal to the minimum threshold and less than the maximum threshold, or when the selected priority is greater than the maximum threshold and the compressed size is greater than the single-level capacity of the first-level cache, if the remaining capacity of the second-level cache is greater than the compressed size, the candidate code segment texture is uploaded to the second-level cache; otherwise, the texture with the earliest last access time and the largest time interval between the last two accesses in the second-level cache is evicted, and the candidate code segment texture is uploaded to the second-level cache; the second texture metadata is recorded and added to the global texture cache table, where the second texture metadata includes cache level, selected priority, texture format, timestamps of the last two accesses, last access time, and texture object.

5. The intelligent code completion optimization method according to claim 1, characterized in that, When the selected priority is less than the minimum threshold or the compressed size is greater than the capacity threshold, if the candidate code segment texture occupancy rate in the global video memory is not greater than the threshold, the candidate code segment texture is uploaded to the global video memory; otherwise, textures with a priority less than the set threshold in the global video memory are eliminated, and then the candidate code segment texture is uploaded to the global video memory. The third texture metadata is recorded and added to the global texture cache table. The third texture metadata includes cache level, selected priority, texture format, creation time, last access time, and release flag.

6. The intelligent code completion optimization method according to any one of claims 1-5, characterized in that, The selection priority of candidate code segments is assigned by the editor.

7. The intelligent code completion optimization method according to any one of claims 1-5, characterized in that, The selection priority of candidate code segments is calculated using the following formula: Priorityᵢ=(0.3×P h + 0.3×P_c + 0.2×P_p + 0.1×P_l + 0.1×P_t) × 100 Where Priorityᵢ is the priority score of candidate code segment i, and its value ranges from [0, 100]; P h P_c is the historical selection probability, P_p is the context matching degree, P_l is the candidate popularity, P_l is the code length factor, and P_t is the type factor.

8. The intelligent code completion optimization method according to claim 1, characterized in that, If the number of lines of code selected by the user in the candidate code segment is less than the threshold, the method for determining the screen coordinates of the target texture after calculating the cursor pixel position is as follows: Calculate the screen coordinates of the top left vertex of the texture display area. The horizontal coordinate is the same as the horizontal coordinate of the cursor pixel position. The calculation method for the vertical coordinate Y_display is as follows: Y_display= Math.floor (Y_cursor / h) × h In this function, Math.floor() is the floor function, Y_cursor is the vertical coordinate of the cursor's pixel position, and h is the height of the code line.

9. The intelligent code completion optimization method according to claim 8, characterized in that, If the number of lines of code selected by the user in the candidate code segment is not less than the threshold, the method for determining the screen coordinates of the target texture after calculating the cursor pixel position is as follows: calculate the screen coordinates of the top left vertex of the texture display area, and add the calculation of the screen coordinates of the bottom right vertex. The horizontal coordinate of the bottom right vertex screen coordinate is the sum of the horizontal coordinate of the top left vertex screen coordinate and the width of the target code segment texture, and the vertical coordinate is the sum of the vertical coordinate of the top left vertex screen coordinate and the height of the target code segment texture.

10. The intelligent code completion optimization method according to claim 1, characterized in that, The fragment shader renders the target texture based on the texture screen coordinates in the following way: The area in the target texture that is occluded by existing code is recorded as the occluded area. The first depth value of the existing display code in the editor and the second depth value of the occluded area are calculated. When the second depth value is greater than the first depth value, the pixels in the occluded area are invalid pixels. Pixels in the blank area of ​​the target texture are invalid pixels. Invalid pixels in the fragment shader are removed, and for the remaining pixels, the source alpha blending mode is used to render the target code segment texture based on the texture screen coordinates.

Images