[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