2D picture control performance Tips

[Taylorh140]

I have never gotten the performance that I desire out of the 2D picture control. I always think that it should be cheaper than using controls since they don't have to handle user inputs and click events etc. But they always seem to be slower.

I was wondering if any of the wizards out there had any 2d picture control performance tips that could help me out?

Some things that come to mind as far as questions go:

Is the conversion to from pixmap to/from picture costly?

Why does the picture control behave poorly when in a Shift register?

What do the Erase first settings cost performance wise?

Anything you can think of that are bad ideas with picture controls?

Anything you can think of that is generally a good idea with picture controls?

[MikaelH]

I love the Picture Control, it's very fast if you use it correctly. I developmed the whole GDS UML modeller (http://opengds.github.io/) based on that.
One performance issue is if you draw lot of text with a none default font size, then it becomes very slow.

Make sure you use Smooth updates, and I always use Erase first.
What does the shft register make it poorly?
Do you have an exmaple where it's slow we can look at?

 

[hooovahh]

13 hours ago, Taylorh140 said:

Why does the picture control behave poorly when in a Shift register?

This one I can answer.  So the picture data type is really a string.  This is a string with instructions on how the image should be rendered.  So imagine if the instruction is something like "Draw a rectangle that is 50 by 50 starting at 0,0 and is solid red", then the next instruction is "Draw a rectangle that is 50 by 50 starting at 0,0 and is solid blue".  Both instructions will be embedded in the string, one gets drawn, then the other on top.  Obviously in this example the red rectangle can't be seen, it will be under the blue one.  But the instructions will still draw all the operations, even the ones that won't be seen.  Now if this is in a shift register, then this string of instructions will keep getting longer as we concatenate more instructions to the end of the string over and over again.  Here is a post over on the dark side talking about it a bit.  And here is an awesome post by Norm talking about how the image instructions are stored, and how they can be manipulated (as strings) to perform image translations (repositioning in the X and Y) by changing these string values.

As for suggestions.  In the past what I often need is a picture control that is built of of several other images.  They can be combined with concatenate string in the order you specify.  So often times I will keep in memory the pieces of the over all image, so that I can quickly recreate the end image by swapping one out.  For instance lets say I have a button, and I have an overlay for when the mouse is over it.  I will draw the button, draw the overlay, and then keep them both in some private data.  Then concatenate the two when the mouse is over the picture, or just show the button (that I've already drawn) when the mouse isn't.  This is what I did in my Toolbar class.  Here each button is also it's own image I keep track of, then combine them all to draw the whole result.  I don't rerender the whole toolbar.

[Darren]

I wrote this nugget a long time ago, but the tips are still applicable:

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-30-2006/m-p/434181

[Taylorh140]

Actually the fact that the data is a string of commands makes a lot of sense. When I did not use smooth display I saw the individual elements being drawn even when i had Front panel updates defered. 

Since i Used bunches of static text I decided to only draw it the first time. by using the erase first and setting the value to 2(erase every time) and then to 0(Never erase). I tried to use the 1 setting (erase first time) but it always erased the stuff i wanted to draw the first time. 

I notice that if i use a sub-VI to do operations like erase first and such that it didn't propagate up a level and the same operations needed to be done on the top level picture control. 

After those things I went from 30 fps to 120 fps which i find more acceptable. 

 

The control only used the Picture Palette drawing functions and looked somewhat like the image attached except with real information: