Hi, recently I was comparing animation performance on i.MX6 DualLite SoC between QtQuick and HTML. I'm not an expert in HTML so do not know if I did things best possible way, but I took Servo rendering benchmark ( https://youtu.be/u0hYIRQRiws there is a link in a description) an reduced number of elements to 60 to get sane results on such weak ARM device I have. Then I reimplemented this in QtQuick. So the results are 8fps for HTML and 60fps for QtQuick.
QML/QtQuick is quite easy and sometimes you'll be surprised that you could've create what you wanted in such few lines of code. But on the other hand, there are things that are not obvious, Qt docs can be lacking some details on something and you may come up with something that looks like hack rather than proper solution. Last but not least - QML is declarative and it is hard to switch from C++. I saw qml files filled with walls of imperative JavaScript code, like some filtering done by copying elements from one ListModel to the other instead of proper proxy model in c++, state handling by ifs spaghetti and some properties like "stateOne: 1" etc. I always suggest getting some professional QtQuick training if that is possible to avoid common mistakes. BR Filip On Feb 15, 2018 5:36 AM, "Jason H" <jh...@gmx.com> wrote: > > > Anyway, you can lament it, but that ship has sailed. > > > If you really want to know what I'm thinking, it would be to ditch JS > entirely and use ChaiScript in QML. > > > > > > Thanks for the response, Jason. > > > > If I understand your salient point here, you're advocating the > "traditional" > > approach of just maintaining device-specific, not-necessarily-related > code > > bases that duplicate the same application functionality? So, use the > > per-platform accepted coding frameworks -- C# for Android, ObjC for iOS, > Qt > > for dekstops, etc. -- and just develop the required expertise in each > area? > > Not at all. Just the loftiness of Widgets everywhere is unlikely to ever > be realized. Qt does a lot very well. I've heard lamenting that most people > get QML wrong - that JS is not to be the application code, just the glue > code. There certainly is appeal to that, C++ code is the most portable and > most efficient, but in the end it is easier to just write JS instead of > C++, though ChaiScript would bridge that gap. JS also bring in async issues > and its own event loop. > > Anyway, at the end of the day, Qt is a success, and the intricacies of > dealing with the various platforms is made manageable. I just assume there > is no back button on the device. Android users never complain. > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
