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

Reply via email to