Overview

Qt Quick Ultralite uses, by default uses a single hardware layer for all the pixels that get shown on the display. This may not be an optimal solution on platforms that have hardware accelerated layer support. To improve performance on such platforms, you can use multiple layers and let the hardware blend them together to produce the final image.

Mutiple layers can be used to represent dynamic UI content rendered into framebuffers in CPU or GPU memory, or by static image data that never changes. A hardware layer composition unit composes the final image that's sent to the display from the multiple independent layers.

Hardware layers can be used by the Qt Quick Ultralite application to reduce memory footprint and CPU or GPU utilization, or to prevent skipped frames caused by expensive rendering operations. By keeping the less frequently changing parts of the UI in separate layers, the main animating UI content can be rendered more quickly.

Reducing memory footprint

Instead of using two full screen framebuffers to show a dynamically updated UI with a single background image covering the entire screen, an image layer can be used instead:

Screen {
    width: 800
    height: 480

    ImageLayer {
        anchors.fill: parent
        source: "background.png"
    }

    ItemLayer {
        anchors.fill: parent
        depth: ItemLayer.Bpp32Alpha

        // UI items here
    }
}

If the background image resides in flash, additional framebuffer memory is not required, reducing the CPU or GPU memory usage.

Using several item layers can also reduce memory usage by lowering bit depths or using smaller item layers instead of a single item layer. The later is used when there are significant gaps in the UI without any content.

Reducing rendering time

Some graphics might be expensive to render, such as images with perspective transformation or effects applied. If possible, they can be placed in a separate item layer, with the ItemLayer::refreshInterval property set to 2. This causes the contents of the layer to only be redrawn every second frame, saving CPU and GPU utilization and reducing the risk of the main UI not animating smoothly.

Screen {
    width: 800
    height: 480

    ItemLayer {
        anchors.fill: parent

        // Main UI items here
    }

    ItemLayer {
        anchors.centerIn: parent
        width: 400
        height: 240

        refreshInterval: 2

        // Expensive to render graphics here
    }
}

Using sprite layers

Hardware layer units typically only support a relatively small amount of root layers, for example four or five. If sprite hardware layer support is available, it's possible to use a sprite layer as a container for multiple smaller item or image layers.

There are, however, some limitations to using sprite layers, which are mentioned in the SpriteLayer documentation. Overlapping sublayers are not blended on top of each other, and all the sublayers need to have the same color depth.

Example

This example demonstrates how an application UI can be composed of multiple independent layers.

Background layer

The background layer can be an ImageLayer, containing static unchanging contents at the bottom of the UI, meaning there is no dynamic content underneath.

Dynamic contents layer

The dynamic contents layer is an ItemLayer containing the main animating parts of the UI, that change every frame. Keeping only these parts in a single layer reduces the draw-call overhead when redrawing the constantly or frequently animating parts of the application.

Static content layers

The static content layers consist of one or more ItemLayer and ImageLayer instances, possibly inside of one or more SpriteLayer instances.

These layers contain the parts of the UI that remain static most of the time. Infrequently animating content can also be placed here, so that it doesn't have to be redrawn each frame, reducing the performance of the frequently or constantly animating contents. The ItemLayer::refreshInterval property can be set between 2 to 4 so that when animations do happen, they are redrawn at a reduced rate, and not together with every single display update.

Final composed result

This is what the final composed result would look like on the display.

Platform-specific guides

For the Infineon TRAVEO T2G boards, refer also to Layer and VRAM optimization guide for Infineon TRAVEO T2G boards.