LabVIEW
Draw Multiple Line for Large data
Solved!
Obviously a picture control is not suitable for that kind of use and I really question the sanity to draw tens of thousands of thick lines in a small canvas. Do you really need lines at all?
In any case, the problem seems to be with the linewidth. Set it to=1 and see if things improve.
I have it on a different computer and can show a picture later.
The code has several serious flaws, such as using a shift register and "delete from array" inside a tight loop to process successive "subsets" (hint at the correct function 😄 ), but that's not the main problem.
My guess is that drawing a multiline with tens of thousands of segments at once overloads the UI threads and starves computer resource (probably more than just CPU and memory, maybe GDI?). I actually had it lock up the computer and crash the mouse driver. No fun!
It would be trivial to map the data into a 2D array first then display it in an intensity graph or convert to an image. An example can be found here.
Under the hood, a 2D image in LabVIEW is very ancient technology, probably dating back to windows 3.1 or earlier. We can look inside the image tools and all they do is basically append binary strings with opcodes and data. We can actually use "string length" to measure the data size of an image wire. (see also this old post for an illustrative example how to accidentally consume all memory!)
Here is the original code (as a picture). The trick is the data, shown as a constant array of clusters (x, y) -- there are 45000 entries! It took my PC about a millisecond to plot the first 10,000 points (which looks like a noisy sampling of an X-Y plot of an oval). I've exported the array to a Control, so I could size it and get its max and min. I'll include the Front Panel, so you can get an idea of the data.
Note that the code below the Frame Structure is code I added -- "Data to plot" is a copy of the Cluster being plotted that I used to find its size and the ranges of x and y.
Bob Schor
@Ben wrote:
It is a variation on HPGL HP Graphic Language used for pen plotters, Move Pen, Pen Up,...
It is a string under the hood.
Two things that sped up picture drawing was
Erase first
FpDefUpdat ( defer first, draw, undefer)
Ah, that brings back memories. I actually generated HPGL code in Fortran in ancient history. Had the HP plotter in eavesdrop mode on the 9600 baud serial line between VT 241 terminal the VAX mainframe. 😄
The other two points probably make no difference here. It starts with an empty picture and the picture indicator can be placed after the sequence structure and things are still gummed up. The slowdown is deep inside draw multiline but there is really not much code visible Maybe it happens when the string is converted to an image wire? Nothing else updates in the front panel. (And if we do it in chunks (code not shown), we cannot erase until all chunks are written and things are fast in that scenario.).
Once that slow picture is drawn on the FP, the VI becomes basically unusable, even in edit mode.
I still suspect that the main problem is GDI exhaustion. My computer went completely haywire and unresponsive. Mouse/keyboard came back after unplugging/plugging to redetect the device. At one point I got a blue screen stating "preparing security options..." or similar. Never seen that before). Make sure to save all work before event attempting to play with any of this! No fun!
It is pure insanity to create tens of thousands of double-width lines just to basically turn a few image pixels black.
I wonder how much effort it would take to rewrite the picture function using more modern tools.
Sorry, just rambling with partial information and guessing. Maybe somebody has more insight!
