> Jędrzej had a beautiful proof of concept at some point for QObject to combine the object and d-pointer allocation into one. If only there was a way to be able to use Qt without all the PIMPLing and just have QObjectPrivate be a "normal" QObject member !
------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, May 26, 2018 at 2:05 PM, Simon Hausmann <simon.hausm...@qt.io> wrote: > Hi, > > > Jędrzej had a beautiful proof of concept at some point for QObject to > combine the object and d-pointer allocation into one. > > > That's where I had the idea that perhaps this idea could be extended all > the way to QML, so that the instantiation of a .qml file would collect all > object and d-pointer sizes at type compilation time and use a bumper > pointer allocator during instantiation (assuming that we can verify upfront > that the types support it). > > > The consequence would be one libc malloc for all objects per .qml file and > pointer based APIs like anchors or gradients would involve no data copying > at all, as opposed to value based gadget APIs. > > > This would require a static QObject parent-hierarchy and make a few other > assumptions, but as long as they are the common case and can be detected, I > think there are ways of making QtQuick elements instantiate faster and use > less memory. > > > > > Simon > > > P.S.: Are you sure the stops: [ ... ] assignment works? > ------------------------------ > *From:* Development <development-bounces+simon.hausmann= > qt...@qt-project.org> on behalf of Uwe Rathmann <uwe.rathm...@tigertal.de> > *Sent:* Saturday, May 26, 2018 12:30:11 PM > *To:* development@qt-project.org > *Subject:* Re: [Development] QTBUG-43096 - QML instantiation performance > decadence > > On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote: > > > The first point I would make in reply, though, is > > that the convenience of creating code with a/b/c are going to be > > significantly better in my experience. > > Code for d) look like this: > https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml > > IMHO the code for a/b would be very similar, the only one that requires > more work would be c as you need extra code for creating the button > itself. > > > Let's take > > another good example from the top of my head: Item::anchors. Behind the > > scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's > > turn it into a Q_GADGET, and we're done, right? > > No, but please let's stay with gradients, where the answer is yes. > > QSkinny offers this class to expose gradients to QML: https://github.com/ > uwerat/qskinny/blob/master/src/common/QskGradient.h > > Now when having an control with a property like this: > > class MyRectangle : public QQuickItem > { > Q_OBJECT > > Q_PROPERTY( QskGradient gradient READ gradient > WRITE setGradient RESET resetGradient NOTIFY gradientChanged ) > > ... > }; > > you can write your QML code this way: > > MyRectangle > { > gradient { > orientation: "Vertical" > > stops: [ > { position: 0.0, color: "MediumAquamarine" }, > { position: 0.5, color: "..." }, > { position: 1.0, color: "DarkSeaGreen" }, > ] > } > } > > The equivalent code offered by Qt/Quick needs 4 QObjects - for each > instance of an item. So when having 100 rectangles these are 400 QObjects > - good for nothing. > > Uwe > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
