Overhead for table columns.

[Sean True]

Folks, that was extremely helpful. I'll see what I can pry loose as an
example.

On Thursday, August 14, 2014, Tomas Mikula <tomas.mikula at gmail.com> wrote:

> I like this kind of being wrong :-)
>
> Tomas
>
> On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles
> <jonathan.giles at 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.true at 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
> >
> >
>