Improving GV performance

[wysota]

Have you seen the elastic nodes example that comes with Qt? It does more or less the same you want.

I'm having trouble here detecting small differences between approaches... Why do you say in the second try the number of nodes will be doubled compared to the first one? You create two new nodes in both cases when adding a resistor.

[Gopala Krishna]

Have you seen the elastic nodes example that comes with Qt? It does more or less the same you want.

I've seen that but it uses some animation which i dont need. Anyway both the implementation seems to be similar.

I'm having trouble here detecting small differences between approaches... Why do you say in the second try the number of nodes will be doubled compared to the first one? You create two new nodes in both cases when adding a resistor.

I'm sorry for not being clear enough. In the first approach whenever two components are connected, they share a common node and so i delete one of the nodes. I maintain a list of connected components in node, which i update in such case. This also shows visual change by using a brush with solid fill in the node showing connection.
When a connection happens and I need to move the node(by moving component), I do that in scene's mouse event carefully selecting the appropriate component to control the node movement.

BTW do you think the second approach is slightly faster(though i cant see difference now) when there's no connection since the parent item includes child's boundRect there by resulting in less updates ?

[wysota]

I've seen that but it uses some animation which i dont need.

I meant to take a look how the nodes are tied to the "rubbers".

I'm sorry for not being clear enough. In the first approach whenever two components are connected, they share a common node and so i delete one of the nodes.

I don't think this is implemented in the code you provided. I was expecting something like that but couldn't find it.

BTW do you think the second approach is slightly faster(though i cant see difference now) when there's no connection since the parent item includes child's boundRect there by resulting in less updates ?

No, I don't think it makes the whole thing faster. boundingRect of the parent doesn't have to include boundingRects of all its children.

I think you should make the connectors separate objects and keep pointers to them in your items. Then when you move the item, update its connector in a way you see fit - either by moving only the ending point of the connector or by iterating over all its points and moving each next one sliightly less than the previous one (provided that your connectors have more than two points, of course).

[Gopala Krishna]

Thanks for replying

I don't think this is implemented in the code you provided. I was expecting something like that but couldn't find it.

It is quite difficult to compress that code into a small example, so I didn't do it

No, I don't think it makes the whole thing faster. boundingRect of the parent doesn't have to include boundingRects of all its children.

Thanks for this information. I wont try 2nd method in my original app. Probably the third approach can be tried , but I'm afraid if the performance might not improve significantly (due to lot of bookkeeping)

I think you should make the connectors separate objects and keep pointers to them in your items. Then when you move the item, update its connector in a way you see fit - either by moving only the ending point of the connector or by iterating over all its points and moving each next one sliightly less than the previous one (provided that your connectors have more than two points, of course).

Can you elaborate more ? I didn't get this clearly ? What do you mean by connector - node or a wire ?

[wysota]

Wire, of course.

[Gopala Krishna]

Well , actually i dont have problem with wire for now. What exactly I do is, if a node has more than 2 items(component or wire), i fill the node with solid brush. If the components are moved apart I add a wire between.

I installed opensource version of qt-4.3 for windows and the result didn't differ much

I made an important observation though:
Select all the components and move them all. Notice the speed of moving components.
Now set the dactor variable in my snippet to 54

const int factor = 54;

const int factor = 54;

To copy to clipboard, switch view to plain text mode 

Doing so will overlap the nodes of elements in a row.
Now see the difference!

With this what I inferred was, there are less number of updates(with bigger update region) and hence faster.
Can I use some tricks to fake situation like this so that when components are moved ?

I went through the chip demo, but it doesn't use child items and also the items are rectangular. Hence i can't directly compare chip and my code. Still performance seems to be better in chip. I welcome any suggestion and correction if i am wrong.
I seriosly want to improve the performance of my app. A client doesn't care what technology you use, he just wants good result. So please do help me. Should I fallback to third approach ?

[Gopala Krishna]

After I read this post #69 , I tried this

view->setViewportUpdateMode(QGraphicsView::SmartViewportUpdate);

view->setViewportUpdateMode(QGraphicsView::SmartViewportUpdate);

To copy to clipboard, switch view to plain text mode 

and speed improvements are amazing . may be I can use this when items are moving and switch back to default in other cases.

Never the less, i still want answer for my questions above since the app has to be compatible with qt-4.2