Folks, that was extremely helpful. I'll see what I can pry loose as an example.
On Thursday, August 14, 2014, Tomas Mikula <tomas.mik...@gmail.com> wrote: > I like this kind of being wrong :-) > > Tomas > > On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles > <jonathan.gi...@oracle.com <javascript:;>> 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 <sean.t...@gmail.com > <javascript:;>> 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 > > > > >
