2D picture control performance

[Philippe_RSA]

The 2D picture control performance does not appear to follow standard LabView conventions. What is the most efficient way to continuously add elements to a 2D picture control?
Attached is a sample vi, which has 3 scenarios, each with very different performance..... what is happening?

[wiebe@CARYA]

There's only one scenario, as far as I can tell.

You're continuously adding items to the picture. Drawing them will take longer and longer.

The picture control data is basically a string, and that string is used to render. The string gets longer and longer, and the rendering will take longer and longer.

That follows every LabVIEW convention I know of, and also all general programming conventions I know of...

If you don't want the rendering time to increase, you need to figure out a way to not increase the data. For instance, render, convert the picture to a pixmap. Next cycle, draw the pixmap, render over it. Etc. This takes longer for a few items, but the rendering will be stable, since the data won't grow.

[GerdW]

Hi Philippe,

you forgot to attach subVIs - and used too many local variables:

[wiebe@CARYA]

Another 'cheap' way to do this is by untagging the 'Erase first' option, and ditching the local in. This will render the new picture, but as it won't clear the previous lines, they will overlap. This might not work when hiding\opening the front panel, as that might clear the picture anyway. I don't really know.

This is in a way the same solution. Both solutions buffer the rendered image, not the raw data. The first method gives you full control over the rendered buffer, but if you can get away with letting LabVIEW do it, I don't see any objections. 

[wiebe@CARYA]

Something in the lines of this.

Conceptually. This would be nice to put in a class.

I draw poly lines, since you didn't post the sub VI. But this would work no matter what you draw.

This won't work if you plan on using the zoom of the picture control. It will zoom, but you'll be zooming in on pixels, not vectors.

[Philippe_RSA]

The sub-vi is a standard picture vi, so LabView refuses to add it automatically to my llb.
Did a manual addition as attached.... not so cool.

Using a local variable vs using a shift register does not appear to improve performance.

[Philippe_RSA]

The "clear" button in my code appears to do the same, but under the hood....
Is it possible "clear" is making a bitmap?
By doing this infrequently (once a second instead of every loop) appears to give a performance boost also.

[wiebe@CARYA]

---

@Philippe_RSA wrote:

Using a local variable vs using a shift register does not appear to improve performance.

---

Of course not. You still get the infinite data growth.

But you avoid a race condition. You're setting a local, while reading and writing a local. This means the first write can be undone by the read\write in the other loop.

[wiebe@CARYA]

---

@Philippe_RSA wrote:

The "clear" button in my code appears to do the same, but under the hood....
Is it possible "clear" is making a bitmap?
By doing this infrequently (once a second instead of every loop) appears to give a performance boost also.

---

The clear will clear the data, so it will be fast for a while. But you've also lost all data.

I was assuming you want all previous data to appear, because that's what you programmed. And that's what the computer is doing.

If you don't want previous data to be drawn, why would you use locals or shift registers to get previous data? Why not simply draw the current lines and put them in the picture control?

[GerdW]

Hi Philippe,

---

@Philippe_RSA wrote:

The "clear" button in my code appears to do the same, but under the hood....
Is it possible "clear" is making a bitmap?

---

The clear button calls a case where you write an (apparently) empty image constant into a local of your 2DPictureIndicator…

You know there is an "Empty image" constant in the picture functions palette?

Your indicator is set to "antialiasing" the image: this may also have some influence on performance!