Performance issue with programatical change of list box control background color

[Larsky]

Hi everybody,

I know the topic of programatical change of cell backgrounds has been adressed several times in the past but nonetheless I hope that since 2005 when this issue first came up sombeody has found a solution.

We run an application with a workpiece that has certain properties (up to 64). To visualize the status of these properties (good/bad/inactive) to the machine operator the measurement results are written to (the top of) an array which is shown by use of an multicolumn list box control that acts as a workpiece history. According to the property status the cell background is either set to green, red or gray. This is currently done by the use of two For-loops going through every single cell of the list box element. This is working well as long as the number of rows/columns is relative small. With increasing numbers however there is an serious performance issue setting the cell color this way. For example it takes as long as several minutes to work through an array with 64 columns and 1000 rows - far to long as the cycle time per part is about 30 seconds.

Inserting the newest part at the bottom of the array instead of the top will only postpone the problem until the max allowed number of history entries is reached - this is thus not the solution. I have attached a test.vi to simulate the processing time for various array sizes.

Is there any way to read / write a complete color attribute structure (array) of the list box element rather than only the single cell property. Or is there any other possibility to adress this problem.

Any tips are greatly appreciated. Thanks in advance for your attention.

Lars

---

[Matthew_Kelton]

I don't have LabVEIW 8.6 installed, so I cannot look at your VI, but are you using Defer Panel Updates and setting it to true before you set all your colors, then setting it to false afterwards to update the color changes?

Also, if you look at this message, I posted a solution for someone who was doing a similar thing as you (my example does not use Defer Panel Updates, as the demo was a cleaner way to do the color changes).  You will see in that VI that I set all the cells of the listbox to white before I start.  If you know what the most used color will be, you can set the whole listbox to that color, then skip updating individual cells whichmatch that color.

[altenbach]

Matthew is of course correct. "Setting defer panel updates" speeds things up by a factor of about 3 (still not that great :()

(About style: why do you use all these unneeded sequences?

For example the big frame zero could be eliminated if you would simply place the property node to the left of the while loop and wire the error out to the while loop ((see inset image, again no seequence needed because you can do both with one property node. Even if you want to use two property nodes, simply connect them via the error cluster and execution order is enforced.) ).

Your innermost sequence "(1) set active cell, (2) set color" is also useless, because you can do it in one property node (see image). Also the randomize button belongs outside the FOR loops, because most likely the value will not change during the loops so you don't need to constantly read it over and over. If the terminal is outside the loop, it's value will be folded into a constant during the loops, streamlining the execution.)

Message Edited by altenbach on 12-10-2008 09:42 AM

[Larsky]

Hello Matthew, hello altenbach,

thanks a lot for your reply and your input.

Testing the behavior a little further I encountered some rather strange effect. The first time I run my vi execution is much faster. With 64 columns and 100 rows the coloring just needs about 17 second instead of 28. Afterwards the execution time remains relative stable at 28 seconds. Therefore I followed Matthews suggestion and inserted an additional "clean up" of the list box colors to white prior to the recoloring. Execution time after this is back to 17 seconds and it remains at 17 seconds. Why the initial color has any effect on performance however is a mystery to me.

The usage of defer panel update has an significant effect only for small array sizes. For my standard test array with 64 cols and 100 rows the time usage drops only by approx. 3 seconds (this corresponds btw. to visible rows (10) divided by rows in array (100) = 0,1 (10%) - the effect seems to be rather linear).

Still processing time is much to long - so if there are any further tips ...please let me know.

Maybe for future labview versions the cell propertys could be adressed instead of single cell property rather as array.

@altenbach: generally you are right about the sequences...two reasons I like to use them nonetheless....first the block diagram window size can be smaller (a remaining habit from the time of low resolution monitors),  second I am always a little uncertain about race conditions in labview. Is it certain that always the upper property is activated first in a property node or could it also happen that e.g.. with regard to the inner sequence in the test.vi the color is set prior to the active cell?  I promise to improve my styl though

Concerning the randomizer ... it does not increase processing time significantly but explains what the final list box could look like - a wild mixture of colors and not necessarily unicolor cols and rows - therefore inserted it inside the for-loop. 

[Larsky]

I have added the defer panel update and the clean up as options to the original test programm (and even removed the unecessary sequences) so lease feel free to test my observations by yourself...maybe I am missing something...

Another thanks

Lars

[Matthew_Kelton]

You didn't quite do what I had suggested.  In your example, you have a greater probablility of the cell being green.  So, initialize them all to green, then skip the cell color change in your for loop if it's green.  In your final case, hopefully most of the items pass, so going all green in the beginning will help.

Also, I saw a speed increase when I unchecked the Lock Front Panel option for the event.  On my system, with 64x100, it's running at 4-4.5 seconds.

[Larsky]

Hi Matthew,

you are totally right- with pre-coloring to green execution times decrease....unfortunaely there is always one "but" left and so is here .. the number of cols can change between workpieces, 64 cols is maximum most of them will have less. This means with precoloring to green I will habe cols that are green though they are not really valid for some rows. A distinguishing between really processed and good and just precolored is not possible anymore. In addition I have to look at the worst case timing as it is possible that the processing results can be bad for quite some time (e.g. during parameter evaluation and processing setup). In this case it may be that a majority of the cells have to be recolored to red leading again to a very long execution time and thus a prolonging of general cycle time. A solution that leads to very variable execution times depending on the result input is thus not the best choice. 

However thank you very much for your input and your help and your dedication. This is really appreciated.

Thanks

Lars

[altenbach]

This thing is too slow to execute "in line" with your code.

What you need to do is add a bit more intelligence.

1. check the visible area of the indicator and only olor these.
2. Start a parallel task that updates all hidden cells in the background.

(you could also simply update the visible cells whenever the scroll position changes).