Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight

[Nir Lisker]

On Wed, 9 Jun 2021 18:46:16 GMT, Kevin Rushforth  wrote:

> I intend to test this alone and in connection with your PR.

Alright. I'll keep an eye on this PR.

-

PR: https://git.openjdk.java.net/jfx/pull/531

Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight

[Andreas Heger]

On Wed, 9 Jun 2021 18:46:16 GMT, Kevin Rushforth  wrote:

> @andreas-heger Welcome to the `jfx` project. At a quick glance, the fix looks 
> promising. Have you tested this on Windows with Hi-DPI to make sure there is 
> no impact?

No, I only have got MacOS on retina / non retina and a non Hi-DPI Ubuntu system 
available for tests, but no Windows.

> Would you be able add an automated test case that fails (only on Mac retina) 
> without the fix and passes (on all platforms) with your fix? Hi-DPI fixes are 
> often tricky to test in an automated test, so if not, we can use the existing 
> manual test.

I'm not very experienced in automated tests in general and a test which 
verifies graphic output might be really challenging. I can take a look at it, 
but please don't expect any results for the next couple of weeks, or any at all.

-

PR: https://git.openjdk.java.net/jfx/pull/531

Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight

[Kevin Rushforth]

On Wed, 9 Jun 2021 18:22:31 GMT, Andreas Heger 
 wrote:

> The inconsistent illumination happens on Macs with retina displays only if 
> the 3D shape is placed in a SubScene. The light sources are located with 
> wrong coordinates in sub scenes and this causes a different illumination. The 
> wrong coordinates for the light sources come from the fact that the retina 
> pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in 
> SubScenes and this should resolve the bug 
> [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

@andreas-heger Welcome to the `jfx` project. At a quick glance, the fix looks 
promising. Have you tested this on Windows with Hi-DPI to make sure there is no 
impact? Would you be able add an automated test case that fails (only on Mac 
retina) without the fix and passes (on all platforms) with your fix? Hi-DPI 
fixes are often tricky to test in an automated test, so if not, we can use the 
existing manual test.

@nlisker this is the same problem I noted while testing PR #334. Clearly I had 
forgotten that it was not only a preexisting bug, but a known bug that was 
already filed. I intend to test this alone and in connection with your PR.

-

PR: https://git.openjdk.java.net/jfx/pull/531

RFR: 8255015: Inconsistent illumination of 3D shape by PointLight

[Andreas Heger]

The inconsistent illumination happens on Macs with retina displays only if the 
3D shape is placed in a SubScene. The light sources are located with wrong 
coordinates in sub scenes and this causes a different illumination. The wrong 
coordinates for the light sources come from the fact that the retina pixel 
scale factors are not used in a SubScene.

With this pull request, the retina pixel scale factors will be also used in 
SubScenes and this should resolve the bug 
[https://bugs.openjdk.java.net/browse/JDK-8255015](url)

-

Commit messages:
 - 8255015: Copy pixel scale factors from graphics object to subscene graphics 
so that the position of lights will be scaled correctly on retina displays

Changes: https://git.openjdk.java.net/jfx/pull/531/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255015
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

Withdrawn: 8255015: Inconsistent illumination of 3D shape by PointLight

[Andreas Heger]

On Wed, 9 Jun 2021 18:02:30 GMT, Andreas Heger 
 wrote:

> The inconsistent illumination happens on Macs with retina displays only if 
> the 3D shape is placed in a SubScene. The light sources are located with 
> wrong coordinates in sub scenes and this causes a different illumination. The 
> wrong coordinates for the light sources come from the fact that the retina 
> pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in 
> SubScenes and this should resolve the bug
> [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jfx/pull/530

Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v2]

[Andreas Heger]

> The inconsistent illumination happens on Macs with retina displays only if 
> the 3D shape is placed in a SubScene. The light sources are located with 
> wrong coordinates in sub scenes and this causes a different illumination. The 
> wrong coordinates for the light sources come from the fact that the retina 
> pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in 
> SubScenes and this should resolve the bug
> [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has refreshed the contents of this pull request, and previous 
commits have been removed. The incremental views will show differences compared 
to the previous content of the PR.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/530/files
  - new: https://git.openjdk.java.net/jfx/pull/530/files/66b361a0..ca250364

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=530&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=530&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/530.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/530/head:pull/530

PR: https://git.openjdk.java.net/jfx/pull/530

RFR: 8255015: Inconsistent illumination of 3D shape by PointLight

[Andreas Heger]

The inconsistent illumination happens on Macs with retina displays only if the 
3D shape is placed in a SubScene. The light sources are located with wrong 
coordinates in sub scenes and this causes a different illumination. The wrong 
coordinates for the light sources come from the fact that the retina pixel 
scale factors are not used in a SubScene.

With this pull request, the retina pixel scale factors will be also used in 
SubScenes and this should resolve the bug
[https://bugs.openjdk.java.net/browse/JDK-8255015](url)

-

Commit messages:
 - 8255015: Copy pixel scale factors from graphics object to subscene graphics 
so that the position of lights will be scaled correctly on retina displays

Changes: https://git.openjdk.java.net/jfx/pull/530/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=530&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255015
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/530.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/530/head:pull/530

PR: https://git.openjdk.java.net/jfx/pull/530

Re: RFR: 8267551: Support loading images from inline data-URIs [v17]

[Michael Strauß]

On Wed, 9 Jun 2021 14:20:41 GMT, Michael Strauß  wrote:

>> This PR adds support for loading images from [inline data 
>> URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely 
>> supported by web browsers. This enables developers to package small images 
>> in CSS files, rather than separately deploying the images alongside the CSS 
>> file.
>
> Michael Strauß has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   doc

I've updated the CSR with the documentation diffs.

-

PR: https://git.openjdk.java.net/jfx/pull/508

Re: RFR: 8267551: Support loading images from inline data-URIs [v16]

[Michael Strauß]

On Wed, 9 Jun 2021 13:18:29 GMT, Kevin Rushforth  wrote:

>> Michael Strauß has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   added comment, simplified DataURI.matchScheme()
>
> modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 95:
> 
>> 93:  * the protocol handlers that are registered for the application.
>> 94:  *
>> 95:  * If a URL uses the "data" scheme, the data must be base64-encoded
> 
> I think these two sentences should be in the same paragraph.

Ok.

-

PR: https://git.openjdk.java.net/jfx/pull/508

Re: RFR: 8267551: Support loading images from inline data-URIs [v17]

[Michael Strauß]

> This PR adds support for loading images from [inline data 
> URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely 
> supported by web browsers. This enables developers to package small images in 
> CSS files, rather than separately deploying the images alongside the CSS file.

Michael Strauß has updated the pull request incrementally with one additional 
commit since the last revision:

  doc

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/508/files
  - new: https://git.openjdk.java.net/jfx/pull/508/files/e490cc04..ed498ef6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=15-16

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/508.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508

PR: https://git.openjdk.java.net/jfx/pull/508

Re: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2]

[Michael Strauß]

On Wed, 9 Jun 2021 13:01:17 GMT, Kevin Rushforth  wrote:

>> Michael Strauß has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - wording
>>  - Re-ordered methods
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8167:
> 
>> 8165: /**
>> 8166:  * Indicates whether this {@code Node} should visibly indicate 
>> focus.
>> 8167:  * This flag is set when a node acquired input focus via keyboard 
>> navigation,
> 
> `acquired` --> `acquires`

Done.

-

PR: https://git.openjdk.java.net/jfx/pull/475

Re: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2]

[Michael Strauß]

> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as 
> well as the corresponding `:focus-visible` and `:focus-within` CSS 
> pseudo-classes.

Michael Strauß has updated the pull request incrementally with two additional 
commits since the last revision:

 - wording
 - Re-ordered methods

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/475/files
  - new: https://git.openjdk.java.net/jfx/pull/475/files/7b3efd29..cf1daa2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=00-01

  Stats: 65 lines in 2 files changed: 35 ins; 30 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/475.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475

PR: https://git.openjdk.java.net/jfx/pull/475

Re: RFR: 8267551: Support loading images from inline data-URIs [v16]

[Kevin Rushforth]

On Sat, 5 Jun 2021 17:31:17 GMT, Michael Strauß  wrote:

>> This PR adds support for loading images from [inline data 
>> URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely 
>> supported by web browsers. This enables developers to package small images 
>> in CSS files, rather than separately deploying the images alongside the CSS 
>> file.
>
> Michael Strauß has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   added comment, simplified DataURI.matchScheme()

The docs look good. I left one minor comment inline.

You can update the CSR when ready. As I mentioned in a comment in the CSR, the 
`Specification` section should consist of the diffs to the API documentation. 
Make sure you note what API element (e.g., class doc, `Image(String url)` 
constructor, and so forth) each change is for, if it isn't clear from the 
diffs. You can omit the removal of the `` html tags and the change from 
`example.` to `example:` from the diffs in the CSR.

modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 95:

> 93:  * the protocol handlers that are registered for the application.
> 94:  *
> 95:  * If a URL uses the "data" scheme, the data must be base64-encoded

I think these two sentences should be in the same paragraph.

-

PR: https://git.openjdk.java.net/jfx/pull/508

Re: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses

[Kevin Rushforth]

On Wed, 21 Apr 2021 18:17:27 GMT, Michael Strauß  wrote:

> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as 
> well as the corresponding `:focus-visible` and `:focus-within` CSS 
> pseudo-classes.

I took an initial pass at the API docs. I have a couple global comments.

First, can you reorder the properties and their associated methods such that 
they are grouped together? If the docs are on the (private) field, which is 
what we usually do, it should be followed immediately by the associated setter 
(if any), getter, and property methods.

The order should be:


/**
 * EXISTING API DOCS FOR FOCUSED PROPERTY
 */
private FocusPropertyBase focused;

protected final void setFocused(boolean value) {

public final boolean isFocused() {

public final ReadOnlyBooleanProperty focusedProperty() {

/**
 * API DOCS FOR NEW FOCUSVISIBLE PROPERTY
 */
private FocusPropertyBase focusVisible;

public final boolean isFocusVisible() {

public final ReadOnlyBooleanProperty focusVisibleProperty() {

...


Second, the two new properties need both a `@defaultValue` and an `@since NN` 
tag. You can optimistically use `@since 17` or you can use `@since 18` (the 
latter is more likely).

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8167:

> 8165: /**
> 8166:  * Indicates whether this {@code Node} should visibly indicate 
> focus.
> 8167:  * This flag is set when a node acquired input focus via keyboard 
> navigation,

`acquired` --> `acquires`

-

PR: https://git.openjdk.java.net/jfx/pull/475

Re: [External] : Re: Convenience factories for Border and Background

[Bruce Johnson]

I very much like the idea of a simpler way to create Borders and Backgrounds, 
but once you get beyond the original proposal of Border.stroke(Paint stroke), 
it  seems like a case where a fluent interface would be useful. The 
alternatives of multiple argument constructors just start getting back into 
more complexity and debates about who needs what combination of options 
supported.
 

So if one wanted a simple border:

Border.stroke(Color.RED)

but if you want to set width and styles you could do something like:

   Border.stroke(Color.RED).width(3).dotted();

—Bruce

> On Jun 9, 2021, at 7:59 AM, John Hendrikx  wrote:
> 
> I'm not entirely convinced taking width is all that useful. The (final) pxiel 
> width of a border is normally a calculated value based on the chosen unit and 
> scaling needs of the platform.
> 
> A lot of methods in JavaFX work with pixel values only, while for proper 
> scaling I often find myself needing a different unit, in which case CSS is 
> the only option.
> 
> Perhaps however this is a different issue, as it would apply to much more 
> than just borders.
> 
> --John
> 
> On 08/06/2021 17:29, Scott Palmer wrote:
>> +1 for having a variant that takes a width. Colour, width, and radius are 
>> the main parameters I need, so a variant that takes all three would help:
>> 
>> Border.stroke(Paint p, double width, double radii)
>> 
>> (Though to be honest for my larger projects most of the time this stuff is 
>> set in a style sheet.  It’s smaller tools and utilities that I find this 
>> particularly tedious as the verbosity of the code becomes annoying.)
>> 
>> Scott
>> 
>>> On Jun 8, 2021, at 9:59 AM, Kevin Rushforth  
>>> wrote:
>>> 
>>> I think that the convenience methods should just cover the most common 
>>> cases, so I'd rather skip the dotted and dashed variants. It is a good 
>>> question as to whether there ought to be a variant that takes width. I 
>>> wouldn't do that as the only method, though. I'd lean towards not taking 
>>> the width. Once you start getting into more parameters you can just use the 
>>> constructors without much more trouble.
>>> 
>>> As for the names, I have a slight preference for Border.stroke and 
>>> Background.fill.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 6/8/2021 4:25 AM, Nir Lisker wrote:
 Are dashed and dotted used frequently? I find that I only use solid unless 
 I'm doing something fancy.
 
 On Tue, Jun 8, 2021 at 5:21 AM Michael Strauß >>> > wrote:
 
   What do you think about this variation?
 
   Border.solid(Paint color, double width) ->
   new Border(new BorderStroke(color, BorderStrokeStyle.SOLID,
   null, new BorderWidths(width)))
 
   Border.dashed(Paint color, double width)  ->
   new Border(new BorderStroke(color, BorderStrokeStyle.DASHED,
   null, new BorderWidths(width)))
 
   Border.dotted(Paint color, double width) ->
   new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED,
   null, new BorderWidths(width)))
 
   Background.fill(Paint color) ->
   new BackgroundFill(color, null, null)
 
   This gives developers a good deal of customizability before needing to
   fall back to using constructors.
 
 
   Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker
   mailto:nlis...@gmail.com>>:
   >
   > The new API:
   >
   > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)`
   that does
   > `new Border(new BorderStroke(Paint stroke ,
   BorderStrokeStyle.SOLID, null,
   > null));`
   > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)`
   that does
   > `new Background(new BackgroundFill(Paint fill, null, null));`
   >
   > I don't mind either name choice.
   >
 
>>> 
>> 

Re: [External] : Re: Convenience factories for Border and Background

[John Hendrikx]

I'm not entirely convinced taking width is all that useful. The (final) 
pxiel width of a border is normally a calculated value based on the 
chosen unit and scaling needs of the platform.


A lot of methods in JavaFX work with pixel values only, while for proper 
scaling I often find myself needing a different unit, in which case CSS 
is the only option.


Perhaps however this is a different issue, as it would apply to much 
more than just borders.


--John

On 08/06/2021 17:29, Scott Palmer wrote:

+1 for having a variant that takes a width. Colour, width, and radius are the 
main parameters I need, so a variant that takes all three would help:

 Border.stroke(Paint p, double width, double radii)

(Though to be honest for my larger projects most of the time this stuff is set 
in a style sheet.  It’s smaller tools and utilities that I find this 
particularly tedious as the verbosity of the code becomes annoying.)

Scott


On Jun 8, 2021, at 9:59 AM, Kevin Rushforth  wrote:

I think that the convenience methods should just cover the most common cases, 
so I'd rather skip the dotted and dashed variants. It is a good question as to 
whether there ought to be a variant that takes width. I wouldn't do that as the 
only method, though. I'd lean towards not taking the width. Once you start 
getting into more parameters you can just use the constructors without much 
more trouble.

As for the names, I have a slight preference for Border.stroke and 
Background.fill.

-- Kevin


On 6/8/2021 4:25 AM, Nir Lisker wrote:

Are dashed and dotted used frequently? I find that I only use solid unless I'm 
doing something fancy.

On Tue, Jun 8, 2021 at 5:21 AM Michael Strauß mailto:michaelstr...@gmail.com>> wrote:

   What do you think about this variation?

   Border.solid(Paint color, double width) ->
   new Border(new BorderStroke(color, BorderStrokeStyle.SOLID,
   null, new BorderWidths(width)))

   Border.dashed(Paint color, double width)  ->
   new Border(new BorderStroke(color, BorderStrokeStyle.DASHED,
   null, new BorderWidths(width)))

   Border.dotted(Paint color, double width) ->
   new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED,
   null, new BorderWidths(width)))

   Background.fill(Paint color) ->
   new BackgroundFill(color, null, null)

   This gives developers a good deal of customizability before needing to
   fall back to using constructors.


   Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker
   mailto:nlis...@gmail.com>>:
   >
   > The new API:
   >
   > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)`
   that does
   > `new Border(new BorderStroke(Paint stroke ,
   BorderStrokeStyle.SOLID, null,
   > null));`
   > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)`
   that does
   > `new Background(new BackgroundFill(Paint fill, null, null));`
   >
   > I don't mind either name choice.
   >

Re: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene [v2]

[Ajit Ghaisas]

On Tue, 8 Jun 2021 11:51:32 GMT, Ambarish Rapte  wrote:

>> Issue:
>> There are several issues related to Accelerator of MenuItem of a ConextMenu 
>> set on Control.
>> 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is 
>> removed from Scene
>> 2. Accelerator is not updated correctly when the Control is removed from a 
>> Scene and Added to a different Scene
>> 3. Accelerator is not removed from Scene when the anchor node is removed 
>> from Scene and then it's ContextMenu is set to null
>> 
>> Fix:
>> The accelerator should be added or removed correctly according to the Scene 
>> property of the anchor node. 
>> The issue#3 in above list is only fixed for Button and fails for other 
>> Controls. A test is added for this scenario and I shall report a new issue 
>> to address it.
>> Added tests that fails before and pass after the fix.
>
> Ambarish Rapte has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   update @ignore() with bugid

Marked as reviewed by aghaisas (Reviewer).

-

PR: https://git.openjdk.java.net/jfx/pull/515

[jfx11u] Integrated: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096

[Johan Vos]

On Tue, 8 Jun 2021 08:37:45 GMT, Johan Vos  wrote:

> …xception: Index 4096 out of bounds for length 4096
> 
> Reviewed-by: kcr, arapte

This pull request has now been integrated.

Changeset: db9b1b74
Author:Johan Vos 
URL:   
https://git.openjdk.java.net/jfx11u/commit/db9b1b74408a78353af331a048c9b7165c143cec
Stats: 130 lines in 2 files changed: 118 ins; 1 del; 11 mod

8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: 
Index 4096 out of bounds for length 4096

Backport-of: 7b7050c46299c0e6771ae02fbb5ceaf22104d3e4

-

PR: https://git.openjdk.java.net/jfx11u/pull/25

[jfx11u] Integrated: 8210199: [linux / macOS] fileChooser can't handle emojis

[Johan Vos]

On Tue, 8 Jun 2021 08:34:30 GMT, Johan Vos  wrote:

> Reviewed-by: pbansal, kcr

This pull request has now been integrated.

Changeset: 259cd4f9
Author:Johan Vos 
URL:   
https://git.openjdk.java.net/jfx11u/commit/259cd4f91b050263a178079966b5f71e5a21b207
Stats: 15 lines in 2 files changed: 12 ins; 0 del; 3 mod

8210199: [linux / macOS] fileChooser can't handle emojis

Backport-of: aebac072b1919e68f7732de929dc085d00c62e92

-

PR: https://git.openjdk.java.net/jfx11u/pull/24

[jfx11u] Integrated: 8216377: JavaFX: memoryleak for initial nodes of Window

[Johan Vos]

On Tue, 8 Jun 2021 07:42:19 GMT, Johan Vos  wrote:

> 8207837: Indeterminate ProgressBar does not animate if content is added after 
> scene is set on window
> 
> Add or remove the windowShowingChangedListener when the scene changes
> 
> Reviewed-by: arapte, kcr

This pull request has now been integrated.

Changeset: 8af39d66
Author:Johan Vos 
URL:   
https://git.openjdk.java.net/jfx11u/commit/8af39d66924ec1a958894c2b10ee50285f21e251
Stats: 120 lines in 2 files changed: 119 ins; 0 del; 1 mod

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

Add or remove the windowShowingChangedListener when the scene changes

Backport-of: e21606d3a1b73cd4b44383babc750a4b4721edfd

-

PR: https://git.openjdk.java.net/jfx11u/pull/23