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.
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 ;)