Overhead for table columns.

[Jonathan Giles]

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.true at gmail.com> 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