LabVIEW
Draw Multiple Line for Large data
Solved!
wiebe@CARYA wrote:
@Yamaeda wrote:
Ok, so i just resaved the VI outside the LLB and removed the unnessecary I32 convertions and now i can do a Plot All in 17ms!
With a line width of 2 and 40000 coordinates, this still completely ruins my entire PC, to a point even the mouse pointer isn't moving.
It's the GDI bug...
True! 2 pixel lines took me ~30 secs. If you look inside the Draw VI it basically just makes all into a string, so i guess there's some old 16 bit code behind it and we get memory problems (definatly the latter). So a limiter/cut inside that VI to improve performance and stability is a good idea.
@Yamaeda wrote:
I've modded the function to draw in chunks, fast and works with all sizes!
Ah, it does behave better if it draws many tiny chunks.
I can draw 40000 or 40X1000 lines (2 pixels), it doesn't stop the problem. 400X100 lines is much better though, even if you feed each last point to the next iteration (or it would be cheating).
I guess this means NI could (should?) fix it.
Turning "smooth updates" on makes it behave even better, at least visually.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
@Yamaeda wrote:
I've modded the function to draw in chunks, fast and works with all sizes!
Ah, it does behave better if it draws many tiny chunks.
I can draw 40000 or 40X1000 lines (2 pixels), it doesn't stop the problem. 400X100 lines is much better though, even if you feed each last point to the next iteration (or it would be cheating).
I guess this means NI could (should?) fix it.
Turning "smooth updates" on makes it behave even better, at least visually.
yeah it seems to work fairly well with 1k chunks but since there was no downside with 100 element chunks i went with that. 🙂
@Bob_Schor wrote:
Sigh. I still fail to understand why you insist on using a "picture" system for plotting a lot of points (which, after all, is what an XY graph is designed to do, while I think of a "picture" as "create regions of various kind, such as polygons, circles, text, etc.". One works spectacularly well (largely because it was designed to do that), while the other has led to a long, multi-day, discussion that still doesn't answer the "Why?" question.
Could you please explain? "I was just curious" is perfectly OK, but then please drop the topic!
Bob Schor
One reason would be if you want more than points and\or lines, other point\line combinations than a graph supports.
This actually happens fairly often to me, having costumers with 'out of the box' requirements. For showing a rectangular selection in a 2D graph for instance, the picture overlay is great.
Another is if the number of lines is ridiculously high (like, adding 10k lines at 10 Hz, for hours) and has to update very frequently. A picture with only the new lines merged into a 2D raster image works really well. A normal graph, in my experience, stops being useful if there's more than 70 MBi of data in it.
You can get the best of both (Solved: Re: Plotting Types - NI Community).
With a good library of picture control functions it doesn't take that much time.
I agree XY graph is the right control, if I am only plotting the points.
In my application, there is a predefined template that includes axis scales, notes, annotations, limit lines and images. I need to scale the canvas to the physical dimension based on the overlay, so the user can check the transparent overlay or Digital Overlay against the picture control on the monitor. In the below picture I am holding the overlay on top of the picture control to check the pass/fail. I can auto detect the pass/fail If I have digital overlay.
I use the PPI and Resolution to scale the picture to match against the overlay, so I can make it work for different monitor sizes and resolution.
User can also print the picture and check the print against the transparent overlay sheet to determine the pass/fail result.
I can easily scale the picture control for different overlays and paper sizes, All these options are not easier using XY Graph.
Let me know, if you think any other better solution to meet these requirements.
Thanks for the multi-week discussion on this topic and all your inputs. I learned and enjoyed this discussion.
As has been said in many forms, it is completely pointless to draw so many lines, either on a picture control or on an xy graph. You don't have enough pixels to see even 10% of the data because everything overlaps. In my example using the intensity graph, we map the data into a fixed memory space (2D array) and once the 2D array is complete, you can convert it to an image for display. (no intensity graph needed). That 2D array can beU8 for up to 256 different colors and the memory used is constant, even if you would "draw" a billion points!
@altenbach wrote:
As has been said in many forms, it is completely pointless to draw so many lines, either on a picture control or on an xy graph.
The user could zoom in...
@altenbach wrote:
You don't have enough pixels to see even 10% of the data because everything overlaps.
That's true, but simply omitting points does show. Not everything overlaps. If you incidentally remove min or max values (e.g. by averaging), it will look different. To do it right, you have to take the entry point, min, max and exit point of a block that covers a pixel. Then the decimated data will look as if all points where drawn.
Sadly I manually have to add decimation, if this situation is there.
200 tags, 7 days, 1 Hz data just doesn't work in native graphs. And the user wants to see all data, and still be able to zoom in on a single minute.
