[Development] QTBUG-43096 - QML instantiation performance decadence

[Uwe Rathmann]

Hi Robin,

> Why does it need to be? I have never needed to subclass QQuickControl,
> personally, so I have never brought this topic up.

For the same reason all other controls from QC2 do subclass it. If you 
want to participate in mechanisms ( like font/locale/palette propagation 
) that are implemented in this base class, you have to.

> There is a cost, yes. But I would say it's more a cost/benefit tradeoff.
> Faster prototyping and development cycles at a cost of requiring some of
> your resources to munch on.

Please allow me not to respond: I would like to avoid ending up in yet 
another QML vs. C++ discussion.

> Anyway, wrt direction, I assume you are hinting at a scenegraph that is
> less tied to QtQuick.

No, the scene graph is already a standalone module with a well designed 
public API: many thanks to the authors. Its API could be more comfortable 
and the existing set of nodes is underfeatured, but in general I have not 
much to complain.

Almost everything is about the C++ classes of the various Qt/Quick 
modules. The majority of them is designed with having QML as the one and 
only use case in mind.

I'm also not happy about how the scene graph is used inside of those 
classes, because it substantially contributes to the memory and startup 
performance problems of Qt/Quick. It took me some tome to get those 
things under control, but in the end it was possible without having to 
patch Qt code itself.

> If you are volunteering ...

I am - and you can already see more than 50K lines of code from my 
efforts.

Uwe