I was not talking about QQC1, but about Qt Quick 1 it was QML blamed to be a behemoth, but usually, its translates to appropriate C++ code. My point is even in Qt Quick 1 times performance was not so bad for simple UIs if using QML wisely
On Fri, Oct 20, 2017 at 10:20 AM, Uwe Rathmann <uwe.rathm...@tigertal.de> wrote: > 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 > -- Best regards, Vlad
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
