How to speed up redrawing on a graph with many lines?

[asper]

Hi folk,
I'm plotting a huge number of lines (curves) on a graph, at the present 40000 lines (curves) each with 10 data points (with the goal to reach 100 data point for each line).
As soon I fill the graph, each operation (system or user) on the graph become extremely slow!
Operations like resizing the panel, zoom in or out, moving the X scroll bar, etc. require a long while before to finish. A similar behavior happens changing the plot property by program, as for example the line color.

Please note that LabVIEW handles very well the transposes situation, i.e. a graph with 10 lines (curves) each with 40000 data points. All operation on the graph are fast and fluent.

I have attached a small example that show the described behavior.

Do you have any idea how to speed up the operation?

Thanks

[JÞB]

Scaling the graph with panel size will cause multiple redraws durring a panel size drag.  This is got to be undesireable!  Instead use a This Vi mouse leave/Mouse enter and test if the pane size changed and resize the graph if needed.

Replace the SRs on the loops in the "redraw" events with tunnels (They are only there for data flow anyway) and enable loop parallelization.  (If you are on a multi core processor)

LastIts unlikely that you need to "Zoom" on 40000 plots.  offer another graph to zoom and compare a limited subset of the plots.

[asper]

Hi Jeff·þ·Bohrer,
thanks for the replay.

Your first two suggestions don't change much the result, and do not explain why the transposed situation, with the same number of total points, is so fast and fluent.

For the third suggestion I am not interested in.

The rappresentation, that I am try to realize with LabVIEW, to plot a huge number of lines with relatively few data points, is a common way of visualizing high-dimensional geometry and analyzing multivariate data.

Regards,
Asper

[JÞB]

I should have addressed the transpose.

When plotting 40000 lines with 10 points 40000*9=360,000 line sements are drawn each line segment consists of about (dX^2+dY^2)^-2 pixels  (So sayeth the pathagorean theorm)

When plotting 10 lines with 40,000 points there are more points than pixels the 40,000 point arrays are decimated prior to being drawn

[asper]

Hi Jeff·þ·Bohrer,
following your idea, when plotting 10 lines with 40,000 points there are 10*39.999 = 399.990 segments, more than in the other case.
It is hard to know in which of the two cases the line segments are longer, the data points are random.

I think you are right about the decimation along the x axis.

Any way the question is still open.

Regard,

Asper

[Darin.K]

If you do not mind losing interactivity with the graph (zoom, changing scales, cursors) or rolling your own, there is a fairly straightforward workaround that did 40000 plots of 100 points on my machine.

1) Place a Tab Control on the Front Panel.

2) Put your XY graph in Page 1, put a similar sized Picture Indicator in Page 2. Display Page 2

3) Generate the data and feed it to the XY Graph.

4) Use the Get Image Method of the XY Graph and Draw Flattened Pixmap (depth=24) to display the Image of the Graph in the Picture Control.

I usually hide the Tabs, and color the Tab Control Invisible.  Now the initial drawing is still slow, but there is no refreshing.  You can add your own controls to adjust the scales if you'd like, simply redraw the graph and update the picture as necessary.

[JÞB]

I think you are right about the decimation along the x axis.

Any way the question is still open.

Regard,

Asper

---

Well my screen is 1600/1200  so if the graph stretched over the whole thing.....  nope I cant plot more that 15990 segments of 1 pixel + the 10 start points (That seams a bit less than the 399,990 multi pixel segments):smileywink:

[asper]

Hi Darin.K,
your workaround is a small step forward, I have tested it, and the interaction of the graph panel, as picture, with the other Windows panels is more fluent.

But, as you have already noted, all the rest is still very slow, operations like resizing the panel, zoom in or out, moving the X scroll bar, etc. require a long while before to finish. A similar behavior happens changing the plot property by program, as for example the line color.

Regard,
Asper

[asper]

Hi folk,
I have got some clarifications, on the graph redrawing performance, directly from the local NI support.
The issue is well known from NI!

They told me that the graph has embedded some algorithms for decimate from the real number of lines/points to the display resolution, in pixels, and for compute the overlap between points (as Jeff·þ·Bohrer has correctly supposed).
These algorithms play every time you zoom, resize, flyovers, etc. on the graph.
The algorithms have been optimized for the standard NI solutions, i.e. for display the acquisition of a number of channels for a time or continuously, that, in other words, means a limited number of lines for a huge amount of points.
The algorithms can be scratched as two nested loops, one on the lines and the other on the points, and in total they require a number of iterations equal circa to: (number of points) * (number of line)^2.

In my case I switch from 40000*100^2 iterations to 100*40000^2  iterations, the difference is a factor 400 in time!
If in the first case the algorithm requires a tenth of second for redrawing, in the second case case it requires 40 seconds! ...

... We have observed that a possible and simple patch for the two opposite cases could be to use an IF to verify if the lines are more than the points or viceversa, and to use the proper algorithms for the two different cases. NI have observed that this is a lot of work that involve every different events of the graph.

The NI support told me that there are not short or mid term plans to improve the performance of  redrawing algorithms.

😞
Asper