LV8.2 X-Y Plot Background Image

[Gary Rubin]

Hi all,

For one of our applications, we want to plot points on a polar plot, using lots of different colors for the symbols.

I figured there were two solutions for this:

1) "manually" draw the plot symbols in the polar plot picture indicator (ugh)

2) create the polar plot picture control, and put a transparent x-y plot on top of it.

I elected to go with option 2, knowing that my performance was probably going to suffer a bit because I've got a transparent front panel object overlapping another object.

I was therefore pretty excited when our local NI rep told me about the new "background picture" feature of LV 8.x X-Y plots. I was hopeful that a single integrated indicator that contains the foreground X-Y plot AND the background would be more efficient at redrawing itself than my transparent overlay approach. Instead, I've found the following (see attached):

- If the background picture is not updated, the transparent X-Y sitting atop a picture indicator runs just as fast as the new X-Y with background picture.

- If the background picture IS updated, the new integrated background picture is actually a factor of 8-10 SLOWER than the transparent overlay (I suspect this is because of the property node)

So, what gives? What benefits do I actually get from the new background picture feature?

Thanks,

Gary

Download File:post-4344-1160503832.vi

[Born2Wire]

Hi all,

For one of our applications, we want to plot points on a polar plot, using lots of different colors for the symbols.

I figured there were two solutions for this:

1) "manually" draw the plot symbols in the polar plot picture indicator (ugh)

2) create the polar plot picture control, and put a transparent x-y plot on top of it.

I elected to go with option 2, knowing that my performance was probably going to suffer a bit because I've got a transparent front panel object overlapping another object.

I was therefore pretty excited when our local NI rep told me about the new "background picture" feature of LV 8.x X-Y plots. I was hopeful that a single integrated indicator that contains the foreground X-Y plot AND the background would be more efficient at redrawing itself than my transparent overlay approach. Instead, I've found the following (see attached):

- If the background picture is not updated, the transparent X-Y sitting atop a picture indicator runs just as fast as the new X-Y with background picture.

- If the background picture IS updated, the new integrated background picture is actually a factor of 8-10 SLOWER than the transparent overlay (I suspect this is because of the property node)

So, what gives? What benefits do I actually get from the new background picture feature?

Thanks,

Gary

Well for your application, none. However in my last project it was decided to add fancy background graphics (stills) to make the product look more attractive to the customer. Since this was 7.1, the solution was a bit painful and we all had to learn not to touch the various panels for fear of getting everythng misaligned.

[Mike Ashe]

Hi all,

For one of our applications, we want to plot points on a polar plot, using lots of different colors for the symbols.

I figured there were two solutions for this:

1) "manually" draw the plot symbols in the polar plot picture indicator (ugh)

2) create the polar plot picture control, and put a transparent x-y plot on top of it.

I elected to go with option 2, ... <snip> ...

So, what gives? What benefits do I actually get from the new background picture feature?

As someone else pointed out, not much. Might I humbly put in a plug for reconsidering option 1? In my estimation, the picture control is one of the most powerful, yet under utilized features available in LabVIEW. Yes, it will take a little work to get going, but a few *well thought out* VIs for implementing your current requirements using the PC could be very handy later down the road.

YMMV, good luck

[Gary Rubin]

Might I humbly put in a plug for reconsidering option 1? In my estimation, the picture control is one of the most powerful, yet under utilized features available in LabVIEW. Yes, it will take a little work to get going, but a few *well thought out* VIs for implementing your current requirements using the PC could be very handy later down the road.

I'll have to give it a try sometime. This project is actually going to be moving away from using its own display - instead passing data to an existing display. Because of that, I not sure it's worth spending the time to do a major rewrite of the plotting method. It does, however, sound like something I should play with in my free time.

I can see where the flexibility of drawing your own pictures could be very powerful, but what about performance? How does running though all the picture control routines compare to just wiring into an indicator?

Are there any resources that you can recommend that will give me an idea of smart vs. dumb ways to do things? For example, is it best to always erase first (I would guess not)? Does it make sense to try to keep track of "foreground" vs. "background" pixels to avoid redrawing the background when not necessary? That then gets a little complicated because removing a point would require replacing its pixels with whatever was there before (i.e. the background).

Thanks,

Gary

[JasonKing]

Gary:

Your timings aren't really making a fair comparison. There are a few things to note.

1) The time to write a value to a terminal does not include the time to actually draw the updated value, unless you have Synchronous Display turned on. Try your timings with sync display on and off for the graphs, and see how the timings change.

2) Writing a value to a control's terminal is considerably different from writing the value property. Not only is there the overhead of the VI server call (which in most cases requires a switch to the UI thread), but the call does not return until the control/indicator draws with the new value. Thus, the two calls are not equivilent if you are trying to time them and compare the efficiency. Therefore, in the first case you are not including the time to actually draw the picture control, while in the second you are.

3) In both of your loops, there is a race condition between when the picture gets updated and when the data does. While in the first case, the graph will get invalidated every time the picture gets a new value, in the second case, the graph almost certainly redraws itself every time the background image gets updated. This means that, in both cases, we may draw the data twice for a given iteration if the value is written and then the picture gets updated. I believe over the course of many iterations this should average out, this is another inconsistency that can remove a bit of confidence in comparison of the timings.

In summary, I don't think your timings are accurate. Now, it may still be the case that the first implementation is faster, but I highly doubt it's by the factor that you see.

Okay, I got over my laziness. If you turn on synchronous display for both the graphs and the picture control, you'll see that #1 is about twice as fast as #2. I don't think this should be the case - chances are we're just being stupid somewhere in the drawing code - but it's certainly a more fair comparison than what you initially discussed. If you change the first implemtation to use a property node for value rather than the terminal (to remove the discrepancy in VI server overhead), you'll see that it takes about 1/3 as long. I cannot explain why this speeds things up, but it's still not as bad as the original numbers you quote. It does look like the picture control is a bit smaller than the graph, so you're drawing a little bit less, but I can't see that explaining the difference.

Again, I'm not sure why the built-in option is slower, but at least it's not as bad as you thought

J

[Gary Rubin]

Jason,

Thanks for your feedback.

I believe we've delivered our only copy of LV8.20 along with a customer system. I therefore can't open my own attachment to review your points.

Would you (or someone else) mind posting a screenshot of the BD so I can look at it again?

Thanks,

Gary

[JasonKing]

It turns out I was wrong in a couple of my assertions above. To clarify:

1) In any timings, the cost to draw the picture control in the first implementation will not be timed. Because the picture control is overlapped by the graph, we will not draw immediately and instead will invalidate our bounds to make sure we re-draw with the new value in the correct z-plane order.

2) Writing any of the plotimages properties of the graph will not cause an immediate draw of the picture data/graph (instead we just invalidate and come back and redraw later). As such, the cost of this call is simply the VI Server overhead and the time to copy over the new picture string. Thus, in neither implementation is the cost of drawing the picture taken into account, except as described in #3.

3) When we draw the graph in the second implementation, we are also forced to re-draw the picture data as well. Thus, the time to update the data of the picture control will include both drawing the plots as well as the picture data. This explains why implementation #1 appears faster than implementation #2. The drawing of the picture data is not measured in #1 (there really is no way other than to pull the graph off of the picture control to ensure we draw immediately). This explains why #1 appears to be faster than #2.

J

[Gary Rubin]

I've attached an 8.0 version of my edited VI to this post.

Don't have access to 8.0 right now either.

3) When we draw the graph in the second implementation, we are also forced to re-draw the picture data as well. Thus, the time to update the data of the picture control will include both drawing the plots as well as the picture data. This explains why implementation #1 appears faster than implementation #2. The drawing of the picture data is not measured in #1 (there really is no way other than to pull the graph off of the picture control to ensure we draw immediately). This explains why #1 appears to be faster than #2.

disclaimer: I'm going on memory that implementation #1 is the overlaid controls and implementation #2 is the new LV8 background image. If this is not the case, please ignore the following comment

So, does that mean that despite the warnings about overlaying transparent controls on top of other controls, that's still more efficient than using the new background image feature?

[JasonKing]

Your memory serves you correctly regarding which implementation is which (I've attached a screenshot of the diagram to this post).

As far as your conclusion...I suppose it depends on what you mean by "efficient". I would summarize it this way: using the transparent graph on top of a picture control does not require a redraw of the picture control every time the graph is updated. However, when using the bgimage of the graph, every time the graph gets redrawn (with new data, etc), the picture must be re-rendered from the picture string (we don't even cache the picture image like we do in a picture control - I'm not sure why we chose to implement it this way as it's inefficient).

There's still some quirkiness in the timings I can't figure out if synchronous display is not turned on for the graphs, but it shouldn't invalidate the statement above.

The main benefit to the built-in picture properties of the graph really shouldn't be looked at from a performance perspective, but rather that it makes it easier for one to align the picture with the actual data points of the graph.

Does that all make sense?

J

And another note, regarding overlaying controls. It's one thing if the graph is transparent and placed over a control. It's a whole different issue if a control is placed on top of the graph. Any object that has another object on top of it is forced to redraw inefficiently, as we must ensure that we draw back to front.

J

[Gary Rubin]

As far as your conclusion...I suppose it depends on what you mean by "efficient". I would summarize it this way: using the transparent graph on top of a picture control does not require a redraw of the picture control every time the graph is updated. However, when using the bgimage of the graph, every time the graph gets redrawn (with new data, etc), the picture must be re-rendered from the picture string (we don't even cache the picture image like we do in a picture control - I'm not sure why we chose to implement it this way as it's inefficient).

By "efficient", I am refering to writing the code in a way to minimize the CPU cycles needed to execute. It sounds to me that overlaying a transparent graph on a picture control provides the same UI look-and-feel as using the bgimage, and does so with less CPU time devoted to the UI thread. Is that correct?

The main benefit to the built-in picture properties of the graph really shouldn't be looked at from a performance perspective, but rather that it makes it easier for one to align the picture with the actual data points of the graph.

You certainly have a point there - it took a good half-day to get everything lined up, and if I want to change the size I've got to do it very carefully. I guess that's consistent with the whole Express VI philosophy (and any high-level language, for that matter); you're sacrificing some speed and efficiency in exchange for ease of programming.

And another note, regarding overlaying controls. It's one thing if the graph is transparent and placed over a control. It's a whole different issue if a control is placed on top of the graph. Any object that has another object on top of it is forced to redraw inefficiently, as we must ensure that we draw back to front.

Are you saying that a transparent control on top of an indicator is a bad thing, but a transparent indicator on top of a control isn't so bad? Hmm, that's interesting.

Thanks,

Gary

[JasonKing]

By "efficient", I am refering to writing the code in a way to minimize the CPU cycles needed to execute. It sounds to me that overlaying a transparent graph on a picture control provides the same UI look-and-feel as using the bgimage, and does so with less CPU time devoted to the UI thread. Is that correct?

Yes, you are correct. Overall, likely less work is done to draw the transparent graph on top of a picture control rather than the graph+picture control if you are regularly updating the data in the graph (and not the picture control). If both are being updated, then approximately the same amount of work is being done.

Are you saying that a transparent control on top of an indicator is a bad thing, but a transparent indicator on top of a control isn't so bad? Hmm, that's interesting.

No, what I'm saying has nothing to do with control vs indicator. Given a control or indicator that has another object on top of it, whenever that control/indicator gets a new value there is a penalty to being redrawn, as we must not only redraw the control/indicator with the updated value, but the object on top of it as well. If instead the control/indicator is on top of another object, when the control/indicator gets an updated value we must only re-draw it, as re-drawing it does not affect the object below it. Transparency really isn't a factor in this issue.

J

[Gary Rubin]

Thanks. I am grateful for the explanations of Labview's inner workings from you and the other NI experts who hang out here.

Gary