Memory problems with a picture wired to a shift register?

[DeltaJ]

Hi All,

I have two questions I hope you can help me out with:

1. I am building an application where a user selects a number of buttons. My GUI essentially looks like an array of booleans. However for some additional functionality (I wanted to click and drag across the buttons to change multiple values and I could not figure out how to do this using a Boolean array) and also for appearances I have decided to use a picture as my interface. The picture is approximately 400pixels by 300pix. Clicking on the picture reads the mouse co-ordinates which in turn updates an array running in the background. (An array of clusters containing a Boolean among other data - see Data In in attached image).

This array is accessed by my subVI to update the picture on the front screen. The array is indexed in a for loop and two circles are drawn - one filled and the other adding a black border:

The VI functions perfectly well. However after selecting and deselecting the buttons a few times the frontscreen starts to slow down. Some other functions start to lag and the CPU also starts to struggle. Removing this subVI allows the frontscreen to run as usual.

Initially I used this subVI to update all the buttons (about 100) for each iteration. Within about 10 mouse clicks (1000 iterations of the For Loop) my PC had visibly slowed. The front screen gets progressively slower with every mouse-click - essentially every time this VI is accessed. I suspect that each iteration of the loop is adding memory to the shift register which is slowing my PC. However this makes no sense to me as I am not adding data to an array in the shift register, and the register is pre-initialised each time the VI is accessed.

I've since re-written the code to only update the buttons whose value has changed (about 6 per iteration) and the performance has improved enough that I can probably proceed with my project. However it is bugging me that I can't figure out why my code is slowing by so much.

I have seen a few hints in the forums that might point me in the correct direction. For example one post mentioned that an image wire (is this the same as the picture wire I am working with?) is a reference to where the data is actually stored. So perhaps the pictures are not being over-written because they are not actually 'in' the shift register? And can anyone suggest a better way of handling this task? For example one thought I had was perhaps converting the image to an RGB array for storage in the shift register, back to an image in the loop for drawing the circles and then back to an array in the shift register? Or is there a way to deallocate memory from a shift register once it has been accessed and used?

Any suggestions would be greatly appreciated as I can't really see a problem with what I consider a relatively simple subVI!

2. The second question is possible how to approach the obvious solution. If I rebuild my program to use an array of booleans in place of my picture control, is there a way of selecting multiple buttons by clicking and dragging the mouse across the array. Similar for example to selecting multiple cells in excel?

Thank you,

Dave

[MikeS81]

Hi Dave,

you can make some tests with the "delete first" property of your picture indicator.

You can also read about it in this thread.

Mike

[DeltaJ]

Hi Mike,

Thanks for the suggestions. I tried the 'erase first' idea but unfortunately it made no difference to the performance of my code. I had a look through the linked nugget but again nothing leapt out at me that may be a solution.

Thanks,

Dave

[Ben]

I think you are piling all of your draw commands.

As a quick test type cast your picture wire as a string and drop a string lngth with indicator so you can see how big the data in the picture wire is. To avoid the pile up start with a blank picture constant(erase if you want) so that you don't keep building a bigger and bigger draw list with each update.

Ben

[DeltaJ]

Hi Ben,

I think you are correct about piling images on top of each other. I actually tried this (rather horrible, CPU intensive) work-around to not wire pictures into the shift register:

I found that the subVI executed much more slowly but that there was no 'on-going' effects on the performance of the overall program. Once the buttons had been selected the front-panel responded as quickly as it should. The postive is this works for me when I only select 6 buttons with one click (part of my app) but in the future I'll have to select 100 buttons with one click and testing this does show a visible time lag. So a proper solution rather than a work around would be for the best

I've also tried to typecast the picture wire to a string and got a broken wire! However the 'flatten to string vi' did the job and I tried what you suggested. Each time I click on a well the subvi is executed 6 times. I fed the string length into an array and got a 'wire size' for each loop iteration. 

What you see is my base size seems to be about 11000 bits. Each saw tooth corresponds to a click of the mouse. So the wire size is definately growing  more every time....although it seems to be starting at the same size each time also! I have to be honest and say I don't really get whats happening here! And also this is just 6 loops of the for loop - I'm sure with 1000 it must grow massively!

As for your suggestion could you clarify where I should put the blank picture constant on my VI in order to avoid the draw list?

Thanks a million,

Dave

[DeltaJ]

Just as an extra I tried measuring the wire size in the 'work-around' and it remained constant. If only it wasn't so CPU heavy!!!