Closed chdh closed 7 years ago
Thanks for getting in touch,
I will take a look over your example this weekend and get back to you with some suggestions.
Cheers
Oli
Hey,
That does seem jerky, are you running on the latest version of Tabulator pulled from the repo? there have been a number of updates recently.
In this sort of situation i would usually recommend lowering the progressiveRenderSize to give the system more of a chance to update between row renders.
try setting progressiveRenderSize to 5 and progressiveRenderMargin to 100.
How are you passing your data into the tabulator, is it just a data object loaded at the start and then locally paginated?
Do you have a copy of the constructor object that I could have a look at. I can see that you programatically build it before creating your tabulator but it is rather hard to isolate the issue with out the whole object to hand.
Cheers
Oli
Hi while also having discussed that with chdh, I am wondering, if progressive rendering per se might be less optimal for having a really fast UI for large tables (client or server), because that usually means that the allready rendered part is kept. While virtual rendering usually means that only a small part is currently actually rendered. I am not an technical expert. but is it possible that progessive rendering in that sense is a limitation ? Or is this irrelevant? Cheers, Michael
Hi Michael,
It is on the roadmap in the next few months to move over to a full virtual rendering for the table, i agree that would be much more resource efficient.
I dont think in this instance that is the problem though, as tabulator has run with considerably more data than your examples in the past with no issue. If you could send over the test data when ever is convenient for you i can look into the root cause of the issue.
Cheers
Oli
Thanks for the very prompt answer. I myself have different test examples. I will test them in the next days. And again impressed by the drive and appropriateness Your roadmaps conveys.
Cheers, Michael
@olifolkerd Thanks for your response.
I have made the following changes:
The data is loaded at the start and passed to the Tabulator constructor as a static array of 800 row objects that contain the data fields. There is no pagination.
The full source code and data files are available. You can copy it to your server and run it there. There are no depencencies. But I could create a simplified test case if you like.
The constructor is called at the end of buildMeterDataPage() (source code):
const tabulatorOptions = {
columns: tableColumns,
data: tableData,
height: genMeterTableHeight(),
selectable: false,
progressiveRender: true,
progressiveRenderSize: 5,
progressiveRenderMargin: 100
};
$(".meterTable").tabulator(tabulatorOptions);
Is there a way to populate the full table in the background with progressive rendering?
I have created an isolated simple test case with the same table data: SimpleTest.html and SimpleTest.js (link).
With IE11, the table is never displayed.
With Chrome and Firefox, the table is displayed, but it's nearly impossible to scroll to the bottom.
Amazing, that will really help me get to the bottom of the issues.
I will take a look tomorrow.
Cheers
Oli
Hi Oli I can basically confirm chdh's observations in a completely independent example. Getting data from server with ajax as js json object. Only three columns in columns setup. 411 rows. IE 11 takes 30 -45 secs for displaying them with $('#tabulatortest').tabulator("setData", data); Scrolling then choppy. Progressive Rendering changes nothing with that. Chrome: Initial display very fast, with or without progessive rendering. Without progressive rendering scroll ok and fast. With prog. rend: cannot scroll down to end. Since these are same effects as with chdh, not preparing example. Unless you think it would help You.
Cheers Michael
Hi Michael,
Thanks for the external confirmation, something must have regressed in one of the last updates,
I will have a look into it in the next couple of days and see what i can doo.
Cheers
Oli
Hi Oli tested again with Your new 2.12. Chrome: Works now basically ok with and without progressive rendering. with progressive rendering: initial display very fast. Srollbar behavior somewhat scetchy. But works. IE11: for 500 - 1800 rows: without progessive rendering: starts to take very long, Minutes. For exm: 770 rows: setData: 3 Minutes. Heavy bugIE11 only: when resizing column: vertical scrollbar disappears. For fitcolumns true and false.
And in the enterprise and public sector one (I) has still a lot of organisations that enforce the usage of IE11. And wait until the last maintainable point in time before migrating to Win10 Cheers, Michal
But I would understand if one drops IE11 support. Is a pita. Also Semantic-UI had taken some basic rendering decicons that lead to not beeing really compatible with IE 11 for some elements (f.i. basic button)
hey michaelongithub,
Thanks for the information, that will be a great help in isolating the issue, i will have a look this weekend for you.
I think IE is still being used by too many users to be ignored so it is still a priority for me that Tabulator support it.
Cheers
Oli
Hey,
I have just pushed an update to the repo that should fix the IE and smooth scrolling issues.
Have a play and let me know your thoughts.
Cheers
Oli
@olifolkerd
Thanks, IE11 is working now. But it's still nearly impossible to scroll to the bottom of the 800 row table.
see SimpleTest.html
Hi Oli tested too. (without progressive rendering: IE11 very slow, And even Chrome ; 7 secs for 600 rows 25 for 1200 rows 7 cols, 1 very large text col Textformatter textarea does not seem to have a slowing down influence. Times the same without.)
With progressive rendering: Initial display Chrome and IE fast. Scrollbar in both jumpy and diffcult to handle for user. Chrome: if contiuosly pressing on arrow down of scrollbar, ok. But with mouse on scrollbar, almost impossible, too jumby. IE11: basically same problem. Additionally: the more down one scrolls, the more jumpy and sometimes even blocking a few secs.
Played with different progessivernedersize/margin. didnt help. Otherwise docu for optimal values. Cheers Michael
Hey Guys,
Thanks for all the feedback it has been extremely helpful.
I have isolated the cause of the issues to part of the rendering system. I am looking to have a complete overhaul of the rendering system in the next release (May) so will get this all resolved then.
The next release will move to virtual rendering for the table so should be much more efficient.
Thanks
Oli
Hey Guys,
Got a bit of a status update for you, version 3.0 is coming along nicely. ive just got the virtual DOM rendering installed and Tabulator is now incredibly smooth and fast scrolling with any number of rows.
It is about a week away from a usable beta for this sort of functionality. if anyone would be interested in having a play please get in touch and i can talk you through how to get set up.
Cheers
Oli
Hey,
You will be happy to hear that version 3.0 is now in beta release, and comes with a full Virtual DOM.
I'm still working on some optimizations for Microsoft browsers, but on the hole you should find it a very smooth experience.
Head over to http://olifolkerd.github.io/tabulator/news/ to see the latest features!
Let me know what you think :)
Cheers
Oli
I like Tabulator, but I have relatively large tables with 800 rows and 30 columns that I want to display without pagination. Vertical scrolling is very slow and jumpy with Chrome and Firefox. With IE11, the table only gets displayed when I reduce the number of rows.
I tried to adjust the
progressiveRenderSize
parameter, but that didn't help. If progressive rendering would continue in the background until the whole table is populated, this could be an improvement.Please have a look at my test case. To see the effect, a table can be opened via tabulator/TabulatorTest.html. The data is read from tab-separated (TSV) files. There are also static HTML versions of the same tables that show that opening static HTML tables of that size is unproblematic even with IE11.