[Qt-interest] C++ or QML

[Thiago Macieira]

Em Domingo 27. Junho 2010, às 18.20.53, Carsten Breuer escreveu:
> Hi Thiago,
> > That's not a fair question.
> > Obviously QML cannot be faster than the equivalent, well-written C++.
> 
> The question here is not if QML is faster. That is obvious.
> The question is how much QML is slower then native C++.

It's not much slower than well-written C++. And I doubt most applications 
written out there are as well-written.

So, I expect Qt Quick apps to be faster than most apps.

> As i said before, using border images in stylesheets
> increase e. g. the cpu load from 4% to 28%. That happens,
> because this feature is badly implemented in QT.

QtDeclarative has been optimised a lot, to be used in low-powered devices like 
handhelds.

> So it would be very interesting to compare QML with C++.
> If the cpu load is 1% higher or QML is a little bit slower,
> i would not care.

Let us know of your results.

> What i would like to see if the QT developers first fix
> existing bugs before implement new features.

Will never happen.

First of all, because we'll never be done with fixing bugs. There will always 
be bugs, period.

Second, because we must implement new features, to stay ahead of the 
competition in some areas, to catch up in others, to fill requirements by 
customers and Nokia in many other domains.

But please don't go overboard and say I claimed that we're not fixing bugs. 
We're fixing bugs, as much as possible. When people complain that bugs aren't 
getting fixed, it's usually because our priorities and those people's 
priorities don't match.

> For Example:
> - Styling border and transparency of QTableView.
> - Elide mode in styled QHeaderView.
> - Styling of QHeaderView.

Forget styling and use QML.

Qt classic widgets were made to have native look and feel. They were not made 
to be tweakable -- that is the opposite of native look and feel. That's why 
the use of stylesheets causes such a slowdown.

If you want to change the look, you should use styles, not stylesheets, or 
paint the widget yourself.

But, anyway, precise "how I want it to look" is exactly what Qt Quick is 
about.

> > The biggest advantage QML is going to give you is the ease of writing
> > your UI, both in terms of time spent, the flexibility to change, and the
> > fact that you're building on top of an optimised stack for doing the UI.
> 
> The model / view concept of Qt is one of the advanced technologies.
> Nonetheless there are some bottlenecks that results in inhereited
> classes of QItemDelegate, QTableView, QSpinbox, ... .
>
> If you want a component that acts like excel, this is going worse.
> In C++ you can do that. what's about QML?

I don't understand the question.

> As i said before, i don't know enough about QML.
> As an embedded developer i know about platform limitations and from my
> point of view, the OP has to make a analysis on his platform to check
> if QML is worse to give it a try.

Most definitely.

You'll see I did not intervene to promote Qt Quick. I just replied to answer 
to an unfair question.

You'll also see that Lorn never claimed it is faster than other solutions. He 
said it was designed to animate, to run on embedded devices and be fast at it.

However, I honestly expect that the OP will find out that his app using QML has 
better UI performance than another solution.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100627/9f460034/attachment.bin