Re: TableView slow vertical scrolling with 300+ columns
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 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" > 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
Re: TableView slow vertical scrolling with 300+ columns
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" 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
Re: TableView slow vertical scrolling with 300+ columns
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 --
Re: TableView slow vertical scrolling with 300+ columns
Hi Jonathan, Thanks for jumping into the discussion. I’ve tested setting a value for fixedCellSize… Against Java 8, there is indeed a _major_ improvement in vertical scrolling performance, but there are some issues that come with that. Performance of horizontal scrolling suffers, becoming similarly juddery to how the vertical scrolling was, although not quite as bad. Also, when scrolling horizontally, the left-most 1, 2 or 3 columns are rendered incorrectly, seemingly with their values not being set. This issue gets worse the further you scroll to the right, so if the horizontal scroll bar is all the way to the left then there’s no issue, but if it’s all the way to the right, in my sample table with 382 columns, 3.5 columns are rendered blank on the left side of the table. Against Java 11 LTS, setting fixedCellSize no longer has any positive impact on the vertical scrolling, but it does still bring all of the negative effects to the horizontal scrolling. Out of the above, I’m not sure what is valuable to formally submit as bugs/changes, versus what not. If someone could give me guidance on that, happy to prepare test code focusing on the useful stuff. Thanks Ed From: Jonathan Giles Date: Sunday, 26 January 2020 at 22:48 To: Ed Kennard Cc: Nir Lisker , "openjfx-dev@openjdk.java.net" Subject: Re: TableView slow vertical scrolling with 300+ columns It's been a wee while since I built TableView, but from memory there is code in there that virtualises the columns, such that those that are scrolled out of view are not being included in the scenegraph needlessly. From memory, to achieve this all you needed to do was set a fixed row height on the TableView, using this API: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableView.html#fixedCellSizeProperty I'm sure it will won't be a silver bullet, but from my recollection it did massively help for these scenarios where there were many columns, most of which were not in the viewable area. -- Jonathan On Sun, Jan 26, 2020 at 5:11 AM Ed Kennard mailto:e...@kennard.net>> wrote: I did previously look at the ControlsFX SpreadsheetView, but it wasn’t a good match, at least at that time. Off the top of my head, I’m not sure it supports nested column headers, which is essential for our purposes. Furthermore, in my travels around the internet on this subject I’ve seen comments suggesting it has its own performance issues, too. I will revisit it though, just to be sure. Beyond that, I haven’t seen any other 3rd party libraries along these lines From: Nir Lisker mailto:nlis...@gmail.com>> Date: Saturday, 25 January 2020 at 16:40 To: Ed Kennard mailto:e...@kennard.net>> Cc: Kevin Rushforth mailto:kevin.rushfo...@oracle.com>>, "openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net>" mailto:openjfx-dev@openjdk.java.net>> Subject: Re: TableView slow vertical scrolling with 300+ columns 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 mailto:e...@kennard.net><mailto:e...@kennard.net<mailto:e...@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" mailto:kevin.rushfo...@oracle.com><mailto:kevin.rushfo...@oracle.com<mailto:kevin.rushfo...@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<http://bugs.java.com><http://bugs.java.com>, though I suspect this is known. > > I don't know the technicalities of VirtualFlow in Ta
Re: TableView slow vertical scrolling with 300+ columns
It's been a wee while since I built TableView, but from memory there is code in there that virtualises the columns, such that those that are scrolled out of view are not being included in the scenegraph needlessly. >From memory, to achieve this all you needed to do was set a fixed row height on the TableView, using this API: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableView.html#fixedCellSizeProperty I'm sure it will won't be a silver bullet, but from my recollection it did massively help for these scenarios where there were many columns, most of which were not in the viewable area. -- Jonathan On Sun, Jan 26, 2020 at 5:11 AM Ed Kennard wrote: > I did previously look at the ControlsFX SpreadsheetView, but it wasn’t a > good match, at least at that time. Off the top of my head, I’m not sure it > supports nested column headers, which is essential for our purposes. > Furthermore, in my travels around the internet on this subject I’ve seen > comments suggesting it has its own performance issues, too. I will revisit > it though, just to be sure. > > Beyond that, I haven’t seen any other 3rd party libraries along these lines > > > From: Nir Lisker > Date: Saturday, 25 January 2020 at 16:40 > To: Ed Kennard > Cc: Kevin Rushforth , " > openjfx-dev@openjdk.java.net" > Subject: Re: TableView slow vertical scrolling with 300+ columns > > 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 e...@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" <mailto:kevin.rushfo...@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<http://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 r
Re: TableView slow vertical scrolling with 300+ columns
Doesn't ControlsFX have that already, or some other 3rd party library? Yes ControlsFX has a GridView class. But it is based on Skin in "com.sun.javafx" packages (replaced by "javafx.scene.control.skin" packages since JavaFX 9). I have not tested if it would still work with JavaFX more recent than version 8. Martin
Re: TableView slow vertical scrolling with 300+ columns
I did previously look at the ControlsFX SpreadsheetView, but it wasn’t a good match, at least at that time. Off the top of my head, I’m not sure it supports nested column headers, which is essential for our purposes. Furthermore, in my travels around the internet on this subject I’ve seen comments suggesting it has its own performance issues, too. I will revisit it though, just to be sure. Beyond that, I haven’t seen any other 3rd party libraries along these lines From: Nir Lisker Date: Saturday, 25 January 2020 at 16:40 To: Ed Kennard Cc: Kevin Rushforth , "openjfx-dev@openjdk.java.net" Subject: Re: TableView slow vertical scrolling with 300+ columns 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 mailto:e...@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" mailto:kevin.rushfo...@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<http://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 mailto: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 >>
Re: TableView slow vertical scrolling with 300+ columns
Hi Martin, Big thank you for your message, and for sharing your code. I took a look and it could definitely be a great starting point for me. The content we need to display is very simple, every cell just needs to display text, occasionally with an expand/collapse button on the left. So I think the only two features we rely on from TableView I'd need to add support for are varying cell widths, and nested column headers, both of which I imagine will require a lot of patience, but I'm definitely going to spend some time looking into it and will let you know how it goes. Ed On 25/01/2020, 15:52, "Martin Desruisseaux" wrote: Hello Ed > 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. > > (…snip…) > 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? By coincidence I'm developing right now a GridView for displaying large grids (millions of rows and columns) using JavaFX VirtualFlow. It seems to work smoothly up to now. That GridView is specifically designed for rendering the sample values of large java.awt.image.RenderedImage using its tile management capacity (tiles loaded in background thread when first requested). It is not my goal to create a general purpose GridView at this time. However it should be possible to remove the RenderedImage-specific code and replace it by another model with not too much effort. The code is at [1]. About improving TableView for managing thousands of columns, I believe that one difficulty is that TableView depends extensively on TableColumn, which provides a lot of capability (resizing, sorting, reordering, hiding, etc.) at the cost of more complexity that may be difficult to optimize. By contrast, above-cited GridView has a lot of restrictions (all cells of the same size, no sorting, no reordering, etc.) for easier implementation. Martin [1] https://github.com/apache/sis/tree/geoapi-4.0/application/sis-javafx/src/main/java/org/apache/sis/gui/coverage
Re: TableView slow vertical scrolling with 300+ columns
> > 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 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" > 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 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 > >> > > >
Re: TableView slow vertical scrolling with 300+ columns
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" 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 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 >>
Re: TableView slow vertical scrolling with 300+ columns
Hello Ed 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. (…snip…) 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? By coincidence I'm developing right now a GridView for displaying large grids (millions of rows and columns) using JavaFX VirtualFlow. It seems to work smoothly up to now. That GridView is specifically designed for rendering the sample values of large java.awt.image.RenderedImage using its tile management capacity (tiles loaded in background thread when first requested). It is not my goal to create a general purpose GridView at this time. However it should be possible to remove the RenderedImage-specific code and replace it by another model with not too much effort. The code is at [1]. About improving TableView for managing thousands of columns, I believe that one difficulty is that TableView depends extensively on TableColumn, which provides a lot of capability (resizing, sorting, reordering, hiding, etc.) at the cost of more complexity that may be difficult to optimize. By contrast, above-cited GridView has a lot of restrictions (all cells of the same size, no sorting, no reordering, etc.) for easier implementation. Martin [1] https://github.com/apache/sis/tree/geoapi-4.0/application/sis-javafx/src/main/java/org/apache/sis/gui/coverage
Re: TableView slow vertical scrolling with 300+ columns
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 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
Re: TableView slow vertical scrolling with 300+ columns
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 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 >
TableView slow vertical scrolling with 300+ columns
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
