Using an event structure for a UI, how to smoothly update plot overlays after multiple scale range changes

[ColeVV]

Hello!

I have created a sample peice of code to illustrate my issue, but this portion is part of a much larger section. I have a producer consumer architecture to seperate my UI from my plotting commands. I have an intensity plot which I have to put an overlay on top of, and I took advantage of some code on this thread here. This method of creating a picture over top of the intensity plot works, but is not ideal. I have to be able to save .jpgs of the graph as well as change the scales and pan the graph as there will be a lot of data. I inserted an event structure to detect when the scale ranges change so that I can replot my picture on top of my graph. This works fine for zooms (it's not hugely responsive, but it works), but when I pan a lot of "scale changes" are caught in the producer queue and are then are updated, one at a time. Because the overlay is not very responsive there is a flickering of the overlay as the consumer queue works to catch up.

As far as I can see, there are two possible routes to deal with this.

1) Make the overlay code much more responsive. If anyone knows how to do this, or a better way to do overlays, I would love to hear it. Remember that this will be used for large data sets where we have to use techniques described here.

2) Purge the queue of the extra message calls to redraw the overlay, but somehow only draw the overlay after the final scale change. I notice that the event structure has "Cursor" events as well as "Drag" events and maybe I should be taking advantage of those? I don't actually know what they do.

I have attached my example code, but please tell me if I somehow missed a file for this.

Thanks in advance!

[Mark_Yedinak]

If you know you have multiple changes to make you should disable the UI updates, make all of your changes and then re-enable the UI updates.

[ColeVV]

I don't think that will work. If I am panning my graph, which trips an event structure to tell me to stop updating the UI then I no longer have an event structure to tell me when I am done panning... Did you try the example I put in to see what I am talking about?

[Mark_Yedinak]

No, I don't have LV 2012 installed.

[ColeVV]

I think I have them all saved as 2010 now.

[Basil-B]

Hi my name is Basil with Applications Engineering in National Instruments. In your consumer loop you only have one instance of the draw plot on intensity graph. Since it is this loop that is falling behind could you try to just copy in the actual VI instead of referencing the subVI. The page you linked about memory management suggests this if you don't have many instances since calling a subVI is much more RAM intensive you could say. Also, look closely at your arrays to see where you could implement the suggestions put forth in the link you posted. Get back to us with what you find!

[nathand]

One common way to deal with this situation is to wait until a timeout occurs, then do the update. In the simplest situation, in the Scale Range Change event case you set a boolean in a shift register to true, and then in the timeout case you check if that boolean is true. If it is, do the plot and overlay update. This will help prevent multiple scale range events from queueing quickly while maintaining a responsive user interface.

[ColeVV]

Hi Basil-B,

You are correct that I am not using the suggestion from the link in this case for the mapping function. Inserting this section of code directly would avoid data copies. However, and maybe I am venting a bit here, I find this practice to be incredibly frustrating. I would like to be able to develop modular, reusable, readable code such as the subvi's I have included here, which I do use in other projects. However, because LabVIEW does not allow passing by reference as an option on the subvi, I suppose I need to write all of my functions using the techniques described here. Most of my main code, which this was taken from, extensively uses queues to try to avoid these copies. I just find my block diagram is filled now with queue vi's which make it very difficult to arrange the block diagram in a readable manner.

Thanks for the response though! If there are other techniques to get around what I described above I would love to hear them!

[ColeVV]

Hi Nathand,

Thanks for the response! I think you are right, this might be the way to go. I hadn't thought about moving the updates until after a timeout. I'll give it a shot and then get back to you with the results.

[Mark_Yedinak]

---

@ColeVV wrote:

Hi Nathand,

Thanks for the response! I think you are right, this might be the way to go. I hadn't thought about moving the updates until after a timeout. I'll give it a shot and then get back to you with the results.

---

I had started to do something along those lines to your earlier code. I still see a bit of a flicker in the display update. Maybe this can be your starting point.