Freezes and slows UI on panel with large struct table

Automation & Control
1

Hello Ross support,

I’m working on panel that works with Ross inception lineups, via MOS protocol. So, i fetching lineups, and represents them in struct table. Its works fantastic with small amount of rows, but if i go higher ( some lineups contains up to 400 rows), the UI is getting very slow, scrolling delays, etc. But, its still possible to work that way. BUT, and this is deal breaker in my project, on lineups changes, table should update (add, remove row ) and its seems like its so hard to dashboards that you see distortion movements on the table.

  • Our lineups are Hebrew based.

I publish here example panel that i created to demonstrate the issue, maybe there is a way to solve that somehow?

selected false video,name,itemNumber true 35 var structCount = params.getElementCount('ROTable'); ogscript.debug(structCount); if (structCount == 1 && params.getValue('raceList.0.name', 0) == "") // If this is the first element and it has not been set yet { structCount = 0; }

var newValue = {
“channel”: " ",
“available”: “” ,
“video”: " ",
“name”: “” ,
“itemNumber”: " ",
“storyID”: “”
};

params.setValue(‘ROTable’, structCount, newValue);


var x = params.getValue(‘selected’, 0);

params.getParam(‘ROTable’, x).remove();

2

Hi Alex,

I just copied and pasted your panel into a DB panel here. I have a couple questions and comments:

  1. I see a bit of slowdown when scrolling, but it’s not horrible on my computer. What version of DB are you using, and how much memory does your computer have? I have a fairly performant computer with lots of memory.

  2. When I was scrolling the table, it looked as if it was resizing the rows on the fly. I added a w.rowheight config option, set to 40, and the scrolling seems smoother to me. I’m wondering if without that option, it’s trying to calculate the rowheights as you scroll. Try adding that option.

  3. There is a 64-bit version of DashBoard that allows you to use more of your system memory, you could try that as well.

If those things don’t work, then are you open to other options? Instead of cramming all the information in one large table, you could use an API table, and only show 20-30 items at a time, with page buttons on the bottom. Let me know if that would be acceptable, and I’ll see if I can whip up an example for you.

#DashBoard

3

Hi Ben , thanks for quick answer

  1. I run it on DB 9.1.2 , 64 bit. And the pc have enough resources (i7, 16 G RAM) .

  2. With w.rowheight its looks much more better - and if there is no other option i will work with that.

  3. 64 bit version. Just downloaded and installer fresh copy at home.

So, after an little investigation, i’m pretty sure that’s Hebrew language character issue. What i did: just created 2 buttons: one replaces all the rows with English text, the other one is the same but with Hebrew analogue.

English:

var structCount = params.getElementCount(‘ROTable’);
var newValue,i;

for(i=0;i<structCount;i++){

ogscript.debug(‘count is :’ + i);

newValue = {
“channel”: " ",
“available”: “” ,
“video”: ‘text’,
“name”: “some text in english” ,
“itemNumber”: ‘0’+i,
“storyID”: “”
};

params.setValue(‘ROTable’, i, newValue);
}

Hebrew:

var structCount = params.getElementCount(‘ROTable’);
var newValue,i;

for(i=0;i<structCount;i++){

ogscript.debug(‘count is :’ + i);

newValue = {
“channel”: " ",
“available”: “” ,
“video”: ‘טקסט’,
“name”: “טקסט כלשהו בעיברית” ,
“itemNumber”: ‘0’+i,
“storyID”: “”
};

params.setValue(‘ROTable’, i, newValue);
}

Conclusion: It’s run perfect with English, and bad with Hebrew.

I also tried to change windows non-Unicode language to Hebrew - didn’t helped.

#DashBoard

4

I took the code and added both buttons to my panel. I can confim that it seems to scroll slightly better on the English version compared to the Hebrew version. I’m not sure why that is. I’ll see if I can find anything.

#DashBoard

5

You also have a lot of repetitive style information for that parameter table:

evenstyle=“f:txt-align:east;f:size:Big;t:txt-align:east;t:size:Big;” expand=“true” height=“720” left=“20” oddstyle=“f:txt-align:east;f:size:Big;t:txt-align:east;t:size:Big;” oid=“ROTable” showlabel=“false” style=“txt-align:east;f:txt-align:east;t:txt-align:east;”
The evenstyle, oddstyle and style are all the same. The true and false states are also the same.

You could just have style=“txt-align:east;size:Big” and get rid of the evenstyle and oddstyle completely.

That may help a bit too.

#DashBoard

6

Thats because you have different styles for odd and even rows, and also for selected and unselected row. Of course if it can be set by single defenition, its preffered.

I’ll check it tomorrow, thanks, Ben.

#DashBoard

7

I understand why the different styles are there, you just seem to have them all set to the same value (txt-align:east, size:Big).

#DashBoard

8

Yes, i set them all to same value, correct. Because hebrew text starts from rigth to left, and default dashboard is left to rigth. So, i wanted that in all cases it will get east align.

Ill will fix it tommorow with

style=“txt-align:east;size:Big”

#DashBoard

9

OK, i fixed the repetitive style data.

Still, as you saw, there is Unicode encoding issue. When you work with that as live and dynamic lineup, that also react to lineup changes (rebuilds, changing cell values etc) it’s becomes real liability.

And DB is fantastic product!

So, i believe you and other develop Ross team will find whats wrong there, and fix it in future releases.

Thanks!

#DashBoard