Moving to Qt5? Will that remove Qt’s performance issues on Linux?

The last year and a half I’ve immersed myself with Qt, both for comparison reasons with other graphical frameworks and lately with hands-on system development. It’s been fun and I really like how easy Qt allows you to create widgets and GUI with your own look-and-feel.

Today I read a somewhat dated post regarding the coming Qt5 which is the next big Qt API change. The move from Qt3 to Qt4 was huge and it wasn’t done in a snap to convert Qt3 made software to Qt4 – but this time seems that most of the API:s will stay intact. So I hope that Qt4 based software can do this transaction without too much headache for the programmers.

With Qt5 the Qt Quick technology is definitely put in focus. As Qt Quick is a web development inspired technology GUI and widget making should get easier and faster. But the change of focus from Qt/C++ to Qt/Quick might not be altogether positive. I see a trend that companies are choosing not to adopt to the Qt Quick technology for a few different reasons.

1. Transparency. In Qt/C++ most *magic* behind the curtains can be crystal clear with just a small effort on the developer’s side. If problems occur you can debug your way into the C++ core of Qt itself. With the Javascript-ish QML that transparency is gone or at least muddled thanks to the extra layers for handling QML.

2. Performance. Already today Qt is suffering from performance issues. Putting QML on top befuddles even more the reason why some operations are sluggish. It’ll make it much harder to see if it’s the Qt/C++ part or the QML part that’s the culprit.

Already now it’s pretty darn hard to find out these things, especially when you throw in graphic driver dependencies as well.

Let me give you an example of the performance issues I’ve seen with Qt. Maybe this is actually the core of today’s blog:

Especially with the native graphical engine on Linux-types of OS:es can Qts performance issues be manifested. This is evident on Intel’s Atom platforms with integrated graphical chips.

Inte’s drivers should support all the necessary bells and whistles but even standard 2D rendering operations are sluggish with X using up most of the CPU resources. This is very easy to verify with Qt’s example software “concentric circles“.

Use the native graphical engine, hack the concentriccircles example so it runs 10.000 “circle operations” and measure the time for this. Then run the same concentriccirles example but this time with the runtime flag for using Qt’s raster graphical engine. With -graphicssystem raster the graphics will be software (Qt) rendered and not through X11/Intels drivers. All of a sudden, by bypassing the Inte’s drivers the rendering performance gets a boost. On three different Intel Atom Linux projects I’ve heard about, or worked with firsthand the difference was in the area of 80% X11/CPU utilization (native) vs 2-4% X11/CPU utilization (raster).

Here Qt probably says it’s Intels driver’s fault, where Intel blames it on Qt’s lack of OpenVG support. The solution is however easy, no matter whose fault it is. Just use -graphicssystem raster and your system should work great.

According to testing of Qt and communication with Intel I’ve gleaned the following.

-graphicssystem raster works great. Low CPU overhead and high speed for most (all) operations. Software rendering is done in the Qt libraries (?) instead at the driver.

-graphicssystem native (the default) will make your Linux ( in case of Intel Atom with integrated graphical chip) very sluggish due to the CPU (X11) overhead.The fault of this is according to Intel how Qt approximates a sine wave using the native X calls. This is highly inefficient and resulting in a multitude of extra calls into the Intel driver for creating/deleting pixmaps and drawing trapezoids.

Whether this is true or not I’ve not even tried to confirm. I know that raster works so that is my recommendation to go with. A few years ago (2009?) raster wasn’t that stable but I hope it is now. However it might be for good reasons that the trolls haven’t made raster the default on X11, so who knows there might be other pitfalls when using raster that I do not know about.

I guess my blog lost focus a bit. My point being. Adding a new layer on top of Qt for the GUI work can be great for decreasing developing time. But this will definitely come at a cost whenever the software engineers doing the work run into performance issues – are those issues due to Qt or QML? In the end, if these issues occur or cannot be understood or worked around it may be a show stopper for the project! forcing the project to switch graphical technology or hardware altogether.

I guess I’ll have “fun” debugging tasks in a year or so ;)

About these ads

About kjellkod

Software Engineer by trade, (former?) Martial Artist and Champion by strong will and small skill... and a Swede by nationality :)
This entry was posted in C++, Qt, Software Engineering. Bookmark the permalink.

14 Responses to Moving to Qt5? Will that remove Qt’s performance issues on Linux?

  1. Michal Minar says:

    You just saved my day!! Thank you so much. I was going to replace all the stylesheet logic with hardcoded drawing to speed things up. But then I tried your suggestoin: “-graphicssystem raster”.
    Those are some pretty magical args… :-)
    Running on AMD Geode LX800/500MHz with linux

  2. supercopier says:

    Yes, when raster will be as default? I hope wayland fix all performance case issue, mainly because the dev like the performance

  3. aliancemd says:

    QML 2 will have performance issues? Read this article: http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/
    Scroll down for a benchmark between QML 1 and QML 2.

  4. ngodichat says:

    I am currently encountering this problem with applying stylesheets to my application in OpenSuse. The stylesheet is loaded one time when the program starts but the performance is very bad even with the keyboard input to QLineEdit. Can you give me any suggestion to deal with my problem? Many thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s