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 <e...@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 >
