Re: Overhead for table columns.
Folks, that was extremely helpful. I'll see what I can pry loose as an example. On Thursday, August 14, 2014, Tomas Mikula wrote: > I like this kind of being wrong :-) > > Tomas > > On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles > > wrote: > > Actually this is slightly wrong. I was holding off replying until I had a > > bit more time to be thorough, but I'll respond now to prevent this > > misunderstanding from being discussed :-) > > > > It _is_ possible to virtualise the TableView in both directions. This > > doesn't necessarily help with the overhead entirely, but it should help > > substantially. I might be forgetting some important element as I have not > > referred back to the code, but I believe that the only thing that is > > necessary is for the developer to set a fixed cell size on the TableView > > (via TableView#setFixedCellSize). When this happens, the TableView can 1) > > reduce enormously the amount of computations it has to do for layout and > 2) > > virtualise the columns. I suspect 2 is your primary goal, but 1 > shouldn't be > > underestimated given the enormity of your table. > > > > Sean, it would be interesting if you could send me a sample application > that > > demonstrates your problem. I am always trying to optimise these > virtualised > > controls and would appreciate adding your specific use case to my suite > of > > tests. > > > > Thanks, > > > > -- Jonathan > > > > > > On 15/08/2014 10:35 a.m., Tomas Mikula wrote: > >> > >> On Thu, Aug 14, 2014 at 9:01 PM, Sean True > wrote: > >>> > >>> We've been looking at very large tables for use in data grid display. > >>> > >>> Row count scales very nicely indeed, but column count is much more > >>> problematic. > >> > >> To explain your observation: TableView is based on VirtualFlow, which > >> optimizes the number of cells simultaneously attached to the scene > >> graph in one direction (horizontal or vertical). For TableView, > >> vertical VirtualFlow is used, which means rows are optimized > >> (invisible rows are not in the scene graph), while all columns for > >> each visible row are in the scene graph. > >> > >> To be able to scroll smoothly through the table, you would want a > >> two-dimensional virtual flow. You can look at VirtualFlow.java from > >> OpenJFX or from my alternative virtual flow implementation Flowless > >> [1] to get an idea about the complexity of the one-dimensional case. > >> > >> If you don't require smooth scrolling and are fine with scroll by one > >> row/column at a time, you could display a small table with fixed cell > >> count, say 30x20 (maybe calculated dynamically based on the available > >> area), and display your own scrollbars that will update the data model > >> behind this small table. Not the best solution, but much less work. > >> > >> Regards, > >> Tomas > >> > >> [1] https://github.com/TomasMikula/Flowless > >> > >>> In the March time frame, our tests showed that each column had > >>> approximately 100KB overhead (using VisualVM), which is negligible at > 100 > >>> columns, but at 10,000 columns becomes an issue. We have real world use > >>> cases of more columns than that . > >>> > >>> Is there planned effort to reduce the overhead, or are we looking at > >>> likely > >>> having to build our own table component to serve these large needs? > >>> > >>> -- Sean > > > > >
Re: Overhead for table columns.
I like this kind of being wrong :-) Tomas On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles wrote: > Actually this is slightly wrong. I was holding off replying until I had a > bit more time to be thorough, but I'll respond now to prevent this > misunderstanding from being discussed :-) > > It _is_ possible to virtualise the TableView in both directions. This > doesn't necessarily help with the overhead entirely, but it should help > substantially. I might be forgetting some important element as I have not > referred back to the code, but I believe that the only thing that is > necessary is for the developer to set a fixed cell size on the TableView > (via TableView#setFixedCellSize). When this happens, the TableView can 1) > reduce enormously the amount of computations it has to do for layout and 2) > virtualise the columns. I suspect 2 is your primary goal, but 1 shouldn't be > underestimated given the enormity of your table. > > Sean, it would be interesting if you could send me a sample application that > demonstrates your problem. I am always trying to optimise these virtualised > controls and would appreciate adding your specific use case to my suite of > tests. > > Thanks, > > -- Jonathan > > > On 15/08/2014 10:35 a.m., Tomas Mikula wrote: >> >> On Thu, Aug 14, 2014 at 9:01 PM, Sean True wrote: >>> >>> We've been looking at very large tables for use in data grid display. >>> >>> Row count scales very nicely indeed, but column count is much more >>> problematic. >> >> To explain your observation: TableView is based on VirtualFlow, which >> optimizes the number of cells simultaneously attached to the scene >> graph in one direction (horizontal or vertical). For TableView, >> vertical VirtualFlow is used, which means rows are optimized >> (invisible rows are not in the scene graph), while all columns for >> each visible row are in the scene graph. >> >> To be able to scroll smoothly through the table, you would want a >> two-dimensional virtual flow. You can look at VirtualFlow.java from >> OpenJFX or from my alternative virtual flow implementation Flowless >> [1] to get an idea about the complexity of the one-dimensional case. >> >> If you don't require smooth scrolling and are fine with scroll by one >> row/column at a time, you could display a small table with fixed cell >> count, say 30x20 (maybe calculated dynamically based on the available >> area), and display your own scrollbars that will update the data model >> behind this small table. Not the best solution, but much less work. >> >> Regards, >> Tomas >> >> [1] https://github.com/TomasMikula/Flowless >> >>> In the March time frame, our tests showed that each column had >>> approximately 100KB overhead (using VisualVM), which is negligible at 100 >>> columns, but at 10,000 columns becomes an issue. We have real world use >>> cases of more columns than that . >>> >>> Is there planned effort to reduce the overhead, or are we looking at >>> likely >>> having to build our own table component to serve these large needs? >>> >>> -- Sean > >
Re: Overhead for table columns.
Actually this is slightly wrong. I was holding off replying until I had a bit more time to be thorough, but I'll respond now to prevent this misunderstanding from being discussed :-) It _is_ possible to virtualise the TableView in both directions. This doesn't necessarily help with the overhead entirely, but it should help substantially. I might be forgetting some important element as I have not referred back to the code, but I believe that the only thing that is necessary is for the developer to set a fixed cell size on the TableView (via TableView#setFixedCellSize). When this happens, the TableView can 1) reduce enormously the amount of computations it has to do for layout and 2) virtualise the columns. I suspect 2 is your primary goal, but 1 shouldn't be underestimated given the enormity of your table. Sean, it would be interesting if you could send me a sample application that demonstrates your problem. I am always trying to optimise these virtualised controls and would appreciate adding your specific use case to my suite of tests. Thanks, -- Jonathan On 15/08/2014 10:35 a.m., Tomas Mikula wrote: On Thu, Aug 14, 2014 at 9:01 PM, Sean True wrote: We've been looking at very large tables for use in data grid display. Row count scales very nicely indeed, but column count is much more problematic. To explain your observation: TableView is based on VirtualFlow, which optimizes the number of cells simultaneously attached to the scene graph in one direction (horizontal or vertical). For TableView, vertical VirtualFlow is used, which means rows are optimized (invisible rows are not in the scene graph), while all columns for each visible row are in the scene graph. To be able to scroll smoothly through the table, you would want a two-dimensional virtual flow. You can look at VirtualFlow.java from OpenJFX or from my alternative virtual flow implementation Flowless [1] to get an idea about the complexity of the one-dimensional case. If you don't require smooth scrolling and are fine with scroll by one row/column at a time, you could display a small table with fixed cell count, say 30x20 (maybe calculated dynamically based on the available area), and display your own scrollbars that will update the data model behind this small table. Not the best solution, but much less work. Regards, Tomas [1] https://github.com/TomasMikula/Flowless In the March time frame, our tests showed that each column had approximately 100KB overhead (using VisualVM), which is negligible at 100 columns, but at 10,000 columns becomes an issue. We have real world use cases of more columns than that . Is there planned effort to reduce the overhead, or are we looking at likely having to build our own table component to serve these large needs? -- Sean
Re: Overhead for table columns.
On Thu, Aug 14, 2014 at 9:01 PM, Sean True wrote: > We've been looking at very large tables for use in data grid display. > > Row count scales very nicely indeed, but column count is much more > problematic. To explain your observation: TableView is based on VirtualFlow, which optimizes the number of cells simultaneously attached to the scene graph in one direction (horizontal or vertical). For TableView, vertical VirtualFlow is used, which means rows are optimized (invisible rows are not in the scene graph), while all columns for each visible row are in the scene graph. To be able to scroll smoothly through the table, you would want a two-dimensional virtual flow. You can look at VirtualFlow.java from OpenJFX or from my alternative virtual flow implementation Flowless [1] to get an idea about the complexity of the one-dimensional case. If you don't require smooth scrolling and are fine with scroll by one row/column at a time, you could display a small table with fixed cell count, say 30x20 (maybe calculated dynamically based on the available area), and display your own scrollbars that will update the data model behind this small table. Not the best solution, but much less work. Regards, Tomas [1] https://github.com/TomasMikula/Flowless > > In the March time frame, our tests showed that each column had > approximately 100KB overhead (using VisualVM), which is negligible at 100 > columns, but at 10,000 columns becomes an issue. We have real world use > cases of more columns than that . > > Is there planned effort to reduce the overhead, or are we looking at likely > having to build our own table component to serve these large needs? > > -- Sean
Overhead for table columns.
We've been looking at very large tables for use in data grid display. Row count scales very nicely indeed, but column count is much more problematic. In the March time frame, our tests showed that each column had approximately 100KB overhead (using VisualVM), which is negligible at 100 columns, but at 10,000 columns becomes an issue. We have real world use cases of more columns than that . Is there planned effort to reduce the overhead, or are we looking at likely having to build our own table component to serve these large needs? -- Sean
