QGraphicsScene performance (200000 static items and 1 moving)

[Obey-Kun]

Hello. I'm making cad-like software. It is for temperature field modeling and visulization. User will work with MANY blocks here. It can be 10000, it can be 10000 or more.

I obviously use Graphics Scene engine for it. Each block is QGraphicsItem.

Also I have 1 item there — Anchor. It follows cursor. It is done by signal (from view)l/slot (in Anchor). Slot makes setPos().

The problem is that setPos() sometimes results in scene reindexing. It is slow, when there is many items.

I'm thinking about moving that moving item to view (make it as widget there). Any better solution?

Screenshot discribing why I need many blocks (not so many blocks here): http://obey.su/upload/11-01-23_LOR_QFrost/qfrost2.png

[Lykurg]

There are several options coming in my mind: disable indexing or "play around" with the various performance tunings the view and scene offers: level of detail, update mode...

Further (please attach images to the forum, that the post stays valid) it seems that you are composing a grid out of items, and your anchor "frames" one item. If so, skip the anchor, and alter the paint method of your items to draw the focus frame itself. To move the anchor, unset the "highlight frame" from the current one and set it to the other.

[totem]

Maybe I'm wrong but your app makes me think of the Pixelator example (in case you're interested)

[Obey-Kun]

There are several options coming in my mind: disable indexing or "play around" with the various performance tunings the view and scene offers: level of detail, update mode...

Disabling index is not ok (coze I need itemAt, itemsAt).
lod, update mode etc tuning is not a solutions, becouse problem is in index recalculating.

Maybe I'm wrong but your app makes me think of the Pixelator example (in case you're interested)

Naah, my app is doing absolutely other thing . It's about temperature field modeling for engineering geocryology needs. And it is more complicated. It already has 7500 lines of code (+ 4000 lines of comments + 2000 empty lines).

---

Added after 1 32 minutes:

If I add all static items as children of other item (so this item is parent for every static items), it works much faster. Nice and weird. Someone can exmplain?

[wysota]

Disabling indexing doesn't make itemAt stop working but anyway I wouldn't go for this option here. Consider using drawBackground and drawForeground for things such as the grid. You don't have to compose everything from items.

[Obey-Kun]

I already use view's background/foreground for grid etc.
And the final solution is:
1) Use more balanced bsp trees (put static items in portions of 10000 doughters of some container items).
2) Move moving item to view's viewport (as widget).

[totem]

2) Move moving item to view's viewport (as widget).

could you precise please ?

[stampede]

User will work with MANY blocks here

Maybe that's just wrong assumption. What is the point of using many small blocks to represent one, huge field with constant temperature ? I'd rather consider the other way around - create as many big items as possible, and eventually split them into smaller groups in the areas where you need more precision (some general LODs algorithms may be usefull here).

[Obey-Kun]

Maybe that's just wrong assumption. What is the point of using many small blocks to represent one, huge field with constant temperature ? I'd rather consider the other way around - create as many big items as possible, and eventually split them into smaller groups in the areas where you need more precision (some general LODs algorithms may be usefull here).

It is not grid, it's blocks. So it can look like this:

_________
|_________|
|____|____|

_________
|_________|
|____|____|

To copy to clipboard, switch view to plain text mode 

So using separate blocks is much easier to code. Later, I maybe will add grid representation. But not shure, that it will be better. Maybe scene indexes will not be going crazy, but paint system will.

could you precise please ?

I'll create widget and put it into view's viewport. Will use setRect to move it there. So it will not change scene indexes.

[wysota]

You don't need a widget. You can paint your rect on the viewport using QPainter::drawRect(). But then I'm not sure if this is a good idea. One item more or less shouldn't make a difference. I'd focus on reducing the number of items in the scene and optimizing what you already have. There are a couple of threads on this forum where I show how to do that.