A cross-runtime environment CPU high-performance rendering method based on instruction level acceleration

Abstract

The application discloses a cross-environment CPU high-performance rendering method based on instruction-level acceleration, and a shared physical memory pool of a non-cache device memory type is created by a host memory management service in a Hongmeng host and an Android container environment and is mapped to the user states of both parties, and a lock-free buffer queue based on ARM atomic instructions is established; after drawing instructions are generated by an Android application, the container first optimizes the drawing instructions, allocates size and calculates power according to complexity, then the rendering engine completes accelerated rendering of a layer by means of NEON vector operation, determines the layer Z-order by means of an ARM bit inversion instruction, separates and mixes only RGB color planes, generates frame metadata after synthesizing and optimizing frame data, writes the frame metadata and a queue marked as ready into the shared memory pool; the host Hongmeng display service acquires an effective area by atomic loading, transfers frame data to a display controller by means of a linked list mode DMA channel after converting a data format, and notifies the CPU of completion of on-screen display after the transmission is completed.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a high-performance rendering method for CPUs across runtime environments based on instruction-level acceleration. Background Technology

[0002] When running Android applications in containers within the OpenHarmony system, GPU hardware-accelerated rendering faces challenges such as complex GPU model adaptation (requiring compatibility with multiple GPU series like Mali and Adreno) and cross-system resource conflicts (due to time-consuming GPU context switching). Therefore, CPU rendering has become a significant alternative. However, existing CPU rendering solutions suffer from the following significant performance bottlenecks: First, the characteristics of the ARM architecture are not fully utilized. Android's native rendering engines (such as Skia) limit their application of the ARM NEON vector instruction set to basic pixel copying, failing to design dedicated instruction sequences for complex graphics (such as vector path clipping and Gaussian blur), and not adapting to the heterogeneous core scheduling characteristics of the ARM big.LITTLE architecture. High-complexity rendering tasks may be assigned to smaller cores, leading to inefficiency. Second, cross-container data transfer is inefficient. Frame data from Android rendering needs to be transferred to OpenHarmony via a container isolation layer (such as LXC's namespace isolation). Current methods rely on multiple rounds of memory copying from user space to kernel space and then to OpenHarmony user space, consuming significant amounts of ARM memory. The CPU bandwidth is limited, and the ARM Cache Coherence Extension (CCE) is not utilized, which can easily lead to screen tearing due to cache inconsistency. Thirdly, the format conversion and screen display latency are high. The RGBA8888 format output by the Android CPU rendering differs from the YUV420 or ARGB format supported by the OpenHarmony display service, requiring CPU time for conversion (conversion of a single frame in 1080P takes about 15ms). The screen display process relies on software to drive the display controller and does not utilize the hardware transmission capability of the ARM DMA controller, resulting in end-to-end latency often exceeding 80ms, which cannot meet the smoothness requirements of video, games and other scenarios. Summary of the Invention

[0003] In view of this, the present invention provides a high-performance CPU rendering method for cross-runtime environments based on instruction-level acceleration. By deeply optimizing the Android CPU rendering link, cross-container data interaction mechanism and HarmonyOS display pipeline, a method is achieved to display the CPU-rendered graphics of Android applications in containers on the HarmonyOS side with high performance.

[0004] This invention provides a high-performance cross-runtime environment CPU rendering method based on instruction-level acceleration, which specifically includes the following steps:

[0005] Using HarmonyOS as the host and Android as the container, the host memory management service creates a shared physical memory pool, which is of type non-cached device memory. This pool is mapped to the user space of the container and the host, and a lock-free buffer queue managed by ARM atomic instructions is created.

[0006] Android applications generate drawing instructions. The container optimizes the drawing instructions according to their type, and then evaluates the complexity of the drawing instructions based on their computational cost and the number of pixels they cover. Instructions with a complexity greater than a threshold are marked with a large kernel affinity, while those with a complexity less than the threshold are marked with a small kernel affinity, and the instructions are bound to the corresponding kernel.

[0007] The container rendering engine uses NEON vector operations to calculate the alpha blending of drawing instructions in parallel. It determines whether pixels are within the path in parallel for path drawing instructions, performs multi-pixel RGB interpolation synchronously for linear gradient fill, and performs multi-pixel Gaussian blur in parallel for shadow blur, thereby accelerating the rendering of all layers. The obtained pixel data is written to a shared physical memory pool. The ARM bit inversion instruction is used to determine the Z-order of layers, and the NEON instruction is used to separate the RGB and alpha planes of transparent layers, blending only the RGB plane. After compositing, frame data in the first optimized pixel format is generated, and a hash value is generated, with the inter-frame change area as the valid area. The frame sequence number, timestamp, valid area, hash value, and format tag are combined to form metadata. The frame data and metadata are written to the shared physical memory pool, and the lock-free buffer queue is marked as ready.

[0008] The host HarmonyOS display service obtains the ready-state valid area by atomically loading LDXR, loads the encoded data and Alpha plane data and converts the format, and marks its status as displayable; sets the direct memory access DMA channel to linked list mode, transfers frame data from the shared physical memory pool to the display controller frame buffer, and sends a notification to the CPU after the transfer is completed, triggering the display service to complete the screen display and synchronously updating the frame status to displayable.

[0009] Furthermore, the method by which the container optimizes drawing instructions based on type is as follows:

[0010] When the drawing instruction is a path drawing instruction, the third-order Bézier curve is decomposed into multiple straight line segments for approximation, the coordinates of the straight line segments are loaded in parallel, the fixed weight matrix of the pixel block is pre-calculated, and the weights are applied in parallel in the edge region of the path to complete the anti-aliasing transparency calculation; when the drawing instruction is a texture drawing instruction, the texture coordinates are converted into block coordinates adapted to the ARM L2 cache line, and the pixel offset within the block is recorded to support data preloading; when the drawing instruction is a text rendering instruction, a unique identifier is generated for the glyph, and the rendered glyph is stored in the shared memory of the text rendering cache in the container to achieve reuse.

[0011] Furthermore, when the drawing instruction is a path drawing instruction, the third-order Bézier curve is decomposed into multiple straight line segments for approximation, the coordinates of the straight line segments are loaded in parallel, the fixed weight matrix of the pixel block is pre-calculated, and the weights are applied in parallel in the edge region of the path to complete the anti-aliasing transparency calculation, specifically:

[0012] The path described by the third-order Bézier curve is decomposed into 16 line segments for approximate drawing. Each line segment consists of the starting point coordinates and the ending point coordinates, corresponding to 4 consecutive single-precision floating-point numbers, forming a line segment coordinate array. The ARM NEON vector instruction vld1q_f32 is used to perform single-instruction multiple data parallel loading on the line segment coordinate array.

[0013] A pixel block of a predefined size is used. An auxiliary line passes through the pixel block in a defined manner. The distance from each pixel in the pixel block to the auxiliary line is calculated. A fixed weight matrix for the pixel block is generated in such a way that the closer the distance, the higher the weight.

[0014] The outer contour edge of the path is obtained based on the line segment coordinate array. Pixel blocks are then used to cover the edge area block by block to form a continuous local area, so that the pre-calculated fixed weight matrix matches the real edge. The final color value of each pixel in the local area is the product of the original color value and the NEON vector of the corresponding weight in the fixed weight matrix. This completes the anti-aliasing transparency calculation and achieves smooth drawing of the path edge.

[0015] Furthermore, when an Android application creates a framebuffer, it allocates contiguous physical memory, aligns the starting address of the framebuffer memory to 128 bytes, and then sets the framebuffer's memory attributes to write-back mode.

[0016] Furthermore, the method of using NEON vector operations to parallelly calculate the alpha blending of drawing instructions is as follows:

[0017] The color blending formula is converted into NEON vector operations. The source pixel color data src to be superimposed, the target pixel color data dst already existing in the frame buffer, and the alpha transparency weight data corresponding to the source pixel are loaded by the vld1q_u8 instruction. The vmulq_u8 instruction is used to perform parallel multiplication operations on the src data and alpha data, and the dst data and the inverse alpha data, respectively. Then, the vaddq_u8 instruction is used to accumulate the two sets of multiplication results in parallel, realizing the color blending calculation of multiple pixels in a single instruction.

[0018] Furthermore, the method for determining whether a pixel is within the path in parallel according to the path drawing command is as follows:

[0019] Construct a mask vector representing whether a pixel within a pixel block is located within the path. Represent the edge line of the path as a path boundary vector in NEON vector format. Use the vandq_u32 instruction to perform a bitwise AND operation on the mask vector and the path boundary vector to determine in parallel whether all pixels within the pixel block are located inside the path.

[0020] Furthermore, the first optimized pixel format is as follows: color information is represented by 16-bit RGB565 encoding, and an additional 8-bit Alpha channel is set up to store transparency data in a separate plane manner. Its resolution is consistent with that of the RGB array, and each pixel occupies 24 bits.

[0021] Furthermore, the method of determining the Z-order of layers using the ARM bit inversion instruction is as follows: the container rendering engine executes the ARM bit inversion instruction on all rendered layers to obtain the inverted bit sequence, compares the inverted bit sequences of multiple layer IDs in parallel using the vcge_u32 instruction, and determines the Z-order of the layers based on the numerical value. The larger the value, the higher the Z-order of the corresponding layer.

[0022] Furthermore, the host collects real-time time-consuming data for each stage of rendering, transmission, and preprocessing, constructing a dynamic feedback adjustment closed-loop control mechanism to adaptively adjust container rendering parameters. Rendering time is the time difference between the container starting a rendering command and the frame data being ready; transmission time is the access latency to the shared physical memory pool; and preprocessing time is the time spent converting the frame data to the NEON instruction format. The adaptive adjustment method is as follows: when the rendering time accounts for more than a first threshold of the total time spent in the entire process, the rendering thread priority is raised to the highest level; when the transmission time accounts for more than a second threshold of the total time spent in the entire process, a notification is sent to the container to reduce the effective area, transmitting only the smallest variation range in the frame data.

[0023] Furthermore, when the hardware does not support mixing, the vmulq_u8 instruction is used to perform real-time mixing of Alpha plane data and RGB565 encoded data to complete the transparency calculation and obtain the final display color with transparency effect.

[0024] Beneficial effects:

[0025] This invention uses HarmonyOS as the host and Android as the container. The host memory management service creates a shared physical memory pool and a lock-free buffer queue with contiguous, aligned, and non-cached physical addresses, and completes virtual address mapping. The container simultaneously initiates NEON optimization, core scheduling, and cache initialization, and establishes an event notification chain. After the Android application generates drawing instructions, anti-aliasing, cache friendliness, and glyph cache reuse optimizations are applied to path, texture, and text instructions. Instruction complexity evaluation is used to achieve big-little core affinity scheduling and load balancing. The container rendering engine utilizes NEON vector instructions to complete rendering calculations such as alpha blending, path determination, gradient filling, and shadow blurring, and processes the image... The layers are sorted using Z-order. For transparent layers, RGB and Alpha planes are separated and composited to generate optimized pixel format frame data and calculate hash values. Combined with frame information, metadata is written to shared memory and marked as ready. The host display service reads the frame data through atomic instructions and selectively performs Alpha channel insertion to generate ARGB8888 format based on hardware mixing capabilities to complete preprocessing. DMA is started to directly transfer the frame data to the display controller frame buffer in a linked list mode. After the transfer is completed, an interrupt is triggered. The host service configures the display hardware and completes the on-screen display under VSYNC synchronization. Finally, the container is notified to start rendering the next frame, forming a complete and efficient cross-system display process. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a high-performance CPU rendering method across runtime environments based on instruction-level acceleration, provided by the present invention. Detailed Implementation

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

[0028] This invention provides a high-performance CPU rendering method across runtime environments based on instruction-level acceleration. Its core idea is as follows: using HarmonyOS as the host and Android as the container, the host memory management service creates a shared physical memory pool and a lock-free buffer queue with contiguous, aligned, and non-cached physical addresses, and completes virtual address mapping. The container synchronously starts NEON optimization, core scheduling, and cache initialization, and establishes an event notification chain. After the Android application generates drawing instructions, anti-aliasing, cache friendliness, and glyph cache reuse optimization are performed on path, texture, and text instructions respectively. Big-little core affinity scheduling and load balancing are achieved through instruction complexity evaluation. The container rendering engine uses NEON vector instructions to complete alpha blending and path determination. The rendering process includes gradient fill and shadow blur calculations, Z-order sorting of layers, RGB and Alpha plane separation and compositing of transparent layers, generation of optimized pixel format frame data and calculation of hash values, combination of frame information to form metadata written to shared memory and marked as ready; the host display service reads frame data through atomic instructions, selectively performs Alpha channel insertion to generate ARGB8888 format based on hardware mixing capabilities to complete preprocessing; DMA is started to directly transfer frame data to the display controller frame buffer in linked list mode, an interrupt is triggered after the transfer is completed, the host service configures the display hardware and completes the on-screen display under VSYNC synchronization, and finally notifies the container to start rendering the next frame, forming a complete and efficient cross-system display process.

[0029] This invention provides a high-performance rendering method for cross-runtime environment CPUs based on instruction-level acceleration, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0030] Step 1: Using HarmonyOS as the host and Android as the container, within the HarmonyOS host, the memory management service creates a shared physical memory pool. The size of this shared physical memory pool is set to a multiple of the screen resolution, the physical addresses are contiguous and aligned to the ARM page size, and the memory type is non-cached device memory. The header area of ​​the shared physical memory pool stores frame metadata describing the basic information of the frame, which is mapped to the virtual address space of the container and the host user space. A lock-free buffer queue managed by ARM atomic instructions is created, and the queue state is stored using atomic variables. When the queue is full, a clear exclusive access instruction deletes the set frame. Within the container, NEON compositing optimization and core affinity scheduling are started, the text rendering cache is initialized, and a link is established with the host's SEV instruction trigger event notification.

[0031] The frame metadata includes frame number, timestamp, valid area, hash value and format tag. The valid area is the area where the data changes between the current frame and the adjacent data of the previous frame, and the format tag is the pixel format of the current frame.

[0032] This invention configures cross-container shared memory as ARM Device-n GnRE uncached device memory, prohibits CPU caching and instruction reordering, and ensures real-time consistency and stable reliability of cross-system data access.

[0033] Step 2: After the Android application starts, it performs drawing operations and generates drawing instructions. The instructions are optimized for different types. When the drawing instruction is a path drawing instruction, the third-order Bézier curve is broken down into multiple straight line segments for approximation. The coordinates of the straight line segments are loaded in parallel, and a fixed weight matrix for the pixel blocks is pre-calculated. Weights are applied in parallel in the edge areas of the path to complete the anti-aliasing transparency calculation. When the drawing instruction is a texture drawing instruction, the texture coordinates are converted into block coordinates adapted to the ARM L2 cache line, and the pixel offset within the block is recorded to support data preloading. When the drawing instruction is a text rendering instruction, a 32-bit unique identifier is generated for the glyph, and the rendered glyph is stored in the shared memory of the text rendering cache in the container for reuse.

[0034] An instruction complexity evaluation module is added to the Android rendering thread RenderThread. Before RenderThread executes drawing instructions, the instruction complexity evaluation module evaluates the complexity of the drawing instructions based on the instruction computation amount and the number of pixels covered. Instructions with a complexity greater than a threshold are marked with a large core affinity, and instructions with a complexity not greater than the threshold are marked with a small core affinity. Instructions are then bound to the corresponding cores for execution according to the affinity marks. At the same time, the load of large cores is periodically collected. When the load is greater than a threshold, some instructions with large core affinity marks are split and scheduled to idle small cores for execution.

[0035] RenderThread is an independent thread introduced in Android 5.0 (Lollipop) that is specifically responsible for executing GPU rendering commands. Its core function is to take over the drawing work of the main thread and improve UI smoothness through hardware acceleration.

[0036] Furthermore, when the drawing command is for path drawing, the anti-aliasing transparency is calculated as follows:

[0037] The path described by the third-order Bézier curve is decomposed into 16 line segments for approximate drawing. Each line segment consists of the starting point coordinates and the ending point coordinates, corresponding to 4 consecutive single-precision floating-point numbers, forming a line segment coordinate array. The ARM NEON vector instruction vld1q_f32 is used to perform single instruction multiple data parallel loading on the line segment coordinate array.

[0038] A pixel block of a predefined size is used. An auxiliary line passes through the pixel block in a defined manner. The distance from each pixel in the pixel block to the auxiliary line is calculated. A fixed weight matrix for the pixel block is generated in such a way that the closer the distance, the higher the weight.

[0039] The outer contour edge of the path is obtained based on the line segment coordinate array. Pixel blocks are then used to cover the edge area block by block to form a continuous local area, so that the pre-calculated fixed weight matrix matches the real edge. The final color value of each pixel in the local area is the product of the original color value and the NEON vector of the corresponding weight in the fixed weight matrix. This completes the anti-aliasing transparency calculation and achieves smooth drawing of the path edge.

[0040] Furthermore, when creating a frame buffer in an Android application, this invention allocates contiguous physical memory, aligns the starting address of the frame buffer memory to 128 bytes, and then sets the memory attribute of the frame buffer to write-back mode by configuring the ARM MAIR_EL1 register. This enables the CPU to prioritize the use of the L2 cache for reading and writing to the frame buffer, thereby reducing memory access latency and improving the efficiency of subsequent rendering and layer compositing.

[0041] Step 3: After receiving the optimized drawing instructions, the in-container rendering engine converts the color blending formula into NEON vector operations for Alpha blending in the drawing instructions. It loads the source pixel color data src to be superimposed, the target pixel color data dst already existing in the framebuffer, and the transparency weight data alpha corresponding to the source pixel through the vld1q_u8 instruction. It then performs parallel multiplication operations on the src data and alpha data, and the dst data and the inverse alpha data respectively through the vmulq_u8 instruction. Finally, it accumulates the two sets of multiplication results in parallel through the vaddq_u8 instruction, realizing the color blending calculation of multiple pixels in a single instruction.

[0042] For path drawing instructions, a mask vector is constructed to indicate whether a pixel in a pixel block is located inside the path. The edge line of the path is represented as a path boundary vector in NEON vector format. The vandq_u32 instruction is used to perform a bitwise AND operation on the mask vector and the path boundary vector, and to determine in parallel whether all pixels in a pixel block are located inside the path.

[0043] For linear gradient fill in path drawing instructions, color interpolation calculation is converted into NEON vector operation, and interpolation calculation is performed synchronously on the RGB channels of multiple pixels through the vqmovn_u16 saturation instruction;

[0044] For the shadow blur effect of the path drawing command, the vld1q_s16 command is used to load the gray values ​​of multiple pixels in parallel. Combined with the pre-calculated blur kernel vector, the vmlaq_s16 command is used to complete the parallel multiplication and addition operation to achieve multi-pixel synchronous Gaussian blur processing. After the rendering of all layers is completed, the obtained pixel data is written to the shared physical memory pool.

[0045] The fuzzy kernel vector is a set of fuzzy weights pre-calculated based on a Gaussian distribution and converted to NEON vector format, used for parallel multiplication and addition operations with the pixel grayscale value vector.

[0046] Step 4: The in-container rendering engine executes the ARM bit inversion instruction RBIT on the layer IDs of all rendered layers to obtain the inverted bit sequence. The vcge_u32 instruction is used to compare the inverted bit sequences of multiple layer IDs in parallel, determining the Z-order of the layers based on the numerical values; larger values ​​correspond to higher Z-order layers. For compositing transparent layers containing alpha channels, the NEON instruction is used to split the color and transparency data of the layer pixels into RGB color planes and alpha transparency planes, storing them separately. During compositing, only the RGB color plane is subjected to blending operations, while the alpha transparency plane is directly reused. All layers are composited to obtain frame data in the first optimized pixel format. An encryption algorithm is used to generate hash values ​​for the frame data. The area of ​​change between the frame data and the previous adjacent frame data is taken as the valid area, and the format marker is set to the first optimized pixel format. Frame metadata is composed of the frame sequence number, timestamp, valid area, hash value, and format marker of the frame data. The frame data and frame metadata are written to the shared physical memory pool, and the state in the lock-free buffer queue is marked as ready using atomic storage STXR.

[0047] The first optimized pixel format is as follows: it uses 16-bit RGB565 encoding to represent color information, and sets up an 8-bit Alpha channel to store transparency data in a separate plane manner. Its resolution is the same as that of the RGB array, and each pixel occupies 24 bits.

[0048] Furthermore, when performing layer compositing operations in an Android application, this invention optimizes the memory access mode for the ARM CPU multi-level cache structure. Specifically, it rearranges the layer data according to the Z-order hierarchy and row priority to improve cache space locality; for layers with access frequency greater than a threshold, it configures their memory pages to be stored in the L2 cache through the ARM coprocessor instruction MCR to reduce cache thrashing.

[0049] Step 5: The HarmonyOS display service within the host obtains ready-to-read frame data and frame metadata from the shared physical memory pool via atomic loading of LDXR, acquires the valid area, loads RGB565 encoded data and Alpha plane data using ARM NEON instructions, expands the 16-bit RGB565 data to a 32-bit format, and then places the Alpha channel into the corresponding pixel using vector insertion instructions to obtain the ARGB8888 format supported by the HarmonyOS display service, completing the preprocessing of the frame data and marking its status as displayable.

[0050] Furthermore, this invention integrates an ARM performance monitoring unit (PMU) into the HarmonyOS kernel to collect real-time data on the time consumption of each stage of rendering, transmission, and preprocessing. It constructs a dynamic feedback adjustment closed-loop control mechanism to adaptively adjust container rendering parameters (such as rendering resolution, rendering thread priority, etc.) to ensure load balancing across the entire cross-core display chain and guarantee smooth display.

[0051] Furthermore, when the hardware does not support mixing, the present invention uses the vmulq_u8 instruction to perform real-time mixing of Alpha plane data and RGB565 encoded data to complete the transparency calculation and obtain the final display color with transparency effect.

[0052] Specifically, rendering time is the time difference between when the container starts rendering instructions and when the frame data is ready; transmission time is the access latency of the shared physical memory pool; and preprocessing time is the time spent converting the frame data to the NEON instruction format. The adaptive adjustment method is to dynamically adjust the priority of the container rendering thread. That is, when the proportion of rendering time to the total time of the entire link exceeds the first threshold, the priority of the rendering thread is raised to the highest priority to avoid rendering tasks being preempted by other system tasks. When the proportion of transmission time to the total time of the entire link exceeds the second threshold, a notification is sent to the container to trigger an effective region reduction operation, transmitting only the smallest change range in the frame data to reduce the pressure on shared memory access.

[0053] Step 6: When the frame data is in displayable status, the host starts the ARM Direct Memory Access (DMA), initializes the DMA channel, sets the DMA transfer mode to linked list mode, and splits the frame data into multiple fixed-size transfer blocks according to the bus width of the display controller. The physical address, data length, and next block transfer address of each transfer block are linked through a linked list mode descriptor. The DMA controller automatically completes the transfer of all transfer blocks in sequence according to the descriptor, realizing the direct hardware transfer of frame data from the shared physical memory pool to the display controller frame buffer. After all frame data transfers are completed, the DMA controller sends a notification to the CPU through an IRQ interrupt, where the interrupt handler only performs the transfer status update operation.

[0054] Step 7: After receiving the notification, the HarmonyOS display service reads the DMA status register, confirms that the entire frame data has been completely written to the display controller's frame buffer, configures the display controller's layer switching and frame start address register, submits the current frame buffer address to be displayed to the display hardware pipeline, triggers the display controller to perform vertical synchronization switching, outputs the frame buffer content to the screen in the next effective scan cycle to complete the on-screen display, synchronously updates the frame status to be displayed, and notifies the container through the event channel that the next frame rendering can begin.

[0055] Example:

[0056] This embodiment employs a cross-runtime environment CPU high-performance rendering method based on instruction-level acceleration provided by the present invention. High-performance display is achieved by modifying the Android rendering engine, designing a dedicated ARM data interaction mechanism, and optimizing the OpenHarmony display pipeline. The specific process includes:

[0057] S1. ARM instruction set adaptation and optimization for Android application rendering instructions: Preprocessing of drawing instructions (such as Canvas.drawPath, drawBitmap) generated by Android applications to make the output instruction format more suitable for ARM CPU rendering, laying the foundation for subsequent ARM accelerated rendering, and is the starting point for end-to-end optimization.

[0058] S1.1 Modify the Canvas API implementation of the Android application framework layer.

[0059] A new ARM optimization mode switch has been added to Android (enabled by setting the system property ro.android.render.arm_optimize to true). When enabled, Canvas breaks down complex drawing instructions into micro-instructions suitable for ARM NEON vector calculations.

[0060] For path drawing (drawPath): the Bézier curve (third order) is decomposed into 16 straight line segments for approximation (traditionally 4 segments), and the start and end coordinates of the 16 straight lines are loaded in parallel (stored as a float32 array) using the vld1q_f32 command, replacing the segment-by-segment calculation; at the same time, for the anti-aliased edges of the path, the edge weight matrix of 8*8 pixel blocks is pre-calculated, and the weights are applied in parallel using the NEONvmulq_f32 command to reduce the time spent on edge blur calculation.

[0061] For texture drawing (drawBitmap): the texture coordinates (u,v) are converted into block coordinates (e.g., 8*8 pixel blocks) based on ARM L2 cache lines (64 bytes), and the offset of pixels within the block is recorded (0 to 63 bytes). This allows subsequent rendering to prefetch data block by block via PLD (preload) instructions (2 to 3 clock cycles in advance), increasing the L1 cache hit rate from 50% to 85%.

[0062] For text rendering (drawText): ARM's CRC32 instruction (CRC32W) is used to generate a 32-bit checksum for the font glyph data (each glyph is 32*32 pixels). The rendered glyph blocks are cached in the shared memory cache. When a checksum is hit, the glyph blocks can be reused directly without re-rasterization. Experimental data shows that this can reduce text rendering instructions by 30%.

[0063] S1.2 Implement ARM big.LITTLE core affinity tags for rendering instructions. In Android RenderThread, a new instruction complexity evaluation module is added based on the number of pixels involved in the instruction and its computational complexity.

[0064] ARM big.LITTLE core affinity flag: This refers to the flag added to rendering instructions to indicate whether the instruction is more suitable for execution on the big cores (such as Cortex-A78, high performance) or small cores (such as Cortex-A55, low power) of the ARM big.LITTLE architecture. It is stored as a 2-bit field in the instruction header, where 00 means no affinity, 01 means big core affinity, and 10 means small core affinity.

[0065] High-complexity instructions (such as multi-layered path overlays with transparency, involving instructions larger than 10,000 pixels) are marked as large-core affinity. The current core ID is obtained by reading the ARM MPIDR_EL1 register to identify the core ID of the large core, and pthread_setaffinity_np is called to bind it to the large core. Low-complexity instructions (such as solid color fills, involving instructions smaller than 1,000 pixels) are marked as small-core affinity and bound to the small core.

[0066] Meanwhile, the ARM PMU performance monitoring unit collects the load of the large core in real time (reads the PMCCNTR_EL0 counter every 10ms to calculate the instruction execution density). When the load is greater than 70%, some high-complexity instructions are split (such as splitting a 200*200 pixel block into four 100*100 blocks) and scheduled to idle small cores to avoid blocking of the large core. Experiments show that this can reduce rendering blocking time by 20%.

[0067] S1.3 Optimize the memory access mode of rendering instructions.

[0068] To address the multi-level caching characteristics of ARM CPUs (typical configuration: L1 32KB per core, L2 256KB per cluster), adjust the memory alignment of the frame buffer in Android's GraphicBuffer:

[0069] The pixel data start address is aligned to 128 bytes, that is, aligned to the optimal access granularity of ARM NEON instructions, avoiding memory alignment penalties of instructions such as vld4q_u8;

[0070] Layer data is rearranged according to Z-order and row-major order: During SurfaceFlinger compositing, the top layer is processed first, followed by the bottom layer Z-order, and each layer stores pixels in row-scan order, so that memory access conforms to the spatial locality principle of ARM CPU, allowing continuous access to adjacent pixels, and the L2 cache hit rate is improved from 60% to 90%;

[0071] For frequently accessed layers (such as button layers for user interaction), their memory pages are configured to be resident in the L2 cache (not replaced) via ARM MCR instructions to reduce cache thrashing.

[0072] The core affinity marking mechanism combines the heterogeneous core characteristics of ARM. It adds big-core or small-core affinity marks to rendering instructions through instruction complexity evaluation and links with the ARM PMU to dynamically schedule tasks. High-complexity instructions are bound to big cores and low-complexity instructions are bound to small cores. When the load exceeds the limit, the task is split. At the same time, complex drawing instructions are decomposed into NEON vector-friendly micro-instructions (such as 16 straight lines approximating Bézier curves). It realizes ARM-specific adaptation of instruction format, core scheduling and cache access from the application framework layer, laying the underlying foundation for subsequent rendering acceleration.

[0073] S2, on the Android side, is accelerated by the ARM NEON rendering engine. It receives optimized instructions and uses the Android underlying rendering library (Skia). It utilizes the ARM NEON vector instruction set to accelerate pixel calculation, which is the core link to improve CPU rendering efficiency. The output frame data format needs to be adapted to the subsequent cross-container transmission requirements.

[0074] S2.1 For the most time-consuming path rasterization and color blending modules in Skia, including:

[0075] Path rasterization: The scanline algorithm that calculates whether a pixel is in the path line by line is replaced with block parallel computation. An 8x8 pixel block mask vector (32 bits) is generated by vcreate_u32. The vandq_u32 is used to perform a bitwise AND operation with the path boundary vector to determine whether 64 pixels are in the path at once. The existing method requires 64 judgments, which improves the computation efficiency by 8 times, from 12ms per frame to 1.5ms per frame, based on 720P resolution;

[0076] Color blending: For Alpha blending (srcOver mode), the formula (dst=src*alpha+dst*(1-alpha)) is converted into NEON vector operation. The src, dst, and alpha data of 8 pixels are loaded through vld1q_u8, totaling 24 bytes. vmulq_u8 performs parallel multiplication of 8 groups of data simultaneously, and vaddq_u8 performs parallel addition. Processing 8 pixels at a time replaces the existing single-pixel processing, improving blending efficiency by 6 to 7 times.

[0077] Gradient color fill: The linear gradient color interpolation formula (color=start+(end-start)*t) is converted into NEON's saturation shift instruction vqmovn_u16, which performs interpolation calculations on the RGB channels of 16 pixels simultaneously, avoiding pixel-by-pixel floating-point operations. Due to the weak performance of ARM floating-point units, the fill speed is increased by 5 times.

[0078] Gaussian blur optimization: For the shadow blur effect of Android applications, the grayscale values ​​of 16 pixels are loaded in parallel using the NEON vld1q_s16 instruction. The vmlaq_s16 multiplication and addition operation is performed through the pre-computed blur kernel vector (such as a 5*5 kernel), reducing the blur processing time from 30ms to 5ms.

[0079] S2.2 ARM instruction-level optimization of SurfaceFlinger layer compositing, utilizing the ARM instruction set to optimize multi-layer compositing.

[0080] Layer Z-order sorting: The comparison process of fast sorting is optimized by using the ARM RBIT bit reversal instruction. After performing RBIT on the 32-bit layer ID (such as 0x12345678), the reversed bit sequence is obtained. Multiple layer IDs are compared in parallel by the vcmpeq_u32 instruction, reducing the comparison time from 2ns to 0.5ns.

[0081] Transparent layer compositing: For layers containing an alpha channel, NEON vzip_u8 and vuzp_u8 are used in conjunction with the vzip_u8 command to split the RGBA data into two planes, RGB and alpha, for separate storage. During compositing, only the RGB plane is blended, and the alpha plane is reused, which can reduce the amount of data access by 50%.

[0082] Synthesis result verification: The ARM SHA1 encryption instructions (SHA1C or SHA1P) are used to generate a 20-byte hash value for the synthesized frame data and store it in the frame header (replacing the traditional 32-bit checksum). This not only improves the verification speed (from 4ms to 0.8ms) but also provides data integrity verification for subsequent cross-container transmission, thus improving the ability to resist data tampering.

[0083] S2.3 ARM cache optimization management for frame buffers.

[0084] In Android's GraphicBufferAllocator, a frame buffering strategy based on ARM caching characteristics is designed:

[0085] When allocating contiguous physical memory, the memory attribute is configured to Normal Write-Back mode through the ARM MAIR_EL1 register (memory attribute indirect register) to ensure that the CPU writes to the frame buffer are first cached in L2, reducing the latency of direct memory writes (L2 access latency is about 3ns, memory access latency is about 60ns).

[0086] During the rendering process, after each 16*16 pixel block is rendered, the DC CVAU (clear virtual address cache) instruction is called to refresh the data of that block from L2 to memory (instead of waiting for the entire frame to be completed), avoiding the time-consuming large cache refresh at the end of a single frame rendering, and reducing the total refresh time by 40%;

[0087] For unmodified pixel blocks (such as static backgrounds), the ARM AT S1E1R address translation read instruction marks them as read-only, so that the CPU can directly hit the L2 cache when accessing them, without triggering memory read and write, reducing memory bandwidth usage by 30%.

[0088] When the frame buffer is released, the DC ISW instruction is called to clean up the internal shared cache, ensuring that the memory block can be reused by other processes without any data residue.

[0089] To address time-consuming processes such as path rasterization, color blending, and Gaussian blurring in Skia, NEON instructions are used to implement block-parallel computation (e.g., one-time rasterization of 8*8 pixel blocks and parallel alpha blending of 8 pixels). A frame buffer management strategy is designed in conjunction with ARM cache characteristics (aligned by L2 cache lines and refreshed in blocks), which improves CPU rendering efficiency by 8 times (e.g., path rasterization time is reduced from 12ms to 1.5ms), breaking through the bottleneck of traditional Skia not fully utilizing ARM vector computing power.

[0090] S3. Cross-container frame data transmission based on ARM shared memory and cache consistency: Receives output frame data and implements a low-overhead transmission of frame data from the Android container to the OpenHarmony side through a cross-container memory sharing mechanism designed specifically for the ARM architecture. This is a key link connecting Android rendering and OpenHarmony display, and data integrity and real-time performance must be ensured.

[0091] S3.1, Cross-container mapping design of ARM physical memory pool.

[0092] A shared physical memory pool that meets the following characteristics is initialized by OpenHarmony's memory management service (MMService):

[0093] The size is 3 times that of the screen resolution, and it supports triple buffering including rendering, transmission and display. For example, at 1080P (1920*1080) resolution, the data size of a single frame is 1920*1080*2 bytes (RGB565), which is 4.1MB, and the total size of the triple buffer is 12.3MB.

[0094] The physical address is contiguous and aligned to 4KB (ARM page size). The physical base address (e.g., 0x80000000) is obtained through the PHYS_OFFSET register (the physical memory start address register provided by the ARM core).

[0095] Configure the memory type as ARM Device-nGnRE (non-cache, device memory) to avoid cache interference from the OpenHarmony-side GPU (if present);

[0096] The memory pool is mapped to both the Android container user space address and the OpenHarmony side display service user space address through the container virtualization layer (such as the lxc_config_set interface of LXC). During mapping, the PROT_READ|PROT_WRITE permissions are set to ensure that both sides can directly read and write the same physical memory.

[0097] S3.2 Cross-core data consistency guarantee based on ARM cache instructions.

[0098] To address the cache inconsistency issue between the Android container and the OpenHarmony display service, a bidirectional cache synchronization mechanism is designed:

[0099] After the Android side frame rendering is completed: the DC CVAC (clean and invalidate cache to shared memory) instruction is called to traverse all L1 and L2 cache lines corresponding to the frame and refresh the data to shared physical memory; the TLBI VMALLE1 (invalidate the entire TLB) instruction is called to ensure that other cores re-go through address translation when accessing this memory and hit the latest data; a frame ready signal is sent to the OpenHarmony side, and an event notification is triggered through the ARM SEV instruction to wake up the waiting threads on the OpenHarmony side.

[0100] After receiving the signal on the OpenHarmony side: it calls the DC IVAC (invalidate buffer) instruction to discard the old data of the frame in the local L1 and L2 (to avoid reading dirty data in the buffer); it calls the AT S1E1W (address translation write operation) instruction to ensure that subsequent reads hit the latest memory data; it reads the frame hash value in the shared memory and verifies the data integrity through the ARM SHA1 instruction. If the verification fails, it requests the Android side to retransmit through the SEV instruction, with a retransmission rate of less than 0.1%.

[0101] S3.3, ARM-optimized frame data format and metadata interaction.

[0102] Define a dedicated frame format to reduce transmission volume and design a metadata area to achieve cross-system information synchronization:

[0103] The ARM-optimized RGB565 and separate Alpha format is a pixel storage format optimized for the ARM NEON instruction set. The RGB channel uses 16-bit RGB565 encoding (R5 bits, G6 bits, B5 bits), and the Alpha channel is stored separately in an 8-bit plane (with the same resolution as the RGB channel). Compared with the traditional RGBA8888 format, it reduces the amount of data by 50% (from 8.3MB to 4.1MB for a single 1080P frame) and facilitates parallel processing of NEON instructions.

[0104] Format conversion process: The NEON vshr_n_u8 (right shift and extract high bits) instruction extracts the high 5 bits from the R channel (8 bits), the high 6 bits from the G channel (8 bits), and the high 5 bits from the B channel (8 bits) of the RGBA8888. Then, the vzip_u8 (interleave and reassemble) instruction reassembles the extracted bits into 16-bit RGB565 data. The conversion time per frame is reduced from 8ms to 1.2ms.

[0105] The metadata area, a 512-byte (32-bit aligned) section in the shared memory header, stores the following information:

[0106] Frame sequence number (uint32_t): Used by OpenHarmony to determine the frame order (to avoid out-of-order display);

[0107] Timestamp (uint64_t): A time stamp for the ARM GTimer (global timer with a precision of 1ns), used for cross-system synchronization;

[0108] Valid region (uint32_t x1, y1, x2, y2): Only the changed region is transmitted (such as partial updates after the application window is moved), further reducing the amount of data. It can reduce the amount of data transmitted by 70% when performing partial updates.

[0109] Hash value (uint8_t

[20] ): SHA1 result, used for integrity verification;

[0110] Format tag (uint8_t): Identifies the pixel format of the current frame (e.g., 0x01 indicates ARM-optimized RGB565 + separated Alpha), which facilitates parsing by the OpenHarmony side.

[0111] OpenHarmony allocates a cross-container shared memory pool that meets the ARM Device-nGnRE attribute. Cross-core data consistency is ensured through ARMDC CVAC and IVAC caching instructions. At the same time, ARM-optimized RGB565 and separated Alpha format are defined (reducing data volume by 50%), and GTimer timestamp metadata is embedded, completely avoiding the overhead of traditional multi-round memory copying. This achieves a breakthrough in cross-container transmission with zero data copy, integrity verification, and embedded synchronization information.

[0112] S4, OpenHarmony side, based on ARM NEON, performs frame data preprocessing (OpenHarmony system layer). It receives the transmitted frame data and performs format adaptation and optimization of the data through the OpenHarmony display service to prepare it for display. Its processing efficiency directly affects the final display latency and needs to be closely coordinated with the transmission and display steps.

[0113] S4.1 and OpenHarmony display services offer native support for proprietary formats.

[0114] In OpenHarmony's display services, a new parsing module has been added that optimizes RGB565 for ARM and separates the Alpha format:

[0115] Parse the valid regions (x1, y1, x2, y2) in the metadata, and only process the changing regions (such as processing only the pop-up region when applying a pop-up window), thereby reducing invalid calculations;

[0116] For RGB565 data, the ARM NEON vld2q_u16 instruction is used to load the data (2 pixels at a time, 32 bits in total), and the vshll_n_u16 instruction (with signed left shift extension) is used to extend the 16-bit data to 32 bits. Then, the vinsq_u32 instruction is used to insert the data into the Alpha channel (obtained from the separate Alpha plane), and the data is converted to the ARGB8888 format supported by the OpenHarmony display controller. The conversion process processes 16 pixels in parallel, and the time taken is reduced from 5ms to 0.8ms.

[0117] After loading the separate Alpha plane via vld1q_u8, it is mixed with RGB data in real time via vmulq_u8 instructions, replacing the hardware mixing of the display controller and improving the mixing efficiency by 4 times.

[0118] Added rotation and scaling preprocessing: For frame data that needs to be rotated (such as from landscape to portrait) or scaled, the NEON vrev64q_u8 (reverse byte) instruction is used to achieve 90-degree rotation, and the vqmovun_s16 instruction is used to achieve bilinear scaling (parallel processing of 4*4 pixel blocks). The time spent on rotation and scaling is reduced to 1 / 5 of the traditional method.

[0119] S4.2 Frame Buffer Queue Management Based on ARM Atomic Instructions

[0120] A triple-buffered queue is designed on the OpenHarmony side, and lock-free access is achieved using ARM atomic instructions (LDXR and STXR), avoiding the context switching overhead of traditional mutex locks.

[0121] ARM Atomic Instruction Lockless Buffer Queue is a frame buffer queue management mechanism implemented based on ARM LDXR (atomic load) and STXR (atomic store) instructions. It ensures thread safety when accessing the queue by multiple threads and across containers through atomic operations, without relying on mutexes, thus reducing synchronization overhead.

[0122] The queue status (idle, ready, and showing) is stored using 32-bit atomic variables (each buffer block corresponds to 10 status bits). When the frame is released on the Android side, the status is marked as ready through STXR (atomic storage), and 0 is returned to indicate that the operation was successful.

[0123] The OpenHarmony display service obtains ready frames through LDXR (atomic loading), avoiding the context switching overhead of traditional mutexes (reducing it from 2ms to 0.3ms).

[0124] When the queue is full (Android rendering is faster than display), the oldest frame is discarded via the CLREX (clear exclusive access) instruction (to avoid blocking rendering), and the number of dropped frames is recorded (for subsequent synchronization adjustments).

[0125] Performance monitoring and dynamic adjustment of S4.3 and ARM PMU drivers.

[0126] Integrate the ARM PMU driver (based on the perf_event framework) into the OpenHarmony kernel and collect the following performance metrics in real time (once per frame):

[0127] The ARM PMU-driven performance monitoring closed loop is a closed-loop control mechanism that collects time-consuming data of each stage of rendering, transmission, and preprocessing through the ARM performance monitoring unit (PMU), and dynamically adjusts Android-side rendering parameters (such as resolution and thread priority) to ensure load balancing across the entire link.

[0128] Rendering time is the difference between the GTimer values ​​from the start of the instruction to the frame readiness on the Android side; transmission time is the shared memory access latency, measured by the CYCCNT counter, with one cycle being approximately 0.5ns; preprocessing time is the NEON conversion time.

[0129] Based on this data, the Android side's rendering thread priority is dynamically adjusted (via the setpriority system call): when rendering time accounts for more than 50%, the priority is increased to the highest level to ensure that rendering is not preempted by other tasks; when transmission time accounts for more than 30%, the Android side is notified to reduce the effective area and only transmit the smallest change range.

[0130] By utilizing ARM LDXR and STXR atomic instructions to achieve lock-free access to a triple-buffered queue, mutex lock context switching is avoided, reducing latency from 2ms to 0.3ms. At the same time, ARM NEON accelerates the conversion from proprietary format to display format (16-pixel parallel processing), and the ARM PMU collects the end-to-end time in real time, dynamically adjusting Android-side rendering parameters (such as resolution and thread priority), forming a closed-loop optimization of preprocessing, performance feedback, and rendering adjustment.

[0131] The S5 and OpenHarmony side, based on ARM DMA and timers, are high-performance displays that transmit pre-processed frame data to the display controller. This is the final link in the display chain and requires ARM hardware features (DMA, timers) to ensure low latency and smooth visuals. Its synchronization mechanism must match the rendering rhythm of the Android side.

[0132] S5.1 and ARM DMA controller frame data are directly transmitted.

[0133] Configure the ARM DMA-330 controller in the OpenHarmony display driver to implement hardware transfer of frame data from shared memory to the display controller frame buffer (FB).

[0134] When initializing the DMA channel, set the transfer mode to linked list mode (LLI): the frame data is split into multiple transfer blocks (16KB each) according to the bus width of the display controller (e.g., 64 bits). The physical address, length, and address of the next block of each block are linked through an LLI descriptor (8 bytes). The DMA controller automatically transfers the data in order without CPU intervention.

[0135] Transmission trigger condition: When preprocessing is completed and the frame is marked as displayable, transmission is started by the EN bit (bit 0) of the DMA_SxCR register (channel control register). After transmission is completed, the DMA controller notifies the CPU via an IRQ interrupt (the interrupt handler only updates the status and takes less than 100us).

[0136] Compared to traditional CPU copying, DMA transfer reduces the transmission time of 1080P frames from 8ms to 0.5ms, and CPU utilization from 15% to 0.5%.

[0137] S5.2, Cross-system synchronization based on ARM GTimer and VSYNC.

[0138] A high-precision synchronization mechanism is designed to ensure that the Android rendering frame and the OpenHarmony display refresh rhythm are consistent. On the Android side, when the frame rendering is completed, the GTimer time stamp T1 is recorded; on the OpenHarmony side, when the display controller generates the VSYNC signal (vertical synchronization, 60Hz with a period of 16.67ms), the GTimer time stamp T2 is recorded.

[0139] Calculate the frame preparation time difference ΔT = T2 - T1:

[0140] If ΔT is less than 5ms (frame preparation is too early), the CPU enters a low-power state (C2 state) through the ARM WFI (Wait for Interrupt) instruction, and is woken up by the timer when there are 5ms left before the next VSYNC, thus avoiding invalid waiting (saving 20% ​​of CPU power consumption).

[0141] If ΔT is greater than 10ms (frame preparation is too late), the PMU monitoring module will notify the Android side to reduce the rendering resolution (e.g., from 1080P to 720P) to ensure that subsequent frames can be completed within the VSYNC cycle.

[0142] The synchronization accuracy is controlled within ±1ms, and the screen tearing rate is reduced from 15% to 0%.

[0143] S5.3 Optimization of ARM instruction-level configuration for display controller.

[0144] For register configuration of OpenHarmony display controllers (such as the DSI interface), ARM assembly instructions are used for direct manipulation (replacing C language function calls), reducing configuration latency.

[0145] The display resolution (e.g., 1920x1080) can be quickly set to the DSI_TIMING_REG register using the MOV32 pseudo-instruction (combining multiple MOV instructions) (avoiding multiple shift operations in C language).

[0146] The pixel format configuration (ARGB8888) is directly written to DSI_FORMAT_REG using the STR instruction, avoiding the overhead of C language register mapping functions (reducing from 2ms to 0.1ms).

[0147] Before starting the display, the DSB (Data Synchronization Barrier) command is used to ensure that all configurations have taken effect (to prevent display abnormalities caused by command out-of-order execution), and the command pipeline is refreshed using the ISB (Command Synchronization Barrier) command to ensure that subsequent commands are executed based on the latest configuration.

[0148] The ARM DMA-330 controller is configured to achieve direct hardware transmission of frame data in linked list mode without CPU intervention. The transmission time for 1080P is reduced from 8ms to 0.5ms. The ARM GTimer (1ns precision) is used to calculate the frame preparation time difference ΔT in conjunction with the VSYNC signal, and the DMA start timing is dynamically adjusted (when ΔT is too small, WFI low-power wait is triggered). At the same time, the display controller is directly configured using ARM assembly instructions, and the latency is reduced from 2ms to 0.1ms, achieving the triple goals of low-latency on-screen display, no screen tearing, and low power consumption.

[0149] Experiments have verified that this embodiment effectively improves rendering efficiency. Through ARM NEON instruction optimization and big.LITTLE scheduling, the CPU rendering frame rate of Android applications is increased by 80% to 120%, and the rendering time for complex scenes (such as vector map zooming and text-intensive interface scrolling) is reduced from 100ms to less than 30ms. It also reduces transmission overhead; based on ARM shared memory and cache instructions, the CPU utilization rate for cross-container frame data transmission is reduced from 30% to below 3%, and the transmission latency is reduced from 20ms to less than 1ms. Furthermore, it optimizes on-screen performance, combining ARM... DMA transfer is synchronized with GTimer, reducing the on-screen latency on the OpenHarmony side from 15ms to 0.8ms. The end-to-end display latency (including rendering, transfer, and on-screen display) is controlled within 35ms, achieving a smooth 60fps display standard. Compatibility and stability have been enhanced, with rendering entirely based on CPU, avoiding GPU adaptation issues (supporting all ARM architecture devices). Through ARM atomic instructions and SHA1 verification, data transmission stability has been improved by 99.9%, with no screen tearing or glitches. Power consumption has been optimized, with an overall power consumption reduction of 25% through big.LITTLE core scheduling, WFI low-power instructions, and partial update mechanisms.

[0150] 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 high-performance rendering method for cross-runtime environment CPUs based on instruction-level acceleration, characterized in that, Specifically, the following steps are included: Using HarmonyOS as the host and Android as the container, the host memory management service creates a shared physical memory pool, which is of type non-cached device memory. This pool is mapped to the user space of the container and the host, and a lock-free buffer queue managed by ARM atomic instructions is created. Android applications generate drawing instructions. The container optimizes the drawing instructions according to their type, and then evaluates the complexity of the drawing instructions based on their computational cost and the number of pixels they cover. Instructions with a complexity greater than a threshold are marked with a large kernel affinity, while those with a complexity less than the threshold are marked with a small kernel affinity, and the instructions are bound to the corresponding kernel. The container rendering engine uses NEON vector operations to calculate the alpha blending of drawing instructions in parallel, determines whether pixels are within the path in parallel for path drawing instructions, performs multi-pixel RGB interpolation synchronously for linear gradient fill, and performs multi-pixel Gaussian blur in parallel for shadow blur, thereby accelerating the rendering of all layers and writing the obtained pixel data into a shared physical memory pool. The ARM bit inversion instruction is used to determine the Z-order of layers, and the NEON instruction is used to separate the RGB and alpha planes of transparent layers, blending only the RGB plane. After compositing, frame data in the first optimized pixel format is generated, a hash value is generated, and the inter-frame change area is taken as the effective area. The frame sequence number, timestamp, valid area, hash value and format tag are combined to form metadata. The frame data and metadata are written to the shared physical memory pool and the lock-free buffer queue is marked as ready. The host HarmonyOS display service obtains the ready-state valid area by atomically loading LDXR, loads the encoded data and Alpha plane data and converts the format, and marks its status as displayable; sets the direct memory access DMA channel to linked list mode, transfers frame data from the shared physical memory pool to the display controller frame buffer, and sends a notification to the CPU after the transfer is completed, triggering the display service to complete the screen display and synchronously updating the frame status to displayable.

2. The cross-runtime environment CPU high-performance rendering method according to claim 1, characterized in that, The method for optimizing drawing instructions based on container type is as follows: When the drawing instruction is a path drawing instruction, the third-order Bézier curve is decomposed into multiple straight line segments for approximation, the coordinates of the straight line segments are loaded in parallel, the fixed weight matrix of the pixel block is pre-calculated, and the weights are applied in parallel in the edge region of the path to complete the anti-aliasing transparency calculation; when the drawing instruction is a texture drawing instruction, the texture coordinates are converted into block coordinates adapted to the ARM L2 cache line, and the pixel offset within the block is recorded to support data preloading; when the drawing instruction is a text rendering instruction, a unique identifier is generated for the glyph, and the rendered glyph is stored in the shared memory of the text rendering cache in the container to achieve reuse.

3. The cross-runtime environment CPU high-performance rendering method according to claim 2, characterized in that, When the drawing instruction is a path drawing instruction, the third-order Bézier curve is decomposed into multiple straight line segments for approximation, the coordinates of the straight line segments are loaded in parallel, a fixed weight matrix for the pixel blocks is pre-calculated, and the weights are applied in parallel in the edge region of the path to complete the anti-aliasing transparency calculation. Specifically: The path described by the third-order Bézier curve is decomposed into 16 line segments for approximate drawing. Each line segment consists of the starting point coordinates and the ending point coordinates, corresponding to 4 consecutive single-precision floating-point numbers, forming a line segment coordinate array. The ARM NEON vector instruction vld1q_f32 is used to perform single-instruction multiple data parallel loading on the line segment coordinate array. A pixel block of a predefined size is used. An auxiliary line passes through the pixel block in a defined manner. The distance from each pixel in the pixel block to the auxiliary line is calculated. A fixed weight matrix for the pixel block is generated in such a way that the closer the distance, the higher the weight. The outer contour edge of the path is obtained based on the line segment coordinate array. Pixel blocks are then used to cover the edge area block by block to form a continuous local area, so that the pre-calculated fixed weight matrix matches the real edge. The final color value of each pixel in the local area is the product of the original color value and the NEON vector of the corresponding weight in the fixed weight matrix. This completes the anti-aliasing transparency calculation and achieves smooth drawing of the path edge.

4. The cross-runtime environment CPU high-performance rendering method according to claim 1, characterized in that, When creating a framebuffer in an Android application, allocate contiguous physical memory, align the starting address of the framebuffer memory to 128 bytes, and then set the framebuffer's memory attributes to write-back mode.

5. The cross-runtime environment CPU high-performance rendering method according to claim 1, characterized in that, The method of using NEON vector operations to parallel compute drawing instructions for Alpha blending is as follows: The color blending formula is converted into NEON vector operations. The source pixel color data src to be superimposed, the target pixel color data dst already existing in the frame buffer, and the alpha transparency weight data corresponding to the source pixel are loaded by the vld1q_u8 instruction. The vmulq_u8 instruction is used to perform parallel multiplication operations on the src data and alpha data, and the dst data and the inverse alpha data, respectively. Then, the vaddq_u8 instruction is used to accumulate the two sets of multiplication results in parallel, realizing the color blending calculation of multiple pixels in a single instruction.

6. The cross-runtime environment CPU high-performance rendering method according to claim 1, characterized in that, The method for determining whether a pixel is within the path in parallel for path drawing commands is as follows: Construct a mask vector representing whether a pixel within a pixel block is located within the path. Represent the edge line of the path as a path boundary vector in NEON vector format. Use the vandq_u32 instruction to perform a bitwise AND operation on the mask vector and the path boundary vector to determine in parallel whether all pixels within the pixel block are located inside the path.

7. The high-performance CPU rendering method across operating environments according to claim 1, characterized in that, The first optimized pixel format is as follows: 16-bit RGB565 encoding is used to represent color information, and an 8-bit Alpha channel is set up to store transparency data in a separate plane manner. Its resolution is the same as that of the RGB array, and each pixel occupies 24 bits.

8. The cross-runtime environment CPU high-performance rendering method according to claim 1, characterized in that, The method of determining the Z-order of layers using the ARM bit inversion instruction is as follows: the container rendering engine executes the ARM bit inversion instruction on all rendered layers to obtain the inverted bit sequence, and compares the inverted bit sequences of multiple layer IDs in parallel using the vcge_u32 instruction. The Z-order of the layers is determined according to the numerical value, with the larger the value, the higher the Z-order of the corresponding layer.

9. The high-performance CPU rendering method across operating environments according to claim 1, characterized in that, The host collects real-time time-consuming data for each stage of rendering, transmission, and preprocessing, and constructs a dynamic feedback adjustment closed-loop control mechanism to adaptively adjust container rendering parameters. Among them, rendering time is the time difference between the container starting the rendering command and the frame data being ready; transmission time is the access latency of the shared physical memory pool; and preprocessing time is the time spent converting the frame data to the NEON instruction format. The adaptive adjustment method is as follows: when the proportion of rendering time to the total time of the entire link exceeds a first threshold, the priority of the rendering thread is raised to the highest level; when the proportion of transmission time to the total time of the entire link exceeds a second threshold, a notification is sent to the container to reduce the effective area, and only the smallest variation range in the frame data is transmitted.

10. The cross-runtime environment CPU high-performance rendering method according to claim 1, characterized in that, When the hardware does not support mixing, the vmulq_u8 instruction is used to perform real-time mixing of Alpha plane data and RGB565 encoded data to complete the transparency calculation and obtain the final display color with transparency effect.

Images