Optimizing Image Loading

How to Implement

Without texture compression, preset images must be decoded by the CPU into a pixel map before being uploaded to the GPU for texture generation. This process is time-consuming. You can use texture compression technology to complete CPU decoding and texture generation in advance in the compilation and build phases, reducing the time for the CPU to process images. For texture compression, relevant properties must be configured in the compilation file. During the build process, preset images are located and converted into texture streams based on these configurations. Super-compression encoding is then applied to generate super-compression streams. After compilation, during runtime, super-compressed data is decoded to generate texture streams. The GPU then reads these streams for rendering and display.

Texture compression compresses preset images in the compilation and build processes. You need to configure texture compression parameters in the compilation file of the editor. Based on the parameters, Hvigor reads the files to be compressed, constructs the restool command to parse resources, and then generates a resource file list. Then, Hvigor traverses the file list and transcodes the files to be converted to the texture format. Converted resource files are no longer packaged into build products. The texture files and unconverted files are then built to generate resource products.

The following figure shows the timing for enabling texture compression for compiling and building resource files.

Scenario Case

Images cannot be directly rendered by the GPU. The CPU needs to decode the images and upload them to the GPU, which takes time. When a certain number of preset images are rendered on a page at the same time, the image completion delay may increase. The following figure shows how to switch between tabs. When you swipe right to switch to tab2, the new page loads 40 PNG images and 40 JPG images using the horizontal layout. The image completion delay is significantly different when texture compression is enabled and disabled. The following figure shows the switching process when texture compression is disabled.

If texture compression is not used, when you swipe right to switch to tab2, the loading of some images may be delayed because multiple preset images need to be loaded on the new page. As a result, white blocks occur.

Project Configuration

Before using texture compression, you need to perform basic configurations and select the preset image to be super-compressed. You can add the media and filters properties to the compression object in the build-profile.json5 configuration file at the project or module level.

media: contains the enable property that specifies whether to enable texture compression. The default value is false, indicating that texture compression is disabled. To enable texture compression, set enable to true.

filters: contains the method, files, and exclude property objects.

• method contains the type and blocks properties. type can be set to sut or astc. blocks is used to set the extended parameters of the conversion type. Currently, only 4x4 is supported.
• The path, size, and resolution properties in files specify filtering by path, size, and resolution, respectively.
• exclude has the same properties as files, which are used to delete files that do not need to be compressed from files.

For details, see compression. The sample code for configuring texture compression is as follows:

"buildOption": {
  "resOptions": {
    "compression": {
      "media": {
        "enable": true // Whether to enable texture compression for media images
      },
      // Filtering of texture compression files. This field is not mandatory. If this field is not set, all images in the resource directory will be compressed
      "filters": [
        {
          "method": {
            "type": "sut", // conversion type
            "blocks": "4x4" // The extended parameters of the conversion type
          },
          // Specifies the files used for compression. Only files that meet all conditions and are not excluded can be compressed
          "files": {
            "path": ["./**/*"], // All files in the specified resource directory
            "size": [[0, '1000k']], // Files with a specified size of less than 1000k
            // Pictures with a resolution smaller than 3000 x 3000
            "resolution": [
              [
                { "width": 0, "height": 0 }, // minimum width and height
                { "width": 3000, "height": 3000 } // Maximum width and height
              ]
            ]
          },
          // Remove files that do not need to be compressed from the files list. Only files that meet all filtering conditions are deleted
          "exclude": {
            "path": ["./**/*.webp"], // Filter all webp files
            "size": [[0, '1k']], // Filter files smaller than 1k in size
            // Filter images with a resolution smaller than 1024 x 1024
            "resolution": [
              [
                { "width": 0, "height": 0 }, // minimum width and height
                { "width": 1024, "height": 1024 } // Maximum width and height
              ]
            ]
          }
        }
      ]
    }
  }},

NOTE

1. filters: When both project-level and module-level filtering conditions are configured, module-level filtering conditions are preferentially used for matching. If module-level filtering conditions are matched, project-level filtering conditions are ignored. If module-level filtering conditions are not matched, project-level filtering conditions are applied.
2. type:
   • astc: adaptive scalable texture compression. It is a GPU-friendly texture format that allows for faster display on devices with less memory usage.
   • sut: super compression for texture. It is a GPU-friendly texture format that allows for faster display on devices with less memory usage. Compared with astc, it offers a higher compression ratio and less ROM usage.
3. size and resolution: The value of size is a one-dimensional array, and the value of resolution is a two-dimensional array.

Therefore, the value range of [0-1k, 1k-2k] is the same as that of [0-2k] for size matching.

When matching is performed by resolution, the width and height of the resolution are two-dimensional arrays. In the following figure, the left part indicates all images whose resolution is less than 2048 × 2048, and the right part indicates images whose resolution is less than 1024 × 1024 and images whose resolution is between 1024 × 1024 and 2048 × 2048. The two formats seem to be the same, but their value ranges are different.

Compilation and Execution

After setting related parameters, compile and build the project. During compilation, Hvigor obtains preset images based on configuration parameters, compresses them into textures using the transcoding component, and packs the textures. The following figure shows the switching effect of the tabs after texture compression.

As shown in the figure, when texture compression is used, images are displayed immediately when the screen switches to tab2, without any delay or white blocks.

Benefits and Overheads

When using texture compression to convert preset images, pay attention to the number of covered resource files to ensure that the overhead is minimized while maximizing the benefits. Therefore, the performance improvement of texture super-compression should be analyzed from both benefits and overheads.

Benefits

Texture compression converts preset images into texture formats, which are directly read by the GPU. This reduces the CPU and DDR load and speeds up image loading. The following figure shows the durations for reading a preset image in .png, .sut, and .astc formats.

The following table lists the durations for H:CreateImagePixelMap.

Loading a .png image takes roughly four times longer than loading a .sut image, while loading an .astc image takes about twice as long as loading a .sut image. When sut or astc is enabled, the preset images can be loaded more quickly.

After comparing the time required for loading images, switch tabs to check the memory usage before and after texture compression is enabled. The following figures show the related data.

The following table lists the memory usage before and after texture compression is enabled.

The table shows that when texture compression is enabled, the memory usage decreases from 598,965 KB to 165,015 KB (.sut) or 167,723 KB (.astc), and the memory usage for image loading decreases significantly.

Overheads

When texture compression is used, preset images are converted during compilation, which increases the compilation duration. Once preset images are converted to the texture format, their size varies based on the image format, which may cause the package to expand or shrink.

The compilation takes a long time because it includes the texture compression process. You can use 87 preset PNG, WebP, and JPG images for compilation and package them in three scenarios: full compilation, modifying parameters of resolution, and adding 1 to 100 images. The following table lists the compilation time when texture compression is enabled and disabled.

As shown in the preceding table, after texture compression is enabled, full compilation takes a longer time. However, reapplying texture compression after filtering preset images by resolution greatly shortens the compilation duration.

Analysis of several sample apps confirms that the expansion rate of .jpg and .webp images is two to three times. The following table lists the expansion rate data after texture super-compression is enabled.

After texture compression, the size of the .png image package remains unchanged, but the size of the .jpg and .webp image packages increases significantly. To optimize performance with texture super-compression in package size-sensitive scenarios, consider compressing all .png images into textures and selectively converting frequently used .jpg and .webp images or those critical to key frames.

ffmpeg -i input.gif -s 90x90 -y output.gif (set the width and height to 90 pixels.)

ffmpeg -i input.gif -vf "scale=90:-1" -y output.gif

Pre-compression Scenario Case

For example, directly scaling an image of 4180 × 4180 pixels to a profile of 80 × 80 pixels on a web page or app will cause high memory usage, slow decoding, and frame freezing. In this case, you are advised to compress and scale the image to a small image of 80 x 80 pixels before loading the image. The image completion delay is significantly different when the image is compressed and when the image is not compressed.

Time Consumption Comparison

Click to switch the test example and check the time consumption for reading images before and after compression. The following figures show the related data.

The following table lists the image decoding duration before and after the image is compressed to the actual UI size.

The table shows that after the image is pre-compressed to the actual UI size, the image loading time decreases significantly from 183 μs to 95 μs.

Memory Usage Comparison

Click to switch the test example and check the memory usage before and after compression. The following figures show the related data.

The following table lists the memory usage before and after the image is compressed to the actual UI size.

The table shows that after the pre-compression is performed, the memory usage for image loading decreases significantly from 90,224 KB to 21,230 KB.

How to Implement

Most CDN service providers (such as Huawei Cloud) allow you to dynamically adjust the image size and format by appending query parameters to the image URL. These parameters can control the width, height, and cropping mode of an image. The following are common parameters:

• w: image width.
• h: image height.
• fit: cropping mode.
• q: image quality.
• format: output format (such as WebP and JPEG)

For example, use the cover cropping mode to convert the network image (URL: https://your-cdn-url.com/path/to/image.jpg) to a .webp image with a width of 200 pixels, height of 150 pixels, and quality of 85% (quality includes comprehensive indicators such as image definition) as follows:

// It needs to be replaced with the image resource address required by the developer.
private imgUrl = 'https://******.com/path/to/image.jpg?w=200&h=150&fit=cover&q=85&format=webp';

build() {
  NavDestination() {
    Column() {
      Image(this.imgUrl)
        .width(200)
        .height(150)
        .objectFit(ImageFit.Cover)
    }
    .width('100%')
    .height('100%')
  }
  .backgroundColor('#F1F3F5')
}

Image(this.imageUrl)
  .width(300)
  .height(200)
  .autoResize(true)