[Interest] QML performance on iOS?

[Alan Alpert]

On Wed, Jan 29, 2014 at 12:07 PM, André Pönitz <apoenitz at t-online.de> wrote:
> On Tue, Jan 28, 2014 at 11:54:21AM -0800, Alan Alpert wrote:
>> Why not tell them that QML is native?
>
> Believe it or not, some people simply dislike the idea of lying.

 I dislike the idea of lying, but I don't mind calling things like I
see them even when others may have another opinion.

> With "native" people usually associate certain properties, like
> performance, lack of separate run time environment, seemless blending
> with other native libraries and tools, painless deployment using
> the same well-trodden path all the other kids take, too.

It has all those from my perspective. I must not be one of those
"kids" you're thinking of.

>> It is just instantiating a tree
>> of C++ objects (if you aren't using JS bindings).
>
> JS is not optional in QML. Some people have argued hard that it should
> be an optional layer of JS (and possibly other) bindings on top of
> a non-scripted core, but there has been no progress whatsoever. Not
> even an effort.

It is not an option to decouple the engine entirely, but you can avoid
using it and then there's just a bit of memory usage overhead. Bad
habit, I know, but performance to me is temporal and not spatial.

>> If you do a C++/QML
>> app, with C++ for the logic instead of JS,
>
> This is not possible right now, and not considered "in scope" for
> the future.

It's possible, and has been the recommended approach, since the
inception of QML.

>> then the only performance cost over "100% native" will be the startup time.
>
> Which already would be prohibitive. But as stated above the setup
> you suggest (and know to not exist) is not possible anyway.

Given the obvious disparity in our perceptions of reality, I have
great skepticism of your ability to attribute knowledge to me ;) .

--
Alan Alpert