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> 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
