TableView slow vertical scrolling with 300+ columns

Tue Jan 28 13:11:58 UTC 2020

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 <ed at 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-bounces at openjdk.java.net on behalf of clemens.kadura at 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
> 
> 