TableView slow vertical scrolling with 300+ columns

[Nir Lisker]

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