Loop delay when using two VI's with picture controls simultaneously

[dnorman]

Hey all,

I have observed an odd behavior and I'm not quite sure why it happens. I have two VI's that are mapping GPS coordinates onto XY graphs that are displayed on top of picture controls. When the maps from both of the VI's are visible on screen the loops get delayed by as much as a second, but if you just cover the map portion with another window they go back to looping at twice a second as they should. It took me a little while to figure this part out, let me tell you. There are no computing limitations that should be affecting it since my CPU is only at 10-12% and have 4GB of RAM available. I checked the GPU too just in case and it was sitting at 3% usage, so no hold up there. Anyone have any experience with something like this happening to them? It has me stumped.

I though it might have to do with how LabVIEW handled them, so I went ahead and made them into EXE's and tried it out with the same results.

Thanks in advance for any help or suggestions,

dnorman

[tst]

When you layer controls on top of each other, LV is forced to redraw the complete control every single time, which is probably what's causing this issue. The GPU being idle is a red herring, because as far as I know, LV still doesn't have any hardware acceleration for drawing this stuff. Not very 21st century, I know, but that comes with an old code base that has to be supported on several different platforms.

One practical solution for your issue would be to draw the picture into the graph indicator. The indicator should have a property for a background image and a foreground image.

[dnorman]

I had heard about the redraw before, but thought since the system wasn't being fully utilized it might be something else. I didn't know about the background image option on the graph though. I would have to change how I handled zoom and origin on the picture if I went this route, but good to know either way, thanks.

[dnorman]

I just ran my exe on the type of computer it will be deployed on, a industrial tablet with a atom processor, and it maxed out one of the cores. My picture control consists of multiple image tiles that are combined in to the control. Is it possible to run the redraw of the picture tiles in parallel, on multiple cores, if they are going into the same control?

[tst]

---

@dnorman wrote:
Is it possible to run the redraw of the picture tiles in parallel, on multiple cores, if they are going into the same control?

---

I doubt it. Even if the picture control wasn't pretty old (and it is), I don't know of any mechanism which will give you this level of control.

Here are potential options. I have no idea if they will help:

1. Instead of building separate commands, process the data in such a way that you have a single raster image (i.e. a 2D array) to place into the control. I believe this should be faster.
2. Use another type of display (such as a .NET indicator).
3. Instead of using the XY graph, overlay the data directly onto the image (there should be some graph VIs in the picture palette which might help).
4. Try defering panel updates before updating all the controls and undefering after. I don't think this will help, but it's probably the easiest change to make.

[dnorman]

Thanks again for the help. I will look into your suggestions, but I know I can't defer panel updates. I have video feed coming through on the FP that needs to be current.