Picture Indicator slows down front panel

[MGyamfi]

Hello folks,

I would like to use the picture functions vi's to draw alot of dots on a bitmap.

Problem is, that after a certain amount of dots (>10k) the vi starts to slow down if I show the indicator of the picture.

However when I use a picture to pixmap and then redraw the picture from the pixmap the front panel indicator doesn't slow down the vi at all.

I would be very grateful for a more elegant solution to this problem other than redrawing the picture from a pixmap.

Best regards,

Mark

[kegghead]

I don't think there's a more elegant solution. When using the picture control you need to decide which is more important, leaving the raw op-code based string or converting it to flattened pixmap data. The original picture data scales really well but renders very slowly, whereas the pixmap data renders very quickly but scales very poorly.

In my applications I ususally keep a cached copy of the raw picture data so when I need to export data (say to the clipboard) I can produce vector style images, but I always display the flattened data so it renders more quickly.

[johnsold]

Mark,

When the image has more datapoints than the image has pixels or when the new image overlaps part of the old image, things can slow down.

But I suspect that the real problem is the re-allocation of memory as the picture string grows.  Open the Draw Point.vi and Set Pen State.vi block diagrams and you will see that each of them does a Concatenate String operation.  Strings are stored in memory as a 4-byte length and an array of characters. Like any other array, the string elements must be in contiguous memory locations. So, as the string grows, frequent memory re-allocations must occur.  This can slow things dramatically.  The way those picture VIs are built there is no way to effectively pre-allocate the memory.

I do not know how effective it might be, but you could rewrite those VIs to use arrays of U8, Initialize Array, and Replace Array Subset, followed by Byte Array to String.  Then only one memory allocation wold be required.

Lynn

[kegghead]

But I suspect that the real problem is the re-allocation of memory as the picture string grows...

While everything you say with regards to arrays and concatenation is of course true, notice that even when the VI is not running, the front panel behaves very slowly if a lot of non-flattened data is drawn. In this case it's all in the rendering behavior of the indicator since the VI itself is not running.

If you supply a raw picture string, the indicator re-renders the entire image whenever a scroll/move/resize event happens, whereas with the pixmap data all the individual instructions have already been pre-rendered into a flattened pixmap, so all that needs to be done is a pixel by pixel copy, a far simpler operation.