Display
Font
Why Is the Font Anti-Aliasing Effect Poor or White Font Edges Have Abnormal Colors?
When using font libraries with more than 2 bits, if the font anti-aliasing effect is poor and the font edges have abnormal colors or the font color display is abnormal, it may be due to endianness issues in the font rendering data.
Please verify by displaying RGB single-channel color fonts. For example, set the font color to gui_rgb(255,0,0,255). Normally it will display red. If the color is blue, it is abnormal (color fonts can all show the abnormality).
Image
Why Do Black Stripes Appear After Image Rotation?
Black stripes may appear after image rotation because the pixel positions change during rotation, and pixels at the rotated positions are not filled, resulting in black stripes.
You can use the gui_img_set_quality function to enable image anti-aliasing calculation, which usually solves this problem.
If the problem persists, please contact the technical support team for assistance.
Screen Rotation
Does HoneyGUI Support Screen Rotation?
HoneyGUI supports screen rotation functionality.
Screen rotation refers to rotating the screen by 90, 180, or 270 degrees, typically used to solve the problem of UI design resolution not matching the display screen dimensions.
For example, the UI design uses 480x800 resolution, but the display screen is 800x480 resolution. In this case, screen rotation is needed to match pixel dimensions.
HoneyGUI does not support real-time rotation within the UI, such as the portrait lock feature on phones or screen flipping when watching videos.
How Is Screen Rotation Implemented?
The current screen rotation functionality is a post-rendering process. After rendering, the generated image buffer is rotated. Its rendering process is completely consistent with normal mode.
What Impact Does Screen Rotation Have on Rendering Frame Rate?
Screen rotation will slightly reduce the frame rate.
How to Enable Screen Rotation?
Since there are many implementation methods for screen rotation, and the most efficient rotation implementation may differ across platforms and applications, the SDK may not include screen rotation functionality implementation.
Users can refer to the technical documentation to make corresponding code modifications, or contact the technical team for assistance.
What Rotation Methods Are Available for Screen Rotation?
The essence of screen rotation is to adjust horizontally arranged pixel data to vertically arranged pixel data. Depending on hardware configuration, there are multiple implementation methods available.
Quick Decision Flow
Note
Important Note: Not all GPUs support rotation functionality. If your GPU does not support rotation, please select according to CPU solutions.
Detailed Rotation Solutions
Solution |
Execution Unit |
Implementation Principle |
Applicable Conditions & Features |
|---|---|---|---|
|
Solution 1: GPU Direct Rotation |
GPU |
GPU directly reads pixels from SRC, rotates and writes to DST |
Applicable: Both SRC and DST are in high-speed area, or no extra high-speed cache Features: Simple implementation, GPU parallel processing, applicable to any range |
|
Solution 2: GPU Cached Rotation |
GPU + DMA |
GPU rotates to high-speed cache first, DMA copies to DST in parallel |
Applicable: DST is in low-speed area and has extra high-speed cache Features: DMA parallel transfer, better performance than CPU copy, suitable for block-based scenarios |
|
Solution 3: CPU Point-by-Point Rotation |
CPU |
CPU reads SRC pixels point-by-point, rotates and writes to DST |
Applicable: Both SRC and DST are in high-speed area Features: Simple implementation, applicable to any range, but average performance |
|
Solution 4: CPU Column-wise Rotation |
CPU |
CPU reads complete rows from SRC column-wise, rotates and writes to DST |
Applicable: DST is in low-speed area Features: Reduces low-speed area write operations, improves efficiency, applicable to any range |
Key Concepts
SRC (Source Buffer): Storage location of pixel data before rotation
DST (Destination Buffer): Storage location of pixel data after rotation
High-speed Area: SRAM or storage medium with speed close to SRAM
Low-speed Area: PSRAM or other storage medium significantly slower than SRAM
Any Range: Solutions can be applied to full-frame or block-based, code logic is the same, only processing range differs
Typical Application Cases
Case 1: :term:`GPU` + Block-based Rendering + Full-frame Display
Hardware Configuration:
Has GPU with rotation support
Block-based rendering, block area in high-speed SRAM
Has another high-speed block cache area
Needs output to low-speed PSRAM full-frame area (no high-speed full-frame cache)
Full-frame display
Recommended Solution: Solution 2 (GPU Cached Rotation), compare with Solution 1
Reason: Block area is high-speed, GPU rotates and saves to another high-speed block cache first, then DMA copies to low-speed full-frame area in parallel. Although DMA parallel copy occupies the bus and affects other low-speed area access, it is usually better than direct writing to low-speed area. It is recommended to compare the performance of Solution 1 (GPU direct rotation to low-speed area) and Solution 2 on the actual platform.
Case 2: GPU + Block-based Rendering + Block Display
Hardware Configuration:
Has GPU with rotation support
Block-based rendering, block area in high-speed SRAM
Block display, no full-frame needed
Recommended Solution: Solution 1 (GPU Direct Rotation)
Reason: Block rotation followed by immediate display, both source and destination are high-speed areas, GPU direct rotation has optimal performance, no extra cache and copy needed, minimal memory usage.
Case 3: GPU + Full-frame Rendering + Full-frame Display
Hardware Configuration:
Has GPU with rotation support
Full-frame rendering, both source and destination frame buffers in high-speed SRAM
Full-frame display
Recommended Solution: Solution 1 (GPU Direct Rotation)
Reason: Since full-frame rendering is used, it indicates sufficient memory and all in high-speed area, GPU direct rotation has optimal performance.
Case 4: CPU + Block-based Rendering + Full-frame Display
Hardware Configuration:
No GPU, CPU only
Block-based rendering, block area in high-speed SRAM
Has another high-speed block cache area
Needs output to low-speed PSRAM full-frame area
Full-frame display
Recommended Solution: Solution 4 (CPU Column-wise Rotation), compare with Solution 3
Reason: Destination is low-speed area, reading complete rows column-wise then writing reduces low-speed area write operations. Column-wise reading can be performed in high-speed block cache area, then batch written to low-speed full-frame area, more efficient than point-by-point rotation.
Case 5: CPU + Block-based Rendering + Block Display
Hardware Configuration:
No GPU, CPU only
Block-based rendering, block area in high-speed SRAM
Block display, no full-frame needed
Recommended Solution: Solution 3 (CPU Point-by-Point Rotation)
Reason: Block rotation followed by immediate display, both source and destination are high-speed areas, using Solution 3 is simple to implement with acceptable performance.
Performance Optimization Recommendations
Prioritize Hardware Acceleration: If screen or GPU supports rotation, prioritize hardware solutions
Reduce Low-speed Area Access: When DST is in low-speed area, consider using high-speed cache transfer or column-wise reading algorithm
Utilize DMA Parallelism: When DMA is available, let DMA handle data transfer while CPU/GPU focuses on computation
Actual Testing Verification: Storage medium speeds vary greatly across platforms, recommend testing each algorithm's performance on target platform
Algorithm Universality: All algorithms support any range (full-frame or block-based), flexibly apply according to actual rendering mode