polylist number of row limit

[terryho]

Hi All,

I see an example for widget "polylist" - "InfiniteList", does there is limit to load number of row in the polylist?

In datagrid, there is a limit to load number of row in the datagrid, does this have the same limit in polylist?

Regards

Terry Ho

[prometheus]

Hi terryho, I think theoretically there is a limit, it all depends on how much memory the computer has, and how much memory the program can handle/address, I have tested it with about 100 000 rows without issues, please let me know if you go further and if you find a limit

[stam]

What is the limitation on the datagrid's number of rows?

[terryho]

Hi

Has I know datagrid has a limit of row around 32,000 row, also it will depend of the formatted height of the datagrid. If each row is more height, then the number of row will be decrease.

I see there is a parameter of Polylist which is the "item cache", I think it will increase the performance. But need more test to prove it.

As I see there have example for polylist to load more row, is anyone know there is a limit on polygrid ?

I had make a test of loading random numeric data for 10,000 row and each row is 12 column, then show the data into a field, datagrid, polygrid, polylist, the result as follow :

Polygrid 36ms
DataGrid 82ms
Polylist 452ms
Field 523ms

Regards

Terry Ho

[prometheus]

Hello everyone, No, there is no such limit for any of the 'Poly' widgets, both of them are built on LCB so they draw at a low level, their rows and columns has no the limitations present on DataGrid with the number of rows/columns.
Regarding the itemCache, it speeds up the performance on PolyList but there are some rendering problems with texts when transparencies are used, so if you use this property make sure you have a solid background on the items

Another thing I have noticed, PolyList is not good rendering tables, so I always try to use a PolyGrid when rendering tabulated content

[terryho]

Hi,

Thanks your hints.

Yes, I have test on Polygrid and Polylist. Discover that :
Polygrid is good for table
Polylist can have more option on table style, fonts and graphic. Also it can design to not load all data in one time.

So under different situation, we can use datagrid, polygrid and polylist.

Regards

Terry Ho

[FourthWorld]

Has I know datagrid has a limit of row around 32,000 row, also it will depend of the formatted height of the datagrid. If each row is more height, then the number of row will be decrease.

I don't believe that's true. Indeed, the DG was invented to get past the 32k pixel limit on rendered group objects.

I had make a test of loading random numeric data for 10,000 row and each row is 12 column, then show the data into a field, datagrid, polygrid, polylist, the result as follow :

Polygrid 36ms
DataGrid 82ms
Polylist 452ms
Field 523ms

Can you share the test stack?

[terryho]

Hi

> I don't believe that's true. Indeed, the DG was invented to get past the 32k pixel limit on rendered group objects.
In the past I had this problem. But did not make a full test on DG2. If I'm wrong, please correct me.

Attach is the stack, which I change the speedtest to add polylist in the test. Please correct me, if some wrong in my script.

Regards

Terry Ho

[FourthWorld]

Attach is the stack, which I change the speedtest to add polylist in the test. Please correct me, if some wrong in my script.

As long as it executes there is no wrong, only degrees of better.

Thank you for posting that. I'll make time to review is after my morning meetings.

[paul@researchware.com]

Has I know datagrid has a limit of row around 32,000 row, also it will depend of the formatted height of the datagrid. If each row is more height, then the number of row will be decrease.

I don't believe that's true. Indeed, the DG was invented to get past the 32k pixel limit on rendered group objects.

Richard is correct. Any limit on Datagrid ROWS is in excess of 32,000. There may be a limit in the number of VISIBLE ROWS of 32,767px due to the rendering limits of the group object, but I doubt anyone has ever run into that limit. The DG is designed to cache rows much greater than 32K and just display the visible ones. There is, however, a 32,767px limit on COLUMNS. See https://quality.livecode.com/show_bug.cgi?id=23875

[stam]

Hi

> I don't believe that's true. Indeed, the DG was invented to get past the 32k pixel limit on rendered group objects.
In the past I had this problem. But did not make a full test on DG2. If I'm wrong, please correct me.

Attach is the stack, which I change the speedtest to add polylist in the test. Please correct me, if some wrong in my script.

Regards

Terry Ho

Hi Terry,

I can see your stack is pretty much the same as the speed test example stack released with polygrid, only with polylist added as well. Interesting to see that it performs slightly faster than PG - but also not sure what this gains? PL is really a version of the DG form (but the ability to show columns of rows) and is a different beast from PG and its use case is different. As you say we now have more options - although for pure customisability the DG is still king.

What was the question regarding your test stack?

For what it's worth, I changed the number of records created from 10,000 to 40,000 - the DG did very well at 65 ms. So your impression about the limitations of the DG seems incorrect. There is also a fixed speed difference between PG and PL in the order of 8-10 ms, which is unaffected by number of rows. In fact the rendering of both DG, PG and PL seem relatively independent of number of rows, whereas the text field slows progressively. These are the results with 40,000 rows :

[stam]

Actually just out of curiosity I increased the number of rows to 80,000 - everything does get a bit slower but clearly the tableField is a dog, 2 whole orders of magnitude slower:

Clearly the DG is able to render 80,000 rows in just 130 ms - so your assumption about the limitation of the DG is not correct... And while the PG is faster, it only gains you 73 milliseconds for the 80,000 rows. If anything this reaffirms what a great tool the DG is

[stam]

Richard is correct. Any limit on Datagrid ROWS is in excess of 32,000. There may be a limit in the number of VISIBLE ROWS of 32,767px due to the rendering limits of the group object, but I doubt anyone has ever run into that limit. The DG is designed to cache rows much greater than 32K and just display the visible ones. There is, however, a 32,767px limit on COLUMNS. See https://quality.livecode.com/show_bug.cgi?id=23875

Thanks Paul, that's very interesting.
Out of curiosity I checked to see how long a width of 32,767 pixels is in reality:
Assuming 1 pixel = 0.0002645833 m (which is what I found online), this would equate to 8.7 meters.
Has anyone really come up against this limit?
I would suggest that if yes, there are more serious issues with the UI design used that with the datagrid itself... No one could possible need an app to use 8.7 m of columns, surely?
Or have I misunderstood the limitation?

S.

[FourthWorld]

Out of curiosity I checked to see how long a width of 32,767 pixels is in reality:
Assuming 1 pixel = 0.0002645833 m (which is what I found online), this would equate to 8.7 meters.
Has anyone really come up against this limit?
I would suggest that if yes, there are more serious issues with the UI design used that with the datagrid itself... No one could possible need an app to use 8.7 m of columns, surely?

A similar question may be worth pondering for record count: what exactly do we expect anyone to actually do with a list of 32,000 records? Read them?

Of course what we'd want there is filtering.

And if the filtering is done up front, we never need to render 32,000 records.

[FourthWorld]

Attach is the stack, which I change the speedtest to add polylist in the test. Please correct me, if some wrong in my script.

Thanks again for the stack. Terry.

Off the top I cut the field rendering sped by about 1/3 with a checkbox: turning on the dontWrap field property bypasses the engine's need to calculate line wraps. In this case I think that's a better comparative representation.

Field rendering time drops another 15% or so if I turn on the xGrid and yGrid properties (I used a tabstops of 50), which is possibly an even better parity to the other displays.


I can't yet compare PolyGrid or PolyList as those don't appear here. Normally such omissions are a result of incomplete inclusion during standalone building, but in this case I'm running in the IDE.

Anyone have enough experience with either of those to have an opinion on why they don't render here? I've never needed either (or any other widget) yet, so there may be some odd thing the widget-using customer is expected to do that I simply haven't done.