Performance messurements - Qt Widgets vs Qt Quick
-
It is almost impossible to compare these two directly, since they cover very separate areas of functionality. Surely well done QML serves better for animated touch like UIs, while Qt's widgets still serve the purposes of the desktop better.
For painting, a custom implemented self-painting widget performs less work than a QML scene and should thus be faster. It is also a lot more work to implement, and there is the potential of getting things wrong that are already solved in QML.
So the answer is no, there is no direct comparison, since it would likely not make sense.
-
bq. It is almost impossible to compare these two directly, since they cover very separate areas of functionality.
Why? If you take for example an image and let it rotate and move around the screen.
This is possible with Qt Quick and Qt Widgets and could be a first impression about the performance differences regarding image manipulation. -
@qtd1d1: For that comparison you would end up using a GraphicsView in the Widget case, and QML (which is based on a GraphicsView) in the QML case so I would image the comparison would show either the same performance, or slightly improved in the Widget case due to less abstraction.
QML provides a good abstraction over the GraphicsView to allow rapid prototyping / development of touch based UIs, but as with any abstraction it will always be faster to write it using the base framework. This comes with the caveat that @miroslav stated, which is that it'll be more difficult and probably have new bugs.
And now in an effort to answer the original question...
We started doing our touch UI based on styled QWidgets, but this was way to slow, so I made the decision to switch to QML rather than coding custom painters. The new QML is much faster and easier to develop, but it does use more memory (javascript core etc.) than the widget based solution.
-
[quote author="qtd1d1" date="1327912915"]bq. It is almost impossible to compare these two directly, since they cover very separate areas of functionality.
Why? If you take for example an image and let it rotate and move around the screen.
This is possible with Qt Quick and Qt Widgets and could be a first impression about the performance differences regarding image manipulation.[/quote]That really depends. In Qt and C++, you can rotate the image and show it after that. In QML, you are always interacting with the scene. This is just an example, but I really think it is quite hard to find practically relevant performance comparisons between the two that are not flawed.
-
[quote author="qtd1d1" date="1327996216"]Maybe another reason why QML would be slower, is that QML needs to be interpreted at runtime.[/quote]
So now, instead of measuring the relative performance of your scenario between QWidget and QML, you simply assume QML is going to be slower? It might be, but then again, it might not be. You don't know untill you measure, and only then you know the result for that case only. -
[quote author="qtd1d1" date="1327677906"]Or just performance messurements for one of these?
Thanks[/quote]Here, at the bottom of the post: "link":http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/.
As stated above, comparing performance of widgets and QML is hard. I've heard that people tried running "chips" Graphics View example with QML, and it was indeed slower (on the other hand, that was a long time ago, so it might be different now). But, I have to confess here - once I've tried QML, I simply stopped worrying. It's easy, flexible, fast to develop, and runs well both under Graphics View and SceneGraph. I'm developing a pretty complex app right now, and there is no performance problems, even on mobile phones (Android in my case), while the workflow is simply full of awesomeness and win :)
-
I agree with @sierdzio. We're developing on poverty spec WinCE5 devices, and although there are some performance constraints (mostly memory usage) the flexibility and development flow more than make up for this. Also I expect we would have had the same memory problems even with a QWidget based approach.
I guess the bottom line is try it and see!
-
[quote author="qtd1d1" date="1327996216"]Maybe another reason why QML would be slower, is that QML needs to be interpreted at runtime.[/quote]
AFAIK the interpretation is done once during load, not again and again.
What CAN make it slow is if you use many cascaded property bindings (which could makes it using much memory and CPU). This was shown on DevDays 2011. But I can also reach this with C++.
I would say it's a matter of case, which is faster. You have to check your requirements then choose the right technology for it.
If you need custom drawn graphs, QML would not fit.
If you need nice animations QML is better.
If you need a label and an edit field, it doesn't matter which you take I would say.
