MacOS Big Sur and OpenJFX on Arm Macs

[Danny Gonzalez]

Hi All,

Not sure if this is the correct place to direct this conversation but here goes.

With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, what 
are the plans to ensure that OpenJFX and Java will run on this platform?

Are there plans to get the Developer Transition Kit to test on real hardware 
prior to the release of consumer hardware?
Are there testers testing on MacOs beta?

Will OpenJFX and Java be able to run natively in this new Arm Mac environment?
Will OpenJFX and Java be able to run in the Rosetta emulator?

We have many MacOS customers, many of whom will be early adopters and upgrade 
to the new Arm Macs so this could be a big issue for us.

Thanks

Danny

Re: JDK-8177945 : Single cell selection flickers when adding data to TableView

[Danny Gonzalez]

Hi David,

Just wanted to add some more information.

The cell selection flashing issue goes away If I put back the following code in 
the layout function in Parent.java:

//
// One idiom employed by developers is to, during the layout 
pass,
// add or remove nodes from the scene. For example, a ScrollPane
// might add scroll bars to itself if it determines during 
layout
// that it needs them, or a ListView might add cells to itself 
if
// it determines that it needs to. In such situations we must
// apply the CSS immediately and not add it to the scene's queue
// for deferred action.
//
// Note that we only call processCSS if the flag is update. If 
the
// flag is DIRTY_BRANCH, then the whatever children need UPDATE
// will be visited during this layout anyway. On the next pulse,
// doCSSPass will clean up the DIRTY_BRANCH nodes.
//
if (cssFlag == CssFlags.UPDATE) {
processCSS();
}

This code was originally added in in the following commit:

commit e76b5755d4d2752037cc95eb75cb2615a740cc30
Author: David Grieve mailto:dgri...@openjdk.org>>
Date:   Thu Apr 10 15:40:34 2014 -0400

RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply 
css to child nodes if nothing has changed. 2 - on applyCss, only look for 
ancestor node with css state = UPDATE. 3 - only recalculate checksum of css 
file if the file has been removed from a scene or parent


It was reverted out in this commit:

commit 05afad6b528e871d607b76aea2642cf788b417fe
Author: David Grieve mailto:dgri...@openjdk.org>>
Date:   Tue Apr 15 11:51:38 2014 -0400

RT-36672: move code to process css during layout back to impl_reapplyCSS, 
which is where it was priort to RT-36559


This was the point at which the cell selection flashing appeared.

Thanks

Danny


On 3 Mar 2020, at 16:50, David Grieve 
mailto:david.gri...@microsoft.com>> wrote:

The importance of 05afad6 Is there in the commit itself:

+//
+// One idiom employed by developers is to, during the layout pass,
+// add or remove nodes from the scene. For example, a ScrollPane
+// might add scroll bars to itself if it determines during layout
+// that it needs them, or a ListView might add cells to itself if
+// it determines that it needs to. In such situations we must
+// apply the CSS immediately and not add it to the scene's queue
+// for deferred action.
+

If you revert 05afad6, you'll break this.

This is the first time I've become aware of this flickering issue. I'll have to 
look at it.
I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has 
any impact on this.

-Original Message-
From: openjfx-dev 
mailto:openjfx-dev-boun...@openjdk.java.net>>
 On Behalf Of
Danny Gonzalez
Sent: Tuesday, March 3, 2020 11:14 AM
To: openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net>
Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding
data to TableView


There is currently an open bug to do with the issue of selection flickering
when using single cell selection and when adding data to a TableView.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
.java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945da
ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008
d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848
9816399816sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb
8AwcRXVrfLo%3Dreserved=0

This bug seems to be low priority because it hasn’t been looked at since I
submitted it at the start of 2017.

This is quite a major issue for us so I have narrowed down when the issue
was first introduced.

Here is the changeset:

commit 05afad6b528e871d607b76aea2642cf788b417fe
Author: David Grieve
mailto:dgri...@openjdk.org>>
Date:   Tue Apr 15 11:51:38 2014 -0400

   RT-36672: move code to process css during layout back to impl_reapplyCSS,
which is where it was priort to RT-36559


I can’t search the bug database for this bug ID as I believe it was submitted
when a previous bug tracking system was in use.

Does anyone have any knowledge as to why this fix was needed and what
the repercussions would be if I reverted it out for our local OpenJFX build.

Alternatively I would be glad to receive any suggestions of how to fix the
flickering issue if this changeset is important to leave in.

Thanks

Danny

Re: JDK-8177945 : Single cell selection flickers when adding data to TableView

[Danny Gonzalez]

Thanks for taking a look at this David.

Danny

> On 3 Mar 2020, at 16:50, David Grieve  wrote:
> 
> The importance of 05afad6 Is there in the commit itself: 
> 
> +//
> +// One idiom employed by developers is to, during the layout pass,
> +// add or remove nodes from the scene. For example, a ScrollPane
> +// might add scroll bars to itself if it determines during layout
> +// that it needs them, or a ListView might add cells to itself if
> +// it determines that it needs to. In such situations we must
> +// apply the CSS immediately and not add it to the scene's queue
> +// for deferred action.
> +
> 
> If you revert 05afad6, you'll break this. 
> 
> This is the first time I've become aware of this flickering issue. I'll have 
> to look at it. 
> I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has 
> any impact on this.  
> 
>> -----Original Message-
>> From: openjfx-dev  On Behalf Of
>> Danny Gonzalez
>> Sent: Tuesday, March 3, 2020 11:14 AM
>> To: openjfx-dev@openjdk.java.net
>> Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding
>> data to TableView
>> 
>> 
>> There is currently an open bug to do with the issue of selection flickering
>> when using single cell selection and when adding data to a TableView.
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
>> .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945da
>> ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008
>> d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848
>> 9816399816sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb
>> 8AwcRXVrfLo%3Dreserved=0
>> 
>> This bug seems to be low priority because it hasn’t been looked at since I
>> submitted it at the start of 2017.
>> 
>> This is quite a major issue for us so I have narrowed down when the issue
>> was first introduced.
>> 
>> Here is the changeset:
>> 
>> commit 05afad6b528e871d607b76aea2642cf788b417fe
>> Author: David Grieve
>> mailto:dgri...@openjdk.org>>
>> Date:   Tue Apr 15 11:51:38 2014 -0400
>> 
>>RT-36672: move code to process css during layout back to impl_reapplyCSS,
>> which is where it was priort to RT-36559
>> 
>> 
>> I can’t search the bug database for this bug ID as I believe it was submitted
>> when a previous bug tracking system was in use.
>> 
>> Does anyone have any knowledge as to why this fix was needed and what
>> the repercussions would be if I reverted it out for our local OpenJFX build.
>> 
>> Alternatively I would be glad to receive any suggestions of how to fix the
>> flickering issue if this changeset is important to leave in.
>> 
>> Thanks
>> 
>> Danny

JDK-8177945 : Single cell selection flickers when adding data to TableView

[Danny Gonzalez]

There is currently an open bug to do with the issue of selection flickering 
when using single cell selection and when adding data to a TableView.
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8177945

This bug seems to be low priority because it hasn’t been looked at since I 
submitted it at the start of 2017.

This is quite a major issue for us so I have narrowed down when the issue was 
first introduced.

Here is the changeset:

commit 05afad6b528e871d607b76aea2642cf788b417fe
Author: David Grieve mailto:dgri...@openjdk.org>>
Date:   Tue Apr 15 11:51:38 2014 -0400

RT-36672: move code to process css during layout back to impl_reapplyCSS, 
which is where it was priort to RT-36559


I can’t search the bug database for this bug ID as I believe it was submitted 
when a previous bug tracking system was in use.

Does anyone have any knowledge as to why this fix was needed and what the 
repercussions would be if I reverted it out for our local OpenJFX build.

Alternatively I would be glad to receive any suggestions of how to fix the 
flickering issue if this changeset is important to leave in.

Thanks

Danny

Re: Monocle as a replacement

[Danny Gonzalez]

Hi Tres,

We also are suffering from this crash when running our TestFX unit tests, 
particularly on Java 11.
It is due to a concurrency issue between the JavaFX thread and the 
QuantumRenderer thread and there is an OpenJDK bug here: 
https://bugs.openjdk.java.net/browse/JDK-8201567

Quoting from this bug report:
“The QuantumRenderer calls the getPixels() method while trying to find a buffer 
that's not in use, yet in doing so it can inadvertently modify a buffer that's 
in use."

There is also a related TestFX Bug: https://github.com/TestFX/Monocle/issues/56

There is a fix for this issue In the first comment of the JDK-8201567, in a 
link to GitLab: 
https://gitlab.com/openjfxepd/jfxpatch/commit/

We have used this patch in our local OpenJFX build.

This has never been made into a pull request however but I believe it should.

Danny

On 17 Feb 2020, at 19:12, Tres Finocchiaro 
mailto:tres.finocchi...@gmail.com>> wrote:

Hi,

I'm the developer of a printing plugin which leverages JavaFX for a few
HTML functions.

One of our functions would greatly benefit from being "headless (or more
accurately, "silent") mode that Monocle offers and I'm evaluating the use
of Monocle on (non-headless) Desktops for this.  I'm currently testing a
monocle build by the TestFX team for MacOS.

Although first test was positive, when invoking multiple times, I'm getting
some internal errors similar to this:
https://stackoverflow.com/questions/49388497 and the framework grows slower
and slower as it nears its final capture. (I'm using WebView.capture(...))

Is this the right place for such as discussion? Where's the best place to
ask about issues with Monocle?


- tres.finocchi...@gmail.com

publishToMavenLocal not publishing source jars

[Danny Gonzalez]

I am using the command "./gradlew publishToMavenLocal” to publish the sdk to my 
local maven repository.

I don’t seem to be getting the sources jar files published along with each 
module. Do I have to configure something specifically in build.gradle? I 
couldn’t see anything obvious.

Thanks

Danny

Re: TableView with many columns poor ui performance

[Danny Gonzalez]

Hi Kevin,

Thanks for your comments.

I am about to push some code for this. I have used a linkedHashMap which stores 
the listener and a count.
I have also updated the unit tests to test for the addListener and 
removeListener behaviour in the case you register the same listener more than 
once.

Would be interested in any comments or suggestions you may have.
This fix has allowed us to move forward to using Java 11 as otherwise the 
number of listeners unregistering when using a TableView was killing our 
application.

Thanks for your time.

Danny

> On 14 Feb 2020, at 14:32, Kevin Rushforth  wrote:
> 
> Whether or not the specification of notifying a listener multiple times was 
> intentional or driven by the implementation, it is part of the spec, and some 
> applications could be relying on it. I do agree that there is no guarantee as 
> to the order, which might simplify things. I can think of two possible 
> implementations:
> 
> 1. Use a counter as you mentioned below as a possibility. If you did this, 
> you would need to add an additional LinkedHashSet of objects containing the 
> Listener and a count. You could initialize that set to null and only 
> constructing it in the (rather unlikely) case that a listener is added when 
> it is already in the set of listeners. You could then test for "if (countSet 
> == null)" in the various operations and do the simple thing if it is.
> 
> 2. Since adding a listener more than once is unlikely, you could switch from 
> a LinkedHashSet to an ArrayList the first time that a listener is added more 
> than once. You would keep a Collection of listeners, initialize it to a 
> LinkedHashSet, and dynamically switch from a LinkedHashSet to an ArrayList 
> (copying existing entries) in addListener if the collection contains the 
> listener already. This would be simpler logic than keeping track of the count 
> for each object.
> 
> I would lean towards the second optoin. It gives the desired speed up for the 
> common case where we don't add a listener more than once, and in the worst 
> case, switches back to what we have today.
> 
> -- Kevin
> 
> 
> On 2/12/2020 4:03 AM, Danny Gonzalez wrote:
>> Hi Jeanette,
>> 
>> 
>> True, I hadn't read that spec in ObservableValueBase.
>> Although that does seem odd behaviour to me. Obviously as the original 
>> implementation was using an array I can see how the implementation drove 
>> that specification.
>> 
>> Non of the JavaFx unit tests test for that specific case as the unit tests 
>> all passed. It would be nice if there was a specific test case for this 
>> behaviour.
>> 
>> I would need to store a registration count for each listener to satisfy this 
>> requirement.
>> 
>> 
>> 
>> On 12 Feb 2020, at 11:34, Jeanette Winzenburg 
>> mailto:faste...@swingempire.de>> wrote:
>> 
>> 
>> Zitat von Danny Gonzalez 
>> mailto:danny.gonza...@screamingfrog.co.uk>>:
>> 
>> Hi Ed,
>> 
>> I have submitted a pull request and the branch is here:
>> https://github.com/screamingfrog/jfx/tree/listeners_optimisation
>> 
>> 
>> 
>> hmm .. the change seems to be breaking spec of add/remove listeners
>> 
>> "If the same listener is added more than once, then it will be notified more 
>> than once".
>> 
>> or what am I missing?
>> 
>> 
> 

Re: TableView with many columns poor ui performance

[Danny Gonzalez]

Hi Jeanette,


True, I hadn't read that spec in ObservableValueBase.
Although that does seem odd behaviour to me. Obviously as the original 
implementation was using an array I can see how the implementation drove that 
specification.

Non of the JavaFx unit tests test for that specific case as the unit tests all 
passed. It would be nice if there was a specific test case for this behaviour.

I would need to store a registration count for each listener to satisfy this 
requirement.



On 12 Feb 2020, at 11:34, Jeanette Winzenburg 
mailto:faste...@swingempire.de>> wrote:


Zitat von Danny Gonzalez 
mailto:danny.gonza...@screamingfrog.co.uk>>:

Hi Ed,

I have submitted a pull request and the branch is here:
https://github.com/screamingfrog/jfx/tree/listeners_optimisation



hmm .. the change seems to be breaking spec of add/remove listeners

"If the same listener is added more than once, then it will be notified more 
than once".

or what am I missing?

Re: TableView with many columns poor ui performance

[Danny Gonzalez]

Hi Ed,

I have submitted a pull request and the branch is here:
https://github.com/screamingfrog/jfx/tree/listeners_optimisation


Danny



On 6 Feb 2020, at 09:50, Ed Kennard mailto:e...@kennard.net>> 
wrote:

Hi Danny,

This is great news, I've previously written about perf  issues with TableView, 
do you have a branch I could try out which is rebased off current jfx master?



On 06/02/2020, 10:40, "openjfx-dev on behalf of Danny Gonzalez" 
mailto:openjfx-dev-boun...@openjdk.java.net>
 on behalf of 
danny.gonza...@screamingfrog.co.uk<mailto:danny.gonza...@screamingfrog.co.uk>> 
wrote:

   Hi,

   We have been struggling with our migration from Java 8 to Java 11 due to 
various issues we are having with TableView. The main issue is the general UI 
lag and slow TableView scroll performance.

   For context here some links around the issues:

   TableView has a horrific performance with many columns #409
   https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033

   JDK-8088394 : Huge memory consumption in TableView with too many columns
   https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088394

   JavaFX TreeTableView slow scroll performance
   https://bugs.openjdk.java.net/browse/JDK-8166956

   TableRowSkinBase fails to correctly virtualise cells in horizontal direction
   https://bugs.openjdk.java.net/browse/JDK-8185887

   OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ 
columns
   https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html


   We have a TableView that is being populated with rows dynamically around the 
rate of 2 rows per second. The issue we are experiencing is the lagginess of 
the UI when these rows are being inserted. TableViews with fewer columns don’t 
seem to exhibit the behaviour quite as badly.

   I can see that there was an optimisation in Java 8 that would alleviate the 
TableView performance issue. If you used a fixed cell size in your TableView, a 
bit of optimisation code in TableRowSkinBase.isColumnPartiallyOrFullyVisible 
would  only render the visible columns. This code, as has been documented in 
the first link above, used to work in Java 8 but not now in Java 11. It also 
has a bug where the visible columns calculation is incorrect and instead 
calculates the visibility on the whole width of the TableView rather than the 
visible columns. I have tried fixing this up, and even with this code fixed, it 
brings in other issues where resizing the TableView results in blank columns.

   I have done some testing and can see that the main issues with the slow down 
is to do with the thousands of listeners that are being removed in TableView 
when you add rows or scroll. It is taking up to 60% of the JavaFX Application 
thread.
   For whatever reason the amount of listeners registering/unregistering has 
jumped significantly between Java 8 and Java 11.

   The following changeset for example (which added an extra listener on the 
Node class) impacted TableView performance significantly:

   commit e21606d3a1b73cd4b44383babc750a4b4721edfd
   Author: Florian Kirmaier 
mailto:f...@sandec.de><mailto:f...@sandec.de>>
   Date:   Tue Jan 22 09:08:36 2019 -0800

   8216377: Fix memoryleak for initial nodes of Window
   8207837: Indeterminate ProgressBar does not animate if content is added 
after scene is set on window



   Add or remove the windowShowingChangedListener when the scene changes



   I can see that the code for removing listeners in ExpressionHelper.Generic 
is extremely sub optimal and uses a linear search through an array to remove 
listeners.

   I have rewritten this class to use a Set instead of an Array and it has 
fixed our major TableView issues where the performance of the UI seriously 
deteriorated to the point of not being usable. The CPU usage of 
com.sun.javafx.binding.ExpressionHelper.removeListener in the JavaFX 
Application Thread has dropped from 60% to less than 1%.

   I believe this fix will alleviate the major issues of TableViews detailed in 
the above links.
   I have run my fix through the unit test suite and believe it is functionally 
equivalent to the original code, just much faster.

   I am happy to submit a pull request. I am new to openJFX contributing so any 
pointers of what I need to do here would be appreciated.

   Thanks

   Danny

TableView with many columns poor ui performance

[Danny Gonzalez]

Hi,

We have been struggling with our migration from Java 8 to Java 11 due to 
various issues we are having with TableView. The main issue is the general UI 
lag and slow TableView scroll performance.

For context here some links around the issues:

TableView has a horrific performance with many columns #409
https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033

JDK-8088394 : Huge memory consumption in TableView with too many columns
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088394

JavaFX TreeTableView slow scroll performance
https://bugs.openjdk.java.net/browse/JDK-8166956

TableRowSkinBase fails to correctly virtualise cells in horizontal direction
https://bugs.openjdk.java.net/browse/JDK-8185887

OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns
https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html


We have a TableView that is being populated with rows dynamically around the 
rate of 2 rows per second. The issue we are experiencing is the lagginess of 
the UI when these rows are being inserted. TableViews with fewer columns don’t 
seem to exhibit the behaviour quite as badly.

I can see that there was an optimisation in Java 8 that would alleviate the 
TableView performance issue. If you used a fixed cell size in your TableView, a 
bit of optimisation code in TableRowSkinBase.isColumnPartiallyOrFullyVisible 
would  only render the visible columns. This code, as has been documented in 
the first link above, used to work in Java 8 but not now in Java 11. It also 
has a bug where the visible columns calculation is incorrect and instead 
calculates the visibility on the whole width of the TableView rather than the 
visible columns. I have tried fixing this up, and even with this code fixed, it 
brings in other issues where resizing the TableView results in blank columns.

I have done some testing and can see that the main issues with the slow down is 
to do with the thousands of listeners that are being removed in TableView when 
you add rows or scroll. It is taking up to 60% of the JavaFX Application thread.
For whatever reason the amount of listeners registering/unregistering has 
jumped significantly between Java 8 and Java 11.

The following changeset for example (which added an extra listener on the Node 
class) impacted TableView performance significantly:

commit e21606d3a1b73cd4b44383babc750a4b4721edfd
Author: Florian Kirmaier mailto:f...@sandec.de>>
Date:   Tue Jan 22 09:08:36 2019 -0800

8216377: Fix memoryleak for initial nodes of Window
8207837: Indeterminate ProgressBar does not animate if content is added 
after scene is set on window



Add or remove the windowShowingChangedListener when the scene changes



I can see that the code for removing listeners in ExpressionHelper.Generic is 
extremely sub optimal and uses a linear search through an array to remove 
listeners.

I have rewritten this class to use a Set instead of an Array and it has fixed 
our major TableView issues where the performance of the UI seriously 
deteriorated to the point of not being usable. The CPU usage of 
com.sun.javafx.binding.ExpressionHelper.removeListener in the JavaFX 
Application Thread has dropped from 60% to less than 1%.

I believe this fix will alleviate the major issues of TableViews detailed in 
the above links.
I have run my fix through the unit test suite and believe it is functionally 
equivalent to the original code, just much faster.

I am happy to submit a pull request. I am new to openJFX contributing so any 
pointers of what I need to do here would be appreciated.

Thanks

Danny

Re: TableView slow vertical scrolling with 300+ columns

[Danny Gonzalez]

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 

How to build standalone openJFX modules for uploading to a local maven repository

[Danny Gonzalez]

We have a java 11 project that uses maven to pull in openJFX modules  i.e. 
javafx-controls, javafx-web, javafx-swing.

What we would like to do is build our own versions of these openJFX modules for 
use as maven dependencies which use a fork of openJFX (which we build locally 
to fix up some bugs).

I can’t however see an obvious way of building these openJFX standalone modules 
for deploying in our local maven repository in the same way that they were 
originally built for uploading into maven central.

Is this documented anywhere?

Thanks for your help

Danny