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!
Nice, however truly cold boots are somewhat of a rarity. I would figure you could capture the last frame on a power-off signal, and show that (or persistent parts of that - like you do with the instrument cluster outline) and then take over. If your first frame is always the same, then just load that.
But the question then is can you hand off to/from the kernel boot image (picture).
It is already advice on many vehicles to turn the key to on and wait for the fuel system to pressurize. The Wake signal can come from the keyless entry system so that by the time you are in the driver's seat, it's already done booting.
Also, couldn't you lazy load a lot of the kernel itself? Then after you start the app, start loading the kernel modules. This creates another handoff issue - how to get notifications that the kernel has loaded a module and for the application to start using it.
You have good points in there.
Main idea behind this demo was to demonstrate cold-boot show that Qt Quick Applications can be started fast.
Hand of from kernel boot image should be possible but having a boot image actually slows down the unpack & loading process of the kernel. The boot image could actually be shown by the u-boot already.
Yes we could lazy load parts of the kernel how ever in this demo the kernel is striped down and it does not have any modules to load. The whole module system is disabled and it has the bare minimum required for the hardware. Also there is no hand-off issues if the application triggers the loading of required modules in the beginning the application only needs OpenGL to be available so only the GPU drivers are required to be loaded before the application starts.
Will you work with Boot to Qt (http://www.qt.io/blog/2013/...) or this be available under LGPL/GPL?
No, you can not get to the same performance level with open source version of Qt. Some of the same tricks can be applied to open source version of Qt, but without static linking and the Qt Quick Compiler (which I'm using) you will not be able get the optimal startup time.