On Fri, 20 Oct 2017 09:14:09 +0200, Vlad Stelmahovsky wrote: > I've created much more complex apps using QtQuick 1 on HW much weaker > than RPi2 (Symbian phones) w/o such laggin as in this simple calc > example. Obviously, there something wrong with code and/or system setup
A simple push button is made of ( IIRC ) more than 30 QObjects with Quick Controls 1, the version of Quick Controls 2 with less features still consists of 7 QObjects. Each stop of a gradient is made as QObject for no other reason, than to make it accessible from QML. I could continue with almost every control, but let's summarize it this way: Qt/Quick has not been designed to be a lightweight technology. But I never heard anyone complaining about the scene graph ! I would have some critics myself about the C++ part on top, but beside its strategy, about when to create the scene graph nodes, it does not prevent you from having an efficient application. The problems start with the fact that the API of most of those C++ classes are designed to serve the QML use case, making QML mandatory. Finally QML on top does not contribute to performance in any positive way - it is about convenience only. In the best case ( small applications ) you won't notice the startup performance penalties, but you definitely always have to pay with a very significant memory footprint. -- IMHO criticizing having to use QML is very valid and it can't be answered because of having a good performance from the scene graph. And to be clear: it is not QML to blame - it is the fact that you have to use it, when you are in need for a modern graphic stack. And this is exactly why I'm trying to create the QSkinny alternative - one where the decision for the graphic stack is independent from the decision about the programming language you prefer to write your application code with. Uwe _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest