[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:

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 

> 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/

Now when having an control with a property like this:

class MyRectangle : public QQuickItem

    Q_PROPERTY( QskGradient gradient READ gradient
        WRITE setGradient RESET resetGradient NOTIFY gradientChanged )


you can write your QML code this way:

    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.


More information about the Development mailing list