Increasing dynamic object creation speed
-
Hi,
I've run into a bottleneck with my application I just can't find a solution for.
I'm dynamically creating views for a game consisting of usually less than 100 dynamically created objects. The problem is, is that it takes about 8ms on a decent computer to generate each object and on a mobile device (N8) it's taking closer to 14 ms.
The component has about 12 properties but apart from that is fairly simple - consisting of text, image and rectangle components with some javascript attached to a mousearea.
I've used Analyzer to determine this is the bottleneck but I can't see a way of drilling further into the call to createComponent to see what's taking so long. I know bindings can take some time but I can't imagine there's more than 40 or so being created.
Is there any best practise or things to look out for or even a faster way of doing it? If I could create them in bulk even then change the x and y and one property that would work for me.
-
I should mention I'm using Qt Quick 1.0 as I'm supporting S60v5 devices. Which are particularly affected by this slowness.
Qt 4.7.4 or 4.7.3
-
Some of the advice at http://qt.gitorious.org/qt/qtdeclarative/blobs/master/doc/src/qml/performance.qdoc is probably still applicable to QtQuick 1.0, although some (eg, scene-graph related) will not be.
-
That is a very useful resource and I made a few changes based on the recommendations but for the most part I was doing it right already.
Is there a way of seeing inside component creation using Analyzer? The docs don't mention a way.
All I see at the moment is "Creating component.qml" and the time it's taking. Which is far too long for what it's doing. Analyzer does show about 3 bindings which are taking a few microseconds each (once again times that by 40 and you still only have 120 microseconds). Way short of 8 - 12 ms it's taking all up.
-
Out of interest, if you remove the image from your component, do the speed problems go away?
Loading a file on Symbian can sometimes be an issue due to the microkernel architecture (FS access via a server process, etc).If removing the Image {} element doesn't make a difference... well, I don't know what the problem could be, to be honest. Generating the text layouts, maybe? If there are any "strange" characters in the text which aren't available in the current font, a deep lookup of an available glyph from any font could cause different font plugins to be loaded by the font engine, perhaps... I'm really not sure.
The actual painting shouldn't take anywhere near that long, and as you say a few bindings shouldn't be a meaningful contribution to the total. :shrug:
