Binary QML compilation...
-
Does anyone know whatever happened to compiling QML text files as binaries so that developers can protect their intellectual property, improve loading performance, etc?
Here's the reference on binary QML from this forums, which according to it, shouldn't be hard to add to Qt:
"Protection of QML code":http://qt-project.org/forums/viewthread/16693/#84245
So, any Qt developers that could tell us if this could come as a feature in Qt 5?
Thanks!
-
The important part is the
[quote]
but noone has come around to it[/quote]AFAIK, that is still the current status. Perhaps you did notice that there have been some changes at Nokia too in the meantime, including closing of the Brisbane office where a lot Quick was developed.
-
Yeah, it was a really sad day for me when I found out that the Brisbane office was being closed, there were some really talented engineers working there and were adding a lot of cool stuff to Quick.
well, I guess that's that, no binary QML until further notice.
I would contribute, but I'm not familiar enough with the Qt source code... I peeked at some stuff once (the network library) trying to understand some async handling, but it was like reading APL code, there's some really black voodoo under the covers, and I feel that the documentation is lacking on how the core works.
Also, if there was a way to find out where that part of the code was being worked, maybe we can all do our part and try to finish it up, according to the post, the code is done, and the part that needs to be finished is the build process.
-
If you really want to work on this just pop in at #qt-labs or development@qt-project.org; people will be more the willingly to help you.
-
I can't go into #qt-labs because the proxy at work has all IRC access blocked, so I'll have to check how to subscribe to development@qt-project.org and ask around
-
freenode listens on ports 6665, 6666, 6667, 6697 (SSL only), 7000 (SSL only), 7070 (SSL only), 8000, 8001 and 8002, so perhaps you can get around the proxy with one of those ports. ref: http://www.freenode.net/irc_servers.shtml
-
oh, there's also webchat: http://webchat.freenode.net/ which should tunnel everything over http
-
nope,
Other ports don't work, as it's a web proxy, so only 80 and 443 are open. And the webchat.freenode.net is blocked.
I really hate web coat proxies, I feel like a f*cking kid being supervised when doing my homework, but hey, it's the only job available at the moment
-
well, in case you haven't found it yet, you can subscribe to the mailing list from http://lists.qt-project.org/mailman/listinfo/development
-
It's probably not a great idea trying to circumvent company filtering of the internet anyway. I know it's a bitch to work with (learned my lesson on my previous job for not checking on that before I came to work there), but actively trying to get around one may jeapardize your job. If you feel treated like a kid there, first try to convince management to lift the restrictions, at least for the developers (explaining that they are blocking useful resources that can help you be more effective), and if that doesn't work: find another job that does treat you like an adult.
-
As a workaround, you can use QRC to build your QML code into the binary.
Internally, QML is compiled into binary data, as this KDAB post neatly explains: "link":http://www.kdab.com/qml-engine-internals-part-1-qml-file-loading/.
-
Thanks for the link @sierdzio
But as you can see on the link I posted at the beginning of this thread, there is already code implemented by the trolls to achieve QML binary compilation.
The only thing that it says is missing, is the integration into the build system so that when you build an application that has QML code, to be able to transparently compile/deploy without having to do anything funny.
The thing is, we have no idea where that code is, or where to start to find out how to finish up on that work.
-
Hi,
It's not quite as simple as Alan said in his original post in that poll thread, unfortunately.
There are a couple of issues.The first is obvious: pointers. The current QML compiler produces compiled data which includes pointers (to type/property caches which can be used to generate QMetaObjects when required), and possibly other things (it's been a few weeks since I looked at the code, and my memory is getting fuzzy already ;-)
Obviously, this would need to change, to using an integer ID, or some other hash key.
The second is less obvious: mmapability. If the compiler output isn't directly mmapable, but instead write it out as some structure which can be read in via QIODevice, you'd probably actually lose time, since it's so inefficient. If it is mmapable, that'd be magic - but then you have platform specificness creeping into your code. That's not a problem (indeed, with the Bundle support that was added to QtQuick2, it's possible that in the future, application developers could provide per-platform precompiled typedata in the bundle, which could be mmaped in as required instead of a compilation step).
In the end, it's certainly possible to implement, but no-one has, yet. It's a fair bit of work to get right, in my opinion - and it's the sort of thing that you really want to get right the first time.
Also, instantiation will, in any event, dominate parsing/compilation in any performance benchmarks, I think.
Cheers,
Chris.
