TableView slow vertical scrolling with 300+ columns

[Jonathan Giles]

It's been a wee while since I built TableView, but from memory there is
code in there that virtualises the columns, such that those that are
scrolled out of view are not being included in the scenegraph needlessly.
>From memory, to achieve this all you needed to do was set a fixed row
height on the TableView, using this API:
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableView.html#fixedCellSizeProperty

I'm sure it will won't be a silver bullet, but from my recollection it did
massively help for these scenarios where there were many columns, most of
which were not in the viewable area.

-- Jonathan

On Sun, Jan 26, 2020 at 5:11 AM Ed Kennard <ed at kennard.net> wrote:

> I did previously look at the ControlsFX SpreadsheetView, but it wasn’t a
> good match, at least at that time.  Off the top of my head, I’m not sure it
> supports nested column headers, which is essential for our purposes.
> Furthermore, in my travels around the internet on this subject I’ve seen
> comments suggesting it has its own performance issues, too.  I will revisit
> it though, just to be sure.
>
> Beyond that, I haven’t seen any other 3rd party libraries along these lines
>
>
> From: Nir Lisker <nlisker at gmail.com>
> Date: Saturday, 25 January 2020 at 16:40
> To: Ed Kennard <ed at kennard.net>
> Cc: Kevin Rushforth <kevin.rushforth at oracle.com>, "
> openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
> Subject: Re: TableView slow vertical scrolling with 300+ columns
>
> So might it be better to submit a new feature request to develop a
> separate and leaner control entirely, geared much more towards viewing
> large datasets without all the bells and whistles of a TableView?
>
>  Doesn't ControlsFX have that already, or some other 3rd party library?
>
> On Sat, Jan 25, 2020 at 5:34 PM Ed Kennard <ed at kennard.net<mailto:
> ed at kennard.net>> wrote:
> Hi Kevin, Nir,
>
> I also dug out those two bug reports and agree neither are close enough.
> However, it seems to be general consensus that in order to properly address
> the issue, TableView's virtualisation would need to be changed to support
> columns in addition to rows, and that the extra complexity through the rest
> of the control's features would not be a worthwhile trade-off.
>
> So might it be better to submit a new feature request to develop a
> separate and leaner control entirely, geared much more towards viewing
> large datasets without all the bells and whistles of a TableView?
>
>
>
>
> On 25/01/2020, 15:39, "Kevin Rushforth" <kevin.rushforth at oracle.com
> <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     I took a quick look and didn't see one that was close enough to this,
> so
>     I think it's worth submitting a new bug report. The closest I found
> were
>     JDK-8166956 [1] and JDK-8185887 [2].
>
>     I also would be interested to know whether others have run into this in
>     their applications.
>
>     -- Kevin
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8166956
>     [2] https://bugs.openjdk.java.net/browse/JDK-8185887
>
>
>     On 1/25/2020 2:10 AM, Nir Lisker wrote:
>     > Hi Ed,
>     >
>     > Try to search JBS [1] for this issue. If you don't find one, you can
> submit
>     > it through bugs.java.com<http://bugs.java.com>, though I suspect
> this is known.
>     >
>     > I don't know the technicalities of VirtualFlow in TableView, so
> can't help
>     > there.
>     >
>     > - Nir
>     >
>     > [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
>     >
>     > On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net<mailto:
> ed at kennard.net>> wrote:
>     >
>     >> Hi everyone,
>     >>
>     >> I’m new to the list, so by way of a short introduction, I’ve been
> working
>     >> with JavaFX for the last 4 years developing a commodities trading
> risk
>     >> management system from the ground up for a software company I
> co-founded in
>     >> London.  All our code is written in Scala, the functional style of
> which is
>     >> essential for the mathematical heavy lifting needed on the backend,
> but
>     >> which also lends itself really well to UI programming and working
> with
>     >> JavaFX.  I’m enthusiastic about JavaFX and would love to make a
>     >> contribution to the project.
>     >>
>     >> At the center of our product is an extension of the TableView
> control
>     >> that’s responsible for displaying all the output from our pivot
> reporting
>     >> engine.  Depending on how the user configures the layout of their
> pivot
>     >> reports, sometimes there are a legitimately large number of columns
>     >> (300+).  When that happens, while the horizontal scrolling remains
>     >> perfectly smooth, the vertical scrolling degrades to a somewhat
> juddery
>     >> state and CPU usage spikes.
>     >>
>     >> I found an issue raised about this in 2019 on the old JFX GitHub
> repo here…
>     >> https://github.com/javafxports/openjdk-jfx/issues/409
>     >>
>     >> …but I’m not sure whether, per Kevin’s suggestion at the bottom, it
> was
>     >> ever submitted through the correct channels.  I can confirm that
> the test
>     >> code included there by “yososs” on 20th May 2019 perfectly
> illustrates the
>     >> problem I’m experiencing.  The same person seems to have a fairly
> clear
>     >> theory on what is causing the problem, too - see their follow-up
> comment on
>     >> 12 Sept 2019.
>     >>
>     >> So, my questions to the list are:
>     >>
>     >>
>     >>    1.  Has anyone seen this issue raised anywhere else?
>     >>    2.  If yes, has anyone taken a look into it yet, and possibly
> even found
>     >> a fix?
>     >>    3.  If no to both of the above, shall I submit it through the
> correct
>     >> channels then have a crack at fixing myself?  Or is the issue
> likely to be
>     >> a much deeper and far-reaching one than I’m anticipating?
>     >>
>     >> Many thanks
>     >>
>     >> Ed
>     >>
>
>