Plotting around 1000 shape items in qwt polar/ qwt plot. Help needed.

Hi,
My application is having a requirement of receiving (on TCP socket) and plotting upto 1000 custom shape items (mostly rectangular/ circular shapes) on qwt ploar as well as qwt plot. The position (keeps changing every time) of these items has to be updated on the plot every 1 second. What is the best strategy to update, by position, the shape items on the plots?:

1. Draw an item, delete it and redraw it at new position ( attach/ detach calls) or
2. Use transformation to translate the painter path of the item to new position?

It is not only required to draw the items on polar plot but also to display them in a table view/ widget as text. So keeping the performance in mind, I request you to suggest what is the best way of achieving this on a qwt ploar & qwt plot?

Also; as the same data is being displayed in qwt polar plot, qwt plot and table widget; I am planning to implement Qt's model/ view concept classes. Is it feasible to derive view classes for qwt polar/qwt plot with QStandardItemView and QwtPolarPlot/ QwtPlot as base classes. Any ideas on this are most welcome. Thanks in advance.

Quote:

---

My application is having a requirement of receiving (on TCP socket) and plotting upto 1000 custom shape items (mostly rectangular/ circular shapes) on qwt ploar as well as qwt plot.

---

First of all you need to be clear about the difference between a shape and a plot item using a symbol: A symbol represents a point ( plot coordinate ), while a shape is a figure made of plot coordinates. Thus position and size of a shape item depend on the scales of the plot, while for the symbol the size is fix only the position is related.

What type of use case do you have ?

Uwe

What type of use case do you have ?

Hi sandysandoro,
I have just given the analogy of the use case, in my reply to Uwe.
Thanks.

Hi Uwe,
Ya, now I am clear about the difference between a shape and a plot item. My requirement is more of plotting customized plot items on qwt polar and qwt plots. Right now, I am not allowed to give the exact use case of this application but I can give the analogy:

There are different vehicles fitted with sensors. These vehicles (sensors) will be transmitting positional other parameters on Ethernet to this application, in a monitoring center. This application will receive date from those vehicles and display positional and other information including shape of the vehicle and update the position of the vehicles on the plots as on when they MOVE. Different symbols (customized) will be allocated to different vehicles and the symbol of the vehicle is fixed and predefined. No path tracing of the vehicles is required, only movement of the vehicles is to be depicted on the plots.
Hope, this gives sufficient information of the use case of this application. Your suggestions are most welcome and could be vital for designing my application in better way using Qt, Qwt and QwtPolar. Thanks in advance.

Hi Uwe,
Any comments on this thread? What is the efficient way of moving (updating positions) around 1000 of plot items on qwt/ qwtpolar plot every second?

Thanks.

When you don't need to scale the vehicles according to the scales I would go with symbols instead of shapes. QPainterPath can be use for both, but the advantage of QwtSymbols implements a pixmap cache, what might be of importance for the performance when having 1000 of them ( at least on graphic stacks running the raster paint engine ).

Next you have to decide:

• QwtPlotCurve
• QwtPlotMarker
• a customized plot item displaying 3D points ( like QwtPlotSpectroCurve ) - the z value would be for the vehicle type.

When having a limited number of vehicle categories ( trucks, small car, big car ... ) you could implement it using one curve for each category. In terms of rendering performance this will be the most performant implementation, but might be a problem, when you need to implement operations on individual element ( f.e drag&drop or controlling an specific stacking order ). When using markers you will have 1000 plot items, what means some overhead, when the plot framework iterates over all items ( f.e. finding the combined bounding rectangle for autoscaling ).

Uwe

Thanks. From your reply:

Quote:

---

In terms of rendering performance this will be the most performant implementation, but might be a problem, when you need to implement operations on individual element ( f.e drag&drop or controlling an specific stacking order ).

---

"most performant implementation" - is it best performance implementation?

Ya, I will be trying these three options and see the performance in simulation. There will not be any graphical operations on the plot items; simply plot and move them on the display according to their instantaneous position. At most, tracker text/ context menu will be provided for mouse hover/ mouse right click on an item.
Actually, also, a unique number is to be displayed along with symbol; that is why I was thinking of customizing a plot item by deriving from QwtPlotItem.
So, I assume, the steps for movement of plot items on plot area would be: i. Create item. ii. Attach item to plot. iii. Detach/Delete and Attach it again at new position.

Thanks for your suggestions.

Quote:

---

"most performant implementation" - is it best performance implementation?

---

No.

Quote:

---

Actually, also, a unique number is to be displayed along with symbol;

---

A marker offers displaying symbol + text, but the text is not cached ( also QStaticText is not used ), so there will be room for optimizations. If you want to go with the one vehicle = one item approach customizing QwtPlotMarker is probably easier than implementing a new item from scratch ( also nothing difficult ).

Quote:

---

So, I assume, the steps for movement of plot items on plot area would be: i. Create item. ii. Attach item to plot. iii. Detach/Delete and Attach it again at new position.

---

In case of a marker it would be:

marker->setValue( ... )
plot->replot();

Detaching/reattaching only because of an attribute change is not necessary.

Uwe

Nice. Thanks Uwe.