From daniel.armbrust.list at gmail.com  Tue Jan  1 03:54:14 2019
From: daniel.armbrust.list at gmail.com (Dan Armbrust)
Date: Mon, 31 Dec 2018 21:54:14 -0600
Subject: Problem running JavaFX in maven plugins
Message-ID: <c2c24a44-bd15-34d2-f734-71fab24d7793@gmail.com>

Hi,

I'm trying to migrate a codebase to JDK 11 / OpenJFX, and have run into an issue I didn't 
have under JDK 8.

We have a complex maven build process - parts of which include building our own maven 
plugins, and then executing those plugins in a different portion of the build.

Maven uses isolated Plugin Classloaders for each plugin execution: 
https://maven.apache.org/guides/mini/guide-maven-classloading.html

When my plugin executes, its going down a path that needs to start up the JavaFX subsystem 
- mostly to get support for tasks and such (we are actually building headless, with a hack 
of a HeadlessToolkit shimmed in to make JavaFX actually work headless) but - it would 
appear that because some other class loader in my build process already hit the JavaFX 
startup once... I fail on a native library load:

Loading library glass from resource failed: java.lang.UnsatisfiedLinkError: Native Library 
/home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another classloader
java.lang.UnsatisfiedLinkError: Native Library 
/home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another classloader
 ??????? at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2456)
 ??????? at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
 ??????? at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
 ??????? at java.base/java.lang.Runtime.load0(Runtime.java:767)
 ??????? at java.base/java.lang.System.load(System.java:1831)
 ??????? at 
com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:205)
 ??????? at 
com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:185)
 ??????? at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:157)
 ??????? at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
 ??????? at com.sun.glass.ui.Application.loadNativeLibrary(Application.java:110)
 ??????? at com.sun.glass.ui.Application.loadNativeLibrary(Application.java:118)
 ??????? at com.sun.glass.ui.gtk.GtkApplication.lambda$static$2(GtkApplication.java:109)
 ??????? at java.base/java.security.AccessController.doPrivileged(Native Method)
 ??????? at com.sun.glass.ui.gtk.GtkApplication.<clinit>(GtkApplication.java:108)
 ??????? at 
com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(GtkPlatformFactory.java:41)
 ??????? at com.sun.glass.ui.Application.run(Application.java:144)
 ??????? at com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:258)
 ??????? at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:269)

Any suggestions on how to deal with this?

I'm running on linux with:
openjdk 11.0.1 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)

I'm going to try this hack and see if it works: 
https://stackoverflow.com/questions/28369180/multiple-maven-plugin-dependencies-native-library-already-loaded-in-another-cl

But it would be nice to have a proper solution for this.

Also, on a completely unrelated note, where the heck is the JavaFX bug tracker these 
days?? There seems to be no end to confusing information out there about where the bug 
tracker is, multiple github mirrors have trackers, and the place that should clarify this 
says nothing: https://openjfx.io/

Multiple Oracle pages still point to the Jira, many other pages point to the 
bugreport.java.com, others point to https://bugs.openjdk.java.net/ but that shows no 
javafx project.

Is this one official now? https://github.com/javafxports/openjdk-jfx/issues


Thanks,
Dan


From mike.ennen at gmail.com  Tue Jan  1 04:36:34 2019
From: mike.ennen at gmail.com (Michael Ennen)
Date: Mon, 31 Dec 2018 21:36:34 -0700
Subject: Problem running JavaFX in maven plugins
In-Reply-To: <c2c24a44-bd15-34d2-f734-71fab24d7793@gmail.com>
References: <c2c24a44-bd15-34d2-f734-71fab24d7793@gmail.com>
Message-ID: <CAOTPd65GN6AbVEJQobfXci4qaHZOdbmoyCLEQQk7G41rn3oxhw@mail.gmail.com>

The official issue tracker for JavaFX is https://bugs.openjdk.java.net. The
JavaFX project is
a "Component" of OpenJDK. You can see the JavaFX bugs from this URL:

https://bugs.openjdk.java.net/browse/JDK-8215964?jql=project%20%3D%20JDK%20AND%20component%20%3D%20javafx

The GitHub issue tracker is a useful addition to the Jira (at least in my
opinion) for talking
about issues that people want to (potentially) create a pull request (on
the Github) for.

Cheers,

Michael Ennen

On Mon, Dec 31, 2018 at 8:54 PM Dan Armbrust <daniel.armbrust.list at gmail.com>
wrote:

> Hi,
>
> I'm trying to migrate a codebase to JDK 11 / OpenJFX, and have run into an
> issue I didn't
> have under JDK 8.
>
> We have a complex maven build process - parts of which include building
> our own maven
> plugins, and then executing those plugins in a different portion of the
> build.
>
> Maven uses isolated Plugin Classloaders for each plugin execution:
> https://maven.apache.org/guides/mini/guide-maven-classloading.html
>
> When my plugin executes, its going down a path that needs to start up the
> JavaFX subsystem
> - mostly to get support for tasks and such (we are actually building
> headless, with a hack
> of a HeadlessToolkit shimmed in to make JavaFX actually work headless) but
> - it would
> appear that because some other class loader in my build process already
> hit the JavaFX
> startup once... I fail on a native library load:
>
> Loading library glass from resource failed:
> java.lang.UnsatisfiedLinkError: Native Library
> /home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another
> classloader
> java.lang.UnsatisfiedLinkError: Native Library
> /home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another
> classloader
>          at
> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2456)
>          at
> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
>          at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
>          at java.base/java.lang.Runtime.load0(Runtime.java:767)
>          at java.base/java.lang.System.load(System.java:1831)
>          at
>
> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:205)
>          at
>
> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:185)
>          at
> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:157)
>          at
> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
>          at
> com.sun.glass.ui.Application.loadNativeLibrary(Application.java:110)
>          at
> com.sun.glass.ui.Application.loadNativeLibrary(Application.java:118)
>          at
> com.sun.glass.ui.gtk.GtkApplication.lambda$static$2(GtkApplication.java:109)
>          at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>          at
> com.sun.glass.ui.gtk.GtkApplication.<clinit>(GtkApplication.java:108)
>          at
>
> com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(GtkPlatformFactory.java:41)
>          at com.sun.glass.ui.Application.run(Application.java:144)
>          at
> com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:258)
>          at
> com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:269)
>
> Any suggestions on how to deal with this?
>
> I'm running on linux with:
> openjdk 11.0.1 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
>
> I'm going to try this hack and see if it works:
>
> https://stackoverflow.com/questions/28369180/multiple-maven-plugin-dependencies-native-library-already-loaded-in-another-cl
>
> But it would be nice to have a proper solution for this.
>
> Also, on a completely unrelated note, where the heck is the JavaFX bug
> tracker these
> days?  There seems to be no end to confusing information out there about
> where the bug
> tracker is, multiple github mirrors have trackers, and the place that
> should clarify this
> says nothing: https://openjfx.io/
>
> Multiple Oracle pages still point to the Jira, many other pages point to
> the
> bugreport.java.com, others point to https://bugs.openjdk.java.net/ but
> that shows no
> javafx project.
>
> Is this one official now?
> https://github.com/javafxports/openjdk-jfx/issues
>
>
> Thanks,
> Dan
>
>

From kevin.rushforth at oracle.com  Wed Jan  2 21:43:31 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 2 Jan 2019 13:43:31 -0800
Subject: [12] RFR: JDK-8214793: Update copyright header for files modified in
 2018
Message-ID: <efeafbfa-e7fc-1681-7480-3a61f2ef37dc@oracle.com>

Ambarish or Murali,

Please review the following fix to bump the copyright year to 2018 for 
files modified last year, but not updated:

https://bugs.openjdk.java.net/browse/JDK-8214793
http://cr.openjdk.java.net/~kcr/8214793/webrev/

Thanks.

-- Kevin


From youngty1997 at gmail.com  Thu Jan  3 00:27:45 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Wed, 2 Jan 2019 18:27:45 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
Message-ID: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>

(I'm too lazy to make different emails for every bug so I've just thrown 
them in a single email. Hopefully that isn't a big deal.)


In my attempt to write a more proper responsive JavaFX UI, I've created 
a new JavaFX project which extensively uses DoubleBindings to force the 
min/max width/height of various components to their parent containing 
objects(HBox and VBox mainly) so that 1440p and 4k displays could be 
more easily supported. While it does allow for easier 1440p and 4k 
scaling, JavaFX itself seems to have /extremely/ horrible content 
rendering & resizing bugs to the point where the application becomes 
usable.


For clarity, the applications uses buttons in a VBox which when clicked 
set a ScrollPane on the right side to whatever pane the button 
represents("About" for example) like a TabPane. This is so it can be 
scaled more easily to different resolutions.


Multiple of the bugs can be observed by simply resizing the JavaFX 
window. When doing so, content will seemingly struggle to keep up with 
resizing events. As a result, white(or sometimes black) glitching can be 
seen wherever the window is being expanded and UI components will "jump" 
around. TableView's horizontal and vertical scrollbars will glitch out 
and show while the window is being resized even though it has plenty of 
room to display the contents. They sometimes even get stuck, requiring 
the user to resize the window for them to go away.


If the window is resized or if the window is maximized and later 
unmaximized , any non visible content will not be resized and will 
require that the window be resized by the user. A horizontal scroll bar 
will be displayed and usable to scroll to the content that hasn't been 
adjusted to the new window size. Sometimes JavaFX will slowly resize the 
content in seemingly steps however it doesn't always do this.


Thinking that this might be problems caused by extensive use of 
DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It 
has all of the same UI glitching that I've encountered in my JavaFX 
application at a lesser scale besides TableView since it doesn't use 
TableView.


The degree of how badly the bugs happen seemingly depend on:

 ??? A. The app launch

 ??? B. The time the application is open

 ??? C. The max stretched width/height of the window


In other words, it's possible to experience little UI glitching one app 
launch while using it after awhile but then relaunch it later with no 
code changed and get far more glitching.


Another problem is a font bug revolving around making text bold. When 
attempting to make a label bold, the boldness is seemingly not being 
applied to some Label text. It might work on a few Labels in a certain 
part of the UI but completely refuse in other parts. Making things 
weirder is the disappearing boldness of Labels after setting a new Pane 
in the ScrollPane and switching back to a that specific pane.


For example: on first click to the pane two labels will be bold as set 
in code. Switching to another pane and back results in the last bold 
label not being bold anymore. Switching to another pane again results in 
the first Label no longer being bold.


All of these bugs make the application unusable(except the boldness 
bug). Is this all known? Are there any workarounds?


P.S. To whoever is developing SceneBuilder, please add a minimum 
width/height to the stage. A user shouldn't be able to make resize the 
window to 1x5 or whatever the smallest window size is allowed by the OS.


From kevin.rushforth at oracle.com  Fri Jan  4 00:31:21 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 3 Jan 2019 16:31:21 -0800
Subject: [12] RFR: 8200665: Ensemble: Update SyntaxHighlighter to version 4.0.1
Message-ID: <371fe481-0ba9-155f-9e2e-bdf4611c81a3@oracle.com>

Hi Ajit or Ambarish,

Please review the following to update the third-party SyntaxHighlighter 
utility (used by the Ensemble8 demo) to the latest version 4.0.1:

https://bugs.openjdk.java.net/browse/JDK-8200665
http://cr.openjdk.java.net/~kcr/8200665/webrev.00/

Details are in the bug report.

Thanks.

-- Kevin


From daniel.armbrust.list at gmail.com  Fri Jan  4 06:28:41 2019
From: daniel.armbrust.list at gmail.com (Dan Armbrust)
Date: Fri, 4 Jan 2019 00:28:41 -0600
Subject: Problem running JavaFX in maven plugins
In-Reply-To: <c2c24a44-bd15-34d2-f734-71fab24d7793@gmail.com>
References: <c2c24a44-bd15-34d2-f734-71fab24d7793@gmail.com>
Message-ID: <a55aafeb-1e8b-1dd5-8fa7-ee4da269cd5d@gmail.com>

As a followup, the easiest workaround I found is this silly hack:

 ???????????????????? String s = System.getProperty("javafxHack");
 ???????????????????? int i = 0;
 ???????????????????? if (!StringUtils.isBlank(s))
 ???????????????????? {
 ??????????????????????? i = Integer.parseInt(s);
 ??????????????????????? i++;
 ???????????????????? }
 ???????????????????? System.setProperty("javafxHack", i + "");
 ???????????????????? System.setProperty("javafx.version", "mavenHack" + i);

Which I run before calling PlatformImpl.startup();
This way, each classloader that launches JavaFX gets its own copy of the dll.

It would be nice if the JavaFX code itself handled the dll's better to not have this issue 
- this is a regression from JDK 8.

But I do realize its probably a rare usecase... I run into it because I have multiple 
instantiations of a plugin that runs during a maven lifecycle that utilizes the tasks API, 
among other things.

But this will also break for anyone that tries to use parts of JavaFX in a server like 
tomcat where classloaders are isolated. But that might not be a common issue either unless 
the very old feature request about JavaFX not supporting running Headless get fixed.

I currently use our own hacked implementation of a ToolKit to inject when running 
headless, in order to make the tasks API work.

Dan



On 12/31/2018 09:54 PM, Dan Armbrust wrote:
> Hi,
>
> I'm trying to migrate a codebase to JDK 11 / OpenJFX, and have run into an issue I 
> didn't have under JDK 8.
>
> We have a complex maven build process - parts of which include building our own maven 
> plugins, and then executing those plugins in a different portion of the build.
>
> Maven uses isolated Plugin Classloaders for each plugin execution: 
> https://maven.apache.org/guides/mini/guide-maven-classloading.html
>
> When my plugin executes, its going down a path that needs to start up the JavaFX 
> subsystem - mostly to get support for tasks and such (we are actually building headless, 
> with a hack of a HeadlessToolkit shimmed in to make JavaFX actually work headless) but - 
> it would appear that because some other class loader in my build process already hit the 
> JavaFX startup once... I fail on a native library load:
>
> Loading library glass from resource failed: java.lang.UnsatisfiedLinkError: Native 
> Library /home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another classloader
> java.lang.UnsatisfiedLinkError: Native Library 
> /home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another classloader
> ??????? at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2456)
> ??????? at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
> ??????? at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
> ??????? at java.base/java.lang.Runtime.load0(Runtime.java:767)
> ??????? at java.base/java.lang.System.load(System.java:1831)
> ??????? at 
> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:205)
> ??????? at 
> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:185)
> ??????? at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:157)
> ??????? at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
> ??????? at com.sun.glass.ui.Application.loadNativeLibrary(Application.java:110)
> ??????? at com.sun.glass.ui.Application.loadNativeLibrary(Application.java:118)
> ??????? at com.sun.glass.ui.gtk.GtkApplication.lambda$static$2(GtkApplication.java:109)
> ??????? at java.base/java.security.AccessController.doPrivileged(Native Method)
> ??????? at com.sun.glass.ui.gtk.GtkApplication.<clinit>(GtkApplication.java:108)
> ??????? at 
> com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(GtkPlatformFactory.java:41)
> ??????? at com.sun.glass.ui.Application.run(Application.java:144)
> ??????? at com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:258)
> ??????? at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:269)
>
> Any suggestions on how to deal with this?
>
> I'm running on linux with:
> openjdk 11.0.1 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
>
> I'm going to try this hack and see if it works: 
> https://stackoverflow.com/questions/28369180/multiple-maven-plugin-dependencies-native-library-already-loaded-in-another-cl
>
> But it would be nice to have a proper solution for this.
>
> Also, on a completely unrelated note, where the heck is the JavaFX bug tracker these 
> days?? There seems to be no end to confusing information out there about where the bug 
> tracker is, multiple github mirrors have trackers, and the place that should clarify 
> this says nothing: https://openjfx.io/
>
> Multiple Oracle pages still point to the Jira, many other pages point to the 
> bugreport.java.com, others point to https://bugs.openjdk.java.net/ but that shows no 
> javafx project.
>
> Is this one official now? https://github.com/javafxports/openjdk-jfx/issues
>
>
> Thanks,
> Dan
>


From arunprasad.rajkumar at oracle.com  Fri Jan  4 10:21:06 2019
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Fri, 4 Jan 2019 15:51:06 +0530
Subject: RFR JDK-8215799: [Windows] Complex texts are not rendered properly
Message-ID: <2C3FA821-68A5-4042-B249-B9ACAC93152B@oracle.com>

Hi,

Please review the following Github PR,

https://github.com/javafxports/openjdk-jfx/pull/337

https://bugs.openjdk.java.net/browse/JDK-8215799

Thanks,
Arun

From kevin.rushforth at oracle.com  Fri Jan  4 23:54:09 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 4 Jan 2019 15:54:09 -0800
Subject: Proposed schedule for JavaFX 12
In-Reply-To: <b524f05f-e8e5-f1dd-c7e0-b521cce22923@oracle.com>
References: <b524f05f-e8e5-f1dd-c7e0-b521cce22923@oracle.com>
Message-ID: <b2c95a28-8a27-e499-c3d8-cb8a740e1505@oracle.com>

As a reminder, the RDP1 date for JavaFX 12 is this coming Monday, 
January 7, at 23:59 Pacific time. This is the deadline for features, 
although we will have a process for getting in some smaller enhancements 
after RDP1 with approval, as was done in previous releases.

-- Kevin


On 10/24/2018 5:42 AM, Kevin Rushforth wrote:
> Here is the proposed schedule for JavaFX 12.
>
> RDP1: Jan 7, 2019 (aka ?feature freeze?)
> RDP2: Feb 4, 2019
> Freeze: Feb 25, 2019
> GA: March 12, 2019
>
> We plan to fork a 12-dev stabilization repo some time between RDP1 and 
> RDP2. The GA date is one week ahead of JDK 12, matching what we did 
> for 11.
>
> Please let Johan or I know if you have any questions.
>
> -- Kevin
>


From ramonjsantiago at gmail.com  Sat Jan  5 13:33:28 2019
From: ramonjsantiago at gmail.com (Ramon Santiago)
Date: Sat, 5 Jan 2019 08:33:28 -0500
Subject: Has any consideration been made to move the Charts into s separate
 module?
Message-ID: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>

-- 
rjs

From johnvalrose at gmail.com  Sat Jan  5 13:43:58 2019
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sun, 6 Jan 2019 00:43:58 +1100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
Message-ID: <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>

Hi Ramon,

I personally have never seen or heard of any such discussion and I?m not entirely sure in which context you are using the word ?module?.

Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?

Either way, can you tell us why you have thought of this idea?

Graciously,

John-Val

> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
> 
> -- 
> rjs

From ramonjsantiago at gmail.com  Sat Jan  5 13:56:29 2019
From: ramonjsantiago at gmail.com (Ramon Santiago)
Date: Sat, 5 Jan 2019 08:56:29 -0500
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
Message-ID: <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>

Yes, I meant removing charts from the core of JavaFX and moving he charts
to a separate JPMS  module.

Why? They are not really core components are they? They are dead weight in
applications that never will use them.

On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:

> Hi Ramon,
>
> I personally have never seen or heard of any such discussion and I?m not
> entirely sure in which context you are using the word ?module?.
>
> Do you meaning simply removing charts from the core of JavaFX or do you
> mean creating the charts as an actual module within JPMS?
>
> Either way, can you tell us why you have thought of this idea?
>
> Graciously,
>
> John-Val
>
> > On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >
> > --
> > rjs
>


-- 
rjs

From tbee at tbee.org  Sat Jan  5 14:00:29 2019
From: tbee at tbee.org (Tom Eugelink)
Date: Sat, 5 Jan 2019 15:00:29 +0100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
 <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
Message-ID: <4d5416a2-ba02-edb4-51d4-9718763854c1@tbee.org>

That does make sense...


On 5-1-2019 14:56, Ramon Santiago wrote:
> Yes, I meant removing charts from the core of JavaFX and moving he charts
> to a separate JPMS  module.
>
> Why? They are not really core components are they? They are dead weight in
> applications that never will use them.
>
> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>
>> Hi Ramon,
>>
>> I personally have never seen or heard of any such discussion and I?m not
>> entirely sure in which context you are using the word ?module?.
>>
>> Do you meaning simply removing charts from the core of JavaFX or do you
>> mean creating the charts as an actual module within JPMS?
>>
>> Either way, can you tell us why you have thought of this idea?
>>
>> Graciously,
>>
>> John-Val
>>
>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
>> wrote:
>>> --
>>> rjs
>


From youngty1997 at gmail.com  Sat Jan  5 14:56:00 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 5 Jan 2019 08:56:00 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
Message-ID: <54431d51-bd6d-c776-4eaa-08cbb8b9e867@gmail.com>


On 1/2/19 6:27 PM, Ty Young wrote:
>
> (I'm too lazy to make different emails for every bug so I've just 
> thrown them in a single email. Hopefully that isn't a big deal.)
>
>
> In my attempt to write a more proper responsive JavaFX UI, I've 
> created a new JavaFX project which extensively uses DoubleBindings to 
> force the min/max width/height of various components to their parent 
> containing objects(HBox and VBox mainly) so that 1440p and 4k displays 
> could be more easily supported. While it does allow for easier 1440p 
> and 4k scaling, JavaFX itself seems to have /extremely/ horrible 
> content rendering & resizing bugs to the point where the application 
> becomes usable.
>
>
> For clarity, the applications uses buttons in a VBox which when 
> clicked set a ScrollPane on the right side to whatever pane the button 
> represents("About" for example) like a TabPane. This is so it can be 
> scaled more easily to different resolutions.
>
>
> Multiple of the bugs can be observed by simply resizing the JavaFX 
> window. When doing so, content will seemingly struggle to keep up with 
> resizing events. As a result, white(or sometimes black) glitching can 
> be seen wherever the window is being expanded and UI components will 
> "jump" around. TableView's horizontal and vertical scrollbars will 
> glitch out and show while the window is being resized even though it 
> has plenty of room to display the contents. They sometimes even get 
> stuck, requiring the user to resize the window for them to go away.
>
>
> If the window is resized or if the window is maximized and later 
> unmaximized , any non visible content will not be resized and will 
> require that the window be resized by the user. A horizontal scroll 
> bar will be displayed and usable to scroll to the content that hasn't 
> been adjusted to the new window size. Sometimes JavaFX will slowly 
> resize the content in seemingly steps however it doesn't always do this.
>
>
> Thinking that this might be problems caused by extensive use of 
> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It 
> has all of the same UI glitching that I've encountered in my JavaFX 
> application at a lesser scale besides TableView since it doesn't use 
> TableView.
>
>
> The degree of how badly the bugs happen seemingly depend on:
>
> ??? A. The app launch
>
> ??? B. The time the application is open
>
> ??? C. The max stretched width/height of the window
>
>
> In other words, it's possible to experience little UI glitching one 
> app launch while using it after awhile but then relaunch it later with 
> no code changed and get far more glitching.
>
>
> Another problem is a font bug revolving around making text bold. When 
> attempting to make a label bold, the boldness is seemingly not being 
> applied to some Label text. It might work on a few Labels in a certain 
> part of the UI but completely refuse in other parts. Making things 
> weirder is the disappearing boldness of Labels after setting a new 
> Pane in the ScrollPane and switching back to a that specific pane.
>
>
> For example: on first click to the pane two labels will be bold as set 
> in code. Switching to another pane and back results in the last bold 
> label not being bold anymore. Switching to another pane again results 
> in the first Label no longer being bold.
>
>
> All of these bugs make the application unusable(except the boldness 
> bug). Is this all known? Are there any workarounds?
>
>
> P.S. To whoever is developing SceneBuilder, please add a minimum 
> width/height to the stage. A user shouldn't be able to make resize the 
> window to 1x5 or whatever the smallest window size is allowed by the OS.
>

I've also just tested this in Ubuntu 18.04 as well via a jlink bundle. 
All of the window resizing and content jumping bugs exist on it as well.


Does anyone know anything?


From johnvalrose at gmail.com  Sun Jan  6 01:58:47 2019
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sun, 6 Jan 2019 12:58:47 +1100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
 <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
Message-ID: <4AD64D16-B2E8-4452-AA11-B755F207945E@gmail.com>

I doubt any JavaFX application would use ALL the features so couldn?t you make the same argument for ?detachment? about many other parts of JavaFX?

And what are the ?core components?? That is probably a subjective question.

> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
> 
> Yes, I meant removing charts from the core of JavaFX and moving he charts to a separate JPMS  module.
> 
> Why? They are not really core components are they? They are dead weight in applications that never will use them.
> 
>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>> Hi Ramon,
>> 
>> I personally have never seen or heard of any such discussion and I?m not entirely sure in which context you are using the word ?module?.
>> 
>> Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?
>> 
>> Either way, can you tell us why you have thought of this idea?
>> 
>> Graciously,
>> 
>> John-Val
>> 
>> > On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>> > 
>> > -- 
>> > rjs
> 
> 
> -- 
> rjs

From tbee at tbee.org  Sun Jan  6 09:27:00 2019
From: tbee at tbee.org (Tom Eugelink)
Date: Sun, 6 Jan 2019 10:27:00 +0100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <4AD64D16-B2E8-4452-AA11-B755F207945E@gmail.com>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
 <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
 <4AD64D16-B2E8-4452-AA11-B755F207945E@gmail.com>
Message-ID: <85bf1b6a-c686-7e5c-8fc9-3e429ac76c72@tbee.org>

But (I assumed charts was in core as Ramon said) taking a look at the javadoc; charts are in the controls module, not in the core (javafx-base or javafx-graphics). So that seems quite ok.

https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html


On 6-1-2019 02:58, John-Val Rose wrote:
> I doubt any JavaFX application would use ALL the features so couldn?t you make the same argument for ?detachment? about many other parts of JavaFX?
>
> And what are the ?core components?? That is probably a subjective question.
>
>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>
>> Yes, I meant removing charts from the core of JavaFX and moving he charts to a separate JPMS  module.
>>
>> Why? They are not really core components are they? They are dead weight in applications that never will use them.
>>
>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>>> Hi Ramon,
>>>
>>> I personally have never seen or heard of any such discussion and I?m not entirely sure in which context you are using the word ?module?.
>>>
>>> Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?
>>>
>>> Either way, can you tell us why you have thought of this idea?
>>>
>>> Graciously,
>>>
>>> John-Val
>>>
>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>
>>>> -- 
>>>> rjs
>>
>> -- 
>> rjs



From johnvalrose at gmail.com  Sun Jan  6 09:43:58 2019
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sun, 6 Jan 2019 20:43:58 +1100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <85bf1b6a-c686-7e5c-8fc9-3e429ac76c72@tbee.org>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
 <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
 <4AD64D16-B2E8-4452-AA11-B755F207945E@gmail.com>
 <85bf1b6a-c686-7e5c-8fc9-3e429ac76c72@tbee.org>
Message-ID: <12ECF4A3-9FC1-42A9-9017-89EDF2346271@gmail.com>

So Tom are you saying that javafx.base and javafx.graphics are the only ?core? modules in JavaFX?

Has that ever been officially stated or established?

How can javafx.controls or javafx.fxml not be considered core modules?

There?s not much you can do with JavaFX without controls and FXML (albeit optional) is a critical part of most JavaFX apps.

> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
> 
> But (I assumed charts was in core as Ramon said) taking a look at the javadoc; charts are in the controls module, not in the core (javafx-base or javafx-graphics). So that seems quite ok.
> 
> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
> 
> 
>> On 6-1-2019 02:58, John-Val Rose wrote:
>> I doubt any JavaFX application would use ALL the features so couldn?t you make the same argument for ?detachment? about many other parts of JavaFX?
>> 
>> And what are the ?core components?? That is probably a subjective question.
>> 
>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>> 
>>> Yes, I meant removing charts from the core of JavaFX and moving he charts to a separate JPMS  module.
>>> 
>>> Why? They are not really core components are they? They are dead weight in applications that never will use them.
>>> 
>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>>>> Hi Ramon,
>>>> 
>>>> I personally have never seen or heard of any such discussion and I?m not entirely sure in which context you are using the word ?module?.
>>>> 
>>>> Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?
>>>> 
>>>> Either way, can you tell us why you have thought of this idea?
>>>> 
>>>> Graciously,
>>>> 
>>>> John-Val
>>>> 
>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>> 
>>>>> -- 
>>>>> rjs
>>> 
>>> -- 
>>> rjs
> 
> 

From siddheshrane at disroot.org  Sun Jan  6 10:43:44 2019
From: siddheshrane at disroot.org (Siddhesh Rane)
Date: Sun, 06 Jan 2019 16:13:44 +0530
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
Message-ID: <b4711e89-2da8-47ff-b197-038a0cdd9d0a@email.android.com>


From siddheshrane at disroot.org  Sun Jan  6 11:06:59 2019
From: siddheshrane at disroot.org (Siddhesh Rane)
Date: Sun, 06 Jan 2019 11:06:59 +0000
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
Message-ID: <2764fba17ca93d885b90c22d417da4a3@disroot.org>

(An earlier version of this email turned out completely empty when delivered on the mailing list)

I have used JavaFX on Linux since 8.0 and have never faced any serious issues.

January 3, 2019 4:29 AM, "Ty Young" <youngty1997 at gmail.com> wrote:

> In my attempt to write a more proper responsive JavaFX UI, I've created
> a new JavaFX project which extensively uses DoubleBindings to force the
> min/max width/height of various components to their parent containing
> objects(HBox and VBox mainly) so that 1440p and 4k displays could be
> more easily supported. 

This is not how layout is supposed to be done. The parent container calculates its computed size based on its children which takes into account min/pref/max size of children. Min/pref/max are intrinsic properties of the child irrespective of the container it is in.
You are introducing a chicken and egg situation here by having both dimensions depend on each other. You'll get undefined behaviour.

If you want children to occupy full width and height of parent, set VBox to "fill width" with Vgrow ALWAYS on children and Hbox to "fill height" and hgrow always in scene builder.

> While it does allow for easier 1440p and 4k
> scaling, JavaFX itself seems to have /extremely/ horrible content
> rendering & resizing bugs to the point where the application becomes
> usable.

If you are taking about buttons being extremely small on high definition screens on Linux, you can set root font size in your css to >1.0em. Alternatively you can set default font size with - Dcom.sun.javafx.fontSize=18 where default is 12. You can try it for any javafx application by setting _JAVA_OPTIONS=-Dcom.sun.javafx.fontSize=18 on the command line. 
 
> Multiple of the bugs can be observed by simply resizing the JavaFX
> window. When doing so, content will seemingly struggle to keep up with
> resizing events. As a result, white(or sometimes black) glitching can be
> seen wherever the window is being expanded and UI components will "jump"
> around.

White or black bars on window expansion are not specific to javafx. I've seen that on Windows file explorer and Chrome with Gmail tab. It seems to me that the window resizing happens asynchronously so it doesn't wait for the application to have calculated layout and painted the new area. For any complex UI, the layout computation cannot keep up with window resize.

> Thinking that this might be problems caused by extensive use of
> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
> has all of the same UI glitching that I've encountered in my JavaFX
> application at a lesser scale besides TableView since it doesn't use
> TableView.

Scene Builder is a complex application. Above point applies.

> Another problem is a font bug revolving around making text bold. When
> attempting to make a label bold, the boldness is seemingly not being
> applied to some Label text. It might work on a few Labels in a certain
> part of the UI but completely refuse in other parts. Making things
> weirder is the disappearing boldness of Labels after setting a new Pane
> in the ScrollPane and switching back to a that specific pane.

Without relevant code, we cannot comment.

Regards
Siddhesh Rane

From tbee at tbee.org  Sun Jan  6 12:16:35 2019
From: tbee at tbee.org (Tom Eugelink)
Date: Sun, 6 Jan 2019 13:16:35 +0100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <12ECF4A3-9FC1-42A9-9017-89EDF2346271@gmail.com>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
 <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
 <4AD64D16-B2E8-4452-AA11-B755F207945E@gmail.com>
 <85bf1b6a-c686-7e5c-8fc9-3e429ac76c72@tbee.org>
 <12ECF4A3-9FC1-42A9-9017-89EDF2346271@gmail.com>
Message-ID: <965fc039-fba7-f005-08b1-bc2257f41f3a@tbee.org>

I'm responding to your "moving he charts to a separate JPMS? module". It would make sense to have a javafx.charts, but at least charts are not in javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal JPMS module to have them in. But since they are now, it's not really worth a refactor. Given the typical size of a controls application, the charts classes won't make much of a difference.

Whether charts belong in OpenJFX in the first place, and this what I think you mean with "core" (you have not established that concept either), is another topic. I would say no, the chart library of Gerrit illustates that. But someone at some point thought it was a good idea, just like half of Maven is/was in the JRE (a new HTTP client implementation???). So because of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes sense. Call it historical debt or something. We just need a better alternative and then the classes can be removed at some point in the future.


On 6-1-2019 10:43, John-Val Rose wrote:
> So Tom are you saying that javafx.base and javafx.graphics are the only ?core? modules in JavaFX?
>
> Has that ever been officially stated or established?
>
> How can javafx.controls or javafx.fxml not be considered core modules?
>
> There?s not much you can do with JavaFX without controls and FXML (albeit optional) is a critical part of most JavaFX apps.
>
>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
>>
>> But (I assumed charts was in core as Ramon said) taking a look at the javadoc; charts are in the controls module, not in the core (javafx-base or javafx-graphics). So that seems quite ok.
>>
>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
>>
>>
>>> On 6-1-2019 02:58, John-Val Rose wrote:
>>> I doubt any JavaFX application would use ALL the features so couldn?t you make the same argument for ?detachment? about many other parts of JavaFX?
>>>
>>> And what are the ?core components?? That is probably a subjective question.
>>>
>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>
>>>> Yes, I meant removing charts from the core of JavaFX and moving he charts to a separate JPMS  module.
>>>>
>>>> Why? They are not really core components are they? They are dead weight in applications that never will use them.
>>>>
>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>>>>> Hi Ramon,
>>>>>
>>>>> I personally have never seen or heard of any such discussion and I?m not entirely sure in which context you are using the word ?module?.
>>>>>
>>>>> Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?
>>>>>
>>>>> Either way, can you tell us why you have thought of this idea?
>>>>>
>>>>> Graciously,
>>>>>
>>>>> John-Val
>>>>>
>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>>>
>>>>>> -- 
>>>>>> rjs
>>>> -- 
>>>> rjs
>>


From johnvalrose at gmail.com  Sun Jan  6 14:40:09 2019
From: johnvalrose at gmail.com (John-Val Rose)
Date: Mon, 7 Jan 2019 01:40:09 +1100
Subject: Has any consideration been made to move the Charts into s
 separate module?
In-Reply-To: <965fc039-fba7-f005-08b1-bc2257f41f3a@tbee.org>
References: <CAHq8-G_Xrjky1utd_mCt5kfZgC_Er=25VgArt3zrmRuvS4wJDA@mail.gmail.com>
 <4E008BED-960E-41B1-AE09-9E1A3FF7136B@gmail.com>
 <CAHq8-G-93DxnHZJivdQNM129oMogO8N-Zq8JdEMw1W_oPDe6PQ@mail.gmail.com>
 <4AD64D16-B2E8-4452-AA11-B755F207945E@gmail.com>
 <85bf1b6a-c686-7e5c-8fc9-3e429ac76c72@tbee.org>
 <12ECF4A3-9FC1-42A9-9017-89EDF2346271@gmail.com>
 <965fc039-fba7-f005-08b1-bc2257f41f3a@tbee.org>
Message-ID: <1672B6A4-853E-42E1-AF71-16209674CB98@gmail.com>

I think we actually agree Tom.

I have not established what is ?core? JavaFX simply because it has never crossed my mind that some modules are ?core? whereas others must (by inference) be ?peripheral?.

I don?t see any value in refactoring charts into their own module given that, as I said, without controls there?s not much value in using JavaFX.

There are lots of really good 3rd-party controls libraries such as those of Gerrit that you mentioned but there are numerous other 3rd-party JavaFX libraries that do not relate to controls at all.

I guess I just don?t see any reason to strip JavaFX right down to the ?core? (whatever that is) by for example moving charts or any other specific type of control into separate JPMS modules.

And does anyone have some actual real-world stats as to how frequently charts are used? I, for one, certainly do not view them as ?dead weight?.

> On 6 Jan 2019, at 23:16, Tom Eugelink <tbee at tbee.org> wrote:
> 
> I'm responding to your "moving he charts to a separate JPMS  module". It would make sense to have a javafx.charts, but at least charts are not in javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal JPMS module to have them in. But since they are now, it's not really worth a refactor. Given the typical size of a controls application, the charts classes won't make much of a difference.
> 
> Whether charts belong in OpenJFX in the first place, and this what I think you mean with "core" (you have not established that concept either), is another topic. I would say no, the chart library of Gerrit illustates that. But someone at some point thought it was a good idea, just like half of Maven is/was in the JRE (a new HTTP client implementation???). So because of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes sense. Call it historical debt or something. We just need a better alternative and then the classes can be removed at some point in the future.
> 
> 
>> On 6-1-2019 10:43, John-Val Rose wrote:
>> So Tom are you saying that javafx.base and javafx.graphics are the only ?core? modules in JavaFX?
>> 
>> Has that ever been officially stated or established?
>> 
>> How can javafx.controls or javafx.fxml not be considered core modules?
>> 
>> There?s not much you can do with JavaFX without controls and FXML (albeit optional) is a critical part of most JavaFX apps.
>> 
>>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
>>> 
>>> But (I assumed charts was in core as Ramon said) taking a look at the javadoc; charts are in the controls module, not in the core (javafx-base or javafx-graphics). So that seems quite ok.
>>> 
>>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
>>> 
>>> 
>>>> On 6-1-2019 02:58, John-Val Rose wrote:
>>>> I doubt any JavaFX application would use ALL the features so couldn?t you make the same argument for ?detachment? about many other parts of JavaFX?
>>>> 
>>>> And what are the ?core components?? That is probably a subjective question.
>>>> 
>>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>> 
>>>>> Yes, I meant removing charts from the core of JavaFX and moving he charts to a separate JPMS  module.
>>>>> 
>>>>> Why? They are not really core components are they? They are dead weight in applications that never will use them.
>>>>> 
>>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>>>>>> Hi Ramon,
>>>>>> 
>>>>>> I personally have never seen or heard of any such discussion and I?m not entirely sure in which context you are using the word ?module?.
>>>>>> 
>>>>>> Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?
>>>>>> 
>>>>>> Either way, can you tell us why you have thought of this idea?
>>>>>> 
>>>>>> Graciously,
>>>>>> 
>>>>>> John-Val
>>>>>> 
>>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>>>> 
>>>>>>> -- 
>>>>>>> rjs
>>>>> -- 
>>>>> rjs
>>> 
> 

From youngty1997 at gmail.com  Sun Jan  6 19:15:15 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 6 Jan 2019 13:15:15 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <2764fba17ca93d885b90c22d417da4a3@disroot.org>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
Message-ID: <29ef5775-9c0d-f9e5-74ad-4d1b7ccb4a39@gmail.com>


On 1/6/19 5:06 AM, Siddhesh Rane wrote:
> (An earlier version of this email turned out completely empty when delivered on the mailing list)
>
> I have used JavaFX on Linux since 8.0 and have never faced any serious issues.
>
> January 3, 2019 4:29 AM, "Ty Young" <youngty1997 at gmail.com> wrote:
>
>> In my attempt to write a more proper responsive JavaFX UI, I've created
>> a new JavaFX project which extensively uses DoubleBindings to force the
>> min/max width/height of various components to their parent containing
>> objects(HBox and VBox mainly) so that 1440p and 4k displays could be
>> more easily supported.
> This is not how layout is supposed to be done. The parent container calculates its computed size based on its children which takes into account min/pref/max size of children. Min/pref/max are intrinsic properties of the child irrespective of the container it is in.
> You are introducing a chicken and egg situation here by having both dimensions depend on each other. You'll get undefined behaviour.
>
> If you want children to occupy full width and height of parent, set VBox to "fill width" with Vgrow ALWAYS on children and Hbox to "fill height" and hgrow always in scene builder.


I'm well aware of how the parents size is calculated. However, the more 
level top level UI components are percentage based of the entire window 
so that, for example, the left button is 15% of the total window width 
and the ScrollPane is 85% of the total window width. Content within the 
ScrollPane is also reduced to 85% of the ScrollPane's width.


This percentage based UI scaling has been done in website for years. 
There isn't anything particularly different here. Content should 
theoretically be resized in a top down fashion on any resize event after 
first creation. If this causes unnecessary resizing events then why 
exactly does the DoubleBinding API even exist to begin with? This is 
always going to be an issue when you use it.


>
>> While it does allow for easier 1440p and 4k
>> scaling, JavaFX itself seems to have /extremely/ horrible content
>> rendering & resizing bugs to the point where the application becomes
>> usable.
> If you are taking about buttons being extremely small on high definition screens on Linux, you can set root font size in your css to >1.0em. Alternatively you can set default font size with - Dcom.sun.javafx.fontSize=18 where default is 12. You can try it for any javafx application by setting _JAVA_OPTIONS=-Dcom.sun.javafx.fontSize=18 on the command line.


As far as I'm aware JavaFX uses the system default font size unless told 
otherwise. As such, font should scale perfectly on native displays. 
Problem is, this is not true when using xrandr to scale the viewport nor 
does it affect padding or spacing between UI elements so while it'll 
supposedly look fine using a more responsive application design like 
i've been doing it will be less 1:1 scaling. Extra handling is required 
for above 1080p scaling sadly.


Default font size is 13 according to Font.getDefault().getSize(). 
According to Gnome Tweaks it's supposed to be 11. Which one is right? 
Who knows. Maybe using Font.getDefault().getSize() isn't a reliable way 
of getting system font size but I can't immediately think of a better 
way to get the actual system font size.


>   
>> Multiple of the bugs can be observed by simply resizing the JavaFX
>> window. When doing so, content will seemingly struggle to keep up with
>> resizing events. As a result, white(or sometimes black) glitching can be
>> seen wherever the window is being expanded and UI components will "jump"
>> around.
> White or black bars on window expansion are not specific to javafx. I've seen that on Windows file explorer and Chrome with Gmail tab. It seems to me that the window resizing happens asynchronously so it doesn't wait for the application to have calculated layout and painted the new area. For any complex UI, the layout computation cannot keep up with window resize.


In complete honestly I've never really payed much attention to window 
resizing behavior until now as I usually just keep applications 
maximized. Opening various applications and resizing them shows that 
while there are far more applications with glitchy and low FPS resizing, 
there are also examples of applications that have no trouble resizing UI 
components.


Non glitchy:


Gnome Settings(My app design is roughly based on this. It too uses 
percentage based UI sizing without issue.)

Gnome Disks

QT5 Settings

GNU Octage

Only Office

Vid Cutter


Glitchy:


JavaFX apps

Netbeans

WPS Office

Steam(game client)


Given that some applications with fairly complex UI work fine I don't 
really buy the "UI is just too complex!" theory/defense/excuse. Not only 
does the app use bog standard JavaFX UI components but there aren't that 
many on the screen at any given time. Going by behavior of ScrollPane's 
glitchy horizontal bar, JavaFX doesn't even resize UI content that isn't 
in a user's view anyway so the amount of UI components that needs to be 
resized is fairly small(maybe 40 including TableView's subcomponents?).


>
>> Thinking that this might be problems caused by extensive use of
>> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
>> has all of the same UI glitching that I've encountered in my JavaFX
>> application at a lesser scale besides TableView since it doesn't use
>> TableView.
> Scene Builder is a complex application. Above point applies.


SceneBuilder's complexity is always a constant so it would stand to 
reason that the glitchy resizing would also be a constant. It isn't. 
Again, the glitchy behavior is seemingly dependent on the 3 things that 
I mentioned.


>> Another problem is a font bug revolving around making text bold. When
>> attempting to make a label bold, the boldness is seemingly not being
>> applied to some Label text. It might work on a few Labels in a certain
>> part of the UI but completely refuse in other parts. Making things
>> weirder is the disappearing boldness of Labels after setting a new Pane
>> in the ScrollPane and switching back to a that specific pane.
> Without relevant code, we cannot comment.


<Label>.setFont(Font.font(Font.getDefault().getFamily(), 
FontWeight.EXTRA_BOLD, Font.getDefault().getSize());


Just a typical setFont() call.

>
> Regards
> Siddhesh Rane

From johan.vos at gluonhq.com  Mon Jan  7 12:28:12 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 7 Jan 2019 13:28:12 +0100
Subject: RFR backport of 8210411
Message-ID: <CABxFH2EUhYN=GKAM_TyLcSgsy5Ca3g89iN8RuwWNPNOUWNZ1tg@mail.gmail.com>

Hi Kevin, Pankaj,

Please review the 11-backport for 8210411 (JavaFX crash with Wayland):

http://cr.openjdk.java.net/~jvos/8210411/webrev.00/

Thanks,

- Johan

From ramonjsantiago at gmail.com  Mon Jan  7 14:44:23 2019
From: ramonjsantiago at gmail.com (Ramon Santiago)
Date: Mon, 7 Jan 2019 09:44:23 -0500
Subject: openjfx-dev Digest, Vol 86, Issue 7
In-Reply-To: <mailman.33.1546862421.24981.openjfx-dev@openjdk.java.net>
References: <mailman.33.1546862421.24981.openjfx-dev@openjdk.java.net>
Message-ID: <CAHq8-G82f-ey8K+9YEs53SVCZ+CA08fVim8AomJ-F-ggoPVYdA@mail.gmail.com>

I thank the community for their feedback.

To clarify my original comments, I would consider "core" UI Controls as
those at the
    javafx.scene.control level but;
    not javafx.scene.chart
    nor javafx.scene.web, which is already in a separate module
    etc...

I still believe that the charts should be put in their own module.
I understand that this opinion is not shared by others.



On Mon, Jan 7, 2019 at 7:00 AM <openjfx-dev-request at openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
>         openjfx-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
>         openjfx-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         openjfx-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Has any consideration been made to move the Charts into s
>       separate module? (Tom Eugelink)
>    2. Re: Has any consideration been made to move the Charts into s
>       separate module? (John-Val Rose)
>    3. Re: JavaFX Content Rendering & Resizing and Font Bugs In
>       Linux (Ty Young)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 6 Jan 2019 13:16:35 +0100
> From: Tom Eugelink <tbee at tbee.org>
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: Has any consideration been made to move the Charts into s
>         separate module?
> Message-ID: <965fc039-fba7-f005-08b1-bc2257f41f3a at tbee.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I'm responding to your "moving he charts to a separate JPMS? module". It
> would make sense to have a javafx.charts, but at least charts are not in
> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal
> JPMS module to have them in. But since they are now, it's not really worth
> a refactor. Given the typical size of a controls application, the charts
> classes won't make much of a difference.
>
> Whether charts belong in OpenJFX in the first place, and this what I think
> you mean with "core" (you have not established that concept either), is
> another topic. I would say no, the chart library of Gerrit illustates that.
> But someone at some point thought it was a good idea, just like half of
> Maven is/was in the JRE (a new HTTP client implementation???). So because
> of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes
> sense. Call it historical debt or something. We just need a better
> alternative and then the classes can be removed at some point in the future.
>
>
> On 6-1-2019 10:43, John-Val Rose wrote:
> > So Tom are you saying that javafx.base and javafx.graphics are the only
> ?core? modules in JavaFX?
> >
> > Has that ever been officially stated or established?
> >
> > How can javafx.controls or javafx.fxml not be considered core modules?
> >
> > There?s not much you can do with JavaFX without controls and FXML
> (albeit optional) is a critical part of most JavaFX apps.
> >
> >> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
> >>
> >> But (I assumed charts was in core as Ramon said) taking a look at the
> javadoc; charts are in the controls module, not in the core (javafx-base or
> javafx-graphics). So that seems quite ok.
> >>
> >> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
> >>
> >>
> >>> On 6-1-2019 02:58, John-Val Rose wrote:
> >>> I doubt any JavaFX application would use ALL the features so couldn?t
> you make the same argument for ?detachment? about many other parts of
> JavaFX?
> >>>
> >>> And what are the ?core components?? That is probably a subjective
> question.
> >>>
> >>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>
> >>>> Yes, I meant removing charts from the core of JavaFX and moving he
> charts to a separate JPMS  module.
> >>>>
> >>>> Why? They are not really core components are they? They are dead
> weight in applications that never will use them.
> >>>>
> >>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com>
> wrote:
> >>>>> Hi Ramon,
> >>>>>
> >>>>> I personally have never seen or heard of any such discussion and I?m
> not entirely sure in which context you are using the word ?module?.
> >>>>>
> >>>>> Do you meaning simply removing charts from the core of JavaFX or do
> you mean creating the charts as an actual module within JPMS?
> >>>>>
> >>>>> Either way, can you tell us why you have thought of this idea?
> >>>>>
> >>>>> Graciously,
> >>>>>
> >>>>> John-Val
> >>>>>
> >>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>>>
> >>>>>> --
> >>>>>> rjs
> >>>> --
> >>>> rjs
> >>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Jan 2019 01:40:09 +1100
> From: John-Val Rose <johnvalrose at gmail.com>
> To: Tom Eugelink <tbee at tbee.org>
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: Has any consideration been made to move the Charts into s
>         separate module?
> Message-ID: <1672B6A4-853E-42E1-AF71-16209674CB98 at gmail.com>
> Content-Type: text/plain;       charset=utf-8
>
> I think we actually agree Tom.
>
> I have not established what is ?core? JavaFX simply because it has never
> crossed my mind that some modules are ?core? whereas others must (by
> inference) be ?peripheral?.
>
> I don?t see any value in refactoring charts into their own module given
> that, as I said, without controls there?s not much value in using JavaFX.
>
> There are lots of really good 3rd-party controls libraries such as those
> of Gerrit that you mentioned but there are numerous other 3rd-party JavaFX
> libraries that do not relate to controls at all.
>
> I guess I just don?t see any reason to strip JavaFX right down to the
> ?core? (whatever that is) by for example moving charts or any other
> specific type of control into separate JPMS modules.
>
> And does anyone have some actual real-world stats as to how frequently
> charts are used? I, for one, certainly do not view them as ?dead weight?.
>
> > On 6 Jan 2019, at 23:16, Tom Eugelink <tbee at tbee.org> wrote:
> >
> > I'm responding to your "moving he charts to a separate JPMS  module". It
> would make sense to have a javafx.charts, but at least charts are not in
> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal
> JPMS module to have them in. But since they are now, it's not really worth
> a refactor. Given the typical size of a controls application, the charts
> classes won't make much of a difference.
> >
> > Whether charts belong in OpenJFX in the first place, and this what I
> think you mean with "core" (you have not established that concept either),
> is another topic. I would say no, the chart library of Gerrit illustates
> that. But someone at some point thought it was a good idea, just like half
> of Maven is/was in the JRE (a new HTTP client implementation???). So
> because of backward compatibility keeping in OpenJFX what was in Oracle's
> JRE makes sense. Call it historical debt or something. We just need a
> better alternative and then the classes can be removed at some point in the
> future.
> >
> >
> >> On 6-1-2019 10:43, John-Val Rose wrote:
> >> So Tom are you saying that javafx.base and javafx.graphics are the only
> ?core? modules in JavaFX?
> >>
> >> Has that ever been officially stated or established?
> >>
> >> How can javafx.controls or javafx.fxml not be considered core modules?
> >>
> >> There?s not much you can do with JavaFX without controls and FXML
> (albeit optional) is a critical part of most JavaFX apps.
> >>
> >>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
> >>>
> >>> But (I assumed charts was in core as Ramon said) taking a look at the
> javadoc; charts are in the controls module, not in the core (javafx-base or
> javafx-graphics). So that seems quite ok.
> >>>
> >>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
> >>>
> >>>
> >>>> On 6-1-2019 02:58, John-Val Rose wrote:
> >>>> I doubt any JavaFX application would use ALL the features so couldn?t
> you make the same argument for ?detachment? about many other parts of
> JavaFX?
> >>>>
> >>>> And what are the ?core components?? That is probably a subjective
> question.
> >>>>
> >>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>>
> >>>>> Yes, I meant removing charts from the core of JavaFX and moving he
> charts to a separate JPMS  module.
> >>>>>
> >>>>> Why? They are not really core components are they? They are dead
> weight in applications that never will use them.
> >>>>>
> >>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com>
> wrote:
> >>>>>> Hi Ramon,
> >>>>>>
> >>>>>> I personally have never seen or heard of any such discussion and
> I?m not entirely sure in which context you are using the word ?module?.
> >>>>>>
> >>>>>> Do you meaning simply removing charts from the core of JavaFX or do
> you mean creating the charts as an actual module within JPMS?
> >>>>>>
> >>>>>> Either way, can you tell us why you have thought of this idea?
> >>>>>>
> >>>>>> Graciously,
> >>>>>>
> >>>>>> John-Val
> >>>>>>
> >>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> --
> >>>>>>> rjs
> >>>>> --
> >>>>> rjs
> >>>
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 6 Jan 2019 13:15:15 -0600
> From: Ty Young <youngty1997 at gmail.com>
> To: openjfx-dev at openjdk.java.net
> Subject: Re: JavaFX Content Rendering & Resizing and Font Bugs In
>         Linux
> Message-ID: <29ef5775-9c0d-f9e5-74ad-4d1b7ccb4a39 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> On 1/6/19 5:06 AM, Siddhesh Rane wrote:
> > (An earlier version of this email turned out completely empty when
> delivered on the mailing list)
> >
> > I have used JavaFX on Linux since 8.0 and have never faced any serious
> issues.
> >
> > January 3, 2019 4:29 AM, "Ty Young" <youngty1997 at gmail.com> wrote:
> >
> >> In my attempt to write a more proper responsive JavaFX UI, I've created
> >> a new JavaFX project which extensively uses DoubleBindings to force the
> >> min/max width/height of various components to their parent containing
> >> objects(HBox and VBox mainly) so that 1440p and 4k displays could be
> >> more easily supported.
> > This is not how layout is supposed to be done. The parent container
> calculates its computed size based on its children which takes into account
> min/pref/max size of children. Min/pref/max are intrinsic properties of the
> child irrespective of the container it is in.
> > You are introducing a chicken and egg situation here by having both
> dimensions depend on each other. You'll get undefined behaviour.
> >
> > If you want children to occupy full width and height of parent, set VBox
> to "fill width" with Vgrow ALWAYS on children and Hbox to "fill height" and
> hgrow always in scene builder.
>
>
> I'm well aware of how the parents size is calculated. However, the more
> level top level UI components are percentage based of the entire window
> so that, for example, the left button is 15% of the total window width
> and the ScrollPane is 85% of the total window width. Content within the
> ScrollPane is also reduced to 85% of the ScrollPane's width.
>
>
> This percentage based UI scaling has been done in website for years.
> There isn't anything particularly different here. Content should
> theoretically be resized in a top down fashion on any resize event after
> first creation. If this causes unnecessary resizing events then why
> exactly does the DoubleBinding API even exist to begin with? This is
> always going to be an issue when you use it.
>
>
> >
> >> While it does allow for easier 1440p and 4k
> >> scaling, JavaFX itself seems to have /extremely/ horrible content
> >> rendering & resizing bugs to the point where the application becomes
> >> usable.
> > If you are taking about buttons being extremely small on high definition
> screens on Linux, you can set root font size in your css to >1.0em.
> Alternatively you can set default font size with -
> Dcom.sun.javafx.fontSize=18 where default is 12. You can try it for any
> javafx application by setting _JAVA_OPTIONS=-Dcom.sun.javafx.fontSize=18 on
> the command line.
>
>
> As far as I'm aware JavaFX uses the system default font size unless told
> otherwise. As such, font should scale perfectly on native displays.
> Problem is, this is not true when using xrandr to scale the viewport nor
> does it affect padding or spacing between UI elements so while it'll
> supposedly look fine using a more responsive application design like
> i've been doing it will be less 1:1 scaling. Extra handling is required
> for above 1080p scaling sadly.
>
>
> Default font size is 13 according to Font.getDefault().getSize().
> According to Gnome Tweaks it's supposed to be 11. Which one is right?
> Who knows. Maybe using Font.getDefault().getSize() isn't a reliable way
> of getting system font size but I can't immediately think of a better
> way to get the actual system font size.
>
>
> >
> >> Multiple of the bugs can be observed by simply resizing the JavaFX
> >> window. When doing so, content will seemingly struggle to keep up with
> >> resizing events. As a result, white(or sometimes black) glitching can be
> >> seen wherever the window is being expanded and UI components will "jump"
> >> around.
> > White or black bars on window expansion are not specific to javafx. I've
> seen that on Windows file explorer and Chrome with Gmail tab. It seems to
> me that the window resizing happens asynchronously so it doesn't wait for
> the application to have calculated layout and painted the new area. For any
> complex UI, the layout computation cannot keep up with window resize.
>
>
> In complete honestly I've never really payed much attention to window
> resizing behavior until now as I usually just keep applications
> maximized. Opening various applications and resizing them shows that
> while there are far more applications with glitchy and low FPS resizing,
> there are also examples of applications that have no trouble resizing UI
> components.
>
>
> Non glitchy:
>
>
> Gnome Settings(My app design is roughly based on this. It too uses
> percentage based UI sizing without issue.)
>
> Gnome Disks
>
> QT5 Settings
>
> GNU Octage
>
> Only Office
>
> Vid Cutter
>
>
> Glitchy:
>
>
> JavaFX apps
>
> Netbeans
>
> WPS Office
>
> Steam(game client)
>
>
> Given that some applications with fairly complex UI work fine I don't
> really buy the "UI is just too complex!" theory/defense/excuse. Not only
> does the app use bog standard JavaFX UI components but there aren't that
> many on the screen at any given time. Going by behavior of ScrollPane's
> glitchy horizontal bar, JavaFX doesn't even resize UI content that isn't
> in a user's view anyway so the amount of UI components that needs to be
> resized is fairly small(maybe 40 including TableView's subcomponents?).
>
>
> >
> >> Thinking that this might be problems caused by extensive use of
> >> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
> >> has all of the same UI glitching that I've encountered in my JavaFX
> >> application at a lesser scale besides TableView since it doesn't use
> >> TableView.
> > Scene Builder is a complex application. Above point applies.
>
>
> SceneBuilder's complexity is always a constant so it would stand to
> reason that the glitchy resizing would also be a constant. It isn't.
> Again, the glitchy behavior is seemingly dependent on the 3 things that
> I mentioned.
>
>
> >> Another problem is a font bug revolving around making text bold. When
> >> attempting to make a label bold, the boldness is seemingly not being
> >> applied to some Label text. It might work on a few Labels in a certain
> >> part of the UI but completely refuse in other parts. Making things
> >> weirder is the disappearing boldness of Labels after setting a new Pane
> >> in the ScrollPane and switching back to a that specific pane.
> > Without relevant code, we cannot comment.
>
>
> <Label>.setFont(Font.font(Font.getDefault().getFamily(),
> FontWeight.EXTRA_BOLD, Font.getDefault().getSize());
>
>
> Just a typical setFont() call.
>
> >
> > Regards
> > Siddhesh Rane
>
>
> End of openjfx-dev Digest, Vol 86, Issue 7
> ******************************************
>


-- 
rjs

From kevin.rushforth at oracle.com  Mon Jan  7 17:17:40 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 7 Jan 2019 09:17:40 -0800
Subject: RFR backport of 8210411
In-Reply-To: <CABxFH2EUhYN=GKAM_TyLcSgsy5Ca3g89iN8RuwWNPNOUWNZ1tg@mail.gmail.com>
References: <CABxFH2EUhYN=GKAM_TyLcSgsy5Ca3g89iN8RuwWNPNOUWNZ1tg@mail.gmail.com>
Message-ID: <d565d846-13ec-1843-d5df-313040c861e1@oracle.com>

Approved.

-- Kevin

On 1/7/2019 4:28 AM, Johan Vos wrote:
> Hi Kevin, Pankaj,
>
> Please review the 11-backport for 8210411 (JavaFX crash with Wayland):
>
> http://cr.openjdk.java.net/~jvos/8210411/webrev.00/
>
> Thanks,
>
> - Johan


From pankaj.b.bansal at oracle.com  Mon Jan  7 18:15:40 2019
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 7 Jan 2019 10:15:40 -0800 (PST)
Subject: RFR backport of 8210411
In-Reply-To: <d565d846-13ec-1843-d5df-313040c861e1@oracle.com>
References: <CABxFH2EUhYN=GKAM_TyLcSgsy5Ca3g89iN8RuwWNPNOUWNZ1tg@mail.gmail.com>
 <d565d846-13ec-1843-d5df-313040c861e1@oracle.com>
Message-ID: <796179e2-959f-4a92-a846-f96ff43d3842@default>

Looks good to me.

-- Pankaj

-----Original Message-----
From: Kevin Rushforth 
Sent: Monday, January 7, 2019 10:48 PM
To: Johan Vos; openjfx-dev at openjdk.java.net List
Subject: Re: RFR backport of 8210411

Approved.

-- Kevin

On 1/7/2019 4:28 AM, Johan Vos wrote:
> Hi Kevin, Pankaj,
>
> Please review the 11-backport for 8210411 (JavaFX crash with Wayland):
>
> http://cr.openjdk.java.net/~jvos/8210411/webrev.00/
>
> Thanks,
>
> - Johan


From johan.vos at gluonhq.com  Mon Jan  7 19:48:45 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 7 Jan 2019 20:48:45 +0100
Subject: Request approval to backport 8207159: update ICU to 62.1
Message-ID: <CABxFH2HFnJqx1yafGJ9jF_T2JrfPr4oLN+MpAoWyGR5LQgQeHw@mail.gmail.com>

Hi Kevin,

I request approval to backport JBS-8207159
<https://bugs.openjdk.java.net/browse/JDK-8207159> to 11-dev (targeting
11.0.2):

JBS: https://bugs.openjdk.java.net/browse/JDK-8207159
Changeset:  http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/20a8447c71c6

The changeset patch applies cleanly to 11-dev (tested building with
-PCOMPILE_WEBKIT=true on mac/linux)

- Johan

From john at status6.com  Mon Jan  7 20:10:32 2019
From: john at status6.com (John Neffenger)
Date: Mon, 7 Jan 2019 12:10:32 -0800
Subject: RFE: Add support for e-paper displays
Message-ID: <d1eab322-c972-a65a-4eda-d6d1f64c9fae@status6.com>

I submitted the following GitHub issue requesting an enhancement that I 
would like to see in JavaFX. I used the JDK Enhancement Proposal 
template as a guide in writing the request. I would greatly appreciate 
any comments you can provide. I also have an implementation ready for a 
pull request.

Add support for e-paper displays
https://github.com/javafxports/openjdk-jfx/issues/339

I realize this is probably too late for version 12, and too early for 
version 13, so forgive me for the timing.

Should I duplicate the text in a Request for Enhancement on the Java Bug 
Report page, or may I provide a brief description and just link to the 
issue on GitHub? I don't have direct access to the Java Bug System.

Thank you,
John

From kevin.rushforth at oracle.com  Mon Jan  7 20:27:53 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 7 Jan 2019 12:27:53 -0800
Subject: Request approval to backport 8207159: update ICU to 62.1
In-Reply-To: <CABxFH2HFnJqx1yafGJ9jF_T2JrfPr4oLN+MpAoWyGR5LQgQeHw@mail.gmail.com>
References: <CABxFH2HFnJqx1yafGJ9jF_T2JrfPr4oLN+MpAoWyGR5LQgQeHw@mail.gmail.com>
Message-ID: <dd1f222d-6f65-61ad-166f-0e4b2099078e@oracle.com>

Approved.

-- Kevin

On 1/7/2019 11:48 AM, Johan Vos wrote:
> Hi Kevin,
>
> I request approval to backport JBS-8207159 
> <https://bugs.openjdk.java.net/browse/JDK-8207159>?to 11-dev 
> (targeting 11.0.2):
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8207159
> Changeset: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/20a8447c71c6
>
> The changeset patch applies cleanly to 11-dev (tested building with 
> -PCOMPILE_WEBKIT=true on mac/linux)
>
> - Johan


From kevin.rushforth at oracle.com  Mon Jan  7 23:01:43 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 7 Jan 2019 15:01:43 -0800
Subject: [8u-dev announce] Future contributions to openjfx/8u-dev
In-Reply-To: <6786cef7-31a3-33c8-c4ee-f65e5ded30fc@bestsolution.at>
References: <1b2b1803-5052-979b-f8f9-391661f327eb@oracle.com>
 <6786cef7-31a3-33c8-c4ee-f65e5ded30fc@bestsolution.at>
Message-ID: <7cd363f0-7f2b-4758-796a-84cc1238af2c@oracle.com>

I'm not sure that an 8u-dev mirror would be suitable for the javafxports 
project, but if someone wanted to set up such a mirror elsewhere they 
could do so. It might be best left to the future maintainer (if any 
suitable party steps forward) to determine whether and where to host a 
git mirror.

-- Kevin


On 12/21/2018 1:39 PM, Tom Schindl wrote:
> Hi,
>
> Could we get a mirror of 8u setup for github as well? I wanted to ask
> for that since some time but always forgot to do so.
>
> Tom
>
> On 21.12.18 22:32, Kevin Rushforth wrote:
>> As has been previously announced [1][2], Oracle will no longer
>> contribute to the JDK 8 Updates Project after the January 2019 quarterly
>> CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part
>> of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev
>> code line (8u-dev/rt repo) after JDK 8u202 ships.
>>
>> This means that Oracle will be stepping down as the maintainer of the
>> openjfx/8u-dev code line after January, and will call for a new
>> maintainer. If a suitable party steps forward to maintain the OpenJFX 8
>> Updates code line after the final Oracle-led JDK 8 Update release has
>> been published, we will discuss how to best enable such a transition on
>> this Project's mailing list.
>>
>> I wanted to send this before the holidays, although I realize it might
>> get lost in the shuffle, so I will resend it after the first of the
>> year, along with a formal call for interested parties who wish to put
>> their name forward as a maintainer for the openjfx/8u-dev release.
>>
>> -- Kevin
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html
>>


From kevin.rushforth at oracle.com  Mon Jan  7 23:01:54 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 7 Jan 2019 15:01:54 -0800
Subject: [8u-dev announce] Future contributions to openjfx/8u-dev
Message-ID: <87a3d9da-50e0-e6b5-fb23-5911d28ac42d@oracle.com>

This is a follow-up to the "heads-up" [0] email I sent before the New Year.

As has been previously announced [1][2], Oracle will no longer 
contribute to the JDK 8 Updates Project after the January 2019 quarterly 
CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part 
of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev 
code line (8u-dev/rt repo) after JDK 8u202 ships.

This means that Oracle is stepping down as the maintainer of the 
openjfx/8u-dev code line after January. As with the JDK 8 Updates 
Project, a suitable party might step forward to maintain the 8u-dev code 
line in the OpenJFX Project once the final Oracle-led JDK 8 Update 
release has been published. If such a party is nominated, we will 
discuss how to best enable such a transition on this Project's mailing list.

-- Kevin

[0] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-December/023007.html
[1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html
[2] 
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html


From arunprasad.rajkumar at oracle.com  Tue Jan  8 04:12:06 2019
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Tue, 8 Jan 2019 09:42:06 +0530
Subject: RFR 8214452: Update libxml2 to version 2.9.9
Message-ID: <A5714511-FC17-4104-9711-4F8EA97CBADD@oracle.com>

Hi,

Please review the following PR which upgrades libxml2 to latest stable version 2.9.9.

https://github.com/javafxports/openjdk-jfx/pull/340

https://bugs.openjdk.java.net/browse/JDK-8214452

Thanks,
Arun

From arunprasad.rajkumar at oracle.com  Tue Jan  8 06:41:45 2019
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Tue, 8 Jan 2019 12:11:45 +0530
Subject: RFR 8211454: Update SQLite to version 3.26.0
Message-ID: <6E2FB0A4-E512-44C3-8C1B-A012E3CD1408@oracle.com>

Hi,

Please review the following PR which upgrades sqlite to latest stable version 3.26.0.

https://github.com/javafxports/openjdk-jfx/pull/341

https://bugs.openjdk.java.net/browse/JDK-8211454

Thanks,
Arun

From johnvalrose at gmail.com  Tue Jan  8 07:36:35 2019
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 8 Jan 2019 18:36:35 +1100
Subject: openjfx-dev Digest, Vol 86, Issue 7
In-Reply-To: <CAHq8-G82f-ey8K+9YEs53SVCZ+CA08fVim8AomJ-F-ggoPVYdA@mail.gmail.com>
References: <mailman.33.1546862421.24981.openjfx-dev@openjdk.java.net>
 <CAHq8-G82f-ey8K+9YEs53SVCZ+CA08fVim8AomJ-F-ggoPVYdA@mail.gmail.com>
Message-ID: <74DF2930-085F-45FA-A80A-F3AD1FC833DB@gmail.com>

Upon reflection Ramon, and not being fully aware of the existing modularisation of JavaFX, I now agree with your suggestion.

Graciously,

John-Val

> On 8 Jan 2019, at 01:44, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
> 
> I thank the community for their feedback.
> 
> To clarify my original comments, I would consider "core" UI Controls as
> those at the
>    javafx.scene.control level but;
>    not javafx.scene.chart
>    nor javafx.scene.web, which is already in a separate module
>    etc...
> 
> I still believe that the charts should be put in their own module.
> I understand that this opinion is not shared by others.
> 
> 
> 
>> On Mon, Jan 7, 2019 at 7:00 AM <openjfx-dev-request at openjdk.java.net> wrote:
>> 
>> Send openjfx-dev mailing list submissions to
>>        openjfx-dev at openjdk.java.net
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
>> or, via email, send a message with subject or body 'help' to
>>        openjfx-dev-request at openjdk.java.net
>> 
>> You can reach the person managing the list at
>>        openjfx-dev-owner at openjdk.java.net
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openjfx-dev digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. Re: Has any consideration been made to move the Charts into s
>>      separate module? (Tom Eugelink)
>>   2. Re: Has any consideration been made to move the Charts into s
>>      separate module? (John-Val Rose)
>>   3. Re: JavaFX Content Rendering & Resizing and Font Bugs In
>>      Linux (Ty Young)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Sun, 6 Jan 2019 13:16:35 +0100
>> From: Tom Eugelink <tbee at tbee.org>
>> Cc: openjfx-dev at openjdk.java.net
>> Subject: Re: Has any consideration been made to move the Charts into s
>>        separate module?
>> Message-ID: <965fc039-fba7-f005-08b1-bc2257f41f3a at tbee.org>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> I'm responding to your "moving he charts to a separate JPMS? module". It
>> would make sense to have a javafx.charts, but at least charts are not in
>> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal
>> JPMS module to have them in. But since they are now, it's not really worth
>> a refactor. Given the typical size of a controls application, the charts
>> classes won't make much of a difference.
>> 
>> Whether charts belong in OpenJFX in the first place, and this what I think
>> you mean with "core" (you have not established that concept either), is
>> another topic. I would say no, the chart library of Gerrit illustates that.
>> But someone at some point thought it was a good idea, just like half of
>> Maven is/was in the JRE (a new HTTP client implementation???). So because
>> of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes
>> sense. Call it historical debt or something. We just need a better
>> alternative and then the classes can be removed at some point in the future.
>> 
>> 
>>> On 6-1-2019 10:43, John-Val Rose wrote:
>>> So Tom are you saying that javafx.base and javafx.graphics are the only
>> ?core? modules in JavaFX?
>>> 
>>> Has that ever been officially stated or established?
>>> 
>>> How can javafx.controls or javafx.fxml not be considered core modules?
>>> 
>>> There?s not much you can do with JavaFX without controls and FXML
>> (albeit optional) is a critical part of most JavaFX apps.
>>> 
>>>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
>>>> 
>>>> But (I assumed charts was in core as Ramon said) taking a look at the
>> javadoc; charts are in the controls module, not in the core (javafx-base or
>> javafx-graphics). So that seems quite ok.
>>>> 
>>>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
>>>> 
>>>> 
>>>>> On 6-1-2019 02:58, John-Val Rose wrote:
>>>>> I doubt any JavaFX application would use ALL the features so couldn?t
>> you make the same argument for ?detachment? about many other parts of
>> JavaFX?
>>>>> 
>>>>> And what are the ?core components?? That is probably a subjective
>> question.
>>>>> 
>>>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com>
>> wrote:
>>>>>> 
>>>>>> Yes, I meant removing charts from the core of JavaFX and moving he
>> charts to a separate JPMS  module.
>>>>>> 
>>>>>> Why? They are not really core components are they? They are dead
>> weight in applications that never will use them.
>>>>>> 
>>>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com>
>> wrote:
>>>>>>> Hi Ramon,
>>>>>>> 
>>>>>>> I personally have never seen or heard of any such discussion and I?m
>> not entirely sure in which context you are using the word ?module?.
>>>>>>> 
>>>>>>> Do you meaning simply removing charts from the core of JavaFX or do
>> you mean creating the charts as an actual module within JPMS?
>>>>>>> 
>>>>>>> Either way, can you tell us why you have thought of this idea?
>>>>>>> 
>>>>>>> Graciously,
>>>>>>> 
>>>>>>> John-Val
>>>>>>> 
>>>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
>> wrote:
>>>>>>>> 
>>>>>>>> --
>>>>>>>> rjs
>>>>>> --
>>>>>> rjs
>>>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Mon, 7 Jan 2019 01:40:09 +1100
>> From: John-Val Rose <johnvalrose at gmail.com>
>> To: Tom Eugelink <tbee at tbee.org>
>> Cc: openjfx-dev at openjdk.java.net
>> Subject: Re: Has any consideration been made to move the Charts into s
>>        separate module?
>> Message-ID: <1672B6A4-853E-42E1-AF71-16209674CB98 at gmail.com>
>> Content-Type: text/plain;       charset=utf-8
>> 
>> I think we actually agree Tom.
>> 
>> I have not established what is ?core? JavaFX simply because it has never
>> crossed my mind that some modules are ?core? whereas others must (by
>> inference) be ?peripheral?.
>> 
>> I don?t see any value in refactoring charts into their own module given
>> that, as I said, without controls there?s not much value in using JavaFX.
>> 
>> There are lots of really good 3rd-party controls libraries such as those
>> of Gerrit that you mentioned but there are numerous other 3rd-party JavaFX
>> libraries that do not relate to controls at all.
>> 
>> I guess I just don?t see any reason to strip JavaFX right down to the
>> ?core? (whatever that is) by for example moving charts or any other
>> specific type of control into separate JPMS modules.
>> 
>> And does anyone have some actual real-world stats as to how frequently
>> charts are used? I, for one, certainly do not view them as ?dead weight?.
>> 
>>> On 6 Jan 2019, at 23:16, Tom Eugelink <tbee at tbee.org> wrote:
>>> 
>>> I'm responding to your "moving he charts to a separate JPMS  module". It
>> would make sense to have a javafx.charts, but at least charts are not in
>> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal
>> JPMS module to have them in. But since they are now, it's not really worth
>> a refactor. Given the typical size of a controls application, the charts
>> classes won't make much of a difference.
>>> 
>>> Whether charts belong in OpenJFX in the first place, and this what I
>> think you mean with "core" (you have not established that concept either),
>> is another topic. I would say no, the chart library of Gerrit illustates
>> that. But someone at some point thought it was a good idea, just like half
>> of Maven is/was in the JRE (a new HTTP client implementation???). So
>> because of backward compatibility keeping in OpenJFX what was in Oracle's
>> JRE makes sense. Call it historical debt or something. We just need a
>> better alternative and then the classes can be removed at some point in the
>> future.
>>> 
>>> 
>>>> On 6-1-2019 10:43, John-Val Rose wrote:
>>>> So Tom are you saying that javafx.base and javafx.graphics are the only
>> ?core? modules in JavaFX?
>>>> 
>>>> Has that ever been officially stated or established?
>>>> 
>>>> How can javafx.controls or javafx.fxml not be considered core modules?
>>>> 
>>>> There?s not much you can do with JavaFX without controls and FXML
>> (albeit optional) is a critical part of most JavaFX apps.
>>>> 
>>>>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
>>>>> 
>>>>> But (I assumed charts was in core as Ramon said) taking a look at the
>> javadoc; charts are in the controls module, not in the core (javafx-base or
>> javafx-graphics). So that seems quite ok.
>>>>> 
>>>>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
>>>>> 
>>>>> 
>>>>>> On 6-1-2019 02:58, John-Val Rose wrote:
>>>>>> I doubt any JavaFX application would use ALL the features so couldn?t
>> you make the same argument for ?detachment? about many other parts of
>> JavaFX?
>>>>>> 
>>>>>> And what are the ?core components?? That is probably a subjective
>> question.
>>>>>> 
>>>>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com>
>> wrote:
>>>>>>> 
>>>>>>> Yes, I meant removing charts from the core of JavaFX and moving he
>> charts to a separate JPMS  module.
>>>>>>> 
>>>>>>> Why? They are not really core components are they? They are dead
>> weight in applications that never will use them.
>>>>>>> 
>>>>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com>
>> wrote:
>>>>>>>> Hi Ramon,
>>>>>>>> 
>>>>>>>> I personally have never seen or heard of any such discussion and
>> I?m not entirely sure in which context you are using the word ?module?.
>>>>>>>> 
>>>>>>>> Do you meaning simply removing charts from the core of JavaFX or do
>> you mean creating the charts as an actual module within JPMS?
>>>>>>>> 
>>>>>>>> Either way, can you tell us why you have thought of this idea?
>>>>>>>> 
>>>>>>>> Graciously,
>>>>>>>> 
>>>>>>>> John-Val
>>>>>>>> 
>>>>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
>> wrote:
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> rjs
>>>>>>> --
>>>>>>> rjs
>>>>> 
>>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Sun, 6 Jan 2019 13:15:15 -0600
>> From: Ty Young <youngty1997 at gmail.com>
>> To: openjfx-dev at openjdk.java.net
>> Subject: Re: JavaFX Content Rendering & Resizing and Font Bugs In
>>        Linux
>> Message-ID: <29ef5775-9c0d-f9e5-74ad-4d1b7ccb4a39 at gmail.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> 
>>> On 1/6/19 5:06 AM, Siddhesh Rane wrote:
>>> (An earlier version of this email turned out completely empty when
>> delivered on the mailing list)
>>> 
>>> I have used JavaFX on Linux since 8.0 and have never faced any serious
>> issues.
>>> 
>>> January 3, 2019 4:29 AM, "Ty Young" <youngty1997 at gmail.com> wrote:
>>> 
>>>> In my attempt to write a more proper responsive JavaFX UI, I've created
>>>> a new JavaFX project which extensively uses DoubleBindings to force the
>>>> min/max width/height of various components to their parent containing
>>>> objects(HBox and VBox mainly) so that 1440p and 4k displays could be
>>>> more easily supported.
>>> This is not how layout is supposed to be done. The parent container
>> calculates its computed size based on its children which takes into account
>> min/pref/max size of children. Min/pref/max are intrinsic properties of the
>> child irrespective of the container it is in.
>>> You are introducing a chicken and egg situation here by having both
>> dimensions depend on each other. You'll get undefined behaviour.
>>> 
>>> If you want children to occupy full width and height of parent, set VBox
>> to "fill width" with Vgrow ALWAYS on children and Hbox to "fill height" and
>> hgrow always in scene builder.
>> 
>> 
>> I'm well aware of how the parents size is calculated. However, the more
>> level top level UI components are percentage based of the entire window
>> so that, for example, the left button is 15% of the total window width
>> and the ScrollPane is 85% of the total window width. Content within the
>> ScrollPane is also reduced to 85% of the ScrollPane's width.
>> 
>> 
>> This percentage based UI scaling has been done in website for years.
>> There isn't anything particularly different here. Content should
>> theoretically be resized in a top down fashion on any resize event after
>> first creation. If this causes unnecessary resizing events then why
>> exactly does the DoubleBinding API even exist to begin with? This is
>> always going to be an issue when you use it.
>> 
>> 
>>> 
>>>> While it does allow for easier 1440p and 4k
>>>> scaling, JavaFX itself seems to have /extremely/ horrible content
>>>> rendering & resizing bugs to the point where the application becomes
>>>> usable.
>>> If you are taking about buttons being extremely small on high definition
>> screens on Linux, you can set root font size in your css to >1.0em.
>> Alternatively you can set default font size with -
>> Dcom.sun.javafx.fontSize=18 where default is 12. You can try it for any
>> javafx application by setting _JAVA_OPTIONS=-Dcom.sun.javafx.fontSize=18 on
>> the command line.
>> 
>> 
>> As far as I'm aware JavaFX uses the system default font size unless told
>> otherwise. As such, font should scale perfectly on native displays.
>> Problem is, this is not true when using xrandr to scale the viewport nor
>> does it affect padding or spacing between UI elements so while it'll
>> supposedly look fine using a more responsive application design like
>> i've been doing it will be less 1:1 scaling. Extra handling is required
>> for above 1080p scaling sadly.
>> 
>> 
>> Default font size is 13 according to Font.getDefault().getSize().
>> According to Gnome Tweaks it's supposed to be 11. Which one is right?
>> Who knows. Maybe using Font.getDefault().getSize() isn't a reliable way
>> of getting system font size but I can't immediately think of a better
>> way to get the actual system font size.
>> 
>> 
>>> 
>>>> Multiple of the bugs can be observed by simply resizing the JavaFX
>>>> window. When doing so, content will seemingly struggle to keep up with
>>>> resizing events. As a result, white(or sometimes black) glitching can be
>>>> seen wherever the window is being expanded and UI components will "jump"
>>>> around.
>>> White or black bars on window expansion are not specific to javafx. I've
>> seen that on Windows file explorer and Chrome with Gmail tab. It seems to
>> me that the window resizing happens asynchronously so it doesn't wait for
>> the application to have calculated layout and painted the new area. For any
>> complex UI, the layout computation cannot keep up with window resize.
>> 
>> 
>> In complete honestly I've never really payed much attention to window
>> resizing behavior until now as I usually just keep applications
>> maximized. Opening various applications and resizing them shows that
>> while there are far more applications with glitchy and low FPS resizing,
>> there are also examples of applications that have no trouble resizing UI
>> components.
>> 
>> 
>> Non glitchy:
>> 
>> 
>> Gnome Settings(My app design is roughly based on this. It too uses
>> percentage based UI sizing without issue.)
>> 
>> Gnome Disks
>> 
>> QT5 Settings
>> 
>> GNU Octage
>> 
>> Only Office
>> 
>> Vid Cutter
>> 
>> 
>> Glitchy:
>> 
>> 
>> JavaFX apps
>> 
>> Netbeans
>> 
>> WPS Office
>> 
>> Steam(game client)
>> 
>> 
>> Given that some applications with fairly complex UI work fine I don't
>> really buy the "UI is just too complex!" theory/defense/excuse. Not only
>> does the app use bog standard JavaFX UI components but there aren't that
>> many on the screen at any given time. Going by behavior of ScrollPane's
>> glitchy horizontal bar, JavaFX doesn't even resize UI content that isn't
>> in a user's view anyway so the amount of UI components that needs to be
>> resized is fairly small(maybe 40 including TableView's subcomponents?).
>> 
>> 
>>> 
>>>> Thinking that this might be problems caused by extensive use of
>>>> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
>>>> has all of the same UI glitching that I've encountered in my JavaFX
>>>> application at a lesser scale besides TableView since it doesn't use
>>>> TableView.
>>> Scene Builder is a complex application. Above point applies.
>> 
>> 
>> SceneBuilder's complexity is always a constant so it would stand to
>> reason that the glitchy resizing would also be a constant. It isn't.
>> Again, the glitchy behavior is seemingly dependent on the 3 things that
>> I mentioned.
>> 
>> 
>>>> Another problem is a font bug revolving around making text bold. When
>>>> attempting to make a label bold, the boldness is seemingly not being
>>>> applied to some Label text. It might work on a few Labels in a certain
>>>> part of the UI but completely refuse in other parts. Making things
>>>> weirder is the disappearing boldness of Labels after setting a new Pane
>>>> in the ScrollPane and switching back to a that specific pane.
>>> Without relevant code, we cannot comment.
>> 
>> 
>> <Label>.setFont(Font.font(Font.getDefault().getFamily(),
>> FontWeight.EXTRA_BOLD, Font.getDefault().getSize());
>> 
>> 
>> Just a typical setFont() call.
>> 
>>> 
>>> Regards
>>> Siddhesh Rane
>> 
>> 
>> End of openjfx-dev Digest, Vol 86, Issue 7
>> ******************************************
>> 
> 
> 
> -- 
> rjs

From kevin.rushforth at oracle.com  Tue Jan  8 16:10:24 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 8 Jan 2019 08:10:24 -0800
Subject: OpenJFX 12 is in Rampdown Phase One (RDP1)
Message-ID: <56d0c4eb-ba3a-3773-9f30-9bf2308b6f12@oracle.com>

As a reminder, OpenJFX 12 is now in Rampdown Phase One RDP1. [1]

During RDP1, the only restriction is that any enhancements will need 
explicit approval to go in, although most enhancements should be 
retargeted to openjfx13 now. Note that these restrictions apply to the 
jfx-dev/rt mainline (and by extension, the develop branch of the GitHub 
sandbox), since we have not yet forked a stabilization branch -- for 
this release that will happen closer to RDP2.

We will use the same rules for RDP1 that the JDK uses [2], with the same 
three modifications we did for the previous release:

1. Approval is needed from one of the OpenJFX project leads (not the 
OpenJDK project lead)

2. Since we are not part of the JDK, we need to use labels that do not 
collide with the JDK 12 release. As an obvious choice, derived from the 
JBS fix version, we will use "openjfx12-enhancement-request", 
"openjfx12-enhancement-yes", "openjfx12-enhancement-no" and 
"openjfx12-enhancement-nmi" as corresponding labels.

3. No explicit approval is needed to push P4 bugs during RDP1, as long 
as those bugs have otherwise met the usual code review criteria. Having 
said that, I do not expect reviewers or developers to spend much time on 
P4 bugs. We have less than 4 weeks until RDP2 and we would be better 
served fixing higher priority bugs (doc bugs and test bugs of any 
priority are fine to fix during this time).


Let me know if there are any questions.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022761.html

[2] http://openjdk.java.net/jeps/3


From sdesofi at icloud.com  Tue Jan  8 16:37:27 2019
From: sdesofi at icloud.com (Stephen Desofi)
Date: Tue, 8 Jan 2019 11:37:27 -0500
Subject: Feasibility Question
Message-ID: <B079BA76-6489-44FB-B96F-6C9C34867B64@icloud.com>

I?ve been using FX with Kotlin.   I do a lot with FX Canvas, and Kotlin compiles to JavaScript as well.     Without too much craziness I can get my FX canvas app  to work as a JS Canvas app.


 Unfortunately I can ONLY use FX Canvas and I have to leave behind all my Widgets and controls and rewrite them with DOM equivalents (Button, Label, Checkbox, etc)

Now if only I could have all those components made available as FX Canvas components.    ....then I?d be able to code in FX and run it on the web.   Hmmm.

Too much work?   What about changing the low level renderer of the existing components to render on an abstract canvas using canvas API.  Would that work?

I know this would be a big project but making FX available on the web would be a killer app and I actually think this would be the best way to do it compared to all the other solutions I?ve seen.

Any thoughts?

Sent from my iPhone

From fk at sandec.de  Tue Jan  8 18:19:16 2019
From: fk at sandec.de (Florian Kirmaier)
Date: Tue, 8 Jan 2019 19:19:16 +0100
Subject: RFR: 8216377: memory leak for initial nodes of Window
Message-ID: <CAPdGxv7_8bpugbD0RsX_Mmm6g_LZn_h1AfZFBM_Kw-X0pJWc=g@mail.gmail.com>

Hi everyone,

While working on an update for JPro <https://www.jpro.one/>, I've found
out, that a unit test for a memory leak doesn't work on JavaFX11.
It's a regression and doesn't happen on JavaFX8. There are more details in
the pull request.

Please review the fix for The Bug:
https://bugs.openjdk.java.net/browse/JDK-8216377
https://github.com/javafxports/openjdk-jfx/pull/342

Florian Kirmaier

From youngty1997 at gmail.com  Wed Jan  9 05:13:53 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Tue, 8 Jan 2019 23:13:53 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
Message-ID: <b7a5fd17-36ed-853a-d96a-2faf7adeebe4@gmail.com>

I've done a fresh build of JavaFX 12 and JDK 13(12 hasn't been released 
yet but apparently 13 is a thing). These issues still exist.


Unrelated to JavaFX but client builds of the JDK fail with config 
--disable-warnings-as-errors --with-jvm-variants=client 
--with-import-modules=../rt/build/modular-sdk. What list should this be 
reported to?


On 1/2/19 6:27 PM, Ty Young wrote:
>
> (I'm too lazy to make different emails for every bug so I've just 
> thrown them in a single email. Hopefully that isn't a big deal.)
>
>
> In my attempt to write a more proper responsive JavaFX UI, I've 
> created a new JavaFX project which extensively uses DoubleBindings to 
> force the min/max width/height of various components to their parent 
> containing objects(HBox and VBox mainly) so that 1440p and 4k displays 
> could be more easily supported. While it does allow for easier 1440p 
> and 4k scaling, JavaFX itself seems to have /extremely/ horrible 
> content rendering & resizing bugs to the point where the application 
> becomes usable.
>
>
> For clarity, the applications uses buttons in a VBox which when 
> clicked set a ScrollPane on the right side to whatever pane the button 
> represents("About" for example) like a TabPane. This is so it can be 
> scaled more easily to different resolutions.
>
>
> Multiple of the bugs can be observed by simply resizing the JavaFX 
> window. When doing so, content will seemingly struggle to keep up with 
> resizing events. As a result, white(or sometimes black) glitching can 
> be seen wherever the window is being expanded and UI components will 
> "jump" around. TableView's horizontal and vertical scrollbars will 
> glitch out and show while the window is being resized even though it 
> has plenty of room to display the contents. They sometimes even get 
> stuck, requiring the user to resize the window for them to go away.
>
>
> If the window is resized or if the window is maximized and later 
> unmaximized , any non visible content will not be resized and will 
> require that the window be resized by the user. A horizontal scroll 
> bar will be displayed and usable to scroll to the content that hasn't 
> been adjusted to the new window size. Sometimes JavaFX will slowly 
> resize the content in seemingly steps however it doesn't always do this.
>
>
> Thinking that this might be problems caused by extensive use of 
> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It 
> has all of the same UI glitching that I've encountered in my JavaFX 
> application at a lesser scale besides TableView since it doesn't use 
> TableView.
>
>
> The degree of how badly the bugs happen seemingly depend on:
>
> ??? A. The app launch
>
> ??? B. The time the application is open
>
> ??? C. The max stretched width/height of the window
>
>
> In other words, it's possible to experience little UI glitching one 
> app launch while using it after awhile but then relaunch it later with 
> no code changed and get far more glitching.
>
>
> Another problem is a font bug revolving around making text bold. When 
> attempting to make a label bold, the boldness is seemingly not being 
> applied to some Label text. It might work on a few Labels in a certain 
> part of the UI but completely refuse in other parts. Making things 
> weirder is the disappearing boldness of Labels after setting a new 
> Pane in the ScrollPane and switching back to a that specific pane.
>
>
> For example: on first click to the pane two labels will be bold as set 
> in code. Switching to another pane and back results in the last bold 
> label not being bold anymore. Switching to another pane again results 
> in the first Label no longer being bold.
>
>
> All of these bugs make the application unusable(except the boldness 
> bug). Is this all known? Are there any workarounds?
>
>
> P.S. To whoever is developing SceneBuilder, please add a minimum 
> width/height to the stage. A user shouldn't be able to make resize the 
> window to 1x5 or whatever the smallest window size is allowed by the OS.
>

From tom.schindl at bestsolution.at  Wed Jan  9 07:59:55 2019
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 9 Jan 2019 08:59:55 +0100
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <b7a5fd17-36ed-853a-d96a-2faf7adeebe4@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <b7a5fd17-36ed-853a-d96a-2faf7adeebe4@gmail.com>
Message-ID: <44e59f1c-5fd5-fca1-bc12-048966d9b0e5@bestsolution.at>

On 09.01.19 06:13, Ty Young wrote:
> I've done a fresh build of JavaFX 12 and JDK 13(12 hasn't been released
> yet but apparently 13 is a thing). These issues still exist.
> 

To really help finding and solving the problem you need to provide
source code for us to reproduce the problem.

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From youngty1997 at gmail.com  Wed Jan  9 17:47:44 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Wed, 9 Jan 2019 11:47:44 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <05b398ca-c7e5-4746-2bf0-d4eee4661f97@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <b7a5fd17-36ed-853a-d96a-2faf7adeebe4@gmail.com>
 <44e59f1c-5fd5-fca1-bc12-048966d9b0e5@bestsolution.at>
 <05b398ca-c7e5-4746-2bf0-d4eee4661f97@gmail.com>
Message-ID: <a9a0ea3c-72f0-0593-4de7-cecf674c6182@gmail.com>

On 1/9/19 2:38 AM, Ty Young wrote:
>
> On 1/9/19 1:59 AM, Tom Schindl wrote:
>> On 09.01.19 06:13, Ty Young wrote:
>>> I've done a fresh build of JavaFX 12 and JDK 13(12 hasn't been released
>>> yet but apparently 13 is a thing). These issues still exist.
>>>
>> To really help finding and solving the problem you need to provide
>> source code for us to reproduce the problem.
>>
>> Tom
>>
>
> For the actual application see the repo[1]. I've uploaded a new 
> release(see releases page) which can be used to actually run without 
> compiling.
>
>
> Requirements to run are of course Linux but also:
>
>
> 1. A modern Nvidia GPU
>
> 2. Nvidia GPU driver(newer is better)
>
> 3. Nvidia-smi(should come with driver)
>
> 4. Nvidia-settings(may ship with binary driver depending on distro).
>
>
> If a dummy GUI is necessary I can strip anything that isn't JavaFX.
>
>
> MainAppContentBox.java and the content of the various "NavButton"(s) 
> is the most relevant bits.
>
> [1] https://github.com/BlueGoliath/GoliathEnviousFX
>
>
>

From jose at heitorprojects.com  Thu Jan 10 06:01:26 2019
From: jose at heitorprojects.com (Heitor Projects - Jose)
Date: Thu, 10 Jan 2019 08:01:26 +0200
Subject: JavaFX 11 - Where is ButtonBuilder, HBoxBuilder, etc...?
Message-ID: <1683659e180.f0687fb8203373.5340243029954817485@heitorprojects.com>

Hi,



I am migrating a swing interop application from JavaFX-8? to JavaFX-11...



Have the ButtonBuilder, HBoxBuilder, etc. been removed? And if so, can anyone point me to an example alternative?



Jose Heitor

From ajit.ghaisas at oracle.com  Thu Jan 10 07:13:54 2019
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 10 Jan 2019 12:43:54 +0530
Subject: JavaFX 11 - Where is ButtonBuilder, HBoxBuilder, etc...?
In-Reply-To: <1683659e180.f0687fb8203373.5340243029954817485@heitorprojects.com>
References: <1683659e180.f0687fb8203373.5340243029954817485@heitorprojects.com>
Message-ID: <F2F3808E-E278-413A-ACD2-5C0260644A1C@oracle.com>

Hi,

Builders were removed from JavaFX since jdk9.
https://bugs.openjdk.java.net/browse/JDK-8092861 <https://bugs.openjdk.java.net/browse/JDK-8092861>

There is no alternative as such but to construct the needed scene graph objects directly.
Please see description of https://bugs.openjdk.java.net/browse/JDK-8175964 <https://bugs.openjdk.java.net/browse/JDK-8175964>.

Regards,
Ajit


> On 10-Jan-2019, at 11:31 AM, Heitor Projects - Jose <jose at heitorprojects.com> wrote:
> 
> Hi,
> 
> 
> 
> I am migrating a swing interop application from JavaFX-8  to JavaFX-11...
> 
> 
> 
> Have the ButtonBuilder, HBoxBuilder, etc. been removed? And if so, can anyone point me to an example alternative?
> 
> 
> 
> Jose Heitor


From arunprasad.rajkumar at oracle.com  Thu Jan 10 11:42:47 2019
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Thu, 10 Jan 2019 17:12:47 +0530
Subject: RFR 8216470: Some methods of System.Logger are unimplemented in
 PlatformLogger
Message-ID: <FE3D2036-11A5-4320-B118-A7A56B4526DE@oracle.com>

Hi Kevin, Ajit,

Please review the following PR which fixes JDK-8216470.

https://github.com/javafxports/openjdk-jfx/pull/343/

https://bugs.openjdk.java.net/browse/JDK-8216470

Thanks,
Arun

From youngty1997 at gmail.com  Sun Jan 13 06:20:31 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 13 Jan 2019 00:20:31 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <2764fba17ca93d885b90c22d417da4a3@disroot.org>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
Message-ID: <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>

Seeing as how this important issue is seemingly being ignored, I've 
decided to upload a video showcases the bugs[1]. If this isn't evidence 
that there is a problem with JavaFX's content rendering, resizing, and 
fonts I don't know what is.


The issues I'm experiencing affect every single JavaFX application that 
I've tested, which is:


Goliath Envious FX(mine, repo linked earlier)

Scenic View

Scene Builder

PlayOnLinux 5


Of special note is Scenic View. For reasons I don't understand, Scenic 
View does not always show the glitching. It, however, has extremely 
laggy resizing. Even when it isn't glitching however, it is always 
possible to make it happen by going to Help > About and closing the 
About window that pops up.


Node count for my app is 422 at most and about 150 at its lowest. This 
number will increase/decrease with the amount of Nvidia GPUs connected 
to the system. That decreases or increases depending on the content 
being shown. I have no idea where or how it is even that high seeing as 
how hardly anything is even on the screen to begin with.


Font boldness bug can be found at 6-8 second range in the video. It used 
to happen in a different part of the GUI...


Can we please actually talk about what the actual issues are instead of 
blaming the end programmers and/or excuses like "it's just too complex"? 
Please?


Side note 1: to whoever is developing Scenic View(assuming they are 
subscribed to this list), your application spits out errors like 
crazy(see the video). java.instrument was exported in module-info yet it 
threw errors saying otherwise. Application output was throwing 
connection refused exceptions left and right. Some X related code was 
spitting out a colored error message saying java was doing something 
networking(?) related that it shouldn't and "please stop that" or other. 
I didn't copy the exact text sadly.


Also, specify a min width/height.


Side note 2: I was wrong about JavaFX not supporting 1440p and 4k. It 
uses GDK_SCALE to scale the UI. Problem is, GDK_SCALE isn't a reliable 
way of getting the actual UI scale and will only work for native 
displays at native resolutions. Using xrandr to scale the output display 
results in 1x scaling even though the DE is being rendered in 4k. I'm 
guessing this is related to having to log back out and log back in in 
Windows. It would be nice if JavaFX had failsafe code to dynamically 
handle this.


[1] https://youtu.be/Jin9pQBhDnQ





From kustaa.nyholm at sparetimelabs.com  Sun Jan 13 12:44:49 2019
From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm)
Date: Sun, 13 Jan 2019 14:44:49 +0200
Subject: Filling the Packager gap - again
Message-ID: <93DB854D-D530-41ED-BF79-3026C6F4A9AB@sparetimelabs.com>

Hi,

I've been struggling with packaging my app on MacOs High Sierra (10.13.6) with OpenJDK 11.0.1


Literally I've put days into this.

Won't bore you will all the details (unless you want) but my latest attempt is based on this 
and hence I'm addressing this list:

https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html

Specifically I downloaded 

http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip

and copied:

jpackager -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
jdk.packager.jar -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin


I also have (copied from jdk1.8.0_102):

/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/ant-javafx.jar

The build works in that it produces a working .dmg and .app with correct icons and all '
(in /private/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler7020007958604602553/images/EazyCNC-tmp.dmg etc) 
but the build ends with an unspecified failure (unless it is related to the 'already an item with that name.'):

Building DMG package for EazyCNC
  Using custom package resource [Bundle config file]  (loaded from package/macosx/Info.plist)
  Using custom package resource [icon]  (loaded from package/macosx/EazyCNC.icns)
Did not find a key matching 'Developer ID Application: '
  Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package.
  Using custom package resource [dmg background]  (loaded from package/macosx/EazyCNC-background.png)
  Using custom package resource [volume icon]  (loaded from package/macosx/EazyCNC-volume.icns)
Using default package resource [script to run after application image is populated]  (add package/macosx/EazyCNC-post-image.sh to the class path to customize)
  Using custom package resource [DMG setup script]  (loaded from package/macosx/EazyCNC-dmg-setup.scpt)
/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx/EazyCNC-dmg-setup.scpt:631:738: execution error: Finder got an error: The operation can?t be completed because there is already an item with that name. (-48)
  Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package.

BUILD FAILED
/Users/nyholku/EazyCNC-Project/build.xml:305: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle.

Total time: 6 seconds

Any suggestions to how to dig this further or anything would be highly appreciated.

I'm pretty sure I've tried all the workarounds and suggestions that google can find.


wbr Kusti








From john at status6.com  Sun Jan 13 23:33:31 2019
From: john at status6.com (John Neffenger)
Date: Sun, 13 Jan 2019 15:33:31 -0800
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
Message-ID: <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>

On 1/12/19 10:20 PM, Ty Young wrote:
> Seeing as how this important issue is seemingly being ignored, I've 
> decided to upload a video showcases the bugs[1]. If this isn't evidence 
> that there is a problem with JavaFX's content rendering, resizing, and 
> fonts I don't know what is.

Your video looks similar to a bug I first encountered two years ago [1]. 
I was reluctant to reply earlier because I can't reproduce the bug in a 
windowed environment. So far I have seen the problem in the two cases 
listed below (the bug report lists only the first case):

(a) on a Monocle platform using an off-screen composition buffer that is 
allocated as a non-direct byte buffer, and

(b) on a Monocle platform using the frame buffer directly as the 
composition buffer, and its horizontal visible resolution differs from 
its virtual resolution.

If I play your videos at the slowest speed, I see the entire frame jump 
up when you resize its window. That is just what you would expect if the 
position of the buffer was reset to zero while the buffer was being used 
to draw the frame.

Our environments are very different, and your problem may have origins 
outside of JavaFX entirely, but it may still be worth trying the same 
debugging technique described in the bug report.

John

[1] See: https://bugs.openjdk.java.net/browse/JDK-8201567
or: https://gitlab.com/openjfxepd/jfxpatch/issues/1

From rachel at merus.eu  Mon Jan 14 10:27:35 2019
From: rachel at merus.eu (Rachel Greenham)
Date: Mon, 14 Jan 2019 10:27:35 +0000
Subject: Filling the Packager gap - again
In-Reply-To: <93DB854D-D530-41ED-BF79-3026C6F4A9AB@sparetimelabs.com>
References: <93DB854D-D530-41ED-BF79-3026C6F4A9AB@sparetimelabs.com>
Message-ID: <26a3f661-d8e5-838c-4a4e-653c841f950b@merus.eu>

There have been updates since then. In particular, you can now find it 
hosted here: https://jdk.java.net/jpackage/

What you download is an EA build of jdk-13 which includes jpackage. You 
just use the jpackage that's in that. (You don't have to use that JDK 
for anything else, just literally set a path to that jpackage binary and 
run it.) Up to date options in the JEP: 
https://bugs.openjdk.java.net/browse/JDK-8200758

No idea if the latest fixes your issues. I'm currently only using it on 
Windows where (with a bit of fighting) it's working "good enough for 
now", although updates don't remove the previously installed version of 
your app from the registry like they should yet.

-- 
Rachel

On 13/01/2019 12:44, Kustaa Nyholm wrote:
> Hi,
>
> I've been struggling with packaging my app on MacOs High Sierra (10.13.6) with OpenJDK 11.0.1
>
>
> Literally I've put days into this.
>
> Won't bore you will all the details (unless you want) but my latest attempt is based on this
> and hence I'm addressing this list:
>
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html
>
> Specifically I downloaded
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
>
> and copied:
>
> jpackager -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
> jdk.packager.jar -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
>
>
> I also have (copied from jdk1.8.0_102):
>
> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/ant-javafx.jar
>
> The build works in that it produces a working .dmg and .app with correct icons and all '
> (in /private/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler7020007958604602553/images/EazyCNC-tmp.dmg etc)
> but the build ends with an unspecified failure (unless it is related to the 'already an item with that name.'):
>
> Building DMG package for EazyCNC
>    Using custom package resource [Bundle config file]  (loaded from package/macosx/Info.plist)
>    Using custom package resource [icon]  (loaded from package/macosx/EazyCNC.icns)
> Did not find a key matching 'Developer ID Application: '
>    Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package.
>    Using custom package resource [dmg background]  (loaded from package/macosx/EazyCNC-background.png)
>    Using custom package resource [volume icon]  (loaded from package/macosx/EazyCNC-volume.icns)
> Using default package resource [script to run after application image is populated]  (add package/macosx/EazyCNC-post-image.sh to the class path to customize)
>    Using custom package resource [DMG setup script]  (loaded from package/macosx/EazyCNC-dmg-setup.scpt)
> /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx/EazyCNC-dmg-setup.scpt:631:738: execution error: Finder got an error: The operation can?t be completed because there is already an item with that name. (-48)
>    Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package.
>
> BUILD FAILED
> /Users/nyholku/EazyCNC-Project/build.xml:305: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle.
>
> Total time: 6 seconds
>
> Any suggestions to how to dig this further or anything would be highly appreciated.
>
> I'm pretty sure I've tried all the workarounds and suggestions that google can find.
>
>
> wbr Kusti
>
>
>
>
>
>
>


From kustaa.nyholm at sparetimelabs.com  Mon Jan 14 10:35:57 2019
From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm)
Date: Mon, 14 Jan 2019 12:35:57 +0200
Subject: Filling the Packager gap - again
In-Reply-To: <26a3f661-d8e5-838c-4a4e-653c841f950b@merus.eu>
References: <93DB854D-D530-41ED-BF79-3026C6F4A9AB@sparetimelabs.com>
 <26a3f661-d8e5-838c-4a4e-653c841f950b@merus.eu>
Message-ID: <E68AC5A1-8300-4A44-BC84-5572C06C78D5@sparetimelabs.com>

Thanks!

Yes, I've since downloaded the jdk-13 version and moved to experimenting directly with jpackage 
without the ant component to reduce the number of variables.

Now the .app seems to be produced without errors (does not yet run though, need to get my ducks in a row first).

But the custom icons and other resources are not picked up.

I posted a question on the core-libs-dev list as this is what the https://jdk.java.net/jpackage/ page specified.

wbr Kusti



> On 14 Jan 2019, at 12.27, Rachel Greenham <rachel at merus.eu> wrote:
> 
> There have been updates since then. In particular, you can now find it hosted here: https://jdk.java.net/jpackage/
> 
> What you download is an EA build of jdk-13 which includes jpackage. You just use the jpackage that's in that. (You don't have to use that JDK for anything else, just literally set a path to that jpackage binary and run it.) Up to date options in the JEP: https://bugs.openjdk.java.net/browse/JDK-8200758
> 
> No idea if the latest fixes your issues. I'm currently only using it on Windows where (with a bit of fighting) it's working "good enough for now", although updates don't remove the previously installed version of your app from the registry like they should yet.
> 
> -- 
> Rachel
> 
> On 13/01/2019 12:44, Kustaa Nyholm wrote:
>> Hi,
>> 
>> I've been struggling with packaging my app on MacOs High Sierra (10.13.6) with OpenJDK 11.0.1
>> 
>> 
>> Literally I've put days into this.
>> 
>> Won't bore you will all the details (unless you want) but my latest attempt is based on this
>> and hence I'm addressing this list:
>> 
>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html
>> 
>> Specifically I downloaded
>> 
>> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
>> 
>> and copied:
>> 
>> jpackager -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
>> jdk.packager.jar -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
>> 
>> 
>> I also have (copied from jdk1.8.0_102):
>> 
>> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/ant-javafx.jar
>> 
>> The build works in that it produces a working .dmg and .app with correct icons and all '
>> (in /private/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler7020007958604602553/images/EazyCNC-tmp.dmg etc)
>> but the build ends with an unspecified failure (unless it is related to the 'already an item with that name.'):
>> 
>> Building DMG package for EazyCNC
>>   Using custom package resource [Bundle config file]  (loaded from package/macosx/Info.plist)
>>   Using custom package resource [icon]  (loaded from package/macosx/EazyCNC.icns)
>> Did not find a key matching 'Developer ID Application: '
>>   Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package.
>>   Using custom package resource [dmg background]  (loaded from package/macosx/EazyCNC-background.png)
>>   Using custom package resource [volume icon]  (loaded from package/macosx/EazyCNC-volume.icns)
>> Using default package resource [script to run after application image is populated]  (add package/macosx/EazyCNC-post-image.sh to the class path to customize)
>>   Using custom package resource [DMG setup script]  (loaded from package/macosx/EazyCNC-dmg-setup.scpt)
>> /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx/EazyCNC-dmg-setup.scpt:631:738: execution error: Finder got an error: The operation can?t be completed because there is already an item with that name. (-48)
>>   Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package.
>> 
>> BUILD FAILED
>> /Users/nyholku/EazyCNC-Project/build.xml:305: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle.
>> 
>> Total time: 6 seconds
>> 
>> Any suggestions to how to dig this further or anything would be highly appreciated.
>> 
>> I'm pretty sure I've tried all the workarounds and suggestions that google can find.
>> 
>> 
>> wbr Kusti
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 


From kevin.rushforth at oracle.com  Tue Jan 15 18:05:24 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 15 Jan 2019 10:05:24 -0800
Subject: Changes for January 2019 CPU release synced into FX 8u-dev
Message-ID: <0ef4ccfa-e965-b7f6-047f-1021a71d1b4b@oracle.com>

All,

As a heads-up I have synced the FX 8u201 & 8u202 changes from the 
just-released January 2019 CPU release into 8u-dev. For those who are 
interested, here is the aggregate webrev for the fixes, for those who 
don't want to wade through all 55 changesets, most of which are merge or 
tagging changesets:

http://cr.openjdk.java.net/~kcr/cpu-1901-sync/8u-dev/webrev/

-- Kevin


From kevin.rushforth at oracle.com  Tue Jan 15 18:12:28 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 15 Jan 2019 10:12:28 -0800
Subject: [12] RFR: Request to sync January 2019 CPU changes into jfx-dev
Message-ID: <8d6b668d-97e2-f428-c4dc-f53be99b6f7c@oracle.com>

Johan and Phil,

I request approval to sync changes from to the just-released January 
2019 CPU release into jfx-dev. Here is the aggregate webrev for the fixes:

http://cr.openjdk.java.net/~kcr/cpu-1901-sync/jfx-dev/webrev/

-- Kevin

From kevin.rushforth at oracle.com  Tue Jan 15 18:13:29 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 15 Jan 2019 10:13:29 -0800
Subject: [11] RFR: Request to backport January 2019 CPU changes into 11-dev
Message-ID: <ddac457f-3314-34d9-a2ed-4123ac0414fd@oracle.com>

Hi Johan,

I request approval to backport the changes from the just-released 
January 2019 CPU, along with two changesets to update libjpeg to version 
9c (I discovered that I forgot to include them on the earlier list of 
fixes to backport, else they could have been done ahead of time).

1. Update to libjpeg 9c

The following two bugs were pushed into jfx-dev for FX 12:

https://bugs.openjdk.java.net/browse/JDK-8203884 (Update libjpeg to 
version 9c)
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc4eac151944

https://bugs.openjdk.java.net/browse/JDK-8214035 (Unable to render cmyk 
jpeg image)
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/0e8471a4ad56

The two changesets import cleanly into 11-dev.


2. Aggregate webrev for Jan 2019 CPU changes

http://cr.openjdk.java.net/~kcr/cpu-1901-sync/11-dev/webrev/


Thanks.

-- Kevin


From johan.vos at gluonhq.com  Tue Jan 15 18:41:32 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 15 Jan 2019 19:41:32 +0100
Subject: [12] RFR: Request to sync January 2019 CPU changes into jfx-dev
In-Reply-To: <8d6b668d-97e2-f428-c4dc-f53be99b6f7c@oracle.com>
References: <8d6b668d-97e2-f428-c4dc-f53be99b6f7c@oracle.com>
Message-ID: <CABxFH2FL2nosBurFzyz-4WOt9s4KpdsggqJ+-DaLny9pzNdgQA@mail.gmail.com>

Approved.

On Tue, Jan 15, 2019 at 7:12 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Johan and Phil,
>
> I request approval to sync changes from to the just-released January
> 2019 CPU release into jfx-dev. Here is the aggregate webrev for the fixes:
>
> http://cr.openjdk.java.net/~kcr/cpu-1901-sync/jfx-dev/webrev/
>
> -- Kevin
>

From philip.race at oracle.com  Tue Jan 15 18:42:17 2019
From: philip.race at oracle.com (Phil Race)
Date: Tue, 15 Jan 2019 10:42:17 -0800
Subject: [12] RFR: Request to sync January 2019 CPU changes into jfx-dev
In-Reply-To: <CABxFH2FL2nosBurFzyz-4WOt9s4KpdsggqJ+-DaLny9pzNdgQA@mail.gmail.com>
References: <8d6b668d-97e2-f428-c4dc-f53be99b6f7c@oracle.com>
 <CABxFH2FL2nosBurFzyz-4WOt9s4KpdsggqJ+-DaLny9pzNdgQA@mail.gmail.com>
Message-ID: <e82da279-2c35-9063-5138-4649974bd70d@oracle.com>

Ditto.

-phil.

On 1/15/19 10:41 AM, Johan Vos wrote:
> Approved.
>
> On Tue, Jan 15, 2019 at 7:12 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     Johan and Phil,
>
>     I request approval to sync changes from to the just-released January
>     2019 CPU release into jfx-dev. Here is the aggregate webrev for
>     the fixes:
>
>     http://cr.openjdk.java.net/~kcr/cpu-1901-sync/jfx-dev/webrev/
>
>     -- Kevin
>


From johan.vos at gluonhq.com  Tue Jan 15 18:53:05 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 15 Jan 2019 19:53:05 +0100
Subject: [11] RFR: Request to backport January 2019 CPU changes into 11-dev
In-Reply-To: <ddac457f-3314-34d9-a2ed-4123ac0414fd@oracle.com>
References: <ddac457f-3314-34d9-a2ed-4123ac0414fd@oracle.com>
Message-ID: <CABxFH2HznrBMUj4R1Qq1BU_N9xaNya=p4XUsek3C4Vjq2woCdA@mail.gmail.com>

Approved

On Tue, Jan 15, 2019 at 7:13 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Hi Johan,
>
> I request approval to backport the changes from the just-released
> January 2019 CPU, along with two changesets to update libjpeg to version
> 9c (I discovered that I forgot to include them on the earlier list of
> fixes to backport, else they could have been done ahead of time).
>
> 1. Update to libjpeg 9c
>
> The following two bugs were pushed into jfx-dev for FX 12:
>
> https://bugs.openjdk.java.net/browse/JDK-8203884 (Update libjpeg to
> version 9c)
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc4eac151944
>
> https://bugs.openjdk.java.net/browse/JDK-8214035 (Unable to render cmyk
> jpeg image)
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/0e8471a4ad56
>
> The two changesets import cleanly into 11-dev.
>
>
> 2. Aggregate webrev for Jan 2019 CPU changes
>
> http://cr.openjdk.java.net/~kcr/cpu-1901-sync/11-dev/webrev/
>
>
> Thanks.
>
> -- Kevin
>
>

From kevin.rushforth at oracle.com  Tue Jan 15 21:31:00 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 15 Jan 2019 13:31:00 -0800
Subject: [12] RFR: JDK-8215435: Warn on usage of trampolines with gcc
Message-ID: <e78c5b20-02ca-01ce-3404-10249f5274fb@oracle.com>

Please review the following fix to add the? "-Werror=trampolines" to gcc:

https://bugs.openjdk.java.net/browse/JDK-8215435
https://github.com/javafxports/openjdk-jfx/pull/345

-- Kevin


From nlisker at gmail.com  Tue Jan 15 21:59:04 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 15 Jan 2019 23:59:04 +0200
Subject: Review Request: JDK-8210361: Add images to docs for public API
 classes of controls
Message-ID: <CA+0ynh8fJH0B2fXrqwn=FUjx4TqUaU0BMD3JWLJiRJM+qB05aQ@mail.gmail.com>

Hi,

Please review the current state of the patch for:

https://bugs.openjdk.java.net/browse/JDK-8210361
http://cr.openjdk.java.net/~nlisker/8210361/webrev.00/

Thanks,
Nir

From youngty1997 at gmail.com  Wed Jan 16 02:36:21 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Tue, 15 Jan 2019 20:36:21 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
Message-ID: <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>

On 1/13/19 5:33 PM, John Neffenger wrote:
> On 1/12/19 10:20 PM, Ty Young wrote:
>> Seeing as how this important issue is seemingly being ignored, I've 
>> decided to upload a video showcases the bugs[1]. If this isn't 
>> evidence that there is a problem with JavaFX's content rendering, 
>> resizing, and fonts I don't know what is.
>
> Your video looks similar to a bug I first encountered two years ago 
> [1]. I was reluctant to reply earlier because I can't reproduce the 
> bug in a windowed environment. So far I have seen the problem in the 
> two cases listed below (the bug report lists only the first case):
>
> (a) on a Monocle platform using an off-screen composition buffer that 
> is allocated as a non-direct byte buffer, and
>
> (b) on a Monocle platform using the frame buffer directly as the 
> composition buffer, and its horizontal visible resolution differs from 
> its virtual resolution.
>
> If I play your videos at the slowest speed, I see the entire frame 
> jump up when you resize its window. That is just what you would expect 
> if the position of the buffer was reset to zero while the buffer was 
> being used to draw the frame.


...and can cause undefined behavior like horizontal scrollbars showing 
when they shouldn't I assume?


Does JavaFX only have one frame buffer? If so, would it not be possible 
(and safer) to have a primary buffer and a secondary "prefetch" frame 
buffer to safely create the next frame buffer to ensure that this 
doesn't happen? So that:


1. UI update happens(resize, control clicked, etc)

2. "prefetch" buffer immediately draws the next frame and keeps drawing 
frames if UI updates keep happening

3. primary buffer is replaced with the newest complete "prefetch" buffer


In otherwords, similar to double and triple buffering. Of course, just 
like with double/triple buffering this can cause side affects.


>
> Our environments are very different, and your problem may have origins 
> outside of JavaFX entirely, but it may still be worth trying the same 
> debugging technique described in the bug report.


The waving Duke project no longer works in JavaFX 11. Is there an easy 
way to do similar in any JavaFX project using the latest JavaFX?


I created a new JavaFX/JDK build with the submitted commit and it 
doesn't improve anything. It could just be placebo but it may have 
actually made it worse.


>
> John
>
> [1] See: https://bugs.openjdk.java.net/browse/JDK-8201567
> or: https://gitlab.com/openjfxepd/jfxpatch/issues/1

From john at status6.com  Wed Jan 16 06:17:49 2019
From: john at status6.com (John Neffenger)
Date: Tue, 15 Jan 2019 22:17:49 -0800
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
References: <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
 <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
Message-ID: <e8f655d3-e613-4d87-bdb5-76413646c922@status6.com>

On 1/15/19 6:36 PM, Ty Young wrote:
> In otherwords, similar to double and triple buffering. Of course, just 
> like with double/triple buffering this can cause side affects.

Yes, JavaFX does all that. I was trying to help out by informing you of 
at least one concurrency bug between the QuantumRenderer and JavaFX 
Application thread, because your video looked similar -- like an 
off-screen composition buffer being mistakenly reset.

> I created a new JavaFX/JDK build with the submitted commit and it 
> doesn't improve anything. It could just be placebo but it may have 
> actually made it worse.

Right. I was also unable to hit that specific bug when trying to 
reproduce your problem. I mentioned it only to give you some ideas for 
your own debugging deep dive. Sorry I wasn't more clear.

John

From arunprasad.rajkumar at oracle.com  Wed Jan 16 11:07:03 2019
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Wed, 16 Jan 2019 16:37:03 +0530
Subject: RFR 8215702: SVG gradients are not rendered
Message-ID: <E236086D-DDEA-4BD7-B85E-E830AEAECC51@oracle.com>

Hi,

Please review the following PR related to JDK-8215702,

https://github.com/javafxports/openjdk-jfx/pull/347

https://bugs.openjdk.java.net/browse/JDK-8215702

Thanks,
Arun

From ambarish.rapte at oracle.com  Wed Jan 16 12:37:14 2019
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 16 Jan 2019 04:37:14 -0800 (PST)
Subject: [12] RFR: JDK-8212102: [TextField] IOOBE on paste/replace text with
 control characters
Message-ID: <6928f08f-b5ac-426e-8e87-99111f9e967f@default>

Hi Kevin, Ajit,



                Please review this fix:
                JBS: https://bugs.openjdk.java.net/browse/JDK-8212102
                Webrev: http://cr.openjdk.java.net/~arapte/fx/8212102/webrev.00/ 

Regards,

Ambarish

From siddheshrane at disroot.org  Wed Jan 16 14:57:15 2019
From: siddheshrane at disroot.org (Siddhesh Rane)
Date: Wed, 16 Jan 2019 14:57:15 +0000
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
References: <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
 <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
Message-ID: <fcf4d2e489f779304f6c4bab0dc15c09@disroot.org>

January 16, 2019 8:07 AM, "Ty Young" <youngty1997 at gmail.com> wrote:

> 
> ...and can cause undefined behavior like horizontal scrollbars showing when they shouldn't I
> assume?

As I have said previously, scrollbar issue is occuring only due to your use of DoubleBinding in layout.
I saw your code and I can confirm this is the main cause.
If you want a 15-85 % split, you should have used a GridPane with two columns with the given percentage constraints.
I have created a gist here to demonstrate it [1]. Preview it in Scene Builder. 
I would highly recommend you to play with javafx layout panes in scene builder and to use fxml for more of your layout than handcoding it.

[1] https://gist.github.com/SiddheshRane/74c59832fb2b6287620120a648b5a176

Regards
Siddhesh

From johan.vos at gluonhq.com  Wed Jan 16 15:06:16 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 16 Jan 2019 16:06:16 +0100
Subject: Review request for [JDK-8217259] release notes 11.0.2
Message-ID: <CABxFH2FfSWGvJRU0KdSz2srRupFhu+Z4oRD5fSEb8SFQ7D8_+Q@mail.gmail.com>

Hi Kevin,

Please review http://cr.openjdk.java.net/~jvos/8217259/webrev.00/
which contains the release notes for 11.0.2

A layouted version of this is also available at
https://github.com/johanvos/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.0.2.md

Thanks,

- Johan

From kevin.rushforth at oracle.com  Wed Jan 16 15:58:25 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 16 Jan 2019 07:58:25 -0800
Subject: Review request for [JDK-8217259] release notes 11.0.2
In-Reply-To: <CABxFH2FfSWGvJRU0KdSz2srRupFhu+Z4oRD5fSEb8SFQ7D8_+Q@mail.gmail.com>
References: <CABxFH2FfSWGvJRU0KdSz2srRupFhu+Z4oRD5fSEb8SFQ7D8_+Q@mail.gmail.com>
Message-ID: <4f6b17e3-eb78-9234-a3ec-7dc07ad15d00@oracle.com>

Approved.

-- Kevin


On 1/16/2019 7:06 AM, Johan Vos wrote:
> Hi Kevin,
>
> Please review http://cr.openjdk.java.net/~jvos/8217259/webrev.00/
> which contains the release notes for 11.0.2
>
> A layouted version of this is also available at 
> https://github.com/johanvos/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.0.2.md
>
> Thanks,
>
> - Johan


From youngty1997 at gmail.com  Wed Jan 16 18:00:14 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Wed, 16 Jan 2019 12:00:14 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <fcf4d2e489f779304f6c4bab0dc15c09@disroot.org>
References: <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
 <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
 <fcf4d2e489f779304f6c4bab0dc15c09@disroot.org>
Message-ID: <2025adc7-c8f9-4157-6665-7720320ed4bd@gmail.com>


On 1/16/19 8:57 AM, Siddhesh Rane wrote:
> January 16, 2019 8:07 AM, "Ty Young" <youngty1997 at gmail.com> wrote:
>
>> ...and can cause undefined behavior like horizontal scrollbars showing when they shouldn't I
>> assume?
> As I have said previously, scrollbar issue is occuring only due to your use of DoubleBinding in layout.


How else is percentage based UI sizing besides DoubleBinding(s)? Isn't 
column restraints just the same thing but aligns everything to a column?


I have to ask(again) as to why minWidth/maxWidth, minHeight/maxHeight, 
prefWidth/prefHeight aren't read only if this is going to be an *always* 
realistically going to be an issue.


> I saw your code and I can confirm this is the main cause.
> If you want a 15-85 % split, you should have used a GridPane with two columns with the given percentage constraints.


This works for the buttons/scrollpane but what about the subcontent? 
TableView's scrollbars also glitch out in the exact same way.


> I have created a gist here to demonstrate it [1]. Preview it in Scene Builder.
> I would highly recommend you to play with javafx layout panes in scene builder and to use fxml for more of your layout than handcoding it.


SceneBuilder's lack of UI snapping compared to Netbean's Swing builder 
makes it incredibly difficult to get anything remotely pixel perfect 
without banging your head against a wall. Separate controller classes 
and FXML annotations everywhere isn't really desirable either. I 
originally entertained the idea of doing it all in FXML only to quickly 
discard the idea.


It's my understanding that FXML has to be converted to Java in the end 
anyway so anything done in FXML should theoretically be possible in 
Java. Is that not correct?




>
> [1] https://gist.github.com/SiddheshRane/74c59832fb2b6287620120a648b5a176
>
> Regards
> Siddhesh

From nlisker at gmail.com  Thu Jan 17 00:52:57 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 17 Jan 2019 02:52:57 +0200
Subject: Review Request: JDK-8217270: Broken link to cssref.html in
 javafx.controls package docs
Message-ID: <CA+0ynh8jtGuvLmL097qSfayP2Gw-uAjmj81LOVk1T2YqOt4VJQ@mail.gmail.com>

Hi,

Please review the simple fix for:

https://bugs.openjdk.java.net/browse/JDK-8217270
http://cr.openjdk.java.net/~nlisker/8217270/webrev.00/

Thanks,
Nir

From daniel.weil at argosim.com  Thu Jan 17 13:05:42 2019
From: daniel.weil at argosim.com (daniel.weil at argosim.com)
Date: Thu, 17 Jan 2019 14:05:42 +0100
Subject: JDK-8193445 Performance Test (CSS applied redundantly)
Message-ID: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>

Does anybody has any information about a target release for fixing
https://bugs.openjdk.java.net/browse/JDK-8183100 , this issue causing severe
performance degradation since JDK1.8.172?

 

Since JDK1.8.182, CSS is applied redundantly, leading too significant
performance degradation, on scenes with many levels of hierarchy.

 

I logged this issue in two JIRA in December 2018 (more than 1 year ago) : 

https://bugs.openjdk.java.net/browse/JDK-8193445

https://bugs.openjdk.java.net/browse/JDK-8209830

 

I've reported another issue https://bugs.openjdk.java.net/browse/JDK-8199216
, showing performance and memory issue caused by Javafx PseudoClassState
objects. This issue could be related to the previous ones.

 

This is a really BLOCKING issue, our product is stuck with JDK1.8.162,
blocking us for trying a migration to JDK10 or JDK11!

 

Daniel Weil (ARGOSIM)


From wookey.dean at gmail.com  Thu Jan 17 16:10:25 2019
From: wookey.dean at gmail.com (Dean Wookey)
Date: Thu, 17 Jan 2019 18:10:25 +0200
Subject: EM Font Size Performance
In-Reply-To: <6bc18460-15a8-74d7-3cff-082c87aee1c4@oracle.com>
References: <CAKZ_BFhQuC=ynfnKnh1+Lxa5SZ2cnFomncK4G867B7qB+EdaqQ@mail.gmail.com>
 <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com>
 <CA+0ynh96xqUqdLU7qPJzZ-QfQDUtFOaZHUdNCWZef2OdG327tg@mail.gmail.com>
 <6bc18460-15a8-74d7-3cff-082c87aee1c4@oracle.com>
Message-ID: <CAKZ_BFi=e+gtm4t-2PZFhBR68e8FC3XQ+52Q96z2gxUDeB4UzQ@mail.gmail.com>

This is almost a year old, but I think I've found a partial solution
(David's suggestions on a top down approach still make sense, but that's a
bigger issue). Caching an uncached call to lookupFont definitely improves
performance.

https://github.com/DeanWookey/openjdk-jfx/commit/e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9

Using a stack of 50 stackpanes instead of 20, I now get the following:

Before modification:

With setting font size: 10675ms
Without setting font size: 49243ms

After modification:

With setting font size: 10852ms
Without setting font size: 20357ms

Dean

On Thu, Apr 19, 2018 at 9:51 PM David Grieve <david.grieve at oracle.com>
wrote:

> I was thinking about https://bugs.openjdk.java.net/browse/JDK-8177635 and
> https://bugs.openjdk.java.net/browse/JDK-8090462
>
> There is also https://bugs.openjdk.java.net/browse/JDK-8187955
>
> On 4/19/18 3:02 PM, Nir Lisker wrote:
>
> I think this is the issue:
> https://bugs.openjdk.java.net/browse/JDK-8088615. There's also
> https://bugs.openjdk.java.net/browse/JDK-8193445.
>
> - Nir
>
> On Thu, Apr 19, 2018 at 1:42 PM, David Grieve <david.grieve at oracle.com>
> wrote:
>
>> Resolving the relative size involves a lot of lookup. You have to go up
>> the scene-graph from the child to find a font style. If you get to the root
>> and haven't found a font style, then use the default font. Performance in
>> this area could be vastly improved by passing the size from either a font
>> style or the default font down the scene-graph as styles are evaluated.
>> There are other style lookups that could benefit from this as well,
>> resolving looked-up colors for example. I believe I created a bug for this
>> a long time ago.
>>
>>
>>
>> On 4/19/18 5:57 AM, Dean Wookey wrote:
>>
>>> Hi All,
>>>
>>> In our application we add and remove a lot of nodes to the scene graph
>>> regularly, and also make use of em font sizes to scale certain parts of
>>> our
>>> application. We've noticed performance issues when adding nodes to the
>>> scene, and it seems to be related to em sizes in our css.
>>>
>>> As a test we added a chain of 20 stackpanes to a root stackpane. On the
>>> root, we set a font size of 8pt via inline css. We then added and
>>> removed a
>>> new tableview from the deepest stackpane 500 times, waiting for the node
>>> to
>>> render after each add and remove.
>>>
>>> In each of the experiments, we compared adding tableviews without css and
>>> adding tableviews with an inline css font size of 8pt. We then tried
>>> setting different font sizes in the stackpane chain.
>>>
>>> I've attached sample code for these experiments.
>>>
>>> The results (on jdk 9.0.4 - jdk 10 was similar) are as follows:
>>>
>>> Setting a 1em font size on all stackpanes except the root.
>>> With font on tableview: 14707ms
>>> Without font on tableview: 27725ms
>>>
>>> Setting a 1em font size on the first child of the root only.
>>> With font on tableview: 14221ms
>>> Without font on tableview: 19187ms
>>>
>>> Using the original setup with no additional fonts.
>>> With font on tableview: 13990ms
>>> Without font on tableview: 13847ms
>>>
>>> It looks like using a relative font size has a large effect performance
>>> wise on descendant nodes. I would expect some amount of font size caching
>>> in the chain of stackpanes since I'm reusing the same chain and
>>> adding/removing nodes from that chain repeatedly.
>>>
>>> I'm not sure how valid my test is, or how much of an issue this really is
>>> in practice?
>>>
>>> Dean
>>>
>>
>>
>
>

From david.grieve at oracle.com  Thu Jan 17 16:40:57 2019
From: david.grieve at oracle.com (David Grieve)
Date: Thu, 17 Jan 2019 11:40:57 -0500
Subject: EM Font Size Performance
In-Reply-To: <CAKZ_BFi=e+gtm4t-2PZFhBR68e8FC3XQ+52Q96z2gxUDeB4UzQ@mail.gmail.com>
References: <CAKZ_BFhQuC=ynfnKnh1+Lxa5SZ2cnFomncK4G867B7qB+EdaqQ@mail.gmail.com>
 <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com>
 <CA+0ynh96xqUqdLU7qPJzZ-QfQDUtFOaZHUdNCWZef2OdG327tg@mail.gmail.com>
 <6bc18460-15a8-74d7-3cff-082c87aee1c4@oracle.com>
 <CAKZ_BFi=e+gtm4t-2PZFhBR68e8FC3XQ+52Q96z2gxUDeB4UzQ@mail.gmail.com>
Message-ID: <41f76892-849a-36a5-bceb-f1c97275e355@oracle.com>

I think the change looks reasonable. Has it been tested against things 
like changing -fx-font in some parent, or setting the font property in 
some parent? What about popups? If I have a tooltip on a Label, for 
example, does the tooltip properly pick up font from the Label's style 
or font property?

On 1/17/19 11:10 AM, Dean Wookey wrote:
> This is almost a year old, but I think I've found a partial solution 
> (David's suggestions on a top down approach still make sense, but 
> that's a bigger issue). Caching an uncached call to lookupFont 
> definitely improves performance.
>
> https://github.com/DeanWookey/openjdk-jfx/commit/e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DeanWookey_openjdk-2Djfx_commit_e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=H6jKHjHoLf6vCNF0PYEnJ6cS6kScbGLraJqgoRs9znU&m=xH8dfYiQe6JO5VXucoVgtnsubTZNAhr0XVK5OaSDDbs&s=YvsZxESGrm40L34aR16E2fQCKjh8tCQ311R3h63hu0c&e=>
>
> Using a stack of 50 stackpanes instead of 20, I now get the following:
>
> Before modification:
>
> With setting font size: 10675ms
> Without setting font size: 49243ms
>
> After modification:
>
> With setting font size: 10852ms
> Without setting font size: 20357ms
>
> Dean
>
> On Thu, Apr 19, 2018 at 9:51 PM David Grieve <david.grieve at oracle.com 
> <mailto:david.grieve at oracle.com>> wrote:
>
>     I was thinking about
>     https://bugs.openjdk.java.net/browse/JDK-8177635 and
>     https://bugs.openjdk.java.net/browse/JDK-8090462
>
>     There is also https://bugs.openjdk.java.net/browse/JDK-8187955
>
>
>     On 4/19/18 3:02 PM, Nir Lisker wrote:
>>     I think this is the issue:
>>     https://bugs.openjdk.java.net/browse/JDK-8088615. There's also
>>     https://bugs.openjdk.java.net/browse/JDK-8193445.
>>
>>     - Nir
>>
>>     On Thu, Apr 19, 2018 at 1:42 PM, David Grieve
>>     <david.grieve at oracle.com <mailto:david.grieve at oracle.com>> wrote:
>>
>>         Resolving the relative size involves a lot of lookup. You
>>         have to go up the scene-graph from the child to find a font
>>         style. If you get to the root and haven't found a font style,
>>         then use the default font. Performance in this area could be
>>         vastly improved by passing the size from either a font style
>>         or the default font down the scene-graph as styles are
>>         evaluated. There are other style lookups that could benefit
>>         from this as well, resolving looked-up colors for example. I
>>         believe I created a bug for this a long time ago.
>>
>>
>>
>>         On 4/19/18 5:57 AM, Dean Wookey wrote:
>>
>>             Hi All,
>>
>>             In our application we add and remove a lot of nodes to
>>             the scene graph
>>             regularly, and also make use of em font sizes to scale
>>             certain parts of our
>>             application. We've noticed performance issues when adding
>>             nodes to the
>>             scene, and it seems to be related to em sizes in our css.
>>
>>             As a test we added a chain of 20 stackpanes to a root
>>             stackpane. On the
>>             root, we set a font size of 8pt via inline css. We then
>>             added and removed a
>>             new tableview from the deepest stackpane 500 times,
>>             waiting for the node to
>>             render after each add and remove.
>>
>>             In each of the experiments, we compared adding tableviews
>>             without css and
>>             adding tableviews with an inline css font size of 8pt. We
>>             then tried
>>             setting different font sizes in the stackpane chain.
>>
>>             I've attached sample code for these experiments.
>>
>>             The results (on jdk 9.0.4 - jdk 10 was similar) are as
>>             follows:
>>
>>             Setting a 1em font size on all stackpanes except the root.
>>             With font on tableview: 14707ms
>>             Without font on tableview: 27725ms
>>
>>             Setting a 1em font size on the first child of the root only.
>>             With font on tableview: 14221ms
>>             Without font on tableview: 19187ms
>>
>>             Using the original setup with no additional fonts.
>>             With font on tableview: 13990ms
>>             Without font on tableview: 13847ms
>>
>>             It looks like using a relative font size has a large
>>             effect performance
>>             wise on descendant nodes. I would expect some amount of
>>             font size caching
>>             in the chain of stackpanes since I'm reusing the same
>>             chain and
>>             adding/removing nodes from that chain repeatedly.
>>
>>             I'm not sure how valid my test is, or how much of an
>>             issue this really is
>>             in practice?
>>
>>             Dean
>>
>>
>>
>

From swpalmer at gmail.com  Thu Jan 17 16:42:47 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 17 Jan 2019 11:42:47 -0500
Subject: JDK-8193445 Performance Test (CSS applied redundantly)
In-Reply-To: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>
References: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>
Message-ID: <22F86AD5-696C-4A14-B296-7119EE5CB2E0@gmail.com>

JDK-8183100 is a fixed issue.  But it basically undid the fix for https://bugs.openjdk.java.net/browse/JDK-8151756 <https://bugs.openjdk.java.net/browse/JDK-8151756>
I think you mean to ask when JDK-8193445 might be addressed.

I too would like to see the performance return, and actually I?m hoping it can be made better than it was before. 

Performance improvements and a JNI mechanism to get at native window handles are the first two items on my wish list.  Though extendable media support could potentially beat out the window handle thing.. I only need a native window handle so I can do native rendering of video frames from a non-JavaFX source.

Scott 

> On Jan 17, 2019, at 8:05 AM, <daniel.weil at argosim.com> <daniel.weil at argosim.com> wrote:
> 
> Does anybody has any information about a target release for fixing
> https://bugs.openjdk.java.net/browse/JDK-8183100 , this issue causing severe
> performance degradation since JDK1.8.172?
> 
> 
> 
> Since JDK1.8.182, CSS is applied redundantly, leading too significant
> performance degradation, on scenes with many levels of hierarchy.
> 
> 
> 
> I logged this issue in two JIRA in December 2018 (more than 1 year ago) : 
> 
> https://bugs.openjdk.java.net/browse/JDK-8193445
> 
> https://bugs.openjdk.java.net/browse/JDK-8209830
> 
> 
> 
> I've reported another issue https://bugs.openjdk.java.net/browse/JDK-8199216
> , showing performance and memory issue caused by Javafx PseudoClassState
> objects. This issue could be related to the previous ones.
> 
> 
> 
> This is a really BLOCKING issue, our product is stuck with JDK1.8.162,
> blocking us for trying a migration to JDK10 or JDK11!
> 
> 
> 
> Daniel Weil (ARGOSIM)
> 


From mike.ennen at gmail.com  Thu Jan 17 17:10:39 2019
From: mike.ennen at gmail.com (Michael Ennen)
Date: Thu, 17 Jan 2019 10:10:39 -0700
Subject: Review-Request for JDK-8217333
Message-ID: <CAOTPd66sOaFxshYkrq9gX-tW2tL3GoXr3v0AwEjJBLfqBthMFQ@mail.gmail.com>

 Hi,

I'd like to request a review for JDK-8217333 available as a PR on
Github:

https://github.com/javafxports/openjdk-jfx/pull/346
<https://github.com/javafxports/openjdk-jfx/pull/168>

https://bugs.openjdk.java.net/browse/JDK-8217333
<https://bugs.openjdk.java.net/browse/JDK-8209970>

Thanks.


-- 
Michael Ennen

From siddheshrane at disroot.org  Thu Jan 17 18:55:04 2019
From: siddheshrane at disroot.org (Siddhesh Rane)
Date: Thu, 17 Jan 2019 18:55:04 +0000
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <2025adc7-c8f9-4157-6665-7720320ed4bd@gmail.com>
References: <2025adc7-c8f9-4157-6665-7720320ed4bd@gmail.com>
 <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
 <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
 <fcf4d2e489f779304f6c4bab0dc15c09@disroot.org>
Message-ID: <d1ce54c216b402b37b698be3c24ff9ff@disroot.org>

January 16, 2019 11:31 PM, "Ty Young" <youngty1997 at gmail.com> wrote:

> How else is percentage based UI sizing besides DoubleBinding(s)? Isn't column restraints just the
> same thing but aligns everything to a column?
>
> I have to ask(again) as to why minWidth/maxWidth, minHeight/maxHeight, prefWidth/prefHeight aren't
> read only if this is going to be an *always* realistically going to be an issue.

Column constraints don't use any bindings, neither do any other layout panes.
{min,pref,max} width/height are merely hints for a parent to layout the child. They are not the final authority on child size. The actual final size of a child is set by calling Node#resize on it, which is what the parent does during the Parent#layoutChildren call. During this call the parent knows about its own size and can split that space among the children.
A rogue parent could completely ignore these hints and resize the child to whatever it wants.

On your second point, it is only an issue if you use it in the wrong way, without understanding.
You bound the minWidth of a scrollpane's content to 85% of the scrollpane's widthProperty (which is actual width).
When you resize the scrollpane to <85% of its original size, its content still has the old minWidth property which is greater than the current width of the scroll pane. So the scrollpane shows horizontal bar. This is not a bug. widthProperty is supposed to be valid after layout.

Use bindings for size if you want to do some advanced sizing. Like size matching unrelated nodes with different parents to get some visual effect. You could create a custom textarea that binds minWidth to the number of characters in the first line.
I have never had a use case but someone else might.
Use it for cases where there is no mutual dependency or "race condition".

>> I saw your code and I can confirm this is the main cause.
>> If you want a 15-85 % split, you should have used a GridPane with two columns with the given
>> percentage constraints.
> 
> This works for the buttons/scrollpane but what about the subcontent? TableView's scrollbars also
> glitch out in the exact same way.

Set scrollpane to fit to width. Add a gridpane with a single column whose column width is set to 85%. Set gridpane alignment to center. Drop the bindings and your problems will be solved.

> SceneBuilder's lack of UI snapping compared to Netbean's Swing builder makes it incredibly
> difficult to get anything remotely pixel perfect without banging your head against a wall. Separate
> controller classes and FXML annotations everywhere isn't really desirable either. I originally
> entertained the idea of doing it all in FXML only to quickly discard the idea.

If you are talking about snapping like in aligning to other UI elements, then its there and you dont need it with the rought layout. If you mean snapping to pixels, JavaFX has it inbuilt and on by default.

Regards
Siddhesh

From tom.schindl at bestsolution.at  Thu Jan 17 20:23:07 2019
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 17 Jan 2019 21:23:07 +0100
Subject: JDK-8193445 Performance Test (CSS applied redundantly)
In-Reply-To: <22F86AD5-696C-4A14-B296-7119EE5CB2E0@gmail.com>
References: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>
 <22F86AD5-696C-4A14-B296-7119EE5CB2E0@gmail.com>
Message-ID: <8c90eac3-2c15-d109-19e9-c6498c136f14@bestsolution.at>

Sorry to hi-jack but:

> Performance improvements and a JNI mechanism to get at native window handles are the first two items on my wish list.  Though extendable media support could potentially beat out the window handle thing.. I only need a native window handle so I can do native rendering of video frames from a non-JavaFX source.

Couldn't you leverage our DriftFX work for this?

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From swpalmer at gmail.com  Thu Jan 17 23:31:46 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 17 Jan 2019 18:31:46 -0500
Subject: JDK-8193445 Performance Test (CSS applied redundantly)
In-Reply-To: <8c90eac3-2c15-d109-19e9-c6498c136f14@bestsolution.at>
References: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>
 <22F86AD5-696C-4A14-B296-7119EE5CB2E0@gmail.com>
 <8c90eac3-2c15-d109-19e9-c6498c136f14@bestsolution.at>
Message-ID: <6A347A82-5E31-4ABC-BF8A-71D0394FD0C4@gmail.com>


> On Jan 17, 2019, at 3:23 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> 
> Sorry to hi-jack but:
> 
>> Performance improvements and a JNI mechanism to get at native window handles are the first two items on my wish list.  Though extendable media support could potentially beat out the window handle thing.. I only need a native window handle so I can do native rendering of video frames from a non-JavaFX source.
> 
> Couldn't you leverage our DriftFX work for this?

Yes, possibly!  Thanks for reminding me. I did make note of it last month but it fell off the radar over the holidays. 

Scott


From alexander.matveev at oracle.com  Thu Jan 17 23:48:02 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 17 Jan 2019 15:48:02 -0800
Subject: RFR: JDK-8214185: Upgrade GStreamer to the latest (1.14.4) version
Message-ID: <897e6019-6ac5-7148-8736-8f8efb237394@oracle.com>

Hi Kevin,

Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8214185

- Upgrade for GStreamer (1.14.4) and GLib (2.58.2).

Thanks,
Alexander

From wookey.dean at gmail.com  Fri Jan 18 08:12:31 2019
From: wookey.dean at gmail.com (Dean Wookey)
Date: Fri, 18 Jan 2019 10:12:31 +0200
Subject: JDK-8193445 Performance Test (CSS applied redundantly)
In-Reply-To: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>
References: <0fd201d4ae65$5a76ebe0$0f64c3a0$@argosim.com>
Message-ID: <CAKZ_BFjj3=rY=VWQj5_D4MsEx35o3Yju1MUjheuNhAheGw7huA@mail.gmail.com>

The last time the issue was discussed was in November. You can see the
thread here:
https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022837.html

I too would like to see this and other performance issues addressed
(although our actual biggest priority is mobile). Right now my team is
building javafx ourselves with this fix:
https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6
and
we've been quite happy with it. Our application is fairly complex, and our
tables are particularly susceptible to css bugs. Our team hasn't seen
anything weird happen at all since we started using it. That may be a
solution for you until it's addressed. Alternatively you could try adding
the nodes to the scene graph incrementally, possibly even automatically
breaking a complex node into parts and rebuilding it while it's attached to
the scene. Something like this (I haven't actually tested this):

    public void addComplex() {
        BorderPane borderPane = new BorderPane();
        Pane complexNode = new Pane();
        addChild((n) -> borderPane.setCenter(n), complexNode);

        //or
        StackPane root = new StackPane();
        Pane complexNode2 = new Pane();
        addChild((n) -> root.getChildren().add(n), complexNode2);
    }

    public static void addChild(Consumer<Node> addChild, Node child) {
        if (child instanceof BorderPane) {
            BorderPane childBorderPane = (BorderPane) child;
            Node top = childBorderPane.getTop();
            Node bottom = childBorderPane.getBottom();
            Node left = childBorderPane.getLeft();
            Node right = childBorderPane.getRight();
            Node center = childBorderPane.getCenter();
            ArrayList<Node> all = copy(childBorderPane.getChildren());
            childBorderPane.getChildren().clear();
            addChild.accept(childBorderPane);
            addChild((n) -> childBorderPane.setTop(n), top);
            addChild((n) -> childBorderPane.setBottom(n), bottom);
            addChild((n) -> childBorderPane.setLeft(n), left);
            addChild((n) -> childBorderPane.setRight(n), right);
            addChild((n) -> childBorderPane.setCenter(n), center);
            for (Node node : all) {
                if (!childBorderPane.getChildren().contains(node)) {
                    addChild((n) -> childBorderPane.getChildren().add(n),
node);
                }
            }
        } else if (child instanceof Pane) {
            Pane childPane = (Pane) child;
            ArrayList<Node> all = copy(childPane.getChildren());
            childPane.getChildren().clear();
            addChild.accept(child);
            for (Node node : all) {
                addChild((n) -> childPane.getChildren().add(n), node);
            }
        } else if (child instanceof Group) {
            Group childGroup = (Group) child;
            ArrayList<Node> all = copy(childGroup.getChildren());
            childGroup.getChildren().clear();
            addChild.accept(child);
            for (Node node : all) {
                addChild((n) -> childGroup.getChildren().add(n), node);
            }
        } else {
            addChild.accept(child);
        }
    }

    private static ArrayList<Node> copy(ObservableList<Node> nodes) {
        ArrayList<Node> copy = new ArrayList<>();
        for (Node n : nodes) {
            copy.add(n);
        }
        return copy;
    }

On Thu, Jan 17, 2019 at 3:06 PM <daniel.weil at argosim.com> wrote:

> Does anybody has any information about a target release for fixing
> https://bugs.openjdk.java.net/browse/JDK-8183100 , this issue causing
> severe
> performance degradation since JDK1.8.172?
>
>
>
> Since JDK1.8.182, CSS is applied redundantly, leading too significant
> performance degradation, on scenes with many levels of hierarchy.
>
>
>
> I logged this issue in two JIRA in December 2018 (more than 1 year ago) :
>
> https://bugs.openjdk.java.net/browse/JDK-8193445
>
> https://bugs.openjdk.java.net/browse/JDK-8209830
>
>
>
> I've reported another issue
> https://bugs.openjdk.java.net/browse/JDK-8199216
> , showing performance and memory issue caused by Javafx PseudoClassState
> objects. This issue could be related to the previous ones.
>
>
>
> This is a really BLOCKING issue, our product is stuck with JDK1.8.162,
> blocking us for trying a migration to JDK10 or JDK11!
>
>
>
> Daniel Weil (ARGOSIM)
>
>

From tom.schindl at bestsolution.at  Fri Jan 18 08:27:42 2019
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 18 Jan 2019 09:27:42 +0100
Subject: [8u-dev announce] Future contributions to openjfx/8u-dev
In-Reply-To: <7cd363f0-7f2b-4758-796a-84cc1238af2c@oracle.com>
References: <1b2b1803-5052-979b-f8f9-391661f327eb@oracle.com>
 <6786cef7-31a3-33c8-c4ee-f65e5ded30fc@bestsolution.at>
 <7cd363f0-7f2b-4758-796a-84cc1238af2c@oracle.com>
Message-ID: <b6770928-4096-b290-13d2-079e3401573c@bestsolution.at>

Hi,

Is there any documentation how the current javafxports mirror repository
got created?

Some of our customer projects are going to be stuck on JavaFX-8 for the
forseeable future and while we won't sign up for providing general
support for JavaFX-8 it would be good to have a central place one can
fork JavaFX-8 from.

Having a central place would allow (at least in theory) that
modifications and patches from different people can be merged without to
much manual work.

Tom

On 08.01.19 00:01, Kevin Rushforth wrote:
> I'm not sure that an 8u-dev mirror would be suitable for the javafxports
> project, but if someone wanted to set up such a mirror elsewhere they
> could do so. It might be best left to the future maintainer (if any
> suitable party steps forward) to determine whether and where to host a
> git mirror.
> 
> -- Kevin
> 
> 
> On 12/21/2018 1:39 PM, Tom Schindl wrote:
>> Hi,
>>
>> Could we get a mirror of 8u setup for github as well? I wanted to ask
>> for that since some time but always forgot to do so.
>>
>> Tom
>>
>> On 21.12.18 22:32, Kevin Rushforth wrote:
>>> As has been previously announced [1][2], Oracle will no longer
>>> contribute to the JDK 8 Updates Project after the January 2019 quarterly
>>> CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part
>>> of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev
>>> code line (8u-dev/rt repo) after JDK 8u202 ships.
>>>
>>> This means that Oracle will be stepping down as the maintainer of the
>>> openjfx/8u-dev code line after January, and will call for a new
>>> maintainer. If a suitable party steps forward to maintain the OpenJFX 8
>>> Updates code line after the final Oracle-led JDK 8 Update release has
>>> been published, we will discuss how to best enable such a transition on
>>> this Project's mailing list.
>>>
>>> I wanted to send this before the holidays, although I realize it might
>>> get lost in the shuffle, so I will resend it after the first of the
>>> year, along with a formal call for interested parties who wish to put
>>> their name forward as a maintainer for the openjfx/8u-dev release.
>>>
>>> -- Kevin
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html
>>>
>>>
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From wookey.dean at gmail.com  Fri Jan 18 08:28:59 2019
From: wookey.dean at gmail.com (Dean Wookey)
Date: Fri, 18 Jan 2019 10:28:59 +0200
Subject: EM Font Size Performance
In-Reply-To: <41f76892-849a-36a5-bceb-f1c97275e355@oracle.com>
References: <CAKZ_BFhQuC=ynfnKnh1+Lxa5SZ2cnFomncK4G867B7qB+EdaqQ@mail.gmail.com>
 <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com>
 <CA+0ynh96xqUqdLU7qPJzZ-QfQDUtFOaZHUdNCWZef2OdG327tg@mail.gmail.com>
 <6bc18460-15a8-74d7-3cff-082c87aee1c4@oracle.com>
 <CAKZ_BFi=e+gtm4t-2PZFhBR68e8FC3XQ+52Q96z2gxUDeB4UzQ@mail.gmail.com>
 <41f76892-849a-36a5-bceb-f1c97275e355@oracle.com>
Message-ID: <CAKZ_BFgoPbhXv-TFHJeMQD1B2Yyh0c8ATOKFL8DJpeK-UGkGzQ@mail.gmail.com>

I've only tested with our application that includes all those things. We
set a font size on the root node and everything is done in em. The user can
change the font size of the root node, which filters down to things like
tooltips, context menus, tables etc.

Do you know if there are tests specifically for these things?

Otherwise, I'm not 100% happy with this fix because I feel it makes things
more confusing. In my opinion the lookupFont should cache itself, or there
should be a cachedLookupFont which does this. I don't really understand the
special cases of SKIP and null however, so I replicated the steps used to
cache the result elsewhere. I think it would be better if someone else made
a more comprehensive fix which made things a little clearer.

Dean

On Thu, Jan 17, 2019 at 6:41 PM David Grieve <david.grieve at oracle.com>
wrote:

> I think the change looks reasonable. Has it been tested against things
> like changing -fx-font in some parent, or setting the font property in some
> parent? What about popups? If I have a tooltip on a Label, for example,
> does the tooltip properly pick up font from the Label's style or font
> property?
> On 1/17/19 11:10 AM, Dean Wookey wrote:
>
> This is almost a year old, but I think I've found a partial solution
> (David's suggestions on a top down approach still make sense, but that's a
> bigger issue). Caching an uncached call to lookupFont definitely improves
> performance.
>
>
> https://github.com/DeanWookey/openjdk-jfx/commit/e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DeanWookey_openjdk-2Djfx_commit_e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=H6jKHjHoLf6vCNF0PYEnJ6cS6kScbGLraJqgoRs9znU&m=xH8dfYiQe6JO5VXucoVgtnsubTZNAhr0XVK5OaSDDbs&s=YvsZxESGrm40L34aR16E2fQCKjh8tCQ311R3h63hu0c&e=>
>
> Using a stack of 50 stackpanes instead of 20, I now get the following:
>
> Before modification:
>
> With setting font size: 10675ms
> Without setting font size: 49243ms
>
> After modification:
>
> With setting font size: 10852ms
> Without setting font size: 20357ms
>
> Dean
>
> On Thu, Apr 19, 2018 at 9:51 PM David Grieve <david.grieve at oracle.com>
> wrote:
>
>> I was thinking about https://bugs.openjdk.java.net/browse/JDK-8177635
>> and https://bugs.openjdk.java.net/browse/JDK-8090462
>>
>> There is also https://bugs.openjdk.java.net/browse/JDK-8187955
>>
>> On 4/19/18 3:02 PM, Nir Lisker wrote:
>>
>> I think this is the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8088615. There's also
>> https://bugs.openjdk.java.net/browse/JDK-8193445.
>>
>> - Nir
>>
>> On Thu, Apr 19, 2018 at 1:42 PM, David Grieve <david.grieve at oracle.com>
>> wrote:
>>
>>> Resolving the relative size involves a lot of lookup. You have to go up
>>> the scene-graph from the child to find a font style. If you get to the root
>>> and haven't found a font style, then use the default font. Performance in
>>> this area could be vastly improved by passing the size from either a font
>>> style or the default font down the scene-graph as styles are evaluated.
>>> There are other style lookups that could benefit from this as well,
>>> resolving looked-up colors for example. I believe I created a bug for this
>>> a long time ago.
>>>
>>>
>>>
>>> On 4/19/18 5:57 AM, Dean Wookey wrote:
>>>
>>>> Hi All,
>>>>
>>>> In our application we add and remove a lot of nodes to the scene graph
>>>> regularly, and also make use of em font sizes to scale certain parts of
>>>> our
>>>> application. We've noticed performance issues when adding nodes to the
>>>> scene, and it seems to be related to em sizes in our css.
>>>>
>>>> As a test we added a chain of 20 stackpanes to a root stackpane. On the
>>>> root, we set a font size of 8pt via inline css. We then added and
>>>> removed a
>>>> new tableview from the deepest stackpane 500 times, waiting for the
>>>> node to
>>>> render after each add and remove.
>>>>
>>>> In each of the experiments, we compared adding tableviews without css
>>>> and
>>>> adding tableviews with an inline css font size of 8pt. We then tried
>>>> setting different font sizes in the stackpane chain.
>>>>
>>>> I've attached sample code for these experiments.
>>>>
>>>> The results (on jdk 9.0.4 - jdk 10 was similar) are as follows:
>>>>
>>>> Setting a 1em font size on all stackpanes except the root.
>>>> With font on tableview: 14707ms
>>>> Without font on tableview: 27725ms
>>>>
>>>> Setting a 1em font size on the first child of the root only.
>>>> With font on tableview: 14221ms
>>>> Without font on tableview: 19187ms
>>>>
>>>> Using the original setup with no additional fonts.
>>>> With font on tableview: 13990ms
>>>> Without font on tableview: 13847ms
>>>>
>>>> It looks like using a relative font size has a large effect performance
>>>> wise on descendant nodes. I would expect some amount of font size
>>>> caching
>>>> in the chain of stackpanes since I'm reusing the same chain and
>>>> adding/removing nodes from that chain repeatedly.
>>>>
>>>> I'm not sure how valid my test is, or how much of an issue this really
>>>> is
>>>> in practice?
>>>>
>>>> Dean
>>>>
>>>
>>>
>>
>>

From tom.schindl at bestsolution.at  Fri Jan 18 08:31:58 2019
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 18 Jan 2019 09:31:58 +0100
Subject: [8u-dev announce] Future contributions to openjfx/8u-dev
In-Reply-To: <b6770928-4096-b290-13d2-079e3401573c@bestsolution.at>
References: <1b2b1803-5052-979b-f8f9-391661f327eb@oracle.com>
 <6786cef7-31a3-33c8-c4ee-f65e5ded30fc@bestsolution.at>
 <7cd363f0-7f2b-4758-796a-84cc1238af2c@oracle.com>
 <b6770928-4096-b290-13d2-079e3401573c@bestsolution.at>
Message-ID: <8ede472e-45ee-7e2f-068b-fa782a0bcf76@bestsolution.at>

Well maybe mirror was the wrong term - I think now that 8u-dev is force
and won't see any changes anymore. A one time dump is what we should
have somewhere on git/github.

Tom

On 18.01.19 09:27, Tom Schindl wrote:
> Hi,
> 
> Is there any documentation how the current javafxports mirror repository
> got created?
> 
> Some of our customer projects are going to be stuck on JavaFX-8 for the
> forseeable future and while we won't sign up for providing general
> support for JavaFX-8 it would be good to have a central place one can
> fork JavaFX-8 from.
> 
> Having a central place would allow (at least in theory) that
> modifications and patches from different people can be merged without to
> much manual work.
> 
> Tom
> 
> On 08.01.19 00:01, Kevin Rushforth wrote:
>> I'm not sure that an 8u-dev mirror would be suitable for the javafxports
>> project, but if someone wanted to set up such a mirror elsewhere they
>> could do so. It might be best left to the future maintainer (if any
>> suitable party steps forward) to determine whether and where to host a
>> git mirror.
>>
>> -- Kevin
>>
>>
>> On 12/21/2018 1:39 PM, Tom Schindl wrote:
>>> Hi,
>>>
>>> Could we get a mirror of 8u setup for github as well? I wanted to ask
>>> for that since some time but always forgot to do so.
>>>
>>> Tom
>>>
>>> On 21.12.18 22:32, Kevin Rushforth wrote:
>>>> As has been previously announced [1][2], Oracle will no longer
>>>> contribute to the JDK 8 Updates Project after the January 2019 quarterly
>>>> CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part
>>>> of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev
>>>> code line (8u-dev/rt repo) after JDK 8u202 ships.
>>>>
>>>> This means that Oracle will be stepping down as the maintainer of the
>>>> openjfx/8u-dev code line after January, and will call for a new
>>>> maintainer. If a suitable party steps forward to maintain the OpenJFX 8
>>>> Updates code line after the final Oracle-led JDK 8 Update release has
>>>> been published, we will discuss how to best enable such a transition on
>>>> this Project's mailing list.
>>>>
>>>> I wanted to send this before the holidays, although I realize it might
>>>> get lost in the shuffle, so I will resend it after the first of the
>>>> year, along with a formal call for interested parties who wish to put
>>>> their name forward as a maintainer for the openjfx/8u-dev release.
>>>>
>>>> -- Kevin
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html
>>>> [2]
>>>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html
>>>>
>>>>
>>
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From youngty1997 at gmail.com  Fri Jan 18 09:17:37 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 18 Jan 2019 03:17:37 -0600
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <d1ce54c216b402b37b698be3c24ff9ff@disroot.org>
References: <2025adc7-c8f9-4157-6665-7720320ed4bd@gmail.com>
 <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
 <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
 <fcf4d2e489f779304f6c4bab0dc15c09@disroot.org>
 <d1ce54c216b402b37b698be3c24ff9ff@disroot.org>
Message-ID: <b8261c2d-b52c-0c1a-8ce8-61399c63ec65@gmail.com>


On 1/17/19 12:55 PM, Siddhesh Rane wrote:
> January 16, 2019 11:31 PM, "Ty Young" <youngty1997 at gmail.com> wrote:
>
>> How else is percentage based UI sizing besides DoubleBinding(s)? Isn't column restraints just the
>> same thing but aligns everything to a column?
>>
>> I have to ask(again) as to why minWidth/maxWidth, minHeight/maxHeight, prefWidth/prefHeight aren't
>> read only if this is going to be an *always* realistically going to be an issue.
> Column constraints don't use any bindings, neither do any other layout panes.
> {min,pref,max} width/height are merely hints for a parent to layout the child. They are not the final authority on child size. The actual final size of a child is set by calling Node#resize on it, which is what the parent does during the Parent#layoutChildren call. During this call the parent knows about its own size and can split that space among the children.
> A rogue parent could completely ignore these hints and resize the child to whatever it wants.


The documentation on the sizing says that they override the computed size.


>
> On your second point, it is only an issue if you use it in the wrong way, without understanding.


Excuse me? There is no documentation AFAIK stating that this would ever 
be an issue nor would anyone look at the UI and think that a GridPane is 
necessary to achieve such a basic layout. The use of GridPane seems more 
like a hacky workaround for something JavaFX seemingly has no other way 
to achieve with more appropriate layout management nodes(VBox, HBox, 
etc) without side affects.


I wanted to place the buttons and Scrollpane in a horizontal fashion, so 
I used an HBox. I wanted to dynamically size the nodes based on a 
percentage of the window's total width/height, so I used property 
bindings to force content to the desired correct. If that causes issues 
then maybe all controls should get a supported percentage based way to 
set the width/height like GridPane's columns with appropriate layout 
nodes so people don't try doing this sort of thing.


> You bound the minWidth of a scrollpane's content to 85% of the scrollpane's widthProperty (which is actual width).
> When you resize the scrollpane to <85% of its original size, its content still has the old minWidth property which is greater than the current width of the scroll pane. So the scrollpane shows horizontal bar. This is not a bug. widthProperty is supposed to be valid after layout.


This explains the ScrollPane horizontal scrollbar glitching out but 
doesn't explain TableView's horizontal scrollbar.


>
> Use bindings for size if you want to do some advanced sizing. Like size matching unrelated nodes with different parents to get some visual effect. You could create a custom textarea that binds minWidth to the number of characters in the first line.
> I have never had a use case but someone else might.
> Use it for cases where there is no mutual dependency or "race condition".
>
>>> I saw your code and I can confirm this is the main cause.
>>> If you want a 15-85 % split, you should have used a GridPane with two columns with the given
>>> percentage constraints.
>> This works for the buttons/scrollpane but what about the subcontent? TableView's scrollbars also
>> glitch out in the exact same way.
> Set scrollpane to fit to width. Add a gridpane with a single column whose column width is set to 85%. Set gridpane alignment to center. Drop the bindings and your problems will be solved.


It isn't completely solved but it is better I guess. ScrollPane's 
horizontal bar no longer glitches out and resizing performance has 
increased majorly. TableView still glitches out from time to time and 
app content is still jumping all over the place. Bindings are still 
needed for the size of the main GridPane and other misc nodes. It seems 
to be a bug caused by indirect resizing of the table itself...


And the vertical scrollpane bar is missing from the Overview content. 
Setting the show policy to Always shows it being there where it should 
be and is usable(regardless of policy) via scroll wheel. No other 
section has this issue.


Font rendering is also still an issue...


>
>> SceneBuilder's lack of UI snapping compared to Netbean's Swing builder makes it incredibly
>> difficult to get anything remotely pixel perfect without banging your head against a wall. Separate
>> controller classes and FXML annotations everywhere isn't really desirable either. I originally
>> entertained the idea of doing it all in FXML only to quickly discard the idea.
> If you are talking about snapping like in aligning to other UI elements, then its there and you dont need it with the rought layout. If you mean snapping to pixels, JavaFX has it inbuilt and on by default.


It is but it is incomplete. Try resizing a Button in both SceneBuilder 
and Netbean's Swing builder to the bottom right after first snapping to 
the top left. The button will snap perfectly to both in the Swing 
builder but not SceneBuilder.


>
> Regards
> Siddhesh

From kevin.rushforth at oracle.com  Fri Jan 18 14:34:17 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 18 Jan 2019 06:34:17 -0800
Subject: JavaFX 11/TableView/Resize column to fit content
In-Reply-To: <00f901d4af3a$16c0b900$44422b00$@cmail.cz>
References: <00f901d4af3a$16c0b900$44422b00$@cmail.cz>
Message-ID: <ccfeab4e-a975-1912-02b2-8f1cf90b6017@oracle.com>

This is more relevant to the openjfx-dev alias, so I have redirected the 
thread there (with a "Bcc" of the -discuss alias).

There is currently no way to do this, but it is a known issue [1][2] 
that is under discussion.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8207957
[2] https://github.com/javafxports/openjdk-jfx/pull/289


On 1/18/2019 6:28 AM, Petr Nemecek wrote:
> Hi all,
>
> I'm migrating from Java 8 to Java 11 + JavaFX 11.
>
> I was using TableViewSkin.resizeColumnToFitContent in Java 8 in order to
> resize the width of a column to fit its content.
>
> As this methods is not available in JavaFX 11 anymore, is there any other
> way how to achieve this programatically?
>
> Many thanks,
>   Petr
>


From kevin.rushforth at oracle.com  Fri Jan 18 17:35:30 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 18 Jan 2019 09:35:30 -0800
Subject: RFR: JDK-8214185: Upgrade GStreamer to the latest (1.14.4) version
In-Reply-To: <897e6019-6ac5-7148-8736-8f8efb237394@oracle.com>
References: <897e6019-6ac5-7148-8736-8f8efb237394@oracle.com>
Message-ID: <b64af9c7-69f5-1c2e-2e28-49b189342e01@oracle.com>

+1

-- Kevin

On 1/17/2019 3:48 PM, Alexander Matveev wrote:
> Hi Kevin,
>
> Please review the following:
> https://bugs.openjdk.java.net/browse/JDK-8214185
>
> - Upgrade for GStreamer (1.14.4) and GLib (2.58.2).
>
> Thanks,
> Alexander


From siddheshrane at disroot.org  Fri Jan 18 18:13:40 2019
From: siddheshrane at disroot.org (Siddhesh Rane)
Date: Fri, 18 Jan 2019 18:13:40 +0000
Subject: JavaFX Content Rendering & Resizing and Font Bugs In Linux
In-Reply-To: <b8261c2d-b52c-0c1a-8ce8-61399c63ec65@gmail.com>
References: <b8261c2d-b52c-0c1a-8ce8-61399c63ec65@gmail.com>
 <2025adc7-c8f9-4157-6665-7720320ed4bd@gmail.com>
 <32c45e4a-3c54-b462-fd0e-e473a16c8028@gmail.com>
 <41181d90-c5c4-e6d8-b120-90c6621c3443@gmail.com>
 <2764fba17ca93d885b90c22d417da4a3@disroot.org>
 <ae89f300-70b7-f015-d785-96225b68eebc@gmail.com>
 <5e96ef55-1b0e-430b-8777-a7a41a2dd406@status6.com>
 <fcf4d2e489f779304f6c4bab0dc15c09@disroot.org>
 <d1ce54c216b402b37b698be3c24ff9ff@disroot.org>
Message-ID: <d6aebc8d4b506590727351530fb43246@disroot.org>

January 18, 2019 2:48 PM, "Ty Young" <youngty1997 at gmail.com> wrote:

> The documentation on the sizing says that they override the computed size.

Computed size refers to Region.USE_COMPUTED_SIZE which causes a node to compute its intrinsic or default size if given infinite space. Basically, you want a button with 4 characters of text to have smaller default size (min/pref/max width) than a button with say 20 chars. If anything is overridden, it is this "default" size, not the final laid out size, which is determined by the parent layout pane.

>> On your second point, it is only an issue if you use it in the wrong way, without understanding.
> 
> Excuse me? There is no documentation AFAIK stating that this would ever be an issue nor would
> anyone look at the UI and think that a GridPane is necessary to achieve such a basic layout. The
> use of GridPane seems more like a hacky workaround for something JavaFX seemingly has no other way
> to achieve with more appropriate layout management nodes(VBox, HBox, etc) without side affects.
>
> I wanted to place the buttons and Scrollpane in a horizontal fashion, so I used an HBox. I wanted
> to dynamically size the nodes based on a percentage of the window's total width/height, so I used
> property bindings to force content to the desired correct. If that causes issues then maybe all
> controls should get a supported percentage based way to set the width/height like GridPane's
> columns with appropriate layout nodes so people don't try doing this sort of thing.

There is also no documentation that uses Bindings for layout. All layout panes have been properly documented.
Using GridPane is not a hack because percentage sizing is another type of layout in itself. The only reason percentage feels basic and "seemingly simple" is because the Web has normalized it. But that is because the Web doesn't have layouts.
It simply tries to fit everything to the width of the parent and then calculates the height from reflow. What is a hack is using percentage based grids to create the illusion of having a layout. Percentage works because there is only one way in which size information flows: from main window down to child elements. Parent widths are known before hand (not heights, try setting height:100% to a div inside its height:auto parent).
In JavaFX, parent sizes and the entire size of the window can be "computed" from the child elements, because child size hints are independant on their own. Introducing percentages for controls or any other nodes breaks that property.
Read the -fx-min-width entry on the last row of Region docs at https://docs.oracle.com/javase/9/docs/api/javafx/scene/doc-files/cssref.html#region

>>> SceneBuilder's lack of UI snapping compared to Netbean's Swing builder makes it incredibly
>>> difficult to get anything remotely pixel perfect without banging your head against a wall. Separate
>>> controller classes and FXML annotations everywhere isn't really desirable either. I originally
>>> entertained the idea of doing it all in FXML only to quickly discard the idea.
>> 
>> If you are talking about snapping like in aligning to other UI elements, then its there and you
>> dont need it with the rought layout. If you mean snapping to pixels, JavaFX has it inbuilt and on
>> by default.
> 
> It is but it is incomplete. Try resizing a Button in both SceneBuilder and Netbean's Swing builder
> to the bottom right after first snapping to the top left. The button will snap perfectly to both in
> the Swing builder but not SceneBuilder.

If you need snapping in your design, then you are not doing layouts, you are drawing your UI. For the equivalent, add a button to an AnchorPane in SceneBuilder and right click the button to "Fit to parent". Watch AnchorPane Constraints in Layout tab to the right. Alternatively, add button to stack pane and set button max{width,height} to max value.

From personal experience I can say that a lot of your frustrations with JavaFX are caused due to 2 things:
- You are using your learned knowledge and concepts from Swing/HTML-CSS and applying them to JavaFX
- You have briefly walked through the JFX tutorials and then directly jumped into making one big app, instead of spending more time exploring with smaller examples.

When I was migrating from Swing to JFX, I was myself very confused and frustrated because sizing and layout didnt really work as I expected them to work. I was hand coding everything, essentially replicating what I had done in Swing. But JavaFX is different from platforms out there. Eventually I learned a lot from experimenting in Scene Builder and patiently reading the docs. I would recommend you to spend more time in SceneBuilder, at least for learning.

Regards
Siddhesh

From pruteanu at gmail.com  Sat Jan 19 20:38:32 2019
From: pruteanu at gmail.com (dprutean)
Date: Sat, 19 Jan 2019 21:38:32 +0100
Subject: JavaFx Canvas font rendering issue on 125% scale display
Message-ID: <CAFHJFzSwzdBqbJg5cyTfvTdTRAHuZitUat--38AHaKmR4YQFhg@mail.gmail.com>

Hello,
 This issue https://bugs.openjdk.java.net/browse/JDK-8215295
is related to Canvas graphicsContext.fillText() behaviour on a FullHD
notebook with 125% Windows scaling.

Maybe is possible to get it fixed, I try to use Canvas for diagrams and
text editor.

Best regards,
Dragos Pruteanu

From yuichi.sakuraba at gmail.com  Mon Jan 21 09:28:55 2019
From: yuichi.sakuraba at gmail.com (Yuichi Sakuraba)
Date: Mon, 21 Jan 2019 18:28:55 +0900
Subject: JavaFX 11 TextInputControl IM problem
Message-ID: <CAN+c61N2EqHWC=eWawZtrREUzUJtJH-zRXWZ2VKaJ91nnjak+A@mail.gmail.com>

Hi All,

I try to migrate from JavaFX 10 to JavaFX 11, but TextInputControl of
 JavaFX 11 doesn't deal with input method (Japanese) on Linux.

I use Ubuntu 18.04 and IBUS Mozc for input method.

I attached two images: one is case of JavaFX 10 and other is JavaFX 11.
JavaFX 10 controlled IM to change alphabet to Japanese character,
but JavaFX 11 didn't.

Here is test code:
---
public class IMTest extends Application {
    @Override
    public void start(Stage stage) throws Exception {
        TextField field = new TextField();
        Scene scene = new Scene(field, 300, 40);
        stage.setScene(scene);
stage.setTitle("Ver." + ManagementFactory.getRuntimeMXBean().getSpecVersion());
        stage.show();
    }
    public static void main(String... args) {
        launch(args);
    }
}
---

Are there any changes about IM in JavaFX 11?

Thanks,
Yuichi Sakuraba

From wookey.dean at gmail.com  Mon Jan 21 14:30:14 2019
From: wookey.dean at gmail.com (Dean Wookey)
Date: Mon, 21 Jan 2019 16:30:14 +0200
Subject: RFR: JDK-8205092: NullPointerException in
 PickResultChooser.processOffer
Message-ID: <CAKZ_BFjR1Nr3mrJeBjnKK=WqdwbDJfFJ5QrX-XR_P-i=Vprk6Q@mail.gmail.com>

Hi,

Please review the fix for JDK-8205092: NullPointerException in
PickResultChooser.processOffer
https://bugs.openjdk.java.net/browse/JDK-8205092
https://github.com/javafxports/openjdk-jfx/pull/353

Dean

From kevin.rushforth at oracle.com  Mon Jan 21 16:25:58 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 21 Jan 2019 08:25:58 -0800
Subject: HEADS-UP: FX 12-dev repo will fork from mainline on Friday, Jan 25
Message-ID: <ff1b3323-e66e-3710-ebea-fd2e44533a9b@oracle.com>

To: All OpenJFX Project Committers,

It's time to fork the openjfx/12-dev/rt stabilization repo from the 
jfx-dev/rt mainline. As you may recall, we delayed it past RDP1 (which 
would have matched what the JDK did), to make it a little easier for 
developers, but at the cost of having no place for developers to put new 
enhancements or less important bug fixes that we don't want or need in 
openjfx12.

We plan to fork the repo this Friday, Jan 25. I will send out a 
follow-up email once this is done. After the new 12-dev repo is open, 
the following will be in effect:

* Changes for openjfx12 will be pushed to the HG openjfx/12-dev/rt repo 
instead of openjfx/jfx-dev/rt

* openjfx/jfx-dev/rt will be open to accept enhancements or bug fixes 
for openjfx13

* The develop branch of the GitHub sandbox will be available for changes 
to either openjfx12 or openjfx13

* NOTE: I will periodically sync changes from 12-dev --> jfx-dev, so 
changes should be pushed to either 12-dev/rt or jfx-dev/rt, not both

* NOTE: we are still in RDP1 [1] until Feb 4, 2019 [2], so this repo 
fork does not in any way change the criteria for what can go into FX 12; 
what does change is where you push changesets that are intended for FX 12

Please let me know if you have any questions about this.

Thanks.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-January/023043.html
[2] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022761.html


From pruteanu at gmail.com  Tue Jan 22 09:31:31 2019
From: pruteanu at gmail.com (dprutean)
Date: Tue, 22 Jan 2019 10:31:31 +0100
Subject: TableView Commit on Focus Lost + Canvas Issue
Message-ID: <CAFHJFzSo6ezc6WY4Tj=ymHmoADExDpNFn2b-O7-O-TB0OVkEAQ@mail.gmail.com>

Hi JavaFx,

TableView is behaving different then Excel, for example, when the user
edits a cell and then click another cell. In JavaFx the editing is lost.
This is really an issue, in must of the cases users does not understand
why. This was planned in this issue for Java 10.
The issue is still open, can be please fixed ? Maybe a method
tableView.commitOnFocusLost(true) would be a great solution.

https://bugs.openjdk.java.net/browse/JDK-8089514

Also an issue regarding Canvas and gr.fillText(), will be great to have it
done:

https://bugs.openjdk.java.net/browse/JDK-8215295

Are we allowed to specify here some applications we work on ?
Is just nice to have idea of JavaFx applications.
I ask first, not to be blamed.

Best regards,
Dragos Pruteanu

From arunprasad.rajkumar at oracle.com  Tue Jan 22 17:52:26 2019
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Tue, 22 Jan 2019 23:22:26 +0530
Subject: RFR 8213806: WebView - JVM crashes for given HTML
Message-ID: <9BC41557-F639-40F8-AC77-E4C5D4D88D02@oracle.com>

Hi,

Please review the following PR which fixes JDK-8213806.

https://github.com/javafxports/openjdk-jfx/pull/355

https://bugs.openjdk.java.net/browse/JDK-8213806

Thanks,
Arun

From florian.kirmaier at gmail.com  Thu Jan 24 15:56:18 2019
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Thu, 24 Jan 2019 19:56:18 +0400
Subject: RFR: 8217492: memory leak after the event WindowEvent.DESTROY
Message-ID: <CA+4mSqZahdd9bmUXpVQ6hF9iOG07nXeJWuQvnX-f+PduOa5_oA@mail.gmail.com>

Hi everyone,

I've found a rare happening memory leak while working on JPro
<https://www.jpro.one/>.

Please review the fix for The Bug:
ticket:
https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8217492?filter=allopenissues

pull request: https://github.com/javafxports/openjdk-jfx/pull/357

Florian Kirmaier

From kevin.rushforth at oracle.com  Fri Jan 25 13:56:05 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 25 Jan 2019 05:56:05 -0800
Subject: FX 12-dev repo is now forked from mainline
In-Reply-To: <ff1b3323-e66e-3710-ebea-fd2e44533a9b@oracle.com>
References: <ff1b3323-e66e-3710-ebea-fd2e44533a9b@oracle.com>
Message-ID: <ee92ec06-3d9c-b636-4236-9895beb73cfc@oracle.com>

This is now done. To summarize:

- The openjfx/12-dev/rt repo is now open for pushing changesets for FX 
12 that meet the RDP1 criteria as outlined below.

- The openjfx/jfx-dev/rt repo is now available for pushing changesets 
for FX 13.

- I will periodically sync 12-dev --> jfx-dev (meaning that developers 
should push to one or the other, not both)

- The develop branch of the javafxports/openjdk-jfx GitHub sandbox may 
be used for either FX 12 or FX 13 changes

-- Kevin


On 1/21/2019 8:25 AM, Kevin Rushforth wrote:
> To: All OpenJFX Project Committers,
>
> It's time to fork the openjfx/12-dev/rt stabilization repo from the 
> jfx-dev/rt mainline. As you may recall, we delayed it past RDP1 (which 
> would have matched what the JDK did), to make it a little easier for 
> developers, but at the cost of having no place for developers to put 
> new enhancements or less important bug fixes that we don't want or 
> need in openjfx12.
>
> We plan to fork the repo this Friday, Jan 25. I will send out a 
> follow-up email once this is done. After the new 12-dev repo is open, 
> the following will be in effect:
>
> * Changes for openjfx12 will be pushed to the HG openjfx/12-dev/rt 
> repo instead of openjfx/jfx-dev/rt
>
> * openjfx/jfx-dev/rt will be open to accept enhancements or bug fixes 
> for openjfx13
>
> * The develop branch of the GitHub sandbox will be available for 
> changes to either openjfx12 or openjfx13
>
> * NOTE: I will periodically sync changes from 12-dev --> jfx-dev, so 
> changes should be pushed to either 12-dev/rt or jfx-dev/rt, not both
>
> * NOTE: we are still in RDP1 [1] until Feb 4, 2019 [2], so this repo 
> fork does not in any way change the criteria for what can go into FX 
> 12; what does change is where you push changesets that are intended 
> for FX 12
>
> Please let me know if you have any questions about this.
>
> Thanks.
>
> -- Kevin
>
> [1] 
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-January/023043.html
> [2] 
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022761.html
>


From kevin.rushforth at oracle.com  Fri Jan 25 15:55:15 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 25 Jan 2019 07:55:15 -0800
Subject: [13] RFR: JDK-8215567: Change JavaFX release version to 13
Message-ID: <b5a845d8-1700-a5f7-3817-f99937c140eb@oracle.com>

Hi Phil or Johan,

Please review the following to bump the JavaFX release version to 13, 
now that we have forked the 12-dev stabilization repo:

https://bugs.openjdk.java.net/browse/JDK-8215567
http://cr.openjdk.java.net/~kcr/8215567/webrev/

Thanks.

-- Kevin


From nlisker at gmail.com  Sun Jan 27 08:18:12 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 27 Jan 2019 10:18:12 +0200
Subject: Review Request: JDK-8217470: Upgrade Direct3D9 shader model from 2.0
 to 3.0
Message-ID: <CA+0ynh9MPn6eBRGYtKwx8B34_JZqiU9iOnntzjoG6XwnEiQTbQ@mail.gmail.com>

Hi,

Please review the fix for:

https://bugs.openjdk.java.net/browse/JDK-8217470
http://cr.openjdk.java.net/~nlisker/8217470/webrev.00/

Thanks,
Nir

From johan.vos at gluonhq.com  Sun Jan 27 13:41:22 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sun, 27 Jan 2019 14:41:22 +0100
Subject: mvn exec:java
Message-ID: <CABxFH2G+RvzgSjdmQvEgqA5deXRt5SU8ONdYYfveDM+PyKSpig@mail.gmail.com>

While looking into https://github.com/javafxports/openjdk-jfx/issues/316 (crash
in webkit when using maven), it became clear that the default way of
starting java applications in maven is not really the recommended way
(supplying module path and modules).

However, mvn exec:java is very widely used to launch Java applications, and
I'm thinking a warning mechanism might be appropriate.

If you use the regular Java launcher that is part of OpenJDK, an error will
be reported if you try to launch the JavaFX framework while the
java.graphics module is not found [1].

Maven bypasses this launchers (that is, the JDK launcher only complains
when the main class extends Application, and the maven main class does not
extend Application) but this can lead to problems later at runtime.

We could do a check on modularity during javafx platform initialisation,
but this will of course break all applications that currently bypass the
Java launcher and I'm not sure how widely those are used.

- Johan

[1]
http://hg.openjdk.java.net/jdk/jdk/file/a772e65727c5/src/java.base/share/classes/sun/launcher/LauncherHelper.java#l997

From kevin.rushforth at oracle.com  Wed Jan 30 00:10:35 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 29 Jan 2019 16:10:35 -0800
Subject: REMINDER: OpenJFX 12 Rampdown Phase 2 (RDP2) coming on Monday, Feb 4
Message-ID: <077ffaa3-dc90-14bb-ad1c-6a2500356555@oracle.com>

As a reminder, OpenJFX 12 will hit Rampdown Phase 2 (RDP2) on Monday, 
February 4 [1] at 23:59 Pacific time.

During RDP2, the focus will be on stabilizing the release. Most fixes 
should go into jfx-dev for openjfx13. We will have a process very 
similar to the JDK's process [2] for fixing bugs in openjfx 12 during 
RDP2: P1-P2 bugs can be fixed with approval from a project lead; bugs in 
docs, tests, and demos of any priority can be fixed during RDP2 without 
explicit approval (other than the usual code review).

We will continue to periodically sync changes from 12-dev --> jfx-dev 
for the duration of the release, so as a reminder, any changes that are 
approved to go into 12 should be pushed into 12-dev and then will be 
synced into jfx-dev without the developer needing to push explicitly in 
both places.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022761.html
[2] http://openjdk.java.net/jeps/3


From nlisker at gmail.com  Thu Jan 31 20:49:44 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 31 Jan 2019 22:49:44 +0200
Subject: Public API for PointLight attenuation
Message-ID: <CA+0ynh9E=9_FYiT_yMtk1Hszzjn_huPRdA7z-MBGnAMTQVzxpw@mail.gmail.com>

Hi,

This API will be used as the CSR for JDK-8217472
<https://bugs.openjdk.java.net/browse/JDK-8217472>. It is posted on GitHub:

https://github.com/javafxports/openjdk-jfx/issues/256#issuecomment-459499308

Any comments are welcome.

Thanks,
Nir

From t.rauchhaupt at googlemail.com  Fri Jan 25 11:31:39 2019
From: t.rauchhaupt at googlemail.com (Thimo von Rauchhaupt)
Date: Fri, 25 Jan 2019 12:31:39 +0100
Subject: Two bugs in JFXPanel (OpenJFX 11.01)
Message-ID: <000a01d4b4a1$8a4af6d0$9ee0e470$@gmail.com>

Hi everyone,

 

I am quite unsure if I made everything right. So if not, please tell me how
to contribute the project with bugreports / -fixes.

 

I found two bugs in the JFXPanel and filed issues at the github javafxports
page:

https://github.com/javafxports/openjdk-jfx/issues/356 - Single click becomes
double click under raceconditions if focus must be gained

https://github.com/javafxports/openjdk-jfx/issues/359 - Unnecessary Up and
Downscaling in multi monitor environments.

 

Best regards,

Thimo