QGraphicsItem Creation - Process slower since 4.5.1

[uli]

#

Hi,

I am having a problem with QGraphicsItem Build. Working arround a QGraphicsView, the purpose of the program is to show geographical data.
With Qt 4.5.0, Data is loading fast, then from data QGraphicsItem build is pretty fast to.
But since Qt 4.5.1 and newer version data loading is still fast but not QGraphiscItem Build.

And the more QGraphicsItem are already created the more time is needed for next Item to be done (like if items had to arrange in order somewhere... But thats not the case in my coding part).
So to avoid QGraphicsScene possible implication I delayed putting items in the Scene until all items are created (no change), however the setBspTreeDepth is correcly initialized...
Tryied to simplify my items just for test, same result...
Items have item parent (in case this is an issue...)

The same code built with 4.5.0 work fine, built with 4.5.X ( X > 0 ) is slow.
The same code built running with 4.5.0 dll is fine, built with 4.5.X ( X > 0 ) is slow.

after loading part everything is normal both case.

I have between 50 000 and 500 000 items to load and I'd like to use to new Qt library, and be able to use the LGPL licence.

I am open to any thinking know.
Thank for reading my poor english, let me know if you have an idea.

[uli]

Event with only 20 000 Item loading is slow

[wysota]

Disable indexing of items and reenable it after you create all items. Also be sure to create and add items to the scene before you set the scene on the view. If that doesn't help - use a profiler to find the bottleneck.

[uli]

when building items I only add them to theire parents, and only at the end of process I add the main parent item to scene.
This way I think indexing cannot be part of the slow process
(or I am missing an other indexing place?).

[wysota]

when building items I only add them to theire parents, and only at the end of process I add the main parent item to scene.
This way I think indexing cannot be part of the slow process
(or I am missing an other indexing place?).

If you're in doubt, use a profiler.

[uli]

ok, with profiler I have no experience, do you know a good one with Qt (I am working with QTCreator for now).
Seeking on my own right now but always open to any advise.

[wysota]

On Linux I'm using either gprof or callgrind which is part of the Vallgrind package.

[uli]

Ok the problem seems to come from setParentItem :
- I am working with a layer logic.
- My points layer contain all geographics points
I don't know what change between 4.5.0 and 4.5.1, but the way parentItem are settings know cause slow processing when there is over 10 000 items on one parent, and the more items there is the slower it is.

No idea to solve this yet...
May be set Items parent all in one after items build... But it should still be slow...

[wysota]

Maybe try incorporating more layers to your structure? Instead of having an item with 10000 children, have an item with 100 children that each have 100 children of their own?

[uli]

Yes, that's possible.
But then I worry about memory needs(we try to minize it on this project) and time needed when calling a fonction like show or one layer (responsible to call every item on layer to to set their visibility ).
And the all layer logic should be recheck with this solution

I would like a way to solve the problem to see the program working pretty mutch the same that it use to with 4.5.0.

know looking at Qt library code to understand the difference...

Obviously if no other solution is possbile that the one I'll put in motion.

[wysota]

One empty graphics item uses up about 60 bytes of memory.

[uli]

If someone else met this particular problem, the solution is to correctly set Items

setFlag(QGraphicsItem::ItemDoesntPropagateOpacityT oChildren);

Opacity since 4.5.1 is not process the same way.

Thank you wysota for your support! Way to build a community!