FloTHERM is powerful 3D computational fluid dynamics (CFD) software that predicts airflow and heat transfer in and around electronic equipment, from components and boards up to complete systems. Learn More →

Debugging performance issues in a Qt application – Part 2

Opening the source, I was quickly able to locate the code responsible for animation:

Because of a 100% CPU cost, I was expecting to find something clumsy, but found the code to be reasonable. It is using Qt’s built-in Property Animation framework. A quick Google search showed that it is the standard way of implementing animation in Qt. This is how Qt’s own examples are coded.

I decided to dig deeper and investigate how Qt implements its internal Animation framework. I needed to find the timer that drove Property Animation. I found the Unified Timer in a parent class of QPropertyAnimation. This timer seemed to be the heartbeat to all animations in Qt. Its interval is controlled by a compile time define and fixed at 16 msec; means 60fps just for the slow blinking round button!

Further review seemed to indicate that this is not a problem when using OpenGL-ES back-end because Qt throttles the fps to vsync. In case of raster drawing however, such timer interval would hog the CPU. Qt Animation framework provides a simple way to build complex animations. I guess the lack of control over CPU use is the cost you pay for convenience.

Now that the problem has been identified, different people can choose to tackle it differently. They may choose not to have an always-on animation, or throttle overall framerate by modifying Unified Timer interval. I decided not to compromise on demo appearance or to modify timer tick because what’s the challenge in that (smile) Seriously speaking, the demo appearance was already approved by marketing and changing the unified timer tick would affect all animations, not just this one. What if an event triggers a screen transition that requires maximum fps?

As a quick fix, I chose to write my own timer in application, configured to run at 5 fps and forgo Qt’s Animation framework in the name of power saving. The first proof of concept incremented/decremented a constant value from “opacity” and “strength” properties at timer callback. Here is the trace analysis:

It made a big difference. It also verified that idle loop was working great. Let’s check out the visual results. The original implementation is shown on top left for reference:

If you look closely, animation fidelity is lost. It may be a minor difference for the untrained eye but the original designer of the demo is not going to be happy.

The problem with the above solution is that it is basically doing a linear interpolation between the start and end values. The designer of the demo did not intend this. This is a result of using the easing curve provided by Qt animation framework (OutInQuad). The challenge is to have the same visual effect, but with lower CPU usage.

It led me to solution 2.0. In this, I decided to sample the properties at run-time, with the desired fps, as they are driven by the Qt animation framework. Then iterate through those values in a lookup table. I hacked an example that came with Qt and programmed it to spit out those values that a user could paste into a lookup table. The example is built and run on host platform and is shown in action below:

My colleagues routinely use Sourcery Analyzer to debug any hard to find issues and also to optimize our Qt port. We use it to find bugs that escape both unit-tests and visual inspection. The issue I narrated above falls into the latter category. I hope you will also find creative ways to apply Sourcery Analyzer to your next project. I encourage you to try out Sourcery Analyzer for yourself, click here to request a trial copy.

More about AsadAsad Zia is a Staff Engineer within the Embedded Software Division (ESD) of Mentor Graphics where he specializes in graphics and user interface technology. His work involves providing differentiated UI solutions for all the different runtimes supported by ESD with expertise that spans drivers and middleware up to the application development.

More Blog Posts

I am part of the marketing organization in the Embedded Software Division here at Mentor. Before this I spent 10 years marketing Mentor's hardware design products, specifically in the RTL and high-level synthesis domains. Moving from addressing the requirements of hardware designers to those of software designers has been quite the change. Throw in open-source and you have a heady mix - which keeps me on my toes!
Outside of work, I enjoy spending time with my family, reading a good book or the occasional round of golf (in the few hours of sunshine we get in Portland!).
I hope you find my thoughts interesting and look forward to your comments.
Visit Embedded Blog