QGraphicsScene/QGraphicsView performance problems

[wysota]

It seems you and Gopala Krishna do not agree on this

We do on most things. I agree that more items mean more strain to the indexing, but if you want to decide what to draw and what to skip yourself without any index, it will be much slower. The depth of the index can be changed, so it's only your decision how deep it should be. And as your items don't move, the tree won't have to be rebuilt, so it will be very fast.

This would mean I cannot use QGraphicsRectItem, right? I have to make my own subclass?

Right. That's what I'm saying from the very beginning.

[Gopala Krishna]

We do on most things. I agree that more items mean more strain to the indexing, but if you want to decide what to draw and what to skip yourself without any index, it will be much slower. The depth of the index can be changed, so it's only your decision how deep it should be. And as your items don't move, the tree won't have to be rebuilt, so it will be very fast.

If that is the case, then i guess bnilsson can try disabling bsp indexing by using scene->setItemIndexMethod(QGraphicsScene::NoIndex);
It would also be nice to play around with bspTreeDepth as well if the disabling index doesn't help.

[wysota]

Disabling the index will make it harder to detect which items to draw without any benefit from disabling it. As the items don't move the use of an index doesn't cause any overhead.

What is important is to divide the "field" item into "subfield" and "subsubfield" items, so that indexing can show its power. The field itself is cheap to draw because you don't really draw anything but drawing all subitems instead of the set that is really visible yields a huge overhead.

[bnilsson]

My first attempt to subclass QGraphicsItem into FieldItem, SubFieldItem and ShapeItem and use them in a parent-child sceme gave even worse performance and memory consumption than using QGraphicsRectItem.
I will prepare the test project I posted before to use the parent-child item strategy and post it later so anyone interested can have a look and see where I am going wrong.

[bnilsson]

Is there any advantage to use integers (QRect, QPoint, etc.) instead of floats (QRectF, QPointF, etc. ) regarding drawing performance?

[wysota]

Yes, it's faster using ints when drawing. Calculations should be more or less equally fast. But in your case the overhead shouldn't be large. Of course it's wise to use either int or real variants depending on the level of detail.

[bnilsson]

Back again...

Here are two test projects with pattern simulation, one "flat" where the items are fields and the painter draws subfields and pattern shapes from a linked list, stored in each field object, and one "hieararcic" where the top items are fields and the subfields are childs to the fields and the pattern shapes are childs to the subfields.

The "flat"version is lean on memory and draws the simulated pattern very fast, 100,000 micron chipsize is no problem.
The "hierachic" version draws a lot of memory, and a chipsize of 50,000 can barely be drawn.

Please comment on these test apps, please suggest how the "hierarchic" version may be improved. I suspect that the "flat" version is fine for the simulated pattern, but may suffer for a real datafile if there is a lot of data in one field.

I noticed that there is a dramatic difference in performance if the item is using a small "local" size and placed by setPos() rather than having a "global" bounding box with large minimum and maximum numeric values. Example min=(0,0) max=(100,100) and setPos(10000,10000) vs. min =(10000,10000) max=(10100,10100) and no setPos.
Can you explain why?

[Gopala Krishna]

It does work on my system now and i still recommend the flat one as you can easily finetune the drawings of subfields (lod)
BTW zooming onto single subfield almost hangs your app on my system. Does it work smooth for you ?

Also as far as i could see you are directly representing the logical sizes as "onscreen" display size.
For eg with chipsize=50000
FieldSize= QSize(32000,32000)
SubFieldSize= QSize(4000,4000)

And you are using this size for each item!

If you need more optimization and if it is possible, do scale down each of these so that on screen "transformation free" size of each item is within (500,500). It is far easier to just multiply the coord by scale factor and then display in sidebar than actually drawing the item in those huge sizes!

Otherwise you can also try to use QStyleOptionGraphicsItem::exposedRect in FieldItem:: paint method and draw only visible part. But i guess this is quite hard and might not work as required.

[bnilsson]

It does work on my system now and i still recommend the flat one as you can easily finetune the drawings of subfields (lod)
BTW zooming onto single subfield almost hangs your app on my system. Does it work smooth for you ?

This is a bug in Qt4.3, probably Linux-specific, will be fixed in Qt4.4.
I tried the Qt4.4 snapshot, and with this it is ok.

Also as far as i could see you are directly representing the logical sizes as "onscreen" display size.
For eg with chipsize=50000
FieldSize= QSize(32000,32000)
SubFieldSize= QSize(4000,4000)

And you are using this size for each item!

If you need more optimization and if it is possible, do scale down each of these so that on screen "transformation free" size of each item is within (500,500). It is far easier to just multiply the coord by scale factor and then display in sidebar than actually drawing the item in those huge sizes!

Unless there is a problem using large numbers, I find it an advantage to use integers with full internal data resolution. It is sometimes of interest to have the cursor position to show the exact position in the drawing. Int's also give a slight drawing performance advantage, right?

Otherwise you can also try to use QStyleOptionGraphicsItem::exposedRect in FieldItem:: paint method and draw only visible part. But i guess this is quite hard and might not work as required.

I will look into this.

[wysota]

I made my own experiments. With about 0.5M items the application was using about 80 megabytes of memory which gives an average of 160 bytes per item (including the memory used by all other components) which I think is not that bad. At that point the application was responsive although very slow. The slowdown is caused by the fact that even if I intend not to draw some item, the matrix still has to be produced and applied for each of them. Making the architecture ignore items that are sure not to be drawn would speed the app significantly.

See attached the code I used.

[bnilsson]

I made my own experiments. With about 0.5M items the application was using about 80 megabytes of memory which gives an average of 160 bytes per item (including the memory used by all other components) which I think is not that bad. At that point the application was responsive although very slow. The slowdown is caused by the fact that even if I intend not to draw some item, the matrix still has to be produced and applied for each of them. Making the architecture ignore items that are sure not to be drawn would speed the app significantly.

Will this be someting for a future Qt release?

See attached the code I used.

I will study the code, I will probably learn a lot from it. Thanks!

[wysota]

Will this be someting for a future Qt release?

I don't think Andreas' team has such plans You'd have to implement it yourself by reimplementing drawItems() in the scene (I think).

[Gopala Krishna]

Making the architecture ignore items that are sure not to be drawn would speed the app significantly.

Is it true ? or did i misunderstand ?
I was under impression that GV framework doesn't draw items not visible on viewport (ofcourse i dont mean hidden items)

[wysota]

I was under impression that GV framework doesn't draw items not visible on viewport (ofcourse i dont mean hidden items)

Take a look at my code. I'm deciding whether to draw something or not based on the distance between the object and the camera (level of detail). If something is very far away (but still inside the camera's viewport) I decide not to draw it, but the whole painting environment is set up by the architecture anyway.