[Development] QTBUG-43096 - QML instantiation performance decadence

Uwe Rathmann Uwe.Rathmann at tigertal.de
Sat May 26 12:30:11 CEST 2018


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




More information about the Development mailing list