LabVIEW
2D picture control performance
Since there is no other loop, there is no race condition.
Yes, this example was purposefully trivial, such that these other situations are irrelevant.
Basically I am trying to determine what the instruction below does (equivalent to empty picture), as it clearly not erasing data (that I do using the property EraseFirst node), yet using this occasionally (every few seconds) appears to give a huge performance boost.... but using it every loop kills performance.
P.S. yes I want to keep all the data points, and not actually clear the image.
Hi Phillippe,
@Philippe_RSA wrote:
Basically I am trying to determine what the instruction below does (equivalent to empty picture), as it clearly not erasing data (that I do using the property EraseFirst node), yet using this occasionally (every few seconds) appears to give a huge performance boost.... but using it every loop kills performance.
That code is writing an empty image into a local of your picture indicator - in parallel to the FOR loop draing new points into the picture indicator while reading from another local of that picture indicator.
Clearly a BIG RACE CONDITION!
Please implement the shift register suggestions you got several times now, then test again…
Another point:
In each iteration of the While loop you draw 100 points into the picture. That picture is 300×300=90k pixels in size - but when running the VI from my message #3 I quickly came to count>10000 and so was drawing >1M pixels into that picture. This whole test is kind of nonsense: when there are only 90k pixels available you don't need to draw >1M points (with additional antialiasing)…
Your whole test VI could be replaced by an IntensityGraph displaying a 2D-array of 300×300 elements, with a color ramp according to the point colors you use right now. This would be much quicker!
Okay think of the 2D picture data type as a string...because it is. If you have a string in a shift register, and you append new text to it (which is what the drawing function does) and then loop that forever, your string length will grow forever. It is like drawing something, then drawing something on top of it, and something on top of that over and over again.
I asked a similar question a while ago here. On the best way to handle this. One method is to occasionally flatten the image, getting rid of any image data, under other image stuff. The first VI in that post shows a potential work around by flattening the image, then drawing one thing on top. For me the real solution was to keep track of the 10 separate images, then concatenate them (yes that function works on the 2D picture) into the final image. This eventually became the Ribbon Interface I made here.
Thanks GerdW
I have made the changes you recommend: the shift register (on both the for and while loop).
This gave no obvious performance boost. However the "clear" button no longer has any effect (I no longer get a performance boost when I click on the button). In total I get therefore get a worse performance.
Of course, when I put the indicator outside the for loop (so it displays 100* less often), then I get a 100* performance boost (see below). Yes this is a solution for this trivial example, but it is not an answer to my question: in my actual application I do not have this luxury of updating the display 100* less frequently.
Interestingly however is that in this optimized version (displayed 100* less), the front panel becomes unresponsive very quickly unless I add a wait instruction.
Of course in this particular trivial example, I can make a picture, save a picture etc, or even simply use a different indicator (XY graph, intensity graph, 3D picture etc), but the question was a request for information.
Hi Philippe,
@Philippe_RSA wrote:
However the "clear" button no longer has any effect (I no longer get a performance boost when I click on the button). In total I get therefore get a worse performance.
Because you didn't implement the "clear" button like I did.
(Because you replaced the race condition by a Rube-Goldberg construct: it doesn't matter when you write to the local, when the indicator is written to from the shift register!)
@Philippe_RSA wrote:
in my actual application I do not have this luxury of updating the display 100* less frequently.
How often do you need to update the display?
On a default monitor 60Hz could make sense, for humans 20Hz should be more than enough…
@Philippe_RSA wrote:
Yes, I had read your post, and hence was aware that the shift register does not work the same way for a 2D picture.....Nice work.
How does it not work exactly the same way as anything else?
It does.
If you put an image in a shift register, and use it as input to new drawing functions, the drawing functions are added to the previous drawing functions.
This is starting to feel repetitive...
Maybe I'm missing the point of what you're trying to do, but if you 'flatten' the image (to pixmap) and put it in a shift register, you can 1) keep adding, 2) get a constant speed and 3) clear the image easily. See this answer.
Search LabVIEW like a graph!
@Philippe_RSA wrote:When I "clear", I get a performance boost, and the reason appears to be a mystery.
Could it be... The data is growing and growing? Maybe flattening the data to a pixmap will help?
@Philippe_RSA wrote:Do I need to optimise code..... yes, we all do (Microsoft included ha ha ha ).
No, we don't.
Code shouldn't be optimized unless it proofs to be too slow.
