Fast-Booting Qt Devices, Part 1: Automotive Instrument Cluster

When creating embedded devices, one crucial part of the user experience is also the boot-up time of the system. In many industries, such as Automotive, there are also hard requirements for the boot-up time.

We get a lot of questions like "How quickly can devices built with Qt start?",  "Can you boot up a system to a Qt application under 2 seconds?", or, "What's the minimum time required for a system to start a Qt application?"

Unfortunately, there is no single answer for the questions. Thus, we decided to create three blog posts to open up a bit how to optimize your Qt-powered embedded systems. In this first part, we will look into automotive instrument clusters as a specific use case and show our instrument cluster showcase fast-booting with some benchmark statistics. The second part will focus more on the practical 'how' part: optimizing the Qt, and especially Qt Quick, application code. Finally the third part will discuss more about the hardware side of boot-up optimization.

The Qt Automotive Instrument Cluster Showcase

In the automotive industry, there is a clear need for fast boot-up times. For example, in the digital instrument clusters, it is crucial to start as quickly as possible: When the car is started, the instrument cluster needs to be up, running and reacting almost immediately. Besides fluent user experience, this is also something controlled by official safety requirements. At the same time, as the clusters get more digitalized and graphically much more verbose with e.g. 3D contents, this is something that requires extra attention from the software design and the underlying platform/framework. To demonstrate that fast-booting instrument clusters is possible by using Qt, we took our Embedded world 2016 instrument cluster demo setup and optimized it.

Take a look at the video to see the results:

The original boot-up time of the demo setup was a bloated 23 seconds. After the optimization, we were able to get the first parts of the screen visible already in around 1.5 seconds, depending on what services are required.

Analyzing the time consumption

From the video we have analyzed and approximated where the time goes:


The complete boot time from power off to first frame visible is 1 560 ms. As you see, majority of the time is actually spent on other items than the Qt application contents. For those parts, we still think that time could be even shorter by selecting a different hardware that can be powered up faster. Also, the board could have a faster memory and memory bus. The u-boot could still be stripped down more or replaced with a custom boot loader. But a lot of improvement was done in general, especially for the Qt Quick application optimization.

Prioritizing views

First and the most important thing before starting the optimization is to think what do you want the user to see first. Then start your application UI with that thing only, and lazy-load the rest dynamically. We selected that user must see the frame of the instrument cluster, and after the frame is drawn, the rest of the components are loaded dynamically. First, we load the gauges and only after that, the 3D car model.

"Cheating" by pre-loading

One way to improve the user experience is to "cheat" a bit on when to actually start the loading, if the startup has to be even faster than is possible with an optimized boot. For the instrument cluster use case, you could actually do the startup when the car door is unlocked or opened. In such approach the system is already running by the time the driver enters the car, and system only needs to engage the back light of the instrument cluster when driver switches power on.

How was the Qt part optimized in practice?

For the practical how-to optimization of the Qt Quick application, I'm going to need you to wait for the next part of the blog post series. In part two, we will talk about the practical tips and tricks around optimizing the Qt application.

Stay tuned!

Blog Topics: