Graphics view with millions of items

[JohannesMunk]

Why do you need that much items? Can't you merge them into groups? Render an approximation for the group. And divide them only if necessary?

If your individual items are complex in design you could consider using openGL and displaylists for the basic shapes, which you then call as often as you have that item-type.
You won't be able to generate millions of displaylists though. So this only works if you have considerably less types, than items.

Can't you provide a screenshot of your working MFC application, so that we have more of an idea, of what you want to achieve?

Johannes

[pherthyl]

First of all, yes, you most likely don't need to create one QGraphicsItem for each item. It's not the fault of QGraphicsView, it's just a fundemental limitation of trying to create millions of any object. You will have a fixed overhead for each object, and if you multiply that fixed overhead (I don't know what it is, but you can imagine with each item holding a rectangle, a brush, a pen, etc that it is several dozen bytes at minimum) you get huge memory usage.

So if you are just visualizing the data, then the obvious solution is just to draw your items directly.

However, you might still be able to take advantage of the scrolling and zooming you get from the QGraphicsView.

Have a look at QGraphicsScene:: drawBackground()

You should paint your boxes there. You can use the CacheBackground flag to avoid unnecessary repaints.

[pherthyl]

sizeof(QGraphicsItemPrivate) returns 280, plus 8 for an QGraphicsRectItem. I'm probably missing some other parts, but basically a million items will take at least 267MB for the items alone.

[JovianGhost]

Thanks everyone, but I've decided to do the painting manually with QPainter and/or low-level WINAPI calls. There's just too much overhead involved in using Qt's built-in graphics management framework.

[wysota]

There's just too much overhead involved in using Qt's built-in graphics management framework.

Maybe you should first find the bottleneck instead of trying to fix random things? I've seen the chips demo running decently with 1 million items and it was in the "old days" when graphics view was not that much optimized yet.

After reading this thread I'm leaning towards an opinion that Graphics View is not for you (but rather because of the memory footprint, not the speed) but not because of the reasons you mentioned. It would help to make a decision if you showed us what the application is meant to be doing.

http://labs.trolltech.com/blogs/2006...ally-possible/

[JovianGhost]

Maybe you should first find the bottleneck instead of trying to fix random things? I've seen the chips demo running decently with 1 million items and it was in the "old days" when graphics view was not that much optimized yet.

After reading this thread I'm leaning towards an opinion that Graphics View is not for you (but rather because of the memory footprint, not the speed) but not because of the reasons you mentioned. It would help to make a decision if you showed us what the application is meant to be doing.

http://labs.trolltech.com/blogs/2006...ally-possible/

I'm not just fixing random things. I've been trying to find the bottlenecks and the only conclusion I can reach is that it's the graphics framework overhead. I've just implemented what I need to using bare-bones QPainter in the paintEvent function and it's very fast and uses very little memory compared to before.

Unfortunately I can't show what the app is doing, since it's IP of my company.

[wysota]

I'm not just fixing random things. I've been trying to find the bottlenecks and the only conclusion I can reach is that it's the graphics framework overhead.

If "fixing" didn't help then obviously that what you tried to fix wasn't a bottleneck.

[JovianGhost]

If "fixing" didn't help then obviously that what you tried to fix wasn't a bottleneck.

Exactly. There's no way to fix the bottleneck, because the bottleneck is the framework itself. There's no way to use the framework whilst maintaining low memory usage. The whole point of the framework is so that it's easy to work with and provides a simple interface to the developer. But all this comes at a price-- the overhead.

[wysota]

There's no way to fix the bottleneck, because the bottleneck is the framework itself.

And you base this statement on what exactly?