Hi Clemens, I am also experiencing the TableView slow vertical scrolling issue with large number of columns.
Did you manage to work around this issue with a code change in TableRowSkinBase as you mentioned in your bullet point 2 and if so could you share what you did? Thanks Danny > On 28 Jan 2020, at 12:54, Ed Kennard <e...@kennard.net> wrote: > > Hi Clemens, > > Thanks very much for your message, it definitely helped me crystalize the > root of the issue beyond my previous understanding, and also gave me some > additional options on how to work around it :) > > Ed > > > > > > > On 27/01/2020, 15:45, "openjfx-dev on behalf of Clemens Kadura" > <openjfx-dev-boun...@openjdk.java.net on behalf of > clemens.kad...@katla.de.com> wrote: > > Hello Ed, hello all, > > It is also the first time that I become active in this mailing list, > although I'm already monitoring this list for half a year to get > familiar with your conventions. > I am co-founder of a software and consulting company in Germany. We > develop a system (JACAMAR) that combines a serverless no-sql database > engine with a customizable user interface for do-it-yourself non-IT > expert end users. We started with an Eclipse based user interface, > switched in 2015 to a self developed UI and unfortunately found out only > very late that JavaFX did just the same with, I guess, a lot more > resources than we have. So we switched another time to JavaFX and are > about to launch our next version. By going this way, we have gained a > lot of insights in the field of user interfaces. > > To come to your question: > Yes we also experienced issues of poor performance on scrolling virtual > tables with a lot of columns. > The reason is in the nature of the VirtualFlow, which is the base of > TableView: It has a "virtual" direction and a "static" direction. By > default the vertical direction is the virtual one. That means the > vertical scrollbar works with a value p between 0 and 1. Depending on > how quick you scroll, only those lines are calculated and rendered, > which will become visible in the the viewport for a given p. This gives > good performance for tables with huge amount of lines. > The problem is now the horizontal direction. Since this dimension is > static, TableRowSkin calculates and renders all TableCells of each > TableRow independent of its actual visibility in the view port. (see > TableRowSkinBase line 519ff.) > This works well for TableRows with relatively low number of columns. And > knowing that, it is obvious, why the horizontal scrolling works so quick > in your application, because all cells are already prepared and just > need to be moved in X to become visible. > There are 2 opportunities how to attack that issue: > 1.) If you don't have many lines, you could just change the vertical > property to false (see VirtualFlow line 745). We did it only in a test > case so far, so we don't have a lot of experience about that. > 2.) is a tradeoff between vertical and horizontal performance. A code > change would be required in TableRowSkinBase to restrict the actual > creation of TableCells for one line to only those cells that will become > visible for a particular scroll pulse. That way only 10-20 cells are > affected for each line and not 300 any longer. If you now scroll > horizontally, all new cells that become visible, must be additionally > calculated and rendered at that point in time. Unless you have a 50-inch > screen, there shouldn't be so many cells, so the loss of performance in > horizontal direction should be manageable. > > At the moment I am still very occupied with our system launch, but I > intend to participate soon in the community and give back a little bit > of what we received from using JavaFX for free in our applications up to > now. > > Greetings > Clemens > > > Am 25.01.2020 um 02:39 schrieb Ed Kennard: >> 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 > > -- > Mit freundlichen Grüßen / Kind Regards > > Clemens Kadura > Development Leader > Co-founder > > *JACAMAR - agiles Datenmanagement im Team > Weitere Informationen auf www.jacamar.de <https://www.jacamar.de> * > > > > Katla GmbH > Immermannstr. 28 > 39108 Magdeburg > Tel: +49 391-50558353 > Fax: +49 391-50549735 > www.katla-gmbh.de > > Vertretungsberechtigter Geschäftsführer: Dr. Jörg Czekalla > Firmensitz: Magdeburg, Amtsgericht Stendal, HRB 19672 > Verantwortlich i.S.d.MDStV: Katla GmbH > >
