picture control speed/memory concern

[jyang72211]

In the attached picture of code, it draws a bunch of rectangle over (70k) based on the input array of rect clusters.  At the beginning of the program, the rectangle are drawn at a good speed, but the speed will slow down dramatically as the program process.  Is there some kind of memory problem? How do I fix it?  

[tst]

The picture control is basically a tool which takes a series of instructions for how to draw something and then draws them. What you're doing in your code is continuously adding more and more instructions to that series. You can see this if you convert the picture to a string (a simple concatentate will do this).

Here are some options:

1. Get rid of the shift register.
2. Make it so that you only add to the shift register when there is an actual change.
3. Convert the picture wire to a pixmap and keep that instead of the picture wire. The pixmap describes the actual pixels, so assuming your picture stays the same size it should never grow.

[jyang72211]

I have some questions (see bold) on your options.  Please see below.  I am trying a map that is made up of 70k small rectangles.  The color of the small rectangles are determined at run time, so I don't have all the information in advanced before I start drawing.  

---

@tst wrote:

The picture control is basically a tool which takes a series of instructions for how to draw something and then draws them. What you're doing in your code is continuously adding more and more instructions to that series. You can see this if you convert the picture to a string (a simple concatentate will do this).

Here are some options:

1. Get rid of the shift register.  Do you have I should uncheck the "erase first" option, and just draw onto the picture control without using the SR?  I tried doing that, and some rectangles I drew previously would get erased.  
2. Make it so that you only add to the shift register when there is an actual change.  There is an actual change everytime.
3. Convert the picture wire to a pixmap and keep that instead of the picture wire. The pixmap describes the actual pixels, so assuming your picture stays the same size it should never grow.  Can you elaborate on that?

---

[tst]

Getting rid of the SR probably won't help you if you want to keep all the previous data. Unchecking erase first might help with that, because then the indicator should keep the previous data, but I don't have enough experience with it. Also, the series of instructions might still be kept in the indicator itself (I'm not entirely sure how unchecking the option affects it).

Like I said, the pixmap basically describes each individual pixel image, instead of having a series of instructions. That makes its size constant. You can convert the picture wire to a pixmap using the picture to pixmap VI and then convert it back using the draw flattened pixmap VI (or unflattened, because there are two pixmap data types). The pixmap is then what you keep in the SR and every time you append a command, you convert the pixmap, add the command to the stream, and then convert it back to a pixmap.

[jyang72211]

Actually getting rid of the SR works with erase first uncheck work for me.  It tried that before, and it didn't work.  I think it was because I had another bug in my code, which was fixed later on.  

However, I noticed one problem.  When the small rectangle are being drawn in loop, sometimes a few rectangles would be missing.  It seems like they were skipped.  Not sure why.  When I slowed down the speed of the loop, I think that helped.

[tst]

---

@jyang72211 wrote:

However, I noticed one problem.  When the small rectangle are being drawn in loop, sometimes a few rectangles would be missing.  It seems like they were skipped.  Not sure why.  When I slowed down the speed of the loop, I think that helped.

---

Probably a matter of async display - LV doesn't actually update the display as soon as you put something in an indicator. I'm not sure if it just waits or if it simply updates the display at a constant rate, but that doesn't actually matter. The point is that if your code is fast enough, there are certain values which will never actually reach the indicator. Normally, that's not a problem, because another value came in their place, but in this case you have a problem because of the DNE setting which allows you to see that they weren't actually drawn.

If you set the async display option on the control, you will probably see that it updates every time, but you will then also see that the loop is running very slowly because of that.

[jyang72211]

Turning on sync display will work, but how bad would it impact my code's performance?  I really need all rectangles drawn on the 2d Picture, but I can't afford to let it pull down my speed.  I don't mind my UI to update with a little lag, but all rectangles must be drawn.  

i am going to have a few threads in my program.  I will dedicate a thread for UI.  If I do that, can I avoid slowing down my other thread?  

I just want all values to be display on the screen without allowing the UI to slow down my critical threads.

[tst]

My very limited experience with the SD option is that it really slows down the loop it's in. If your other code doesn't have any UI interaction, then it's possible that it will run in other threads, but your control over that is limited unless you place it in another VI (and even then you need to make sure that there is nothing in the code that will force it to run in the UI thread).

I would suggest that you simply go with the pixmap method instead of relying on the indicator's erase first property.

Alternatively, you could create an array with 70k empty pictures and simply place the command from each iteration in the appropriate index inside that array. Then, wire that array into a concatenate string node and it should convert it into a single picture (although it would require the allocation of the memory for that string at least once and I'm not sure how large that is).

[jyang72211]

Actually, I dont' need to save all the data points.  I just need all data points to be drawn on the 2d picture indicator.