Improving Table formatting time?

[cherold]

After getting pretty deep into an experimental control paradigm with a Table Control as the user interface, I've run into the very frustrating problem of slow formatting updates (cell background and text color). Even when deferring panel updates, formatting a 50 row by 200 column table based on each cell's string takes seconds. The UI table assists the user in generating a 2d string array, which is subsequently sent to a set of hardware objects to control a Bose-Einstein condensate experiment.

 

From reading other posts on this forum and the NI forums, I've compiled the following suggestions:

• defer panel updates (helped a lot, but still too slow)
• set subVIs containing table Property Nodes to execute in 'user interface' thread (I've tried this but would love to know more about optimizing it. Should the subVI attempt to only contain Property Nodes with logic outside in a different thread?)
• maintain a "display" table which is a subset visible to the user (seems pretty complicated and may only give gains of factor of 2 or 3 since I want the Table to fill the user's monitor)
• obviously, take all steps to format by column, row, all (not possible for about half my columns whose coloring depends on each cell's value)
  

 

Is the above list exhaustive? Can anyone suggest something I haven't listed? 

I'd also appreciate more information about UI thread control. My naive understanding is that table coloring is so slow because to color cell-by-cell the process must switch up to the UI thread and back down. And setting a subVI property to the UI thread saves some of this thread-switching time?

 

Barring any other insights, it seems like we've been burned by trying to use a table control in an unintended way and LabVIEW simply can't do it fast enough. Do XControls suffer from the same thread-switching problems for front-panel appearance updates via Property Nodes? Otherwise, I'll work on rewriting the UI in another language and simply feed the 2d string array to the rest of my LabVIEW code.

[ShaunR]

Have you tried just updating only the visible areas (I expect 200 columns is not all presentable on screen at one time).

MJE demonstrated a Virtual MCL that mitigates the performance impact of cell formatting of large data-sets and the Table control has a similar API.

 

I also understand that the performance of these controls was vastly improved in LV2013.

[hooovahh]

That's a pretty good list.  As mentioned before 2013 had a big improvement in these types of controls as mentioned here.

 

http://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/page-2#entry104672

[Mads]

I just did a quick test for you. Updating the background color of all 200x50 cells (with panel updates deferred) still takes 1,1 seconds in LabVIEW 2013 (on my relatively new PC)...

 

But do you really need to update them all, and in one go - or could you update them individually on changes in the cell content *only* instead?  Checking if a change is actually required first would take no time, so (unless most of them are likely to need a change) you could reduce the number of actual updates enough to make it seem "instant".

[cherold]

Thanks ShaunR, hooovahh, and Mads. I was able to download an evaluation version of LV2013 and saw significant improvement (3-7x faster) for the slowest operations. As Mads says, updating the entire table still takes about 1 s which is an acceptable "loading" time. Most other operations can be optimized to only update a small portion of the table. However, operations like inserting/deleting a row near the top still require shifting the color of all subsequent rows.

 

I'm not sure the responsivity will ever feel "instantaneous," but it should be passable with 2013. Thanks again for the quick comments. 

[Baldrick]

I'm not sure what kind of UI you would need but if the column size can be fixed you could just create a separate 2D Color Array and put 2D String Array (transparent BG) top of it. It would update much faster.

[FrankHS]

Do you want to display a number in each cell of an array or table and also independently change the background color of each cell?  The table must be scrollable and the index control must work properly. It must redraw quickly. Here is a solution that meets these requirements. 

This method uses a cluster of a string and a color box. The string is transparent and is in front of the color box. Put this cluster in an array and wire it as shown in the diagram. This also works with numeric values. 

To see it work, run the vi. You are not limited to two colors. With minor code change’s you can have all the colors you want.

I know of two other ways to do this but each has problems.

The first method is to use a table with a property node to set the background color using nested for loops. This is very slow, typically 1 second per refresh. Setting all colors to green and then only turning the active cells red reduces that by half but this is still slow. In addition it produces a confusing flicker.

The second method is to stack an array of transparent text on top of an array of color boxes. This is fast but the scrollbars and the index controls do not work properly.

Test table background color.vi

Edited July 4, 2016 by FrankHS

[ensegre]

It is certainly a viable idea, but only for those cases where cell sizes and font properties don't need to be customized on cell basis, which is not possible with array elements. Also, thick borders may be somewhat intrusive. The LV table is lousy, but still a notch more customizable over arrays... Been there, done that... (with some of the optimizations mentioned above)