[Development] QTBUG-43096 - QML instantiation performance decadence

[Robin Burchell]

On Fri, May 25, 2018, at 4:31 PM, Uwe Rathmann wrote:
> But at the time, when Controls 2 has been started everything was on the 
> table and - at least from the outside - it looked like a comfortable 
> situation for making good decisions. And this is what I had expected to 
> happen:

What happens is only what there are enough time and resources to do, plus a direction to do it in the first place. It might be that you had attempted to drive some of this work yourself (or yourselves), I don't know - but I didn't see any discussion about it on this list that I recall, and I don't recall anything hitting codereview either, so I have to say that from the perspective of the project, I can't see how you could really expect this to happen.

> Unfortunately I never noticed any indication pointing into the direction 
> of a better C++ support. In fact the opposite happened: even the very 
> base class of all QC 2 controls is not part of the public API ! 

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

Assuming you have a valid reason, then I would present my next problem with that: it's probably not mature enough. QQC2 is only three years old, and it is (still) going through quite a lot of change that is often likely not ABI compatible[1]. Sure, it's often _possible_ to work with this stuff in a backwards-compatible fashion, but that comes at a strong cost, which then requires answering: does the cost of having to work in such a manner justify making it public? I would tend to suggest no in that particular case from what I know right now.

> The stupid fact is that QML always comes at a cost. Trying to reduce 
> these cost has been successfully done and any further improvements are 
> welcome, but: as long as there is no clear separation between the Qt/
> Quick graphic stack and QML I disagree, that the "right direction" has 
> already been found.

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. And, well, this problem isn't just limited to QML or QtQuick- if you want to run Qt as it exists today on a lightbulb, you're probably getting something wrong in your architectural design. ;-)

Anyway, wrt direction, I assume you are hinting at a scenegraph that is less tied to QtQuick. If you are volunteering to help engineer such a separation in a way that is maintainable in the long term, and doesn't negatively impact performance of the graphics stack's consumer (QtQuick), then I have no objections personally, though I'm not really the right person to talk to. I would suggest coming up with specific proposals for what you want done, talking them over on this list, and then working on patches assuming there are no objections.

But if you are asking me personally to separate the scenegraph out, then I have no interest in doing so. As I said, I am happy with QML and QtQuick in their present form (with hopefully indefinite iterations to improve it over time, of course).

[1]: This does bring me to something that I do find unfortunate: API stability is a lot easier to promise than ABI stability. I can imagine a world in which we would have a public _API_ for more things than we do nowadays, but I am hesitant to contemplate that too much, because it ties our hands in changing the implementation a lot wrt ABI compatibility.