From arapte at openjdk.java.net  Fri May  1 10:28:55 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 1 May 2020 10:28:55 GMT
Subject: RFR: 8237504: Update copyright header for files modified in 2020
In-Reply-To: <xvnXZF1AhH8O2jyuXwp7bX2hpUyEYOcoTNAAEJXlnBs=.cafa4cb2-4073-4d36-a973-0fedd4590a9f@github.com>
References: <xvnXZF1AhH8O2jyuXwp7bX2hpUyEYOcoTNAAEJXlnBs=.cafa4cb2-4073-4d36-a973-0fedd4590a9f@github.com>
Message-ID: <7hGEvHcgS9P0YwL3pjMbWQS7vfaj4KIIeyvZ1mbgyyk=.17133da4-1d86-4459-993c-736255f48cf5@github.com>

On Thu, 30 Apr 2020 22:49:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update last modified year of copyright headers for files modified in 2020.

Marked as reviewed by arapte (Reviewer).

-------------

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

From kcr at openjdk.java.net  Fri May  1 11:26:05 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 1 May 2020 11:26:05 GMT
Subject: [Integrated] RFR: 8237504: Update copyright header for files
 modified in 2020
In-Reply-To: <xvnXZF1AhH8O2jyuXwp7bX2hpUyEYOcoTNAAEJXlnBs=.cafa4cb2-4073-4d36-a973-0fedd4590a9f@github.com>
References: <xvnXZF1AhH8O2jyuXwp7bX2hpUyEYOcoTNAAEJXlnBs=.cafa4cb2-4073-4d36-a973-0fedd4590a9f@github.com>
Message-ID: <iRX4R8hKa_X24uVvmAjYiXjgVuNAaDX9y_ZNxJlrxC4=.36081f09-90cf-4513-82d0-3cc772b0a767@github.com>

On Thu, 30 Apr 2020 22:49:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update last modified year of copyright headers for files modified in 2020.

This pull request has now been integrated.

Changeset: 2b9eb52e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/2b9eb52e
Stats:     144 lines in 144 files changed: 0 ins; 0 del; 144 mod

8237504: Update copyright header for files modified in 2020

Reviewed-by: arapte

-------------

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

From kcr at openjdk.java.net  Fri May  1 12:35:47 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 1 May 2020 12:35:47 GMT
Subject: [Rev 03] RFR: 8242548: Wrapped labeled controls using
 -fx-line-spacing cut text off
In-Reply-To: <hHIeTvdz3LP2jHSfnUX3b_NB3xEcUXB9nat0g94wNwk=.49c40cb3-9d8f-4daa-a35a-fc7abf9a49e1@github.com>
References: <fITqSHYVPaCgMLBQjDJyU4Spp31LMRrxRdF8sD-JJec=.b60e407c-0d0b-4d84-bba5-f00711bac67d@github.com>
 <hHIeTvdz3LP2jHSfnUX3b_NB3xEcUXB9nat0g94wNwk=.49c40cb3-9d8f-4daa-a35a-fc7abf9a49e1@github.com>
Message-ID: <S0R0eIoNBJ5aWYURVS7dARmGiLQLJ7lQ3d99ypcDMlM=.ed6fb023-ad68-4bfd-89c1-3fe68330aa3f@github.com>

On Mon, 27 Apr 2020 14:02:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This is a solution for 8242548.  There was zero test coverage, so I added a few tests for this as well.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment

Marked as reviewed by kcr (Lead).

-------------

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

From jvos at openjdk.java.net  Fri May  1 14:46:00 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 1 May 2020 14:46:00 GMT
Subject: RFR: 8176499: Dependence on java.util.Timer freezes screen when
 OS time resets backwards
In-Reply-To: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
References: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
Message-ID: <x14dpTzPhXvNMSoYrgJGBMmDCWwMDaNvEjrcz3AFRsI=.e63ee2ce-17cb-47d1-9278-ef212355bffd@github.com>

On Wed, 19 Feb 2020 19:14:08 GMT, Dell Green <github.com+12861109+dellgreen at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8176499
> 
> This pull request fixes a long standing issue in the MonocleTimer class whereby it has a dependency on the
> java.uti.Timer class which is dependent on system time and can cause UI freezes for seconds/minutes/hours/days/years
> dependent upon how far back in time the system clock is set by either a user manually or NTP. This looks like it is
> because the Timer class will wait for (executionTime - currentTime) before proceeding if a task hasn't fired yet.
> https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553  For a
> long running embedded device with a UI like IOT devices this is pretty disastrous. We recently re-discovered this issue
> whilst testing such a device before going into production.
> The MonocleTimer class is used by MonocleApplication and QuantumToolkit class to create its pulseTimer for emebdded
> systems and sets it up to fire periodically inline with the requested pulse frequency which by default is 60Hz
> resulting in a pulse interval of 16ms.   It is well documented that for implementations that wish to measure elapsed
> time ScheduledThreadPoolExecutor should be used as a replacement for java.util.Timer class.
> Java Concurrency In Practice:
> https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf (page 77)
> 
> "The Timer facility manages the execution of deferred ("run this task in 100 ms") and periodic ("run this task every
> 10ms") tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its
> replacement."  With the original implementation, if I set the date.time back 8 years for example the UI freezes up
> indefinitely (I cant wait 8 years). Repeating the same test with the proposed implementation has no affect on the UI
> and it runs as normal.  The proposed solution has been tested on an Arm iMX6 board.
> 
> Whist testing in isolation the MonocleTimer class with no work to do on each pulse, it looks like the change from Timer
> class to ScheduledThreadPoolExecutor also has brought with it a greater accuracy of when the pulses are fired.
> The following results were observed when running MonocleTimer at 60Hz for 1 minute. It appears that we get a higher
> frequency of pulses hitting the 16ms mark with the replacement solution
> 
> x86-64 linux desktop:
> 
> ---- Timer class ----
> NumSamples: 3599
> Mean: 16.230063906640734
> StdDev: 0.45021901536403147
> Median: 16
> Mode: 16, freq: 2714, perc: 75.40983606557377%
> 
>  
> ---- Scheduler class ----
> NumSamples: 3599
> Mean: 16.0
> StdDev: 0.0
> Median: 16
> Mode: 16, freq: 3599, perc: 100.0%
> 
> 
> 
> Arm linux iMX6:
> 
> ---- Timer class ----
> NumSamples: 3599
> Mean: 16.182272853570435
> StdDev: 0.4224950723394174
> Median: 16
> Mode: 16, freq: 2837, perc: 78.82745207001946%
> 
> 
> ---- Scheduler class ----
> NumSamples: 3599
> Mean: 15.995554320644624
> StdDev: 0.3666906549602725
> Median: 16
> Mode: 16, freq: 3468, perc: 96.3601000277855%

Marked as reviewed by jvos (Reviewer).

-------------

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

From kcr at openjdk.java.net  Fri May  1 14:50:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 1 May 2020 14:50:53 GMT
Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs()
 list
In-Reply-To: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
Message-ID: <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>

On Wed, 29 Apr 2020 04:40:59 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> When tabs are permuted as mentioned in the issue description as,
> 1. TabPane.getTabs().setAll(tab0, tab1)
> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
> 
> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
> => but are show in order as  tab2, tab3, tab0, tab1
> 
> Cause:
> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
> Fix:
> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
> 
> Verification:
> No existing tests fail due to this change.
> Added a system test which fails without and pass with fix.

I think the change is fine, although I still need to run it. I have a couple questions / comments.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 649:

> 648:                 if (!tabsToAdd.isEmpty()) {
> 649:                     addTabs(tabsToAdd, getSkinnable().getTabs().indexOf(tabsToAdd.get(0)));
> 650:                 }

@kleopatra is right in that there is no guarantee that the set of added sublists from multiple Changes are contiguous.
Since this assumption is preexisting, I agree that this is just something to keep in mind.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 994:

> 993:         private void moveTab(int moveToIndex, TabHeaderSkin tabHeaderSkin) {
> 994:             if (moveToIndex != headersRegion.getChildren().indexOf(tabHeaderSkin)) {
> 995:                 headersRegion.getChildren().remove(tabHeaderSkin);

Unless I am missing something, this check seems unrelated to the bug.

tests/system/src/test/java/test/robot/javafx/scene/TabPanePermuteGetTabsTest.java line 194:

> 193:     @Test
> 194:     public void testPermutGetTabsWithMoreTabs1() {
> 195:         // Step #1

Typo: Permut --> Permute

(or, as long as you are changing it anyway, you could rename it now to something other than "permute" since it isn't).

tests/system/src/test/java/test/robot/javafx/scene/TabPanePermuteGetTabsTest.java line 224:

> 223:         });
> 224:         delay();
> 225:

Does using Robot to select the Tab test add value? Probably not worth worrying about given that this will all move to
the controls unit tests with [JDK-8244195](https://bugs.openjdk.java.net/browse/JDK-8244195).

-------------

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

From github.com+2720909+jskov at openjdk.java.net  Fri May  1 15:07:47 2020
From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov)
Date: Fri, 1 May 2020 15:07:47 GMT
Subject: [Rev 06] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <jZ0bdaeutpp4_ZafWu58gzGD0QdzniyGWfKDxAkYJ6M=.a5907e53-e3f6-4cd7-9c2c-14713df44d5d@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <qS8aJCyQVliFFKw9lgyHYWKk_5PyCjf8X5Ohml4I_Ls=.b377c85c-1c1e-42a2-8e3a-bff656b8b631@github.com>
 <-iJFt9jWpM5Hz-v0WQ8yFQQVDiHt3qYu7sM_LeekH0M=.f0f51143-901a-4c82-8834-dd9064498b4c@github.com>
 <jZ0bdaeutpp4_ZafWu58gzGD0QdzniyGWfKDxAkYJ6M=.a5907e53-e3f6-4cd7-9c2c-14713df44d5d@github.com>
Message-ID: <BoReGFcsh6aNswMRWiGJoED20yqtz6RlxQoefffP-Hc=.91cd1f72-e626-44b5-8e02-c76a4de16549@github.com>

On Tue, 17 Mar 2020 11:08:36 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Marked as reviewed by arapte (Reviewer).
>
> @FlorianKirmaier
> Please integrate this PR by issuing `/integrate` command in a new comment. After that one of us can sponsor it.

@FlorianKirmaier  did you want to persue a common shared in-tree GC testing facility?

Otherwise I would like to give it a shot (I have also just added another copy of the attemptGC method to a test).

-------------

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

From jvos at openjdk.java.net  Fri May  1 15:20:00 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 1 May 2020 15:20:00 GMT
Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with
 enabled Monocle on Raspberry Pi
In-Reply-To: <Sftn2QdvuLprK1NsJOrgoWzRNZen7pWrAfv_RIvV8mk=.ebcebe8e-f204-4745-a609-ae17fa1b781a@github.com>
References: <xHVPDsK8hMo-DZGlBo8osTWAzKVs-efe2ulwqJxfxFw=.2df96814-9504-4791-9960-f3394c7b8600@github.com>
 <Sftn2QdvuLprK1NsJOrgoWzRNZen7pWrAfv_RIvV8mk=.ebcebe8e-f204-4745-a609-ae17fa1b781a@github.com>
Message-ID: <UMfuj3pgBFrUbBb3vHY6P7AACCsdeTPrijSqCCkC634=.cf4cf281-3461-4770-a344-fc672a173757@github.com>

On Mon, 27 Apr 2020 11:09:51 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html
>> 
>> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes
>> [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228)
>> method code from
>>> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale()
>> 
>>  to
>>  > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()"
>> 
>> so the font size is not properly calculated based on the given DPI value.
>> 
>> I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On
>> Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app
>> works in the same way.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Search javafx.platform.properties in jfx-runtime/lib directory

Marked as reviewed by jvos (Reviewer).

-------------

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

From arapte at openjdk.java.net  Fri May  1 15:24:51 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 1 May 2020 15:24:51 GMT
Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs()
 list
In-Reply-To: <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
 <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
Message-ID: <E9Ur0EK60zqUJ6VRjwLrxmS57ZlTCcFmpwL4GsT5Kak=.e63fe17e-c904-4e0a-93b8-a7bc916dde4f@github.com>

On Fri, 1 May 2020 14:39:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue:
>> When tabs are permuted as mentioned in the issue description as,
>> 1. TabPane.getTabs().setAll(tab0, tab1)
>> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
>> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
>> 
>> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
>> => but are show in order as  tab2, tab3, tab0, tab1
>> 
>> Cause:
>> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
>> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
>> Fix:
>> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
>> 
>> Verification:
>> No existing tests fail due to this change.
>> Added a system test which fails without and pass with fix.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 994:
> 
>> 993:         private void moveTab(int moveToIndex, TabHeaderSkin tabHeaderSkin) {
>> 994:             if (moveToIndex != headersRegion.getChildren().indexOf(tabHeaderSkin)) {
>> 995:                 headersRegion.getChildren().remove(tabHeaderSkin);
> 
> Unless I am missing something, this check seems unrelated to the bug.

Yes Kevin, this is not required for fix. In some scenarios the tabHeader gets placed at correct index due to the
addition of new headers, so this movement becomes redundant.

-------------

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

From arapte at openjdk.java.net  Fri May  1 15:32:37 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 1 May 2020 15:32:37 GMT
Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs()
 list
In-Reply-To: <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
 <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
Message-ID: <b1Q7zBSM8VQXzIouVIU6NMuPUffs-Bz66mQ76QANmMA=.45d5cf4b-3d48-49f7-a11e-4eb683d953ca@github.com>

On Fri, 1 May 2020 14:46:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue:
>> When tabs are permuted as mentioned in the issue description as,
>> 1. TabPane.getTabs().setAll(tab0, tab1)
>> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
>> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
>> 
>> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
>> => but are show in order as  tab2, tab3, tab0, tab1
>> 
>> Cause:
>> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
>> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
>> Fix:
>> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
>> 
>> Verification:
>> No existing tests fail due to this change.
>> Added a system test which fails without and pass with fix.
>
> tests/system/src/test/java/test/robot/javafx/scene/TabPanePermuteGetTabsTest.java line 224:
> 
>> 223:         });
>> 224:         delay();
>> 225:
> 
> Does using Robot to select the Tab test add value? Probably not worth worrying about given that this will all move to
> the controls unit tests with [JDK-8244195](https://bugs.openjdk.java.net/browse/JDK-8244195).

In these scenarios, the `TabPane.getTabs()` has correct sequence. So selecting a tab using `TabPaneSelectionModel` does
not test the issue. Using Mouse guarantees that `TabHeaderArea` has correct order of tabs. But anyway once we convert
these tests to unit tests, mouse events will be removed.

-------------

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

From github.com+12861109+dellgreen at openjdk.java.net  Fri May  1 16:12:39 2020
From: github.com+12861109+dellgreen at openjdk.java.net (Dell Green)
Date: Fri, 1 May 2020 16:12:39 GMT
Subject: RFR: 8176499: Dependence on java.util.Timer freezes screen when
 OS time resets backwards
In-Reply-To: <x14dpTzPhXvNMSoYrgJGBMmDCWwMDaNvEjrcz3AFRsI=.e63ee2ce-17cb-47d1-9278-ef212355bffd@github.com>
References: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
 <x14dpTzPhXvNMSoYrgJGBMmDCWwMDaNvEjrcz3AFRsI=.e63ee2ce-17cb-47d1-9278-ef212355bffd@github.com>
Message-ID: <4SMQ97GeY88M2p4tSREUqlLqEqsvFSV1QfdrjJ0RCqs=.68c9b8aa-8aed-4a0f-862c-e58108e4cf79@github.com>

On Fri, 1 May 2020 14:43:41 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8176499
>> 
>> This pull request fixes a long standing issue in the MonocleTimer class whereby it has a dependency on the
>> java.uti.Timer class which is dependent on system time and can cause UI freezes for seconds/minutes/hours/days/years
>> dependent upon how far back in time the system clock is set by either a user manually or NTP. This looks like it is
>> because the Timer class will wait for (executionTime - currentTime) before proceeding if a task hasn't fired yet.
>> https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553  For a
>> long running embedded device with a UI like IOT devices this is pretty disastrous. We recently re-discovered this issue
>> whilst testing such a device before going into production.
>> The MonocleTimer class is used by MonocleApplication and QuantumToolkit class to create its pulseTimer for emebdded
>> systems and sets it up to fire periodically inline with the requested pulse frequency which by default is 60Hz
>> resulting in a pulse interval of 16ms.   It is well documented that for implementations that wish to measure elapsed
>> time ScheduledThreadPoolExecutor should be used as a replacement for java.util.Timer class.
>> Java Concurrency In Practice:
>> https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf (page 77)
>> 
>> "The Timer facility manages the execution of deferred ("run this task in 100 ms") and periodic ("run this task every
>> 10ms") tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its
>> replacement."  With the original implementation, if I set the date.time back 8 years for example the UI freezes up
>> indefinitely (I cant wait 8 years). Repeating the same test with the proposed implementation has no affect on the UI
>> and it runs as normal.  The proposed solution has been tested on an Arm iMX6 board.
>> 
>> Whist testing in isolation the MonocleTimer class with no work to do on each pulse, it looks like the change from Timer
>> class to ScheduledThreadPoolExecutor also has brought with it a greater accuracy of when the pulses are fired.
>> The following results were observed when running MonocleTimer at 60Hz for 1 minute. It appears that we get a higher
>> frequency of pulses hitting the 16ms mark with the replacement solution
>> 
>> x86-64 linux desktop:
>> 
>> ---- Timer class ----
>> NumSamples: 3599
>> Mean: 16.230063906640734
>> StdDev: 0.45021901536403147
>> Median: 16
>> Mode: 16, freq: 2714, perc: 75.40983606557377%
>> 
>>  
>> ---- Scheduler class ----
>> NumSamples: 3599
>> Mean: 16.0
>> StdDev: 0.0
>> Median: 16
>> Mode: 16, freq: 3599, perc: 100.0%
>> 
>> 
>> 
>> Arm linux iMX6:
>> 
>> ---- Timer class ----
>> NumSamples: 3599
>> Mean: 16.182272853570435
>> StdDev: 0.4224950723394174
>> Median: 16
>> Mode: 16, freq: 2837, perc: 78.82745207001946%
>> 
>> 
>> ---- Scheduler class ----
>> NumSamples: 3599
>> Mean: 15.995554320644624
>> StdDev: 0.3666906549602725
>> Median: 16
>> Mode: 16, freq: 3468, perc: 96.3601000277855%
>
> Marked as reviewed by jvos (Reviewer).

/integrate
/summary Fixes a long standing issue in the MonocleTimer class as its dependent on the java.uti.Timer class which is
dependent on system time which can cause UI freezes depending upon how far back in time the system clock is set by
either a user or NTP.

-------------

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

From kcr at openjdk.java.net  Fri May  1 16:22:56 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 1 May 2020 16:22:56 GMT
Subject: RFR: 8176499: Dependence on java.util.Timer freezes screen when
 OS time resets backwards
In-Reply-To: <4SMQ97GeY88M2p4tSREUqlLqEqsvFSV1QfdrjJ0RCqs=.68c9b8aa-8aed-4a0f-862c-e58108e4cf79@github.com>
References: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
 <x14dpTzPhXvNMSoYrgJGBMmDCWwMDaNvEjrcz3AFRsI=.e63ee2ce-17cb-47d1-9278-ef212355bffd@github.com>
 <4SMQ97GeY88M2p4tSREUqlLqEqsvFSV1QfdrjJ0RCqs=.68c9b8aa-8aed-4a0f-862c-e58108e4cf79@github.com>
Message-ID: <8QoFfdvUbW_a_SqMzjCVHbwkHZj3vrO2VwQoTFYLLjc=.30caab2e-28c8-4045-a39c-463e70311d1b@github.com>

On Fri, 1 May 2020 16:10:22 GMT, Dell Green <github.com+12861109+dellgreen at openjdk.org> wrote:

>> Marked as reviewed by jvos (Reviewer).
>
> /integrate
> /summary Fixes a long standing issue in the MonocleTimer class as its dependent on the java.uti.Timer class which is
> dependent on system time which can cause UI freezes depending upon how far back in time the system clock is set by
> either a user or NTP.

@dellgreen `/summary` is a distinct command from `/integrate` -- you can't enter multiple commands in a single comment.
`/integrate` should always be the last thing you do, since that indicates you are completely done with the PR and want
to integrate it in its current state.

The `/summary` is going to be ignored, which is likely fine, but this is something to note for next time.

-------------

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

From github.com+12861109+dellgreen at openjdk.java.net  Fri May  1 16:51:26 2020
From: github.com+12861109+dellgreen at openjdk.java.net (Dell Green)
Date: Fri, 1 May 2020 16:51:26 GMT
Subject: RFR: 8176499: Dependence on java.util.Timer freezes screen when
 OS time resets backwards
In-Reply-To: <8QoFfdvUbW_a_SqMzjCVHbwkHZj3vrO2VwQoTFYLLjc=.30caab2e-28c8-4045-a39c-463e70311d1b@github.com>
References: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
 <x14dpTzPhXvNMSoYrgJGBMmDCWwMDaNvEjrcz3AFRsI=.e63ee2ce-17cb-47d1-9278-ef212355bffd@github.com>
 <4SMQ97GeY88M2p4tSREUqlLqEqsvFSV1QfdrjJ0RCqs=.68c9b8aa-8aed-4a0f-862c-e58108e4cf79@github.com>
 <8QoFfdvUbW_a_SqMzjCVHbwkHZj3vrO2VwQoTFYLLjc=.30caab2e-28c8-4045-a39c-463e70311d1b@github.com>
Message-ID: <ZEzvy_v7PjJ-TT5gNpiFcZ2jCk1eY3s5cNDcgIbE9AI=.a072c90a-5aed-459f-9062-021a28e5920c@github.com>

On Fri, 1 May 2020 16:20:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> /integrate
>> /summary Fixes a long standing issue in the MonocleTimer class as its dependent on the java.uti.Timer class which is
>> dependent on system time which can cause UI freezes depending upon how far back in time the system clock is set by
>> either a user or NTP.
>
> @dellgreen `/summary` is a distinct command from `/integrate` -- you can't enter multiple commands in a single comment.
> `/integrate` should always be the last thing you do, since that indicates you are completely done with the PR and want
> to integrate it in its current state.  The `/summary` is going to be ignored, which is likely fine, but this is
> something to note for next time.

@kevinrushforth ok, thank you for the feedback

-------------

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

From github.com+12861109+dellgreen at openjdk.java.net  Fri May  1 16:56:26 2020
From: github.com+12861109+dellgreen at openjdk.java.net (Dell Green)
Date: Fri, 1 May 2020 16:56:26 GMT
Subject: [Integrated] RFR: 8176499: Dependence on java.util.Timer freezes
 screen when OS time resets backwards
In-Reply-To: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
References: <osU_vLNUYJJhIcYcqTzJOtzOn9h-mL1AexwmsXa9md4=.cf9d8940-152c-4c16-a4a4-2fccfd94fd9a@github.com>
Message-ID: <DC4rnq25SegVVXR8-5aHWx-EzMh46G345dNjrScuaa4=.677e6d1c-d569-41b2-b2b3-9863a80346e0@github.com>

On Wed, 19 Feb 2020 19:14:08 GMT, Dell Green <github.com+12861109+dellgreen at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8176499
> 
> This pull request fixes a long standing issue in the MonocleTimer class whereby it has a dependency on the
> java.uti.Timer class which is dependent on system time and can cause UI freezes for seconds/minutes/hours/days/years
> dependent upon how far back in time the system clock is set by either a user manually or NTP. This looks like it is
> because the Timer class will wait for (executionTime - currentTime) before proceeding if a task hasn't fired yet.
> https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553  For a
> long running embedded device with a UI like IOT devices this is pretty disastrous. We recently re-discovered this issue
> whilst testing such a device before going into production.
> The MonocleTimer class is used by MonocleApplication and QuantumToolkit class to create its pulseTimer for emebdded
> systems and sets it up to fire periodically inline with the requested pulse frequency which by default is 60Hz
> resulting in a pulse interval of 16ms.   It is well documented that for implementations that wish to measure elapsed
> time ScheduledThreadPoolExecutor should be used as a replacement for java.util.Timer class.
> Java Concurrency In Practice:
> https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf (page 77)
> 
> "The Timer facility manages the execution of deferred ("run this task in 100 ms") and periodic ("run this task every
> 10ms") tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its
> replacement."  With the original implementation, if I set the date.time back 8 years for example the UI freezes up
> indefinitely (I cant wait 8 years). Repeating the same test with the proposed implementation has no affect on the UI
> and it runs as normal.  The proposed solution has been tested on an Arm iMX6 board.
> 
> Whist testing in isolation the MonocleTimer class with no work to do on each pulse, it looks like the change from Timer
> class to ScheduledThreadPoolExecutor also has brought with it a greater accuracy of when the pulses are fired.
> The following results were observed when running MonocleTimer at 60Hz for 1 minute. It appears that we get a higher
> frequency of pulses hitting the 16ms mark with the replacement solution
> 
> x86-64 linux desktop:
> 
> ---- Timer class ----
> NumSamples: 3599
> Mean: 16.230063906640734
> StdDev: 0.45021901536403147
> Median: 16
> Mode: 16, freq: 2714, perc: 75.40983606557377%
> 
>  
> ---- Scheduler class ----
> NumSamples: 3599
> Mean: 16.0
> StdDev: 0.0
> Median: 16
> Mode: 16, freq: 3599, perc: 100.0%
> 
> 
> 
> Arm linux iMX6:
> 
> ---- Timer class ----
> NumSamples: 3599
> Mean: 16.182272853570435
> StdDev: 0.4224950723394174
> Median: 16
> Mode: 16, freq: 2837, perc: 78.82745207001946%
> 
> 
> ---- Scheduler class ----
> NumSamples: 3599
> Mean: 15.995554320644624
> StdDev: 0.3666906549602725
> Median: 16
> Mode: 16, freq: 3468, perc: 96.3601000277855%

This pull request has now been integrated.

Changeset: 1cae6a87
Author:    Dell Green <dell.green at ideaworks.co.uk>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/1cae6a87
Stats:     17 lines in 1 file changed: 8 ins; 3 del; 6 mod

8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards

Reviewed-by: jvos

-------------

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

From kevin.rushforth at oracle.com  Sat May  2 16:07:12 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 2 May 2020 09:07:12 -0700
Subject: White box / window flicker upon launch
In-Reply-To: <195CE0A5-7112-45AD-8882-71488FBBD4E8@gmail.com>
References: <AC02324E-DDA6-4B78-875E-04B9100F87EB@gmail.com>
 <06627dc5-567f-abf8-a35e-90d192268340@bestsolution.at>
 <7AD41DD1-A1C6-431D-91DF-3B8EC4841871@gmail.com>
 <195CE0A5-7112-45AD-8882-71488FBBD4E8@gmail.com>
Message-ID: <978dace4-5665-17f1-c745-0c3067efd775@oracle.com>

Sorry for the delay in responding. I can reproduce this on macOS. I 
haven't tried on Linux, but I suspect it will reproduce there as well. I 
added an evaluation to the bug report:

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

I don't think this will be an easy bug to fix. In the mean time, the 
suggested workaround of setting the Scene fill to a color that matches 
(as closely as possible) the color of the scene as it is initially 
rendered is the best I can think of.

-- Kevin


On 4/23/2020 4:52 AM, Dirk Lemmermann wrote:
> Ticket created: ID 9064689
>
> Dirk
>
>> On 23 Apr 2020, at 13:40, Dirk Lemmermann <dlemmermann at gmail.com> wrote:
>>
>> I think this is a bug ? I will create a ticket for it. When this behaviour was fixed for Swing in Java 6 it made a huge difference in the perception of the quality and performance of Java applications. Could do the same for JavaFX.
>>
>> Dirk
>>
>>
>>> On 22 Apr 2020, at 20:17, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>>>
>>> yes I do but I think this is by nature:
>>>
>>> a) you use CSS so only after the first CSS-Pass the color could be set
>>>   appropriately, this CSS pass could happen after the Native-Window is
>>>   shown
>>>   => you can mitigate that a bit using
>>>   root.setBackground(new Background(new BackgroundFill(Color.ORANGE,
>>>      CornerRadii.EMPTY, Insets.EMPTY)));
>>>
>>> b) if the above gives you short flash (IMHO shorter than with CSS) and
>>>   you can see that by setting eg RED or GREEN as the Scene-Fill so then
>>>   it gets more prominent
>>>
>>> So the flash is gone if you put the same color to Scene.setFill() as your root-Pane but now something slightly unexpected happens. The trim is colored slighly in your scene-color ;-)
>>>
>>> Tom
>>>
>>> Am 22.04.20 um 19:46 schrieb Dirk Lemmermann:
>>>> import javafx.application.Application;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.layout.VBox;
>>>> import javafx.stage.Stage;
>>>> public class BugDemo extends Application {
>>>>     public void start(Stage stage) {
>>>>         VBox root = new VBox();
>>>>         root.setStyle("-fx-background-color: orange;");
>>>>         Scene scene = new Scene(root, 1000, 800);
>>>>         stage.setScene(scene);
>>>>         stage.show();
>>>>     }
>>>>     public static void main(String[] args) {
>>>>         launch(args);
>>>>     }
>>>> }


From fkirmaier at openjdk.java.net  Sun May  3 20:45:12 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Sun, 3 May 2020 20:45:12 GMT
Subject: [Rev 06] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <BoReGFcsh6aNswMRWiGJoED20yqtz6RlxQoefffP-Hc=.91cd1f72-e626-44b5-8e02-c76a4de16549@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <qS8aJCyQVliFFKw9lgyHYWKk_5PyCjf8X5Ohml4I_Ls=.b377c85c-1c1e-42a2-8e3a-bff656b8b631@github.com>
 <-iJFt9jWpM5Hz-v0WQ8yFQQVDiHt3qYu7sM_LeekH0M=.f0f51143-901a-4c82-8834-dd9064498b4c@github.com>
 <jZ0bdaeutpp4_ZafWu58gzGD0QdzniyGWfKDxAkYJ6M=.a5907e53-e3f6-4cd7-9c2c-14713df44d5d@github.com>
 <BoReGFcsh6aNswMRWiGJoED20yqtz6RlxQoefffP-Hc=.91cd1f72-e626-44b5-8e02-c76a4de16549@github.com>
Message-ID: <vtq9YczXLfG4O9c63tN5S2-d4voktIrBN8eIuMzhZ7c=.8893ccab-c6aa-492f-9231-174e74d59992@github.com>

On Fri, 1 May 2020 15:05:26 GMT, Jesper Skov <github.com+2720909+jskov at openjdk.org> wrote:

>> @FlorianKirmaier
>> Please integrate this PR by issuing `/integrate` command in a new comment. After that one of us can sponsor it.
>
> @FlorianKirmaier  did you want to persue a common shared in-tree GC testing facility?
> 
> Otherwise I would like to give it a shot (I have also just added another copy of the attemptGC method to a test).

@jskov
Thank you for the reminder.
I've updated and improved my [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy), and now I'm working on a PR for
JavaFX add it based on the feedback of this PR and simplifies various tests.

-------------

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

From florian.kirmaier at gmail.com  Sun May  3 21:41:13 2020
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Sun, 3 May 2020 23:41:13 +0200
Subject: RFR: 8244297 memory leak test utility
Message-ID: <CA+4mSqZfxEFiCviGeN0vWTo_+0pe=Yqs0rjQmYBunxXOXwiQTA@mail.gmail.com>

Hi everyone,

as discussed in my older PR, I want to add some utility to test for memory
leaks.
Check out my PR for more details: https://github.com/openjdk/jfx/pull/204

Greetings
Florian Kirmaier

From fkirmaier at openjdk.java.net  Sun May  3 22:23:33 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Sun, 3 May 2020 22:23:33 GMT
Subject: RFR: 8244297: memory leak test utility
Message-ID: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>

It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71

I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests.

It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes.
I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very
stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but
the tests with JMemoryBuddy are basically always correct.

-------------

Commit messages:
 - JDK-8244297

Changes: https://git.openjdk.java.net/jfx/pull/204/files
 Webrev: https://webrevs.openjdk.java.net/jfx/204/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244297
  Stats: 322 lines in 5 files changed: 225 ins; 69 del; 28 mod
  Patch: https://git.openjdk.java.net/jfx/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204

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

From aghaisas at openjdk.java.net  Mon May  4 04:22:21 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 4 May 2020 04:22:21 GMT
Subject: RFR: 8241999: ChoiceBox: incorrect toggle selected for uncontained
In-Reply-To: <c6ROPfPJrRdidk4d1IHJyPPgaAvaNnTafEzapWBoTBQ=.4417a84c-b036-489c-a996-038e8e43916b@github.com>
References: <lDh3qZ-_qScrnhtoM-vcHsP7wBXN2Bz7v32oGJ9gYQA=.65c0e8d5-61d0-4229-97a6-06e4bd40f12c@github.com>
 <c6ROPfPJrRdidk4d1IHJyPPgaAvaNnTafEzapWBoTBQ=.4417a84c-b036-489c-a996-038e8e43916b@github.com>
Message-ID: <qXWkmMEHX4Zz0arC4U61cJ-9zyobPp_huzLOj3Rzwaw=.7db86738-1c15-47ca-ac0e-373cfe128545@github.com>

On Tue, 28 Apr 2020 20:44:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The issue is that the toggles is not reliably unselected if an uncontained value is set.
>> 
>> The root is ChoiceBoxSelectionModel which doesn't update the index on selecting an uncontained item, in particular it
>> fails to keep the invariant:
>>      assertEquals(getItems().indexOf(selectedItem), selectedIndex);
>> 
>> The fix here is to override select(item) to guarantee the assert.
>> 
>> Added/removed ignore from tests that failed before and pass after the fix. All other tests are passing before and after.
>
> @aghaisas can you review this? It looks pretty simple so one reviewer should be enough, unless you spot something where
> you want a second pair of eyes.

@kevinrushforth, I agree on single reviewer being enough for this change.
The fix looks good to me.

-------------

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

From aghaisas at openjdk.java.net  Mon May  4 04:22:20 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 4 May 2020 04:22:20 GMT
Subject: RFR: 8241999: ChoiceBox: incorrect toggle selected for uncontained
In-Reply-To: <lDh3qZ-_qScrnhtoM-vcHsP7wBXN2Bz7v32oGJ9gYQA=.65c0e8d5-61d0-4229-97a6-06e4bd40f12c@github.com>
References: <lDh3qZ-_qScrnhtoM-vcHsP7wBXN2Bz7v32oGJ9gYQA=.65c0e8d5-61d0-4229-97a6-06e4bd40f12c@github.com>
Message-ID: <jHAb0TrcrKoKmL7MwKmnB3wLsyuqss0tp4oS8asmjCY=.88c5e1f2-50ab-4c1a-89d2-28a749175c03@github.com>

On Tue, 28 Apr 2020 15:36:53 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The issue is that the toggles is not reliably unselected if an uncontained value is set.
> 
> The root is ChoiceBoxSelectionModel which doesn't update the index on selecting an uncontained item, in particular it
> fails to keep the invariant:
>      assertEquals(getItems().indexOf(selectedItem), selectedIndex);
> 
> The fix here is to override select(item) to guarantee the assert.
> 
> Added/removed ignore from tests that failed before and pass after the fix. All other tests are passing before and after.

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From aghaisas at openjdk.java.net  Mon May  4 09:49:21 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 4 May 2020 09:49:21 GMT
Subject: RFR: 8244110: NPE in MenuButtonSkinBase change listener
Message-ID: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>

Issue :
https://bugs.openjdk.java.net/browse/JDK-8244110

Root Cause :
Fix of [JDK-8175358](https://bugs.openjdk.java.net/browse/JDK-8175358) added code to remove accelerators from a scene
in Scene property listener of MenuButtonSkinBase. That fix uses getSkinnable() in listener. It turned out that it can
be null as found out by failing system test.

Fix :
As pointed out by @kleopatra on the JBS, getSkinnable() should never be null for a valid skin. Hence, the correct fix
is to remove listener cleanly in dispose method. See JBS comments for more info. This also addresses
[JDK-8244081](https://bugs.openjdk.java.net/browse/JDK-8244081).

Testing :
1) Failing system test - passes after the fix
2) 3 unit tests which used to log NPE message silently and pass have been made to fail without this fix - these tests
passes after the fix

Special Thanks to @kleopatra for most of the test digging and fix guidance.

-------------

Commit messages:
 - MenuButtonSkinBase_Regression_fix

Changes: https://git.openjdk.java.net/jfx/pull/205/files
 Webrev: https://webrevs.openjdk.java.net/jfx/205/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244110
  Stats: 43 lines in 2 files changed: 38 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/205.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/205/head:pull/205

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

From kcr at openjdk.java.net  Mon May  4 14:26:57 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 4 May 2020 14:26:57 GMT
Subject: RFR: 8244297: memory leak test utility
In-Reply-To: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
Message-ID: <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>

On Sun, 3 May 2020 21:39:41 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71
> 
> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests.
> 
> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes.
> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very
> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but
> the tests with JMemoryBuddy are basically always correct.

I'll put this on my queue to review and test it. I left some high-level comments below.

modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 1:

> 1: package de.sandec.jmemorybuddy;
> 2:

This file needs a standard Oracle copyright header, which you can copy from any of the other test files.

Also, this utility class should be moved into a package matching the pattern we already use for our tests. Something
like `test.util.memory`?

modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 145:

> 144:
> 145:     public static void createHeapDump() {
> 146:         try {

I don't think we want automatic creation of heap dumps by our unit test suite. That would need a larger discussion. I
recommend to either comment this out, or else to qualify it with a system property that could be passed in via a
`gradle` property (e.g., as is done for `UNSTABLE_TEST`), with a default of `false`.

modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 15:

> 14:
> 15: public class JMemoryBuddy {
> 16:

Since this is a utility intended to be used by various tests, it would be very helpful to add some documentation about
how to use it.

-------------

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

From kcr at openjdk.java.net  Mon May  4 15:52:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 4 May 2020 15:52:06 GMT
Subject: RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
Message-ID: <ttimW2wcIuABkpILTj-0_95rQDy6A2ochau4uD43hFM=.064f7971-e7b6-4fc9-9c29-68e318f6e1ad@github.com>

On Mon, 4 May 2020 09:07:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244110
> 
> Root Cause :
> Fix of [JDK-8175358](https://bugs.openjdk.java.net/browse/JDK-8175358) added code to remove accelerators from a scene
> in Scene property listener of MenuButtonSkinBase. That fix uses getSkinnable() in listener. It turned out that it can
> be null as found out by failing system test.  Fix :
> As pointed out by @kleopatra on the JBS, getSkinnable() should never be null for a valid skin. Hence, the correct fix
> is to remove listener cleanly in dispose method. See JBS comments for more info. This also addresses
> [JDK-8244081](https://bugs.openjdk.java.net/browse/JDK-8244081).  Testing :
> 1) Failing system test - passes after the fix
> 2) 3 unit tests which used to log NPE message silently and pass have been made to fail without this fix - these tests
> passes after the fix
> Special Thanks to @kleopatra for most of the test digging and fix guidance.

Inline comments below. I still need to test the fix, but will wait until you answer the questions I raised.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 230:

> 229:         // Remove listeners
> 230:         getSkinnable().sceneProperty().removeListener(sceneChangeListener);
> 231:         getSkinnable().getItems().removeListener(itemsChangedListener);

If scene is set to null (which can happen if this control or its parent is removed from the scene graph) before dispose
is called, this will throw an NPE. I think it should be moved inside the above if statement.

This raises the question: when the scene changes, are both the accelerators and this listener removed from the old
scene?

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 77:

> 76:     private ListChangeListener<MenuItem> itemsChangedListener;
> 77:     private ChangeListener<? super Scene> sceneChangeListener;
> 78:

Can this be made final?

-------------

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

From youngty1997 at gmail.com  Mon May  4 19:58:41 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 4 May 2020 14:58:41 -0500
Subject: JavaFX Memory leak
Message-ID: <556bee23-7509-6639-30ba-f71e7e7b2a4b@gmail.com>

Hi,


I'm trying to debug a memory leak in my application using Java Mission 
Control & Flight Recorder[1]. Going down the tree it gives, it seems to 
be caused by this code:


Series<Integer, Long> series = super.getSeries();

ObservableList<Data<Integer, Long>> points = series.getData();

if(points.size() > super.getSeconds().get()-1)
{
 ??? points.remove(super.getSeconds().get()-1);

 ??? points.add(0, new Data(0, readable.getValue().get().longValue()));
}
else
 ??? points.add(0, new Data(0, readable.getValue().get().longValue()));

for(int i = 1; i < points.size(); i++)
{
 ??? Data data = points.get(i);
 ??? data.setXValue(i+1);
}


...but doing a print statement to print the size of the Points list 
shows that the max size is always 60, as expected.


This increase in memory is consistent with multiple recordings, so I do 
think it's a leak but I have no idea what's causing it. Is this leak 
from JavaFX's end or my code?


[1] https://imgur.com/a/oNYb6Q7


From arapte at openjdk.java.net  Tue May  5 05:03:46 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 5 May 2020 05:03:46 GMT
Subject: RFR: 8242507: Add support for Visual Studio 2019
In-Reply-To: <RisPgG6z0Gj9HeeyNJm7z3SftUx6rWvtvZRCmjRZng8=.b39844bb-76a0-4989-9be5-78a7a184be65@github.com>
References: <RisPgG6z0Gj9HeeyNJm7z3SftUx6rWvtvZRCmjRZng8=.b39844bb-76a0-4989-9be5-78a7a184be65@github.com>
Message-ID: <GvtVypJfxFLFrXGET4djbY_x3t7hT5iL-cVU5tQme9E=.96bc4484-21c0-4839-a02a-634625a0e091@github.com>

On Wed, 22 Apr 2020 18:46:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not change the default compiler, which
> remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be proposed in a future PR using a new bug ID,
> and isn't planned until after the JDK updates their compiler.  In order to allow developer builds to use Microsoft
> Visual Studio 2019, we need the following changes at build time and runtime.
> At build time:
> 
> 1. Copy `vsruntime140_1.dll` (if present) to output `sdk/bin` dir
> 2. Don't copy the unused  `concrt140.dll` (it is not used in VS 2017 either)
> 
> At runtime:
> 
> 1. Load `vsruntime140_1.dll` if present
> 2. Don't load the unused `concrt140.dll`
> 
> Additionally, I removed two unused build variables, `ext.MSVCR` and `ext.MSVCP`, which would otherwise have needed to
> be updated.
> I have done a full build and test run using both VS 2017 (which is still the default), and VS 2019.

Looks good to me, verified the build locally.

-------------

Marked as reviewed by arapte (Reviewer).

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

From fastegal at openjdk.java.net  Tue May  5 07:01:47 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 5 May 2020 07:01:47 GMT
Subject: [Integrated] RFR: 8241999: ChoiceBox: incorrect toggle selected
 for uncontained
In-Reply-To: <lDh3qZ-_qScrnhtoM-vcHsP7wBXN2Bz7v32oGJ9gYQA=.65c0e8d5-61d0-4229-97a6-06e4bd40f12c@github.com>
References: <lDh3qZ-_qScrnhtoM-vcHsP7wBXN2Bz7v32oGJ9gYQA=.65c0e8d5-61d0-4229-97a6-06e4bd40f12c@github.com>
Message-ID: <_LFDEr1VKudTEF1xO3NIAWsGhVC92mwe8PB2fAa8FW0=.4b86674e-7d6b-4dfe-a564-94817dd5a651@github.com>

On Tue, 28 Apr 2020 15:36:53 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The issue is that the toggles is not reliably unselected if an uncontained value is set.
> 
> The root is ChoiceBoxSelectionModel which doesn't update the index on selecting an uncontained item, in particular it
> fails to keep the invariant:
>      assertEquals(getItems().indexOf(selectedItem), selectedIndex);
> 
> The fix here is to override select(item) to guarantee the assert.
> 
> Added/removed ignore from tests that failed before and pass after the fix. All other tests are passing before and after.

This pull request has now been integrated.

Changeset: 99f77475
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/99f77475
Stats:     55 lines in 2 files changed: 7 ins; 44 del; 4 mod

8241999: ChoiceBox: incorrect toggle selected for uncontained

Reviewed-by: aghaisas

-------------

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

From fkirmaier at openjdk.java.net  Tue May  5 10:41:04 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 5 May 2020 10:41:04 GMT
Subject: RFR: 8244297: memory leak test utility
In-Reply-To: <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
Message-ID: <YzE1q_oaO0g5rDxsTQnjBMuEfs4natQBwDSXATTXx-c=.276de799-67bd-4f9d-8052-77507fd01502@github.com>

On Mon, 4 May 2020 14:24:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71
>> 
>> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests.
>> 
>> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes.
>> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very
>> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but
>> the tests with JMemoryBuddy are basically always correct.
>
> I'll put this on my queue to review and test it. I left some high-level comments below.

I would suggest making everything configurable in the original library which will be suggested here to be changed.
I will now add the possibility to make the creation of the heapDump configurable, and also the createGarbage method.
If something should behave differently by default, then I will just adjust the default values for this copy of the
library.

I will improve the documentation in the original Library. How should I add the documentation to the JavaFX project?
Ideally, I would just reference somewhere to the documentation of the original library. How/Where should I do that?

-------------

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

From fastegal at openjdk.java.net  Tue May  5 10:55:38 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 5 May 2020 10:55:38 GMT
Subject: RFR: 8242001: ChoiceBox: must update value on setting SelectionModel,
 part2
Message-ID: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>

The issue is that ChoiceBox didn't sync its value to the replaced SelectionModel's selectedItem if the item is null.

Fixed by removing the constraint from selectionModel property.

Added tests that failed before and passed after the fix. Note that I also changed a test method in ChoiceBoxTest with
an incorrect test assumption (which passed for the incorrect implementation).

-------------

Commit messages:
 - 8242001: ChoiceBox: must update value when setting a SelectionModel,

Changes: https://git.openjdk.java.net/jfx/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/jfx/207/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242001
  Stats: 46 lines in 3 files changed: 42 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/207/head:pull/207

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

From fkirmaier at openjdk.java.net  Tue May  5 10:59:37 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 5 May 2020 10:59:37 GMT
Subject: RFR: 8244297: memory leak test utility
In-Reply-To: <YzE1q_oaO0g5rDxsTQnjBMuEfs4natQBwDSXATTXx-c=.276de799-67bd-4f9d-8052-77507fd01502@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
 <YzE1q_oaO0g5rDxsTQnjBMuEfs4natQBwDSXATTXx-c=.276de799-67bd-4f9d-8052-77507fd01502@github.com>
Message-ID: <QQJBaOACUIK3G5Q53c5fW2Dx7QZWxJ-iR4V_R5JUkMs=.f92ecf43-1d5c-431b-8a5d-f12a43596312@github.com>

On Tue, 5 May 2020 10:38:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> I'll put this on my queue to review and test it. I left some high-level comments below.
>
> I would suggest making everything configurable in the original library which will be suggested here to be changed.
> I will now add the possibility to make the creation of the heapDump configurable, and also the createGarbage method.
> If something should behave differently by default, then I will just adjust the default values for this copy of the
> library.
> I will improve the documentation in the original Library. How should I add the documentation to the JavaFX project?
> Ideally, I would just reference somewhere to the documentation of the original library. How/Where should I do that?

It's also worth mentioning that this utility allows checking whether an object can not be collected. This is important
because the applications, which are using WeakReferences/WeakListeners often introduce bugs that are hard to debug
because they only happen after the GC has been run.

-------------

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

From aghaisas at openjdk.java.net  Tue May  5 11:07:45 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 5 May 2020 11:07:45 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <ttimW2wcIuABkpILTj-0_95rQDy6A2ochau4uD43hFM=.064f7971-e7b6-4fc9-9c29-68e318f6e1ad@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
 <ttimW2wcIuABkpILTj-0_95rQDy6A2ochau4uD43hFM=.064f7971-e7b6-4fc9-9c29-68e318f6e1ad@github.com>
Message-ID: <cboGn9rsCQJzn9V9te85xLxkMimibEhlwmUmIWqZoN8=.ead29c01-6033-4b2e-b596-36d3d9196e31@github.com>

On Mon, 4 May 2020 15:46:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make ChangeListener Final
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 230:
> 
>> 229:         // Remove listeners
>> 230:         getSkinnable().sceneProperty().removeListener(sceneChangeListener);
>> 231:         getSkinnable().getItems().removeListener(itemsChangedListener);
> 
> If scene is set to null (which can happen if this control or its parent is removed from the scene graph) before dispose
> is called, this will throw an NPE. I think it should be moved inside the above if statement.
> This raises the question: when the scene changes, are both the accelerators and this listener removed from the old
> scene?

If MenuButton is removed from a scene :
Valid scene -> null scene : sceneChangeListener is invoked to remove accelerators registered with old valid scene.
If the skin is disposed after this - we have a guard to prevent removal of accelerators from a null Scene. Also,
removing of the listener using sceneProperty() does not result in NPE.

To your specific question :
When the Scene changes, only the accelerators need to be removed from the old Scene without removing
sceneChangeListener from skin. This is due to the fact that the Control (removed from old Scene) can be added to
another Scene without recreating the skin.

Please let me know if you have further questions.

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 77:
> 
>> 76:     private ListChangeListener<MenuItem> itemsChangedListener;
>> 77:     private ChangeListener<? super Scene> sceneChangeListener;
>> 78:
> 
> Can this be made final?

Yes. I have made it.

-------------

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

From aghaisas at openjdk.java.net  Tue May  5 11:07:43 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 5 May 2020 11:07:43 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
Message-ID: <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>

> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244110
> 
> Root Cause :
> Fix of [JDK-8175358](https://bugs.openjdk.java.net/browse/JDK-8175358) added code to remove accelerators from a scene
> in Scene property listener of MenuButtonSkinBase. That fix uses getSkinnable() in listener. It turned out that it can
> be null as found out by failing system test.  Fix :
> As pointed out by @kleopatra on the JBS, getSkinnable() should never be null for a valid skin. Hence, the correct fix
> is to remove listener cleanly in dispose method. See JBS comments for more info. This also addresses
> [JDK-8244081](https://bugs.openjdk.java.net/browse/JDK-8244081).  Testing :
> 1) Failing system test - passes after the fix
> 2) 3 unit tests which used to log NPE message silently and pass have been made to fail without this fix - these tests
> passes after the fix
> Special Thanks to @kleopatra for most of the test digging and fix guidance.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Make ChangeListener Final

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/205/files
  - new: https://git.openjdk.java.net/jfx/pull/205/files/66a19546..d0c498e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/205/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/205/webrev.00-01

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

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

From fkirmaier at openjdk.java.net  Tue May  5 12:00:34 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 5 May 2020 12:00:34 GMT
Subject: [Rev 01] RFR: 8244297: memory leak test utility
In-Reply-To: <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
Message-ID: <GhyJ65tZJtHW0LyMba2QHQOphRdvJu15barGB-ajBSI=.a7d5fe51-9445-41da-aa49-8768b4fc4e4b@github.com>

On Mon, 4 May 2020 13:47:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8244297
>>   Updated JMemoeryBuddy
>>   Added Copyright header
>>   disabled default heapdump
>
> modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 1:
> 
>> 1: package de.sandec.jmemorybuddy;
>> 2:
> 
> This file needs a standard Oracle copyright header, which you can copy from any of the other test files.
> 
> Also, this utility class should be moved into a package matching the pattern we already use for our tests. Something
> like `test.util.memory`?

Done!

> modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 15:
> 
>> 14:
>> 15: public class JMemoryBuddy {
>> 16:
> 
> Since this is a utility intended to be used by various tests, it would be very helpful to add some documentation about
> how to use it.

Where/How should I add the documentation? Ideally, I would reference the documentation of the project itself.

> modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 145:
> 
>> 144:
>> 145:     public static void createHeapDump() {
>> 146:         try {
> 
> I don't think we want automatic creation of heap dumps by our unit test suite. That would need a larger discussion. I
> recommend to either comment this out, or else to qualify it with a system property that could be passed in via a
> `gradle` property (e.g., as is done for `UNSTABLE_TEST`), with a default of `false`.

I've made it configurable in the Library with system-parameters and I've changed the default not create a heap dump.
Is that ok?

-------------

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

From fkirmaier at openjdk.java.net  Tue May  5 12:00:32 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 5 May 2020 12:00:32 GMT
Subject: [Rev 01] RFR: 8244297: memory leak test utility
In-Reply-To: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
Message-ID: <8ivKbTiiWl6spiZEBgn5zOVCYrr5sFndmi4akr7vIG4=.60adfaca-e7c8-401b-b32c-324f3db64e41@github.com>

> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71
> 
> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests.
> 
> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes.
> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very
> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but
> the tests with JMemoryBuddy are basically always correct.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8244297
  Updated JMemoeryBuddy
  Added Copyright header
  disabled default heapdump

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/204/files
  - new: https://git.openjdk.java.net/jfx/pull/204/files/5721de18..e7d9ad65

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/204/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/204/webrev.00-01

  Stats: 473 lines in 2 files changed: 259 ins; 214 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204

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

From kcr at openjdk.java.net  Tue May  5 12:40:39 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 5 May 2020 12:40:39 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
 <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>
Message-ID: <hM6M2qsNvHL2YmPcRPbxJ_0xdso7ZF185RKU54ll78U=.a2707c09-2e0f-44dc-832b-88e59927adc4@github.com>

On Tue, 5 May 2020 11:07:43 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Issue :
>> https://bugs.openjdk.java.net/browse/JDK-8244110
>> 
>> Root Cause :
>> Fix of [JDK-8175358](https://bugs.openjdk.java.net/browse/JDK-8175358) added code to remove accelerators from a scene
>> in Scene property listener of MenuButtonSkinBase. That fix uses getSkinnable() in listener. It turned out that it can
>> be null as found out by failing system test.  Fix :
>> As pointed out by @kleopatra on the JBS, getSkinnable() should never be null for a valid skin. Hence, the correct fix
>> is to remove listener cleanly in dispose method. See JBS comments for more info. This also addresses
>> [JDK-8244081](https://bugs.openjdk.java.net/browse/JDK-8244081).  Testing :
>> 1) Failing system test - passes after the fix
>> 2) 3 unit tests which used to log NPE message silently and pass have been made to fail without this fix - these tests
>> passes after the fix
>> Special Thanks to @kleopatra for most of the test digging and fix guidance.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make ChangeListener Final

Looks good. I confirm that the original system test and the new controls unit test both fail without the fix and now
pass with the fix.

-------------

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Tue May  5 12:40:39 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 5 May 2020 12:40:39 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <cboGn9rsCQJzn9V9te85xLxkMimibEhlwmUmIWqZoN8=.ead29c01-6033-4b2e-b596-36d3d9196e31@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
 <ttimW2wcIuABkpILTj-0_95rQDy6A2ochau4uD43hFM=.064f7971-e7b6-4fc9-9c29-68e318f6e1ad@github.com>
 <cboGn9rsCQJzn9V9te85xLxkMimibEhlwmUmIWqZoN8=.ead29c01-6033-4b2e-b596-36d3d9196e31@github.com>
Message-ID: <JR7TVrt2coYAL_KQg-NK4ZJljSMNkXbRoMtS2KVikNY=.10829939-7429-4408-a29f-32396691d090@github.com>

On Tue, 5 May 2020 10:35:12 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 230:
>> 
>>> 229:         // Remove listeners
>>> 230:         getSkinnable().sceneProperty().removeListener(sceneChangeListener);
>>> 231:         getSkinnable().getItems().removeListener(itemsChangedListener);
>> 
>> If scene is set to null (which can happen if this control or its parent is removed from the scene graph) before dispose
>> is called, this will throw an NPE. I think it should be moved inside the above if statement.
>> This raises the question: when the scene changes, are both the accelerators and this listener removed from the old
>> scene?
>
> If MenuButton is removed from a scene :
> Valid scene -> null scene : sceneChangeListener is invoked to remove accelerators registered with old valid scene.
> If the skin is disposed after this - we have a guard to prevent removal of accelerators from a null Scene. Also,
> removing of the listener using sceneProperty() does not result in NPE.
> To your specific question :
> When the Scene changes, only the accelerators need to be removed from the old Scene without removing
> sceneChangeListener from skin. This is due to the fact that the Control (removed from old Scene) can be added to
> another Scene without recreating the skin.  Please let me know if you have further questions.

Yes, you are of course right about `sceneProperty()` not being null just because scene might be. An my other question
was based on a too-quick read of the code: since the listener is on the scene property of the control, and is meant to
track the case where the control moves from one scene to another, it would not be the right thing to do to remove it
when changing scenes.

So the fix looks fine to me.

-------------

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

From jvos at openjdk.java.net  Tue May  5 13:04:13 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 5 May 2020 13:04:13 GMT
Subject: RFR: 8242507: Add support for Visual Studio 2019
In-Reply-To: <RisPgG6z0Gj9HeeyNJm7z3SftUx6rWvtvZRCmjRZng8=.b39844bb-76a0-4989-9be5-78a7a184be65@github.com>
References: <RisPgG6z0Gj9HeeyNJm7z3SftUx6rWvtvZRCmjRZng8=.b39844bb-76a0-4989-9be5-78a7a184be65@github.com>
Message-ID: <MgviuDzSU3Gp6koLpqNTcOtFMDEWrOCvTMrkVtmcnIw=.e0a14075-9cb2-40ca-8f88-e5d9f7d3b8f9@github.com>

On Wed, 22 Apr 2020 18:46:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not change the default compiler, which
> remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be proposed in a future PR using a new bug ID,
> and isn't planned until after the JDK updates their compiler.  In order to allow developer builds to use Microsoft
> Visual Studio 2019, we need the following changes at build time and runtime.
> At build time:
> 
> 1. Copy `vsruntime140_1.dll` (if present) to output `sdk/bin` dir
> 2. Don't copy the unused  `concrt140.dll` (it is not used in VS 2017 either)
> 
> At runtime:
> 
> 1. Load `vsruntime140_1.dll` if present
> 2. Don't load the unused `concrt140.dll`
> 
> Additionally, I removed two unused build variables, `ext.MSVCR` and `ext.MSVCP`, which would otherwise have needed to
> be updated.
> I have done a full build and test run using both VS 2017 (which is still the default), and VS 2019.

Confirmed to work on our build systems.

-------------

Marked as reviewed by jvos (Reviewer).

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

From fastegal at openjdk.java.net  Tue May  5 13:55:17 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 5 May 2020 13:55:17 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <hM6M2qsNvHL2YmPcRPbxJ_0xdso7ZF185RKU54ll78U=.a2707c09-2e0f-44dc-832b-88e59927adc4@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
 <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>
 <hM6M2qsNvHL2YmPcRPbxJ_0xdso7ZF185RKU54ll78U=.a2707c09-2e0f-44dc-832b-88e59927adc4@github.com>
Message-ID: <nYloKcndQNM0tblICAIWg3Z-iPd8Uisa-hj7UyhpH4o=.82510921-37cb-4ff4-9968-e85e35a1f9b9@github.com>

On Tue, 5 May 2020 12:38:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make ChangeListener Final
>
> Looks good. I confirm that the original system test and the new controls unit test both fail without the fix and now
> pass with the fix.

not sure if it is appropriate to approve this? we talked so much about it, that it feels like self-approval :)

-------------

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

From kcr at openjdk.java.net  Tue May  5 14:56:25 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 5 May 2020 14:56:25 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <nYloKcndQNM0tblICAIWg3Z-iPd8Uisa-hj7UyhpH4o=.82510921-37cb-4ff4-9968-e85e35a1f9b9@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
 <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>
 <hM6M2qsNvHL2YmPcRPbxJ_0xdso7ZF185RKU54ll78U=.a2707c09-2e0f-44dc-832b-88e59927adc4@github.com>
 <nYloKcndQNM0tblICAIWg3Z-iPd8Uisa-hj7UyhpH4o=.82510921-37cb-4ff4-9968-e85e35a1f9b9@github.com>
Message-ID: <qR6KlBuG4l5MySXgogcUuLgScOeURxcUTTt9cmTu6lA=.bc6e0191-44c9-4cab-b478-7710d6e9db75@github.com>

On Tue, 5 May 2020 13:53:02 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> 
> 
> not sure if it is appropriate to approve this? we talked so much about it, that it feels like self-approval :)

Please do approve it. And thank you for contributing the solution and test. ??

-------------

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

From fastegal at openjdk.java.net  Tue May  5 15:37:07 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 5 May 2020 15:37:07 GMT
Subject: [Rev 01] RFR: 8244110: NPE in MenuButtonSkinBase change listener
In-Reply-To: <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
 <g2dNChafLWsp8KL8H9knqJxyRq9rH7BBsJh_LwBEWUc=.0e344c03-104e-4699-b116-95a12ab91df8@github.com>
Message-ID: <zamGVUxmCpV7P9mYficlS2woC_kJpjlgROwpciulVmg=.dd616ebb-ade3-41cb-9a7e-2eac7ef1e7b7@github.com>

On Tue, 5 May 2020 11:07:43 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Issue :
>> https://bugs.openjdk.java.net/browse/JDK-8244110
>> 
>> Root Cause :
>> Fix of [JDK-8175358](https://bugs.openjdk.java.net/browse/JDK-8175358) added code to remove accelerators from a scene
>> in Scene property listener of MenuButtonSkinBase. That fix uses getSkinnable() in listener. It turned out that it can
>> be null as found out by failing system test.  Fix :
>> As pointed out by @kleopatra on the JBS, getSkinnable() should never be null for a valid skin. Hence, the correct fix
>> is to remove listener cleanly in dispose method. See JBS comments for more info. This also addresses
>> [JDK-8244081](https://bugs.openjdk.java.net/browse/JDK-8244081).  Testing :
>> 1) Failing system test - passes after the fix
>> 2) 3 unit tests which used to log NPE message silently and pass have been made to fail without this fix - these tests
>> passes after the fix
>> Special Thanks to @kleopatra for most of the test digging and fix guidance.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make ChangeListener Final

looks good :)

-------------

Marked as reviewed by fastegal (Author).

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

From aghaisas at openjdk.java.net  Tue May  5 16:24:20 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 5 May 2020 16:24:20 GMT
Subject: [Integrated] RFR: 8244110: NPE in MenuButtonSkinBase change
 listener
In-Reply-To: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
References: <Xo7KlyzQNRAYNiuw5sJqGmv5vZSlexVjqk0SS6V9IxQ=.6730e38f-0f7a-4e99-971f-558c45e999b3@github.com>
Message-ID: <b5CQhhZGrFWW6g5Wm1dE8f4shkGEiH-0JatCWILJ1Bs=.e96299ab-de6c-4221-8052-cc474435d73a@github.com>

On Mon, 4 May 2020 09:07:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244110
> 
> Root Cause :
> Fix of [JDK-8175358](https://bugs.openjdk.java.net/browse/JDK-8175358) added code to remove accelerators from a scene
> in Scene property listener of MenuButtonSkinBase. That fix uses getSkinnable() in listener. It turned out that it can
> be null as found out by failing system test.  Fix :
> As pointed out by @kleopatra on the JBS, getSkinnable() should never be null for a valid skin. Hence, the correct fix
> is to remove listener cleanly in dispose method. See JBS comments for more info. This also addresses
> [JDK-8244081](https://bugs.openjdk.java.net/browse/JDK-8244081).  Testing :
> 1) Failing system test - passes after the fix
> 2) 3 unit tests which used to log NPE message silently and pass have been made to fail without this fix - these tests
> passes after the fix
> Special Thanks to @kleopatra for most of the test digging and fix guidance.

This pull request has now been integrated.

Changeset: 39d9c3b7
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/39d9c3b7
Stats:     43 lines in 2 files changed: 1 ins; 38 del; 4 mod

8244110: NPE in MenuButtonSkinBase change listener

Co-authored-by: Jeanette Winzenburg <fastegal at openjdk.org>
Reviewed-by: kcr, fastegal

-------------

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

From ajoseph at openjdk.java.net  Tue May  5 16:30:04 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Tue, 5 May 2020 16:30:04 GMT
Subject: [Closed] RFR: 8171898: [WebView] ScrollBarWidget thickness
 calculation is not correct
In-Reply-To: <EgD9eIa5h8B2QhJWsWW7XUIXWGbKRgQHw3L9o_P5Jnw=.b027e3c6-727a-4803-80f7-c4e753ce90a2@github.com>
References: <EgD9eIa5h8B2QhJWsWW7XUIXWGbKRgQHw3L9o_P5Jnw=.b027e3c6-727a-4803-80f7-c4e753ce90a2@github.com>
Message-ID: <yg5Vx-Y35WEs_xA6gfqzbg-mhPWseA746foR6iU_rjk=.5292cca1-df3e-42fb-8419-f71aa1d036db@github.com>

On Mon, 27 Apr 2020 08:17:50 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> ScrollbarThemeJava delegates scrollbar thickness calculation to ScrollBarWidget::initializeThickness()
> [ScrollBarWidget.java] method. Since "ScrollbarThemeJava::scrollbarThickness" is not associated with any
> "ScrollBarWidget" instance, some workaround was made using special "ScrollBarWidget" instance named testRef.

This pull request has been closed without being integrated.

-------------

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

From jpereda at openjdk.java.net  Tue May  5 16:55:07 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Tue, 5 May 2020 16:55:07 GMT
Subject: RFR: 8244421: Wrong scrollbar position on touch enabled devices
Message-ID: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>

`VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out next to the clipped container region, by
default.

However, when touch is supported, these scrollBars are floating controls laid out over the container. Therefore, in
this case, when the viewport dimensions are updated, the presence of the scrollBars shouldn't be taken into account.

-------------

Commit messages:
 - Don?t resize viewport with scrollbar dimensions when touch is supported

Changes: https://git.openjdk.java.net/jfx/pull/208/files
 Webrev: https://webrevs.openjdk.java.net/jfx/208/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244421
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/208.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/208/head:pull/208

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

From fkirmaier at openjdk.java.net  Tue May  5 20:45:31 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 5 May 2020 20:45:31 GMT
Subject: [Rev 02] RFR: 8244297: memory leak test utility
In-Reply-To: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
Message-ID: <PUYxOcqiGOsLI3_iZjaO4ABgJ823CYSXXnrskQpI368=.d11007f2-36b0-46d9-8b3e-5f4f19508e76@github.com>

> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71
> 
> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests.
> 
> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes.
> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very
> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but
> the tests with JMemoryBuddy are basically always correct.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8244297
  Added some javadoc to the testutility
  Some methods/fields are now private

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/204/files
  - new: https://git.openjdk.java.net/jfx/pull/204/files/e7d9ad65..72d12283

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/204/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/204/webrev.01-02

  Stats: 50 lines in 1 file changed: 39 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204

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

From fkirmaier at openjdk.java.net  Tue May  5 20:45:32 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 5 May 2020 20:45:32 GMT
Subject: [Rev 02] RFR: 8244297: memory leak test utility
In-Reply-To: <QQJBaOACUIK3G5Q53c5fW2Dx7QZWxJ-iR4V_R5JUkMs=.f92ecf43-1d5c-431b-8a5d-f12a43596312@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
 <YzE1q_oaO0g5rDxsTQnjBMuEfs4natQBwDSXATTXx-c=.276de799-67bd-4f9d-8052-77507fd01502@github.com>
 <QQJBaOACUIK3G5Q53c5fW2Dx7QZWxJ-iR4V_R5JUkMs=.f92ecf43-1d5c-431b-8a5d-f12a43596312@github.com>
Message-ID: <C2M2G-_X5ZcJYfun3QgSSgjmyNd1Y2ta0E_RtWoHWw4=.701461e6-c432-46fa-8faf-dc7fff4aa528@github.com>

On Tue, 5 May 2020 10:57:23 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> I would suggest making everything configurable in the original library which will be suggested here to be changed.
>> I will now add the possibility to make the creation of the heapDump configurable, and also the createGarbage method.
>> If something should behave differently by default, then I will just adjust the default values for this copy of the
>> library.
>> I will improve the documentation in the original Library. How should I add the documentation to the JavaFX project?
>> Ideally, I would just reference somewhere to the documentation of the original library. How/Where should I do that?
>
> It's also worth mentioning that this utility allows checking whether an object can not be collected. This is important
> because the applications, which are using WeakReferences/WeakListeners often introduce bugs that are hard to debug
> because they only happen after the GC has been run.

I've now added also some JavaDoc to the public methods.

-------------

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

From kcr at openjdk.java.net  Tue May  5 21:19:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 5 May 2020 21:19:06 GMT
Subject: [Integrated] RFR: 8242507: Add support for Visual Studio 2019
In-Reply-To: <RisPgG6z0Gj9HeeyNJm7z3SftUx6rWvtvZRCmjRZng8=.b39844bb-76a0-4989-9be5-78a7a184be65@github.com>
References: <RisPgG6z0Gj9HeeyNJm7z3SftUx6rWvtvZRCmjRZng8=.b39844bb-76a0-4989-9be5-78a7a184be65@github.com>
Message-ID: <BmWqK-t7vC5mEmBIpka-Lqxp8XRTuoUBUnOvsaKMWug=.d18bb15d-1c2d-43e7-b301-156e0eacef1c@github.com>

On Wed, 22 Apr 2020 18:46:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not change the default compiler, which
> remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be proposed in a future PR using a new bug ID,
> and isn't planned until after the JDK updates their compiler.  In order to allow developer builds to use Microsoft
> Visual Studio 2019, we need the following changes at build time and runtime.
> At build time:
> 
> 1. Copy `vsruntime140_1.dll` (if present) to output `sdk/bin` dir
> 2. Don't copy the unused  `concrt140.dll` (it is not used in VS 2017 either)
> 
> At runtime:
> 
> 1. Load `vsruntime140_1.dll` if present
> 2. Don't load the unused `concrt140.dll`
> 
> Additionally, I removed two unused build variables, `ext.MSVCR` and `ext.MSVCP`, which would otherwise have needed to
> be updated.
> I have done a full build and test run using both VS 2017 (which is still the default), and VS 2019.

This pull request has now been integrated.

Changeset: 2e900764
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/2e900764
Stats:     11 lines in 3 files changed: 5 ins; 1 del; 5 mod

8242507: Add support for Visual Studio 2019

Reviewed-by: arapte, jvos

-------------

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

From hall0330 at hotmail.com  Wed May  6 10:53:26 2020
From: hall0330 at hotmail.com (Hall Hank)
Date: Wed, 6 May 2020 10:53:26 +0000
Subject: OpenGL (lwjgl) with JavaFX sharing same context
Message-ID: <VE1PR10MB3407C12CD3DE3B535AA30528C6A40@VE1PR10MB3407.EURPRD10.PROD.OUTLOOK.COM>

Hi everyone.

I'm pretty new to this mailing list so, i hope i write my email as you expect.
I'm working on integration between OpenGL and JavaFX, and i was not really satisfied by the different library that i found on the internet. That is why, i started my own implementation by extending NGRegion (yes, it's private ??).

Here is my idea :
In the NGRegion, we are able to manage the OpenGL context created by JavaFX.
With LWJGL, it's then pretty easy to start to draw everything we want, by sharing this context. The only thing that we MUST be careful is the opengl context state. We must first save the states, draw what we want, and then restore the previous states.
In this way, JavaFX don't really know that we drew something with his own context.
This implementation is approximately the same approcah as FXGL, but without GLFW and hidden window and without creating a new OpenGL context.

I created a really small simple exemple that i would share with you. It's not production ready because i saved only the minimal states but this works really well for the hello world.
In this example, i just draw a green square, just by clearing the color. (no use of glDraw here, but of course it's possible)
I also did some advanced things with this approach, but saving/restoring a lot of states in some advanced JavaFX layout, and really it works great with very good performance.

You will find my little Main.java with few line of code to illustrate the principe. If you want to launch this example you just need the lwjgl dependencies that you can download from their website.
This example use Java 8, because i used to use it and i didn't want to have some problem due to Java 9 modules.

Now, my question is : would it be possible to include something like this in openjfx if we make it production ready ?
The interop between JavaFX & OpenGL is a recurrent question, and i think that it would be great to have a really easy solution like this directly in JavaFX.

I'm really interested about your feelings.

Thank you for reading.
Best regards.

Hank.



From fastegal at openjdk.java.net  Wed May  6 11:26:39 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 6 May 2020 11:26:39 GMT
Subject: RFR: 8244112: Skin implementations: must not violate contract of
 dispose
Message-ID: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>

some skins have not been guarding themselves against multiple calls to dispose (see issue for details)

Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
the controls package. Those that failed for the misbehaving skins before are passing after the fix.

-------------

Commit messages:
 - 8244112: Skin implementations: must not violate contract of dispose

Changes: https://git.openjdk.java.net/jfx/pull/209/files
 Webrev: https://webrevs.openjdk.java.net/jfx/209/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244112
  Stats: 241 lines in 7 files changed: 241 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/209.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/209/head:pull/209

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

From fastegal at openjdk.java.net  Wed May  6 11:46:27 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 6 May 2020 11:46:27 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
Message-ID: <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>

> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
> 
> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
> the controls package. Those that failed for the misbehaving skins before are passing after the fix.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  cleanup
  
  - corrected incorrect bug id in commented
  - removed unrelated test change from TextAreaTest
  - updated copyright year

published and seeing oversights ;)

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/209/files
  - new: https://git.openjdk.java.net/jfx/pull/209/files/cebeba51..fe76204d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/209/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/209/webrev.00-01

  Stats: 27 lines in 5 files changed: 0 ins; 23 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/209.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/209/head:pull/209

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

From hall0330 at hotmail.com  Wed May  6 15:13:27 2020
From: hall0330 at hotmail.com (Hall Hank)
Date: Wed, 6 May 2020 15:13:27 +0000
Subject: OpenGL (lwjgl) with JavaFX sharing same context
Message-ID: <VE1PR10MB340718AC8AB9EF23A920FF02C6A40@VE1PR10MB3407.EURPRD10.PROD.OUTLOOK.COM>

Hi again guys.
Sorry for my last email, but i thought that it was possible to attach some file.

Here is the code of the small application. I will create a github account with this part of code and the screenshot.


package sample;

import com.sun.javafx.sg.prism.NGRegion;
import com.sun.prism.Graphics;
import javafx.application.Application;
import javafx.geometry.Bounds;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.*;
import javafx.stage.Stage;
import org.lwjgl.opengl.GL;
import org.lwjgl.opengl.GL11;

import static org.lwjgl.opengl.GL11.*;

public class Main extends Application {

  @Override
  public void start(Stage primaryStage) throws Exception{

    Region glNode = new Region() {
      @Override
      public NGRegion impl_createPeer() {
        return new NGRegion() {
          boolean shouldInitLwjgl = true;

          @Override
          protected void renderContent(Graphics g) {

            // We must call this clearQuad method to flush everything.
            // I didn't find out to be able to render something without calling this method.
            g.clearQuad(0,0,1,1);
            if(shouldInitLwjgl) {
              // Extracted documentation from https://www.lwjgl.org/guide
              // "LWJGL detects the context that is current in the current thread,
              // creates the GLCapabilities instance and makes the OpenGL
              // bindings available for use."
              GL.createCapabilities();
              shouldInitLwjgl = false;
            }

            // Start to save JavaFX OpenGL context states, in order to restore it properly at the
            // end
            int[] viewport = new int[4];
            GL11.glGetIntegerv(GL11.GL_VIEWPORT, viewport);
            boolean isScissorEnabled = GL11.glIsEnabled(GL11.GL_SCISSOR_TEST);
            int[] scissor = new int[4];
            GL11.glGetIntegerv(GL11.GL_SCISSOR_BOX, scissor);
            float[] clearColors = new float[4];
            GL11.glGetFloatv(GL_COLOR_CLEAR_VALUE, clearColors);

            // Now we can start to draw but first thing to do is to enable the GL_SCISSOR_TEST
            // and put the scissor value to the bounds of the node.
            Bounds bounds = localToScene(getLayoutBounds());
            glEnable(GL_SCISSOR_TEST);
            GL11.glScissor((int)bounds.getMinX() * 2,(int)bounds.getMinY() * 2,
                    (int)getPrefWidth() * 2,(int) getPrefHeight() * 2);

            // And now we can start to draw our things. Here is just a clear color to green for the example.
            GL11.glClearColor(0.0f,1.0f,0.0f, 1.0f);
            GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
            glDisable(GL_SCISSOR_TEST);

            // At the end, we must restore the JavaFX OpenGL states
            if(isScissorEnabled) {
              glEnable(GL_SCISSOR_TEST);
              GL11.glScissor(scissor[0], scissor[1], scissor[2], scissor[3]);
            }
            GL11.glViewport(viewport[0], viewport[1], viewport[2], viewport[3]);
            GL11.glClearColor(clearColors[0], clearColors[1], clearColors[2], clearColors[3]);

            // Call super to handle children
            super.renderContent(g);
          }
        };
      }
    };

    // Here is just a simple layout in a VBox, with one button followed by one
    // OpenGL node followed by one new button
    VBox root = new VBox();
    Button button1 = new Button(("Hello 1"));
    button1.setPrefSize(100, 100);
    Button button2 = new Button(("Hello 2"));
    button2.setPrefSize(100, 100);
    root.getChildren().addAll(button1,glNode, button2);
    glNode.setPrefSize(100,100);


    primaryStage.setScene(new Scene(root, 600, 300));
    primaryStage.show();
  }


  public static void main(String[] args) {
    launch(args);
  }
}

Sorry again, and thank's for reading.

Hank.

From hall0330 at hotmail.com  Wed May  6 15:46:06 2020
From: hall0330 at hotmail.com (Hall Hank)
Date: Wed, 6 May 2020 15:46:06 +0000
Subject: OpenGL (lwjgl) with JavaFX sharing same context
Message-ID: <VE1PR10MB34078154D22A5B656577FECDC6A40@VE1PR10MB3407.EURPRD10.PROD.OUTLOOK.COM>

Last mail, sorry again for disturbing...

Here is the github repository with the sample :
https://github.com/hank0330/Opengl-javafx

Best regards,

Hank

From kevin.rushforth at oracle.com  Wed May  6 16:28:11 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 6 May 2020 09:28:11 -0700
Subject: OpenGL (lwjgl) with JavaFX sharing same context
In-Reply-To: <VE1PR10MB3407C12CD3DE3B535AA30528C6A40@VE1PR10MB3407.EURPRD10.PROD.OUTLOOK.COM>
References: <VE1PR10MB3407C12CD3DE3B535AA30528C6A40@VE1PR10MB3407.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <bb1cfd12-450e-458f-d937-dc6f275151bd@oracle.com>

Hi Hank,

Any solution that assumes OpenGL is the native rendering library is not 
something that we would consider including in JavaFX. We use DirectX to 
render on Windows, and don't build or ship the OpenGL pipeline on 
Windows (there are issues on various graphics adapters, and it isn't a 
focus of graphics vendors on Windows). Also, Apple has deprecated OpenGL 
on Mac and we will be moving to Metal in the not-to-distant future.

Even if we could assume a particular native rendering library, I don't 
believe that using the same graphics context for applications that 
JavaFX Prism uses internally is the right approach (even with saving / 
restoring the context).

I would instead recommend that you look at using the new NIO 
Buffer-based PixelBuffer [1] API added in JavaFX 13. It can be used to 
implement a less-tight coupling of a native graphics library with JavaFX 
without having to have any knowledge of what JavaFX is using as its 
renderer, or hooks into the JavaFX internals.

We could consider additional follow-on improvements to PixelBuffer as 
long as they could be done without assuming a particular native 
rendering library, and without having to rely on internal implementation 
details of Prism.

-- Kevin

[1] 
https://openjfx.io/javadoc/14/javafx.graphics/javafx/scene/image/PixelBuffer.html

On 5/6/2020 3:53 AM, Hall Hank wrote:
> Hi everyone.
>
> I'm pretty new to this mailing list so, i hope i write my email as you expect.
> I'm working on integration between OpenGL and JavaFX, and i was not really satisfied by the different library that i found on the internet. That is why, i started my own implementation by extending NGRegion (yes, it's private ??).
>
> Here is my idea :
> In the NGRegion, we are able to manage the OpenGL context created by JavaFX.
> With LWJGL, it's then pretty easy to start to draw everything we want, by sharing this context. The only thing that we MUST be careful is the opengl context state. We must first save the states, draw what we want, and then restore the previous states.
> In this way, JavaFX don't really know that we drew something with his own context.
> This implementation is approximately the same approcah as FXGL, but without GLFW and hidden window and without creating a new OpenGL context.
>
> I created a really small simple exemple that i would share with you. It's not production ready because i saved only the minimal states but this works really well for the hello world.
> In this example, i just draw a green square, just by clearing the color. (no use of glDraw here, but of course it's possible)
> I also did some advanced things with this approach, but saving/restoring a lot of states in some advanced JavaFX layout, and really it works great with very good performance.
>
> You will find my little Main.java with few line of code to illustrate the principe. If you want to launch this example you just need the lwjgl dependencies that you can download from their website.
> This example use Java 8, because i used to use it and i didn't want to have some problem due to Java 9 modules.
>
> Now, my question is : would it be possible to include something like this in openjfx if we make it production ready ?
> The interop between JavaFX & OpenGL is a recurrent question, and i think that it would be great to have a really easy solution like this directly in JavaFX.
>
> I'm really interested about your feelings.
>
> Thank you for reading.
> Best regards.
>
> Hank.
>
>


From kcr at openjdk.java.net  Wed May  6 17:39:29 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 17:39:29 GMT
Subject: RFR: 8244487: One Windows 10 SDK file missing from FX build
Message-ID: <SXttMK8EqjzIvStVnOe8udVnJS1vIhS2EvPuC4tIe3U=.0c7788ca-598a-4c8f-a768-f0f336bf37cc@github.com>

While auditing the list of redistributed Microsoft files in the JDK versus FX, I discovered one file that the JDK ships
that FX does not:

api-ms-win-core-console-l1-2-0.dll

I checked the Redist directory in the Windows 10 SDK and this is the only one we are missing.

Root cause: the current version of the Windows 10 SDK has 41 redistributable `api-ms-win-*` files. There were 40 when
we first upgraded to VS 2017 and Windows 10 SDK three years ago. We didn't reexamine the list when upgrading to a later
minor version of VS 2017 and the Windows 10 SDK.

We haven't yet seen any problems as a result, but since we are getting ready to upgrade to VS 2019 see
[JDK-8242508](https://bugs.openjdk.java.net/browse/JDK-8242508) -- we should correct this so it doesn't cause problems
in the future.

-------------

Commit messages:
 - 8244487: One Windows 10 SDK file missing from FX build

Changes: https://git.openjdk.java.net/jfx/pull/211/files
 Webrev: https://webrevs.openjdk.java.net/jfx/211/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244487
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/211.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/211/head:pull/211

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

From youngty1997 at gmail.com  Wed May  6 17:39:15 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Wed, 6 May 2020 12:39:15 -0500
Subject: Unable to allocate direct buffer memory
Message-ID: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>

After hours of running my JavaFX application I start getting this error 
spammed in console:


java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct 
buffer memory (allocated: 149066725, limit: 209715200)
 ??? at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
 ??? at 
java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:120)
 ??? at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329)
 ??? at 
javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90)
 ??? at 
javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121)
 ??? at 
javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155)
 ??? at 
javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156)
 ??? at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
 ??? at 
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
 ??? at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
 ??? at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
 ??? at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
 ??? at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
 ??? at java.base/java.lang.Thread.run(Thread.java:832)


Ironically every single error is about allocating the exact same amount 
of bytes.


From alexsch at openjdk.java.net  Wed May  6 17:45:04 2020
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Wed, 6 May 2020 17:45:04 GMT
Subject: [Integrated] RFR: 8243255: Font size is large in JavaFX app with
 enabled Monocle on Raspberry Pi
In-Reply-To: <xHVPDsK8hMo-DZGlBo8osTWAzKVs-efe2ulwqJxfxFw=.2df96814-9504-4791-9960-f3394c7b8600@github.com>
References: <xHVPDsK8hMo-DZGlBo8osTWAzKVs-efe2ulwqJxfxFw=.2df96814-9504-4791-9960-f3394c7b8600@github.com>
Message-ID: <AmOkc98zpmfejPlz1Em_UTiy7sCLEPSW3Rxf3lrFzDg=.0b7a987f-b1f3-4e06-a8dc-4d4b226818e4@github.com>

On Tue, 21 Apr 2020 16:47:44 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html
> 
> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes
> [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228)
> method code from
>> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale()
> 
>  to
>  > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()"
> 
> so the font size is not properly calculated based on the given DPI value.
> 
> I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On
> Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app
> works in the same way.

This pull request has now been integrated.

Changeset: 03855639
Author:    Alexander Scherbatiy <alexsch at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/03855639
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

Reviewed-by: kcr, jvos

-------------

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

From kcr at openjdk.java.net  Wed May  6 20:43:13 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 20:43:13 GMT
Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3
Message-ID: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>

This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019
(version 16.5.3). This will match a recent upgrade done for JDK 15 -- see
[JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214).

I have run a full build and test using this new compiler.

NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which
is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by
this PR.

-------------

Commit messages:
 - 8242508: Upgrade to Visual Studio 2019 version 16.5.3

Changes: https://git.openjdk.java.net/jfx/pull/212/files
 Webrev: https://webrevs.openjdk.java.net/jfx/212/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242508
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/212/head:pull/212

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

From kcr at openjdk.java.net  Wed May  6 20:43:13 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 20:43:13 GMT
Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3
In-Reply-To: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
References: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
Message-ID: <26zwwhWr2a2xPzdjmxcm-rnJQtcEw1umctWoBlb1jhA=.1fed8c0a-d20e-4a45-9309-136df41d89b6@github.com>

On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019
> (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see
> [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214).  I have run a full build and test using this new
> compiler.
> NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which
> is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by
> this PR.

@arapte can you also review this?

-------------

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

From kcr at openjdk.java.net  Wed May  6 23:20:45 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 23:20:45 GMT
Subject: RFR: 8244421: Wrong scrollbar position on touch enabled devices
In-Reply-To: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
References: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
Message-ID: <0dE3GCGOZ366xvorCEVIJUkf4GxIrD9aH0uBixlxH4c=.448f0157-d18a-494d-b323-7c686b8d9e41@github.com>

On Tue, 5 May 2020 16:49:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out next to the clipped container region, by
> default.
> However, when touch is supported, these scrollBars are floating controls laid out over the container. Therefore, in
> this case, when the viewport dimensions are updated, the presence of the scrollBars shouldn't be taken into account.

@aghaisas can you also take a look?

-------------

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

From kcr at openjdk.java.net  Wed May  6 23:20:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 23:20:46 GMT
Subject: RFR: 8244421: Wrong scrollbar position on touch enabled devices
In-Reply-To: <0dE3GCGOZ366xvorCEVIJUkf4GxIrD9aH0uBixlxH4c=.448f0157-d18a-494d-b323-7c686b8d9e41@github.com>
References: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
 <0dE3GCGOZ366xvorCEVIJUkf4GxIrD9aH0uBixlxH4c=.448f0157-d18a-494d-b323-7c686b8d9e41@github.com>
Message-ID: <DB7foRcOykyJ-ivTSvaqwQ14TU7TUJH3pOr60adOwmw=.febffb0d-8342-4cb9-b200-a2fa6d2d479f@github.com>

On Wed, 6 May 2020 23:16:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out next to the clipped container region, by
>> default.
>> However, when touch is supported, these scrollBars are floating controls laid out over the container. Therefore, in
>> this case, when the viewport dimensions are updated, the presence of the scrollBars shouldn't be taken into account.
>
> @aghaisas can you also take a look?

I've asked Ajit to review it (and I presume Johan will review as well?)

It looks like a safe enough fix. Have you tested it on multiple platforms?

-------------

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

From kcr at openjdk.java.net  Wed May  6 23:21:36 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 23:21:36 GMT
Subject: RFR: 8242001: ChoiceBox: must update value on setting
 SelectionModel, part2
In-Reply-To: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>
References: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>
Message-ID: <8R0OZW8ql12266GMUcxSIs-nOg03cT1dvDWsnHfkCkU=.0387cdec-dd46-42ff-9765-815e7c47ffed@github.com>

On Tue, 5 May 2020 10:50:40 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The issue is that ChoiceBox didn't sync its value to the replaced SelectionModel's selectedItem if the item is null.
> 
> Fixed by removing the constraint from selectionModel property.
> 
> Added tests that failed before and passed after the fix. Note that I also changed a test method in ChoiceBoxTest with
> an incorrect test assumption (which passed for the incorrect implementation).

@aghaisas I presume you will review this (as with the earlier fix it probably doesn't need two reviewers)?

-------------

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

From kcr at openjdk.java.net  Wed May  6 23:23:01 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 May 2020 23:23:01 GMT
Subject: [Rev 02] RFR: 8244297: memory leak test utility
In-Reply-To: <GhyJ65tZJtHW0LyMba2QHQOphRdvJu15barGB-ajBSI=.a7d5fe51-9445-41da-aa49-8768b4fc4e4b@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
 <GhyJ65tZJtHW0LyMba2QHQOphRdvJu15barGB-ajBSI=.a7d5fe51-9445-41da-aa49-8768b4fc4e4b@github.com>
Message-ID: <4QDN0xqqZ2ys4LIe0O__NFL_lz7RZcJ3o9EsICqLn-0=.5e3f5471-4560-4330-b4be-1901337a9a03@github.com>

On Tue, 5 May 2020 11:55:41 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 145:
>> 
>>> 144:
>>> 145:     public static void createHeapDump() {
>>> 146:         try {
>> 
>> I don't think we want automatic creation of heap dumps by our unit test suite. That would need a larger discussion. I
>> recommend to either comment this out, or else to qualify it with a system property that could be passed in via a
>> `gradle` property (e.g., as is done for `UNSTABLE_TEST`), with a default of `false`.
>
> I've made it configurable in the Library with system-parameters and I've changed the default not create a heap dump.
> Is that ok?

Yes, that seems fine.

>> modules/javafx.base/src/test/java/de/sandec/jmemorybuddy/JMemoryBuddy.java line 15:
>> 
>>> 14:
>>> 15: public class JMemoryBuddy {
>>> 16:
>> 
>> Since this is a utility intended to be used by various tests, it would be very helpful to add some documentation about
>> how to use it.
>
> Where/How should I add the documentation? Ideally, I would reference the documentation of the project itself.

A javadoc comment right before the class declaration is fine. It can be short.

-------------

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

From github.com+1413266+jgneff at openjdk.java.net  Wed May  6 23:47:08 2020
From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 6 May 2020 23:47:08 GMT
Subject: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6
 devices
In-Reply-To: <coIm5qrZy3NNHlTcD3iAI_gmgZFs1fe_yignOzOqiJE=.2b73131f-359d-4640-80f8-8031175ea73a@github.com>
References: <dsOXhfyXVom4Nd6LGGBZbXc-W58RwUG_7AtUy9JiE0c=.e682c202-ecdc-4030-9a4c-15bb18eb478b@github.com>
 <JM1QDPp-uZNtZuwF3K7XvYX_gYtwJkfTjuzcgPij_Aw=.f2f3de1c-b399-4566-a4f0-50a4c1a277d3@github.com>
 <coIm5qrZy3NNHlTcD3iAI_gmgZFs1fe_yignOzOqiJE=.2b73131f-359d-4640-80f8-8031175ea73a@github.com>
Message-ID: <EKu0q0GcE6u_QDPTHLc9JoZwp3GiSkvpVQihiCdjT1k=.25b92eb3-35e4-4f0d-bd8c-76d16cdfc156@github.com>

On Tue, 28 Apr 2020 23:33:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Neffenger 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.
>
> Looks good to me.

> Below are some of the more interesting test results.
> * The OpenJDK 11 package ... runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the tests. ... I plan
>   to investigate the cause of the performance difference.

This is just a note to follow up on that performance problem I saw in December. I think I found the cause of the
problem, and it appears to be fixed in JDK 14 and 15.

The chart below shows the drastic drop in performance before the fix.

![clarahd-focal-copyTo16-2019-12-16](https://user-images.githubusercontent.com/1413266/81237529-b7dfbc80-8fb4-11ea-9673-11e552ecf991.png)

The following flame graph, created by async-profiler, led quickly to an existing Java bug report.

![java-13-openjdk-armhf-600x](https://user-images.githubusercontent.com/1413266/81237598-ea89b500-8fb4-11ea-8928-3b527cf6ac12.png)

See the description at [JDK 13 Performance](https://jgneff.github.io/framebufferY8/2020-05/#jdk-13-performance) for
details. Thank you for the quick fix, @voitylov!

-------------

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

From jpereda at openjdk.java.net  Thu May  7 09:38:15 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Thu, 7 May 2020 09:38:15 GMT
Subject: RFR: 8244421: Wrong scrollbar position on touch enabled devices
In-Reply-To: <DB7foRcOykyJ-ivTSvaqwQ14TU7TUJH3pOr60adOwmw=.febffb0d-8342-4cb9-b200-a2fa6d2d479f@github.com>
References: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
 <0dE3GCGOZ366xvorCEVIJUkf4GxIrD9aH0uBixlxH4c=.448f0157-d18a-494d-b323-7c686b8d9e41@github.com>
 <DB7foRcOykyJ-ivTSvaqwQ14TU7TUJH3pOr60adOwmw=.febffb0d-8342-4cb9-b200-a2fa6d2d479f@github.com>
Message-ID: <g4p9W6pNr-MX7oSyuUb8BItHVbmXzyNSZiyVA0w3OAg=.1811e260-2aaa-4e72-be1b-8d0dbeb59953@github.com>

On Wed, 6 May 2020 23:18:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @aghaisas can you also take a look?
>
> I've asked Ajit to review it (and I presume Johan will review as well?)
> 
> It looks like a safe enough fix. Have you tested it on multiple platforms?

Yes, I've tested on Mac OS and Linux (with or without `-Dcom.sun.javafx.touch=true`), and also on Android and iOS.

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Thu May  7 10:04:01 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Thu, 7 May 2020 10:04:01 GMT
Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect
Message-ID: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>

Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
otherwise use usual way of rendering.

-------------

Commit messages:
 - Formatting correction (Line Endings)
 - removed executable file mode
 - Added unit test + SW Graphics rendering part
 - Pixel scale issue fix
 - 8218973: SVG with masking is not rendering image with mask effect

Changes: https://git.openjdk.java.net/jfx/pull/213/files
 Webrev: https://webrevs.openjdk.java.net/jfx/213/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8218973
  Stats: 132 lines in 6 files changed: 130 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/213.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213

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

From jvos at openjdk.java.net  Thu May  7 12:03:20 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 7 May 2020 12:03:20 GMT
Subject: RFR: 8244421: Wrong scrollbar position on touch enabled devices
In-Reply-To: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
References: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
Message-ID: <TTiAKfUE62xYf_sNwYKiYNfI8pspTVMqxK2bvMZ8YWU=.198112dc-7681-4587-be5b-5a704ca5aad7@github.com>

On Tue, 5 May 2020 16:49:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out next to the clipped container region, by
> default.
> However, when touch is supported, these scrollBars are floating controls laid out over the container. Therefore, in
> this case, when the viewport dimensions are updated, the presence of the scrollBars shouldn't be taken into account.

I confirm this fixes JBS-8244421

-------------

Marked as reviewed by jvos (Reviewer).

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

From fkirmaier at openjdk.java.net  Thu May  7 16:08:26 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 7 May 2020 16:08:26 GMT
Subject: [Rev 03] RFR: 8244297: memory leak test utility
In-Reply-To: <4QDN0xqqZ2ys4LIe0O__NFL_lz7RZcJ3o9EsICqLn-0=.5e3f5471-4560-4330-b4be-1901337a9a03@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
 <GhyJ65tZJtHW0LyMba2QHQOphRdvJu15barGB-ajBSI=.a7d5fe51-9445-41da-aa49-8768b4fc4e4b@github.com>
 <4QDN0xqqZ2ys4LIe0O__NFL_lz7RZcJ3o9EsICqLn-0=.5e3f5471-4560-4330-b4be-1901337a9a03@github.com>
Message-ID: <wjiBE8a9yBCKMTK7xC_eNfamXaL2Zy9e4bGa3x7zgwk=.56413990-9043-440b-bb8d-083b031b9c5f@github.com>

On Wed, 6 May 2020 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Where/How should I add the documentation? Ideally, I would reference the documentation of the project itself.
>
> A javadoc comment right before the class declaration is fine. It can be short.

Done

-------------

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

From fkirmaier at openjdk.java.net  Thu May  7 16:08:25 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 7 May 2020 16:08:25 GMT
Subject: [Rev 03] RFR: 8244297: memory leak test utility
In-Reply-To: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
Message-ID: <wbLoTDgLw6DtJRP6iqUwTXUVlZByGxgX_wsNaS_FU64=.4a5d444a-84bf-42c3-946b-37561bd58cc6@github.com>

> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71
> 
> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests.
> 
> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes.
> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very
> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but
> the tests with JMemoryBuddy are basically always correct.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8244297
  Improved the JavaDoc for JMemoryBuddy

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/204/files
  - new: https://git.openjdk.java.net/jfx/pull/204/files/72d12283..08528777

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/204/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/204/webrev.02-03

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

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

From jvos at openjdk.java.net  Thu May  7 16:17:32 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 7 May 2020 16:17:32 GMT
Subject: RFR: 8244487: One Windows 10 SDK file missing from FX build
In-Reply-To: <SXttMK8EqjzIvStVnOe8udVnJS1vIhS2EvPuC4tIe3U=.0c7788ca-598a-4c8f-a768-f0f336bf37cc@github.com>
References: <SXttMK8EqjzIvStVnOe8udVnJS1vIhS2EvPuC4tIe3U=.0c7788ca-598a-4c8f-a768-f0f336bf37cc@github.com>
Message-ID: <9-dn5fH-XVW4B_jm3cavNF1d0_oL9p6mPU0KS0-48do=.4b1ffbb5-cd65-4d7c-acb6-5db36b860816@github.com>

On Wed, 6 May 2020 17:34:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> While auditing the list of redistributed Microsoft files in the JDK versus FX, I discovered one file that the JDK ships
> that FX does not:
> api-ms-win-core-console-l1-2-0.dll
> 
> I checked the Redist directory in the Windows 10 SDK and this is the only one we are missing.
> 
> Root cause: the current version of the Windows 10 SDK has 41 redistributable `api-ms-win-*` files. There were 40 when
> we first upgraded to VS 2017 and Windows 10 SDK three years ago. We didn't reexamine the list when upgrading to a later
> minor version of VS 2017 and the Windows 10 SDK.  We haven't yet seen any problems as a result, but since we are
> getting ready to upgrade to VS 2019 see [JDK-8242508](https://bugs.openjdk.java.net/browse/JDK-8242508) -- we should
> correct this so it doesn't cause problems in the future.

Marked as reviewed by jvos (Reviewer).

-------------

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

From github.com+2720909+jskov at openjdk.java.net  Thu May  7 17:01:07 2020
From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov)
Date: Thu, 7 May 2020 17:01:07 GMT
Subject: [Rev 03] RFR: 8244297: memory leak test utility
In-Reply-To: <C2M2G-_X5ZcJYfun3QgSSgjmyNd1Y2ta0E_RtWoHWw4=.701461e6-c432-46fa-8faf-dc7fff4aa528@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
 <YzE1q_oaO0g5rDxsTQnjBMuEfs4natQBwDSXATTXx-c=.276de799-67bd-4f9d-8052-77507fd01502@github.com>
 <QQJBaOACUIK3G5Q53c5fW2Dx7QZWxJ-iR4V_R5JUkMs=.f92ecf43-1d5c-431b-8a5d-f12a43596312@github.com>
 <C2M2G-_X5ZcJYfun3QgSSgjmyNd1Y2ta0E_RtWoHWw4=.701461e6-c432-46fa-8faf-dc7fff4aa528@github.com>
Message-ID: <nNwdrpWzI00fbwZXqzrcxvVdM-cwlTJsgrxAwSAHIxc=.4d116051-933d-4b52-a6fa-c29915ee6b54@github.com>

On Tue, 5 May 2020 20:39:18 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> It's also worth mentioning that this utility allows checking whether an object can not be collected. This is important
>> because the applications, which are using WeakReferences/WeakListeners often introduce bugs that are hard to debug
>> because they only happen after the GC has been run.
>
> I've now added also some JavaDoc to the public methods.

What I tried asking from my work account is: what is the purpose of createGarbage?

-------------

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

From fkirmaier at openjdk.java.net  Thu May  7 18:18:38 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 7 May 2020 18:18:38 GMT
Subject: [Rev 03] RFR: 8244297: memory leak test utility
In-Reply-To: <nNwdrpWzI00fbwZXqzrcxvVdM-cwlTJsgrxAwSAHIxc=.4d116051-933d-4b52-a6fa-c29915ee6b54@github.com>
References: <kPsxpibpczCPBrReqOTsjGc1HiaQwOrfDXHjchG-sQI=.4a604de7-262f-404a-b6b2-c086a4041170@github.com>
 <kpCOpEHTpqoe8bz6W_whuPj3fCOmDVa3gtOTHkgxfgk=.50274afc-7a45-4a94-afd7-57a06ee8a55d@github.com>
 <YzE1q_oaO0g5rDxsTQnjBMuEfs4natQBwDSXATTXx-c=.276de799-67bd-4f9d-8052-77507fd01502@github.com>
 <QQJBaOACUIK3G5Q53c5fW2Dx7QZWxJ-iR4V_R5JUkMs=.f92ecf43-1d5c-431b-8a5d-f12a43596312@github.com>
 <C2M2G-_X5ZcJYfun3QgSSgjmyNd1Y2ta0E_RtWoHWw4=.701461e6-c432-46fa-8faf-dc7fff4aa528@github.com>
 <nNwdrpWzI00fbwZXqzrcxvVdM-cwlTJsgrxAwSAHIxc=.4d116051-933d-4b52-a6fa-c29915ee6b54@github.com>
Message-ID: <Jdlolt5ZpWfseENZ8kvbhWNtMyb0TPmAhjEEFvZmQ7w=.4a42064f-4312-484a-9096-19a785a6766c@github.com>

On Thu, 7 May 2020 16:58:52 GMT, Jesper Skov <github.com+2720909+jskov at openjdk.org> wrote:

>> I've now added also some JavaDoc to the public methods.
>
> What I tried asking from my work account is: what is the purpose of createGarbage?

The createGarbage method stimulates the GC. All unit tests are green without it, but according to my memory some tests
in an earlier version of this library were unstable without this. I can also change the configuration to create 0
garbage.

-------------

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

From youngty1997 at gmail.com  Thu May  7 18:51:14 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 7 May 2020 13:51:14 -0500
Subject: Unable to allocate direct buffer memory
In-Reply-To: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
References: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
Message-ID: <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>


On 5/6/20 12:39 PM, Ty Young wrote:
> After hours of running my JavaFX application I start getting this 
> error spammed in console:
>
>
> java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct 
> buffer memory (allocated: 149066725, limit: 209715200)
> ??? at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
> ??? at 
> java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:120)
> ??? at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329)
> ??? at 
> javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90)
> ??? at 
> javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121)
> ??? at 
> javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155)
> ??? at 
> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156)
> ??? at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> ??? at 
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> ??? at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> ??? at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> ??? at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> ??? at 
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
> ??? at java.base/java.lang.Thread.run(Thread.java:832)
>
>
> Ironically every single error is about allocating the exact same 
> amount of bytes.


Anything on this? I'm also getting:


java.lang.RuntimeException: Requested texture dimensions (32767x1137) 
require dimensions (0x1137) that exceed maximum texture size (16384)
 ??? at 
javafx.graphics/com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
 ??? at 
javafx.graphics/com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:165)
 ??? at 
javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:124)
 ??? at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
 ??? at 
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
 ??? at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
 ??? at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
 ??? at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
 ??? at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
 ??? at java.base/java.lang.Thread.run(Thread.java:832)


spammed alternatively.


From jvos at openjdk.java.net  Thu May  7 19:44:32 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 7 May 2020 19:44:32 GMT
Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3
In-Reply-To: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
References: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
Message-ID: <zQ_srXYvAwcspD4XXXTkkgG2JLw31P5W7GOsF-Blv-k=.763c6ab1-4ed6-46f7-9d6c-505732ef5a2f@github.com>

On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019
> (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see
> [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214).  I have run a full build and test using this new
> compiler.
> NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which
> is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by
> this PR.

Confirmed to work on our build system.

-------------

Marked as reviewed by jvos (Reviewer).

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

From kevin.rushforth at oracle.com  Thu May  7 20:44:41 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 7 May 2020 13:44:41 -0700
Subject: Unable to allocate direct buffer memory
In-Reply-To: <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
References: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
 <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
Message-ID: <cec5b299-a6a6-138d-830d-da43aa774083@oracle.com>

This suggests that there might be a memory leak (possibly in uploading 
painter which I see you are using). Is this easily reproducible?

As for the other exception:

> java.lang.RuntimeException: Requested texture dimensions (32767x1137) 
> require dimensions (0x1137) that exceed maximum texture size (16384) 

Are you really trying to draw into a texture that big? If not, then 
either the error message is printing the wrong sizes (which is quite 
possible) or else something is causing a larger than expected size to be 
used.

-- Kevin


On 5/7/2020 11:51 AM, Ty Young wrote:
>
> On 5/6/20 12:39 PM, Ty Young wrote:
>> After hours of running my JavaFX application I start getting this 
>> error spammed in console:
>>
>>
>> java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct 
>> buffer memory (allocated: 149066725, limit: 209715200)
>> ??? at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
>> ??? at 
>> java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:120)
>> ??? at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329)
>> ??? at 
>> javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90)
>> ??? at 
>> javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121)
>> ??? at 
>> javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155)
>> ??? at 
>> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156)
>> ??? at 
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>> ??? at 
>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
>> ??? at 
>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>> ??? at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>> ??? at 
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>> ??? at 
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
>> ??? at java.base/java.lang.Thread.run(Thread.java:832)
>>
>>
>> Ironically every single error is about allocating the exact same 
>> amount of bytes.
>
>
> Anything on this? I'm also getting:
>
>
> java.lang.RuntimeException: Requested texture dimensions (32767x1137) 
> require dimensions (0x1137) that exceed maximum texture size (16384)
> ??? at 
> javafx.graphics/com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
> ??? at 
> javafx.graphics/com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:165)
> ??? at 
> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:124)
> ??? at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> ??? at 
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> ??? at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> ??? at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> ??? at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> ??? at 
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
> ??? at java.base/java.lang.Thread.run(Thread.java:832)
>
>
> spammed alternatively.
>


From youngty1997 at gmail.com  Thu May  7 21:26:36 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 7 May 2020 16:26:36 -0500
Subject: Unable to allocate direct buffer memory
In-Reply-To: <cec5b299-a6a6-138d-830d-da43aa774083@oracle.com>
References: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
 <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
 <cec5b299-a6a6-138d-830d-da43aa774083@oracle.com>
Message-ID: <747b5663-8668-956d-7fda-a705be0aeffc@gmail.com>


On 5/7/20 3:44 PM, Kevin Rushforth wrote:
> This suggests that there might be a memory leak (possibly in uploading 
> painter which I see you are using). Is this easily reproducible?


Easily? No. I seem to get either(AKA never both) only after hours of 
having the application running. Nothing seems to break either, making it 
very strange. I don't remember getting these exceptions in JavaFX 13, 
just warnings about texture size(which I think others have reported here 
too).


Although, I should say, I'm using Project Panama's Foreign Memory Access 
builds and those can corrupt memory if used incorrectly. That said, 
given that the texture size issue was reported here before in JavaFX 13 
and before IIRC, I'm not so sure that is the issue.


>
> As for the other exception:
>
>> java.lang.RuntimeException: Requested texture dimensions (32767x1137) 
>> require dimensions (0x1137) that exceed maximum texture size (16384) 
>
> Are you really trying to draw into a texture that big? If not, then 
> either the error message is printing the wrong sizes (which is quite 
> possible) or else something is causing a larger than expected size to 
> be used.


Uh, I use Integer.MAX_VALUE for prefered width/height, not 
Short.MAX_VALUE. I don't know where 32767(Short.MAX_VALUE) is coming 
from, I never explicitly request those dimensions.


Could the screen being locked and the screen being off have to do with this?


>
> -- Kevin
>
>
> On 5/7/2020 11:51 AM, Ty Young wrote:
>>
>> On 5/6/20 12:39 PM, Ty Young wrote:
>>> After hours of running my JavaFX application I start getting this 
>>> error spammed in console:
>>>
>>>
>>> java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct 
>>> buffer memory (allocated: 149066725, limit: 209715200)
>>> ??? at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
>>> ??? at 
>>> java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:120)
>>> ??? at 
>>> java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329)
>>> ??? at 
>>> javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90)
>>> ??? at 
>>> javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121)
>>> ??? at 
>>> javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155)
>>> ??? at 
>>> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156)
>>> ??? at 
>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>> ??? at 
>>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
>>> ??? at 
>>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>>> ??? at 
>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>>> ??? at 
>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>>> ??? at 
>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
>>> ??? at java.base/java.lang.Thread.run(Thread.java:832)
>>>
>>>
>>> Ironically every single error is about allocating the exact same 
>>> amount of bytes.
>>
>>
>> Anything on this? I'm also getting:
>>
>>
>> java.lang.RuntimeException: Requested texture dimensions (32767x1137) 
>> require dimensions (0x1137) that exceed maximum texture size (16384)
>> ??? at 
>> javafx.graphics/com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
>> ??? at 
>> javafx.graphics/com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:165)
>> ??? at 
>> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:124)
>> ??? at 
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>> ??? at 
>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
>> ??? at 
>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>> ??? at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>> ??? at 
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>> ??? at 
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
>> ??? at java.base/java.lang.Thread.run(Thread.java:832)
>>
>>
>> spammed alternatively.
>>
>

From sykora at openjdk.java.net  Fri May  8 07:16:32 2020
From: sykora at openjdk.java.net (Joeri Sykora)
Date: Fri, 8 May 2020 07:16:32 GMT
Subject: RFR: 8244417: support static build for Windows
Message-ID: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>

Adds support for building static libraries of the OpenJFX modules for the Windows platform. Building static libraries
is done by providing the gradle property `-PSTATIC_BUILD=true`.

Changes include:

- add static flags for the compiler and linker
- use `lib` for linking instead of `link`
- only build and include version.rc once (from GlassResources.rc)
- include library specific `JNI_OnLoad_xxx` methods
- functionality loaded via `DllMain` has been implemented at a different location

-------------

Commit messages:
 - 8244417: support static build for Windows

Changes: https://git.openjdk.java.net/jfx/pull/214/files
 Webrev: https://webrevs.openjdk.java.net/jfx/214/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244417
  Stats: 83 lines in 9 files changed: 69 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jfx/pull/214.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/214/head:pull/214

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

From jfxuser2 at gmail.com  Fri May  8 07:38:43 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 03:38:43 -0400
Subject: com.sun.javafx vs javafx (with example/request)
Message-ID: <CAHifg5d8i=E9X-mEJJgorg8kWLbUjxPF9+05N4r+HDHvfmCMxA@mail.gmail.com>

Is there documentation around the packages (com.sun.javafx vs javafx) used
in JavaFX?

For example, why is there a com.sun.javafx.geom that isn't fully mirrored
in the javafx.scene.shape package?  Why are there missing features from
Graphics2D?

I have a specific example that prompted the question:

Consider the following classes:

javafx.scene.shape.Shape
    private static Path
createFromGeomShape(com.sunjavafx.geom.Shape geomShape)

javafx.scene.canvas.GraphicsContext
    Path2D path;

I want to write a line as follows:
Path path = Path.createFromGeomShape(gc.path);
b/c I want to inexpensively get the outline of the GraphicsContext.

However:
We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
by the module.
We can't access Path.createFromGeomShape b/c it's private.
We can't access path in GraphicsContext b/c it's default and doesn't have
an accessor.

A possible solution is to add a new method:
javafx.scene.canvas.GraphicsContext
public Path getPath() {
    //implementation copied from
javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
}

That would solve my immediate problem but raises the question... why is
com.sun.javafx hidden?  What's the architectural reason?  Is there any work
in progress that will impact this design?

PS my example is actually very important.  I currently use reflection and
module opens in the build to get the path but if the getPath method could
be added to GraphicsContext, that would be great.  For performance, it
would be even better to get the PathIterator directly instead of
translating into a javafx..Path but that is related to the bigger question.

From jfxuser2 at gmail.com  Fri May  8 08:18:54 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 04:18:54 -0400
Subject: HID multitouch display support in JavaFX
Message-ID: <CAHifg5f7S8uWcj3w+SabM-FkAD_iuaMOPpa55pQUGFnvoiUXSA@mail.gmail.com>

Multitouch display support JavaFX on Windows, iOS, and Android seems
straightforward.  If the OS recognizes the display as multitouch, then the
chances are that JavaFX will also work with it since it relies on the
native multitouch support of the OS.

When it comes to Linux and OSX, it's not always as easy.  Linux sometimes
requires device mapping.  I'm not sure if it works at all in OSX unless you
have specific drivers for the display.

All of the platforms seem to support HID so maybe JavaFX could have direct
support for HID devices (optionally) if they are present instead of just
the current method.  It may also improve performance in cases where the OS
is just piping HID events through their own API's to support multitouch.
Why not just go straight to the HID source and bypass that conduit.

This would vastly improve multitouch app development on OSX.  It would be
possible to connect a HID display and use it for testing apps that are
destined for platforms that formally support multitouch.

Is there any work being done in this area?  Is there a bigger picture (e.g.
better multi-display and connect/disconnect support in JavaFX)?

... coming from a frustrated OSX user with lots of HID displays and no easy
JavaFX support.

https://www.usb.org/hid

From aghaisas at openjdk.java.net  Fri May  8 09:23:33 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 8 May 2020 09:23:33 GMT
Subject: RFR: 8244421: Wrong scrollbar position on touch enabled devices
In-Reply-To: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
References: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
Message-ID: <HwEBScVLd99fBgsaJ82tLA7Q4V95cJS2TmewPP2oLQo=.f1428fb5-4bd1-44c1-b207-da6691c82060@github.com>

On Tue, 5 May 2020 16:49:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out next to the clipped container region, by
> default.
> However, when touch is supported, these scrollBars are floating controls laid out over the container. Therefore, in
> this case, when the viewport dimensions are updated, the presence of the scrollBars shouldn't be taken into account.

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From jpereda at openjdk.java.net  Fri May  8 09:29:31 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 8 May 2020 09:29:31 GMT
Subject: [Integrated] RFR: 8244421: Wrong scrollbar position on touch
 enabled devices
In-Reply-To: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
References: <INlFOUagdBO_TRlIY9d1wfPMNS1Ow62Umm4_xwJ4yn4=.c83e5016-c41a-47ad-a03b-af70556f4006@github.com>
Message-ID: <ddhdMALOONUJfhpHLtjdp6dNj8pOxJRjS4_r1eKCnQs=.2172ec03-0c0f-4550-b1d4-0303c9d2b002@github.com>

On Tue, 5 May 2020 16:49:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out next to the clipped container region, by
> default.
> However, when touch is supported, these scrollBars are floating controls laid out over the container. Therefore, in
> this case, when the viewport dimensions are updated, the presence of the scrollBars shouldn't be taken into account.

This pull request has now been integrated.

Changeset: 236e2d6e
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/236e2d6e
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8244421: Wrong scrollbar position on touch enabled devices

Reviewed-by: jvos, aghaisas

-------------

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

From aghaisas at openjdk.java.net  Fri May  8 10:16:09 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 8 May 2020 10:16:09 GMT
Subject: RFR: 8242001: ChoiceBox: must update value on setting
 SelectionModel, part2
In-Reply-To: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>
References: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>
Message-ID: <7OnlejVBv4n04UihiXyLxtPeEQgdDBxgHx8MZFFaXKU=.0f9d4b45-49e5-4268-8885-281f411d4efa@github.com>

On Tue, 5 May 2020 10:50:40 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The issue is that ChoiceBox didn't sync its value to the replaced SelectionModel's selectedItem if the item is null.
> 
> Fixed by removing the constraint from selectionModel property.
> 
> Added tests that failed before and passed after the fix. Note that I also changed a test method in ChoiceBoxTest with
> an incorrect test assumption (which passed for the incorrect implementation).

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From jpereda at openjdk.java.net  Fri May  8 11:30:55 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 8 May 2020 11:30:55 GMT
Subject: RFR: 8244647: Wrong first layout pass of Scrollbar controls on touch
 supported devices
Message-ID: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>

There is a visual glitch when the scrollbar controls are laid out on touch enabled devices.

The first time they are laid out in the wrong location (20 px from right or bottom), while the next passes are correct
(8 px from right or bottom).

The reason for this glitch is the use of `getWidth()` or `getHeight()` in the `resizeRelocate` calls to relocate the
bars before the controls have been properly resized yet: The initial w/h values are set to the default (20 px / 100
px), while the pref values are correctly set to 8 px.

This PR fixes that, by using the same prefWidth/prefHeight for both resizing and relocating.

It has been tested on Mac OS and Linux (with `-Dcom.sun.javafx.touch=true`), and on Android and iOS.

-------------

Commit messages:
 - Use prefWidth/prefHeight to relocate scrollbars if touch is supported

Changes: https://git.openjdk.java.net/jfx/pull/215/files
 Webrev: https://webrevs.openjdk.java.net/jfx/215/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244647
  Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/215.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/215/head:pull/215

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

From fastegal at openjdk.java.net  Fri May  8 12:28:04 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 8 May 2020 12:28:04 GMT
Subject: [Integrated] RFR: 8242001: ChoiceBox: must update value on
 setting SelectionModel, part2
In-Reply-To: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>
References: <LQFiloaMwrHY5X8aCq_MF4Epqpyxw9a9mvqc2GFjZto=.7afebc50-89ac-446d-b995-1b4c4fe7d52b@github.com>
Message-ID: <EGAQYL8sR3S_63Cn0haeamCde9Md73xiJSlrdQ9hY_0=.5a57e626-9994-4a00-8168-130de61ff31d@github.com>

On Tue, 5 May 2020 10:50:40 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The issue is that ChoiceBox didn't sync its value to the replaced SelectionModel's selectedItem if the item is null.
> 
> Fixed by removing the constraint from selectionModel property.
> 
> Added tests that failed before and passed after the fix. Note that I also changed a test method in ChoiceBoxTest with
> an incorrect test assumption (which passed for the incorrect implementation).

This pull request has now been integrated.

Changeset: 4ec163df
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/4ec163df
Stats:     46 lines in 3 files changed: 1 ins; 42 del; 3 mod

8242001: ChoiceBox: must update value on setting SelectionModel, part2

Reviewed-by: aghaisas

-------------

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

From aghaisas at openjdk.java.net  Fri May  8 12:28:19 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 8 May 2020 12:28:19 GMT
Subject: RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar
Message-ID: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>

Issue :
https://bugs.openjdk.java.net/browse/JDK-8244418

Root Cause :
Incorrect assumption about menu list size.

Fix :
Added check for empty menu list before trying to access it.

Test :
Added a unit test that fails before fix and passes after it.

-------------

Commit messages:
 - 8244418_fix

Changes: https://git.openjdk.java.net/jfx/pull/216/files
 Webrev: https://webrevs.openjdk.java.net/jfx/216/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244418
  Stats: 28 lines in 2 files changed: 22 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/216.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/216/head:pull/216

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

From nlisker at openjdk.java.net  Fri May  8 12:36:41 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 8 May 2020 12:36:41 GMT
Subject: [Rev 04] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
Message-ID: <KPKyCOYnfhLoapWWgckuPsu6pBU_-Moj8L2KNHPXZD4=.bc366ba7-9b8e-4b3a-99c6-7b2d5fc702ed@github.com>

> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264

Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 11 commits:

 - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight
 - Attenuation and range changed internally to floats from doubles
 - Fixed shader compilation errors for 2 and 3 lights in es2
 - Addressing review comments
 - Fixed whitespaces
 - Correction for indexes
 - Docs and year update
 - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into
   8217472_Add_attenuation_for_PointLight
 - GL pipeline
 - Separate range from attenuation
 - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed

-------------

Changes: https://git.openjdk.java.net/jfx/pull/43/files
 Webrev: https://webrevs.openjdk.java.net/jfx/43/webrev.04
  Stats: 501 lines in 27 files changed: 391 ins; 13 del; 97 mod
  Patch: https://git.openjdk.java.net/jfx/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43

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

From kevin.rushforth at oracle.com  Fri May  8 13:37:09 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 May 2020 06:37:09 -0700
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <CAHifg5d8i=E9X-mEJJgorg8kWLbUjxPF9+05N4r+HDHvfmCMxA@mail.gmail.com>
References: <CAHifg5d8i=E9X-mEJJgorg8kWLbUjxPF9+05N4r+HDHvfmCMxA@mail.gmail.com>
Message-ID: <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>

Only javafx.* packages are part of the public API. Anything else, 
including com.sun.javafx.*, is internal implementation details that an 
application should never call.

-- Kevin


On 5/8/2020 12:38 AM, jfx user2 wrote:
> Is there documentation around the packages (com.sun.javafx vs javafx) used
> in JavaFX?
>
> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
> in the javafx.scene.shape package?  Why are there missing features from
> Graphics2D?
>
> I have a specific example that prompted the question:
>
> Consider the following classes:
>
> javafx.scene.shape.Shape
>      private static Path
> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>
> javafx.scene.canvas.GraphicsContext
>      Path2D path;
>
> I want to write a line as follows:
> Path path = Path.createFromGeomShape(gc.path);
> b/c I want to inexpensively get the outline of the GraphicsContext.
>
> However:
> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
> by the module.
> We can't access Path.createFromGeomShape b/c it's private.
> We can't access path in GraphicsContext b/c it's default and doesn't have
> an accessor.
>
> A possible solution is to add a new method:
> javafx.scene.canvas.GraphicsContext
> public Path getPath() {
>      //implementation copied from
> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
> }
>
> That would solve my immediate problem but raises the question... why is
> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
> in progress that will impact this design?
>
> PS my example is actually very important.  I currently use reflection and
> module opens in the build to get the path but if the getPath method could
> be added to GraphicsContext, that would be great.  For performance, it
> would be even better to get the PathIterator directly instead of
> translating into a javafx..Path but that is related to the bigger question.


From fastegal at openjdk.java.net  Fri May  8 13:54:58 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 8 May 2020 13:54:58 GMT
Subject: RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar
In-Reply-To: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
Message-ID: <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>

On Fri, 8 May 2020 12:21:48 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244418
> 
> Root Cause :
> Incorrect assumption about menu list size.
> 
> Fix :
> Added check for empty menu list before trying to access it.
> 
> Test :
> Added a unit test that fails before fix and passes after it.

looks good - just two inline questions :)

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 307:

> 306:                 unSelectMenus();
> 307:                 if (!container.getChildren().isEmpty()) {
> 308:                     menuModeStart(0);

wondering whether this would be an appropriate time to simplify the logic a bit: as unSelectMenus is called in both if
and else block, it could be condensed to

    unSelectMenus();
    if (t1 && !container.getChildren().isEmpty()) {
       ...
    }

might overlook something, though

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 485:

> 484:         }
> 485:
> 486:         if (focusedMenu != null && focusedMenuIndex != -1) {

don't quite understand why this change is necessary? The guard in the listener seems to be enough, at least the test
passes without this. If it's needed to fix another potentially breaking path to this, would it be possible to add a
test method that fails/passes before/after?

-------------

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

From Rony.Flatscher at wu.ac.at  Fri May  8 14:01:58 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Fri, 8 May 2020 16:01:58 +0200
Subject: Questions ad JavaScript in JavaFX' WebEngine
Message-ID: <ddb1f55d-e9fa-eaea-a3dc-d73a72732a76@wu.ac.at>

Wondering which JavaScript engine gets referred to in WebEngine [1].

In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn gets removed from the
next [3] version? In case it is WebKit's JavaScriptCore [4] where can one study the interface from
WebEngine to it?

---rony

[1] WebEngine: <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html>
[2] Nashorn: <https://openjdk.java.net/projects/nashorn/>
[3] Nashorn removal from JDK 15: <https://openjdk.java.net/jeps/372>
[4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore>



From jfxuser2 at gmail.com  Fri May  8 16:35:22 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 12:35:22 -0400
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>
References: <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>
Message-ID: <BA8FA076-079D-4EDC-9E90-DAC80F6C73A0@gmail.com>

I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?

Please consider the example I provided as a feature request.

> On May 8, 2020, at 9:39 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
> 
> -- Kevin
> 
> 
>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>> in JavaFX?
>> 
>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>> in the javafx.scene.shape package?  Why are there missing features from
>> Graphics2D?
>> 
>> I have a specific example that prompted the question:
>> 
>> Consider the following classes:
>> 
>> javafx.scene.shape.Shape
>>     private static Path
>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>> 
>> javafx.scene.canvas.GraphicsContext
>>     Path2D path;
>> 
>> I want to write a line as follows:
>> Path path = Path.createFromGeomShape(gc.path);
>> b/c I want to inexpensively get the outline of the GraphicsContext.
>> 
>> However:
>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>> by the module.
>> We can't access Path.createFromGeomShape b/c it's private.
>> We can't access path in GraphicsContext b/c it's default and doesn't have
>> an accessor.
>> 
>> A possible solution is to add a new method:
>> javafx.scene.canvas.GraphicsContext
>> public Path getPath() {
>>     //implementation copied from
>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>> }
>> 
>> That would solve my immediate problem but raises the question... why is
>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>> in progress that will impact this design?
>> 
>> PS my example is actually very important.  I currently use reflection and
>> module opens in the build to get the path but if the getPath method could
>> be added to GraphicsContext, that would be great.  For performance, it
>> would be even better to get the PathIterator directly instead of
>> translating into a javafx..Path but that is related to the bigger question.
> 

From kevin.rushforth at oracle.com  Fri May  8 17:10:08 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 May 2020 10:10:08 -0700
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <BA8FA076-079D-4EDC-9E90-DAC80F6C73A0@gmail.com>
References: <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>
 <BA8FA076-079D-4EDC-9E90-DAC80F6C73A0@gmail.com>
Message-ID: <4ec4bf6d-0f89-a08b-f984-ce146d04fc19@oracle.com>

While there is no plan to "open up" more of com.sun.javafx (and that 
isn't really the right way to look at it), if you have a proposed 
enhancement to the existing public javafx.* classes we could discuss it.

As for your specific example, can you say more about what your use case 
is? The GraphicsContext object is a drawing context for a Canvas node, 
so it is not a natural place to put an API that computes or returns a 
path. I get the sense that you are looking at the existing internal 
implementation classes and saying "how can I get access to some 
information that might be useful to my application" rather than 
describing what your application is trying to do. Once we understand 
what you are trying to do, we can discuss whether the need is general 
enough to propose adding to the public API of JavaFX and what form such 
a new API might take.

-- Kevin


On 5/8/2020 9:35 AM, jfx user2 wrote:
> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>
> Please consider the example I provided as a feature request.
>
>> On May 8, 2020, at 9:39 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>
>> -- Kevin
>>
>>
>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>> in JavaFX?
>>>
>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>> in the javafx.scene.shape package?  Why are there missing features from
>>> Graphics2D?
>>>
>>> I have a specific example that prompted the question:
>>>
>>> Consider the following classes:
>>>
>>> javafx.scene.shape.Shape
>>>      private static Path
>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>
>>> javafx.scene.canvas.GraphicsContext
>>>      Path2D path;
>>>
>>> I want to write a line as follows:
>>> Path path = Path.createFromGeomShape(gc.path);
>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>
>>> However:
>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>> by the module.
>>> We can't access Path.createFromGeomShape b/c it's private.
>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>> an accessor.
>>>
>>> A possible solution is to add a new method:
>>> javafx.scene.canvas.GraphicsContext
>>> public Path getPath() {
>>>      //implementation copied from
>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>> }
>>>
>>> That would solve my immediate problem but raises the question... why is
>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>> in progress that will impact this design?
>>>
>>> PS my example is actually very important.  I currently use reflection and
>>> module opens in the build to get the path but if the getPath method could
>>> be added to GraphicsContext, that would be great.  For performance, it
>>> would be even better to get the PathIterator directly instead of
>>> translating into a javafx..Path but that is related to the bigger question.


From jfxuser2 at gmail.com  Fri May  8 17:43:50 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 13:43:50 -0400
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <4ec4bf6d-0f89-a08b-f984-ce146d04fc19@oracle.com>
References: <4ec4bf6d-0f89-a08b-f984-ce146d04fc19@oracle.com>
Message-ID: <60BCFC21-FDE2-4EDA-BD4D-63A8D3177E2B@gmail.com>

Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, node attachment points, animating around the non-rectangular border of what?s actually displayed, etc.

The other request that I haven?t posted yet is to do the same for Shape.   I?ve tested both of these enhancements and it works as desired.  I?ll post the second request soon.

But back to the bigger picture.  The requests that I?m making are only additions to return a path from javafx not com.  But there are other cases where geometry and convenience methods in com would be beneficial to the public api.  It also seems odd that there are two layers to begin with...  parallel apis often result in too much object creation or cpu overhead translating between them.  I?ll be more specific about these cases over time.   Part of my intention is to spark a discussion about the design since previously this was relatively closed source.

> On May 8, 2020, at 1:12 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> ?While there is no plan to "open up" more of com.sun.javafx (and that isn't really the right way to look at it), if you have a proposed enhancement to the existing public javafx.* classes we could discuss it.
> 
> As for your specific example, can you say more about what your use case is? The GraphicsContext object is a drawing context for a Canvas node, so it is not a natural place to put an API that computes or returns a path. I get the sense that you are looking at the existing internal implementation classes and saying "how can I get access to some information that might be useful to my application" rather than describing what your application is trying to do. Once we understand what you are trying to do, we can discuss whether the need is general enough to propose adding to the public API of JavaFX and what form such a new API might take.
> 
> -- Kevin
> 
> 
>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>> 
>> Please consider the example I provided as a feature request.
>> 
>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>> 
>>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>> 
>>> -- Kevin
>>> 
>>> 
>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>>> in JavaFX?
>>>> 
>>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>>> in the javafx.scene.shape package?  Why are there missing features from
>>>> Graphics2D?
>>>> 
>>>> I have a specific example that prompted the question:
>>>> 
>>>> Consider the following classes:
>>>> 
>>>> javafx.scene.shape.Shape
>>>>     private static Path
>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>> 
>>>> javafx.scene.canvas.GraphicsContext
>>>>     Path2D path;
>>>> 
>>>> I want to write a line as follows:
>>>> Path path = Path.createFromGeomShape(gc.path);
>>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>> 
>>>> However:
>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>>> by the module.
>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>>> an accessor.
>>>> 
>>>> A possible solution is to add a new method:
>>>> javafx.scene.canvas.GraphicsContext
>>>> public Path getPath() {
>>>>     //implementation copied from
>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>>> }
>>>> 
>>>> That would solve my immediate problem but raises the question... why is
>>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>>> in progress that will impact this design?
>>>> 
>>>> PS my example is actually very important.  I currently use reflection and
>>>> module opens in the build to get the path but if the getPath method could
>>>> be added to GraphicsContext, that would be great.  For performance, it
>>>> would be even better to get the PathIterator directly instead of
>>>> translating into a javafx..Path but that is related to the bigger question.
> 

From kevin.rushforth at oracle.com  Fri May  8 18:41:35 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 May 2020 11:41:35 -0700
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <60BCFC21-FDE2-4EDA-BD4D-63A8D3177E2B@gmail.com>
References: <4ec4bf6d-0f89-a08b-f984-ce146d04fc19@oracle.com>
 <60BCFC21-FDE2-4EDA-BD4D-63A8D3177E2B@gmail.com>
Message-ID: <578860dc-8174-ab71-6786-25fa4ddfc406@oracle.com>

Since Canvas is an immediate mode graphics API, I presume you are 
interested in the most recent drawing primitive? (we don't keep the 
composite shape for all drawing primitives -- that would be both too 
expensive and not really appropriate). How would you expect current 
rendering attributes (e.g., transforms) to affect the results? These are 
all questions that need to be addressed.

As for the bigger picture, we intentionally have a separate render graph 
with "peers" for each node, although some of the duplication of classes 
is historical (we used to have a looser decoupling before Prism became 
the only backend). Unless there is a compelling need, we are unlikely to 
consider changing this in the general case, but perhaps could look at 
specific cases if it made sense. This is a separate issue, though, from 
public API and the two shouldn't be conflated.

Btw, JavaFX has been fully open-sourced since 2013, although the design 
of Prism predates that.

-- Kevin


On 5/8/2020 10:43 AM, jfx user2 wrote:
> Kevin, go easy please :0).  There is a need.
>
> Access to the outline of the path in the canvas is great for edge following, node attachment points, animating around the non-rectangular border of what?s actually displayed, etc.
>
> The other request that I haven?t posted yet is to do the same for Shape.   I?ve tested both of these enhancements and it works as desired.  I?ll post the second request soon.
>
> But back to the bigger picture.  The requests that I?m making are only additions to return a path from javafx not com.  But there are other cases where geometry and convenience methods in com would be beneficial to the public api.  It also seems odd that there are two layers to begin with...  parallel apis often result in too much object creation or cpu overhead translating between them.  I?ll be more specific about these cases over time.   Part of my intention is to spark a discussion about the design since previously this was relatively closed source.
>
>> On May 8, 2020, at 1:12 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> ?While there is no plan to "open up" more of com.sun.javafx (and that isn't really the right way to look at it), if you have a proposed enhancement to the existing public javafx.* classes we could discuss it.
>>
>> As for your specific example, can you say more about what your use case is? The GraphicsContext object is a drawing context for a Canvas node, so it is not a natural place to put an API that computes or returns a path. I get the sense that you are looking at the existing internal implementation classes and saying "how can I get access to some information that might be useful to my application" rather than describing what your application is trying to do. Once we understand what you are trying to do, we can discuss whether the need is general enough to propose adding to the public API of JavaFX and what form such a new API might take.
>>
>> -- Kevin
>>
>>
>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>>> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>>>
>>> Please consider the example I provided as a feature request.
>>>
>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>>>> in JavaFX?
>>>>>
>>>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>>>> in the javafx.scene.shape package?  Why are there missing features from
>>>>> Graphics2D?
>>>>>
>>>>> I have a specific example that prompted the question:
>>>>>
>>>>> Consider the following classes:
>>>>>
>>>>> javafx.scene.shape.Shape
>>>>>      private static Path
>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>>>
>>>>> javafx.scene.canvas.GraphicsContext
>>>>>      Path2D path;
>>>>>
>>>>> I want to write a line as follows:
>>>>> Path path = Path.createFromGeomShape(gc.path);
>>>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>>>
>>>>> However:
>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>>>> by the module.
>>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>>>> an accessor.
>>>>>
>>>>> A possible solution is to add a new method:
>>>>> javafx.scene.canvas.GraphicsContext
>>>>> public Path getPath() {
>>>>>      //implementation copied from
>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>>>> }
>>>>>
>>>>> That would solve my immediate problem but raises the question... why is
>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>>>> in progress that will impact this design?
>>>>>
>>>>> PS my example is actually very important.  I currently use reflection and
>>>>> module opens in the build to get the path but if the getPath method could
>>>>> be added to GraphicsContext, that would be great.  For performance, it
>>>>> would be even better to get the PathIterator directly instead of
>>>>> translating into a javafx..Path but that is related to the bigger question.


From kcr at openjdk.java.net  Fri May  8 18:51:27 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 18:51:27 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <HQRIRLY9UByKRLIAyMZ2GeWbVE-Dlu_5QZpmwCoGzaI=.d35181fe-7f28-4080-83fd-e6d24b2263d4@github.com>
References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com>
 <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com>
 <m8PLeyc0us7uwV8COoAzFRoGILp3UDAjvZOraoQqkLs=.8c118755-bcb8-4ffe-901f-91ce470b4e4e@github.com>
 <HQRIRLY9UByKRLIAyMZ2GeWbVE-Dlu_5QZpmwCoGzaI=.d35181fe-7f28-4080-83fd-e6d24b2263d4@github.com>
Message-ID: <mBHa45YjUdIxuZ3uBtv39EpLNlZOWv6pLRBzpC9zd4Y=.0536ff55-8d9f-423d-bc03-49c8f5eda1c4@github.com>

On Tue, 14 Apr 2020 11:47:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Just a comment on how to add a failing test:  we can replace the actual typing (in the TestFx context) by
>> programmatically replacing the selection, actually, it doesn't even need the skin (so no scene nor parent) because all
>> collaborators are in TextInputControl:
>>       /**
>>         * Test for JDK-8176270: register changeListener on selectedText, select at
>>         * end of text and replace selection throws.
>>         */
>>     @Test
>>     public void addingChangeListenerNoSkin() {
>>         TextField textField = new TextField();
>>         textField.setText("1234 5678");
>>         textField.selectedTextProperty()
>>                  .addListener((o, ov, nv) -> {});
>> 
>>         textField.positionCaret(5);
>>         textField.selectEnd();
>>         textField.replaceSelection("d");
>>     }
>>     
>> Similarly, an invalidationListener that access the selectedText throws, while an invalidationListener not accessing the
>> selected is fine. ~~So it looks like a one-off when evaluating the actual selection during the process, somehow it's
>> not yet ready~~ That was my wrong assumption, the culprit is really the incorrect clamping of a no-longer valid end
>> index when adjusting the selectedText binding (as @Kevin noted above). It shows only if the selectedText must be
>> re-evaluated before the selectionRange is updated, f.i. forced by a changeListener (or direct access).  To make the
>> error show up on the test thread, replace the uncaughtExceptionHandler before (and cleanup after):
>>     @Before public void setup() throws Exception {
>>         Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> {
>>             if (throwable instanceof RuntimeException) {
>>                 throw (RuntimeException)throwable;
>>             } else {
>>                 Thread.currentThread().getThreadGroup().uncaughtException(thread, throwable);
>>             }
>>         });
>>         textInput = (TextInputControl) type.newInstance();
>>     }
>> 
>> 
>>     @After public void cleanup() {
>>         Thread.currentThread().setUncaughtExceptionHandler(null);
>>     }
>
> @koppor are you planning to resume work on this PR?

Closing, since there has been no activity for 3 months.

@koppor - if you would like to pursue this, please address the pending feedback and reopen the PR.

-------------

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

From github.com+1366654+koppor at openjdk.java.net  Fri May  8 18:51:27 2020
From: github.com+1366654+koppor at openjdk.java.net (Oliver Kopp)
Date: Fri, 8 May 2020 18:51:27 GMT
Subject: [Closed] RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com>
References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com>
Message-ID: <bpX4UQh9j3q_kxyP0jJ-YEBOl1km8FLs7EP-TsI9oN0=.19ddc94f-ae5c-4f92-855f-c118193655cc@github.com>

On Sat, 21 Dec 2019 15:36:14 GMT, Oliver Kopp <github.com+1366654+koppor at openjdk.org> wrote:

> This is a WIP PR. Requesting for comments.
> 
> I could not replicate the test given at https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I nevertheless
> let my try to replicate the @Test things in here.
> The fix is just a wild guess without really understanding the side effects of `.addListener`.

This pull request has been closed without being integrated.

-------------

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

From kcr at openjdk.java.net  Fri May  8 18:53:05 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 18:53:05 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
Message-ID: <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>

On Fri, 6 Mar 2020 06:00:36 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> I have exactly the same question.
>> 
>> In general, it's better to work with the author of an existing PR instead of creating a new one. If the original PR #73
>> is completely stalled, then it might make sense, but not until then.
>
> I wasn't aware of PR #73, I only saw the (very old) issue in the JDK Bug System and started to look into the issue.
> The fact that two different people start to look into the same issue shows it is important however :-).
> Should I close this PR and participate in PR #73?

@effad I just closed PR #73 due to inactivity. If you are interested interested in pursuing this, go ahead and reopen
this (although you would need to address the feedback that clamping is insufficient).

-------------

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

From rlichten at openjdk.java.net  Fri May  8 18:53:05 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Fri, 8 May 2020 18:53:05 GMT
Subject: [Closed] RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
Message-ID: <4CMLOEtReMHV7PP4oVT31Iaw7_R1TDRrj_OGDRJ-UBs=.ac0d23bf-9df7-45cc-bbe1-5782e288513d@github.com>

On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text.

This pull request has been closed without being integrated.

-------------

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

From kcr at openjdk.java.net  Fri May  8 18:56:17 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 18:56:17 GMT
Subject: RFR: 8244647: Wrong first layout pass of Scrollbar controls on
 touch supported devices
In-Reply-To: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
References: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
Message-ID: <DJUp7R2K0CqoVKzMyCDWis3G9qkd6XT1V2OqydFFMX4=.f7c95201-529f-47fb-b2f1-2c3d15e20a61@github.com>

On Fri, 8 May 2020 11:25:03 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> There is a visual glitch when the scrollbar controls are laid out on touch enabled devices.
> 
> The first time they are laid out in the wrong location (20 px from right or bottom), while the next passes are correct
> (8 px from right or bottom).
> The reason for this glitch is the use of `getWidth()` or `getHeight()` in the `resizeRelocate` calls to relocate the
> bars before the controls have been properly resized yet: The initial w/h values are set to the default (20 px / 100
> px), while the pref values are correctly set to 8 px.  This PR fixes that, by using the same prefWidth/prefHeight for
> both resizing and relocating.
> It has been tested on Mac OS and Linux (with `-Dcom.sun.javafx.touch=true`), and on Android and iOS.

@aghaisas can you review this please? I think a single reviewer will be sufficient.

-------------

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

From jfxuser2 at gmail.com  Fri May  8 19:02:52 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 15:02:52 -0400
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <578860dc-8174-ab71-6786-25fa4ddfc406@oracle.com>
References: <578860dc-8174-ab71-6786-25fa4ddfc406@oracle.com>
Message-ID: <919A8E16-25BF-435E-92CF-DA5C2AC69A57@gmail.com>

Ok, then please consider the GraphicsContext request that I?ve made.  It simply enables you to get the Path from the context without exposing com classes at all.  I have other workarounds where I have to maintain a path as I?m drawing in the canvas or I have to do hit testing on a non vector image to determine the path but these are way more expensive than simply creating a Path object from the Path2D that is already in the GraphicContext.  That path can be used in drag and drop scenarios, fast secondary rendering under heavy gc use, edge tracing, and the list goes on.

The same is true for the Shape class.  I?d like to request that the following be added to Shape:
public Path getPath() {
    return Shape.createFromGeomShape(getTransformedArea());
}

That?s it.  The underlying methods are there but the public api doesn?t expose them.  This gives you a vector outline of the Shape as Path.l on demand, not stored.

There are expensive workarounds for performing these tasks and I spent a long time trying... until I discovers the private apis already had the capability but simply did. It expose it.

I?d these are not supported, I?ll have to stick with reflection,  bytebuddy, or forking - non of which will be easily maintained or portable.

Ps I will post additional concerns over time.  The next one likely has to do with the mismatch between javafx canvas (gc) and other canvases such as svg, html2.  I think there is private api that would help in this case.

> On May 8, 2020, at 2:41 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> ?Since Canvas is an immediate mode graphics API, I presume you are interested in the most recent drawing primitive? (we don't keep the composite shape for all drawing primitives -- that would be both too expensive and not really appropriate). How would you expect current rendering attributes (e.g., transforms) to affect the results? These are all questions that need to be addressed.
> 
> As for the bigger picture, we intentionally have a separate render graph with "peers" for each node, although some of the duplication of classes is historical (we used to have a looser decoupling before Prism became the only backend). Unless there is a compelling need, we are unlikely to consider changing this in the general case, but perhaps could look at specific cases if it made sense. This is a separate issue, though, from public API and the two shouldn't be conflated.
> 
> Btw, JavaFX has been fully open-sourced since 2013, although the design of Prism predates that.
> 
> -- Kevin
> 
> 
>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>> Kevin, go easy please :0).  There is a need.
>> 
>> Access to the outline of the path in the canvas is great for edge following, node attachment points, animating around the non-rectangular border of what?s actually displayed, etc.
>> 
>> The other request that I haven?t posted yet is to do the same for Shape.   I?ve tested both of these enhancements and it works as desired.  I?ll post the second request soon.
>> 
>> But back to the bigger picture.  The requests that I?m making are only additions to return a path from javafx not com.  But there are other cases where geometry and convenience methods in com would be beneficial to the public api.  It also seems odd that there are two layers to begin with...  parallel apis often result in too much object creation or cpu overhead translating between them.  I?ll be more specific about these cases over time.   Part of my intention is to spark a discussion about the design since previously this was relatively closed source.
>> 
>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>> 
>>> ?While there is no plan to "open up" more of com.sun.javafx (and that isn't really the right way to look at it), if you have a proposed enhancement to the existing public javafx.* classes we could discuss it.
>>> 
>>> As for your specific example, can you say more about what your use case is? The GraphicsContext object is a drawing context for a Canvas node, so it is not a natural place to put an API that computes or returns a path. I get the sense that you are looking at the existing internal implementation classes and saying "how can I get access to some information that might be useful to my application" rather than describing what your application is trying to do. Once we understand what you are trying to do, we can discuss whether the need is general enough to propose adding to the public API of JavaFX and what form such a new API might take.
>>> 
>>> -- Kevin
>>> 
>>> 
>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>>>> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>>>> 
>>>> Please consider the example I provided as a feature request.
>>>> 
>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>>>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>>>> 
>>>>> -- Kevin
>>>>> 
>>>>> 
>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>>>>> in JavaFX?
>>>>>> 
>>>>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>>>>> in the javafx.scene.shape package?  Why are there missing features from
>>>>>> Graphics2D?
>>>>>> 
>>>>>> I have a specific example that prompted the question:
>>>>>> 
>>>>>> Consider the following classes:
>>>>>> 
>>>>>> javafx.scene.shape.Shape
>>>>>>     private static Path
>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>>>> 
>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>     Path2D path;
>>>>>> 
>>>>>> I want to write a line as follows:
>>>>>> Path path = Path.createFromGeomShape(gc.path);
>>>>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>>>> 
>>>>>> However:
>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>>>>> by the module.
>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>>>>> an accessor.
>>>>>> 
>>>>>> A possible solution is to add a new method:
>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>> public Path getPath() {
>>>>>>     //implementation copied from
>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>>>>> }
>>>>>> 
>>>>>> That would solve my immediate problem but raises the question... why is
>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>>>>> in progress that will impact this design?
>>>>>> 
>>>>>> PS my example is actually very important.  I currently use reflection and
>>>>>> module opens in the build to get the path but if the getPath method could
>>>>>> be added to GraphicsContext, that would be great.  For performance, it
>>>>>> would be even better to get the PathIterator directly instead of
>>>>>> translating into a javafx..Path but that is related to the bigger question.
> 

From jvos at openjdk.java.net  Fri May  8 19:03:40 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 8 May 2020 19:03:40 GMT
Subject: RFR: 8244417: support static build for Windows
In-Reply-To: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
References: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
Message-ID: <4BtgTJRnDKOs51VtJHmQZpwLfHPPQJhEOheNYMJu7nE=.f96127d3-721b-42ee-89c2-d5ba0ac0aab7@github.com>

On Thu, 7 May 2020 21:15:02 GMT, Joeri Sykora <sykora at openjdk.org> wrote:

> Adds support for building static libraries of the OpenJFX modules for the Windows platform. Building static libraries
> is done by providing the gradle property `-PSTATIC_BUILD=true`.
> Changes include:
> 
> - add static flags for the compiler and linker
> - use `lib` for linking instead of `link`
> - only build and include version.rc once (from GlassResources.rc)
> - include library specific `JNI_OnLoad_xxx` methods
> - functionality loaded via `DllMain` has been implemented at a different location

modules/javafx.graphics/src/main/native-prism-d3d/D3DPipeline.cc line 39:

> 38:
> 39: static jboolean checkAndClearException(JNIEnv *env) {
> 40:     if (!env->ExceptionCheck()) {

while this looks ok to me, I'm not sure why the old code had `extern` followed by the implementation. There might be
reasons I don't understand, and in that case it might be safer to #ifdef here with STATIC_BUILD. But maybe
@kevinrushforth  knows why this construct is here?

-------------

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

From kcr at openjdk.java.net  Fri May  8 19:05:35 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 19:05:35 GMT
Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH
In-Reply-To: <b7eWzI54_Vzn1JRAqmaJmVSNv1gCoSNYWrvrsIzCFP4=.a7ed1367-14c4-4bd8-b7ed-93353435160f@github.com>
References: <GTDmQgrfoz_Df9NpMp62pRIOLuQtjOuV8TH0hBub4Lo=.37788695-6fc2-4384-8da8-2c6ab1c62621@github.com>
 <Z5mSab7Et5_LBsEnDSoKHPV-jWbbOBVehjHI9SR1wqM=.171bd390-b181-4106-aad1-b8b59e8bbbfb@github.com>
 <u7bgf-2Tu6aaGM5YxzbdJLLi6KmrHyLR1uMcMt6WQng=.a7b5c6fb-0a1d-4d69-bb85-f7222d237888@github.com>
 <b7eWzI54_Vzn1JRAqmaJmVSNv1gCoSNYWrvrsIzCFP4=.a7ed1367-14c4-4bd8-b7ed-93353435160f@github.com>
Message-ID: <7sL4c0N1eXdL_mTZjT4voOgYZdhqgoqee-9_kX2uLTE=.3a5cbfae-0672-49c7-8742-4b2a1b5efbc8@github.com>

On Wed, 15 Apr 2020 02:35:44 GMT, Bernhard M. Wiedemann <github.com+637990+bmwiedemann at openjdk.org> wrote:

>> @bmwiedemann are you planning to pursue this PR?
>
> Long term, yes.
> 
> I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up.

I note that the JDK build recently implemented this feature in JDK 15 with
[JDK-8244592](https://bugs.openjdk.java.net/browse/JDK-8244592).

-------------

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

From kcr at openjdk.java.net  Fri May  8 19:06:56 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 19:06:56 GMT
Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs()
 list
In-Reply-To: <E9Ur0EK60zqUJ6VRjwLrxmS57ZlTCcFmpwL4GsT5Kak=.e63fe17e-c904-4e0a-93b8-a7bc916dde4f@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
 <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
 <E9Ur0EK60zqUJ6VRjwLrxmS57ZlTCcFmpwL4GsT5Kak=.e63fe17e-c904-4e0a-93b8-a7bc916dde4f@github.com>
Message-ID: <KAYh3CRvt2DgThUmg6ss85s_9G3NedTQ9gsN_V9NpSk=.486e40b2-ad56-4e9b-a77a-19fcfbe50dda@github.com>

On Fri, 1 May 2020 15:22:39 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 994:
>> 
>>> 993:         private void moveTab(int moveToIndex, TabHeaderSkin tabHeaderSkin) {
>>> 994:             if (moveToIndex != headersRegion.getChildren().indexOf(tabHeaderSkin)) {
>>> 995:                 headersRegion.getChildren().remove(tabHeaderSkin);
>> 
>> Unless I am missing something, this check seems unrelated to the bug.
>
> Yes Kevin, this is not required for fix. In some scenarios the tabHeader gets placed at correct index due to the
> addition of new headers, so this movement becomes redundant.

In that case, this change is fine.

-------------

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

From kcr at openjdk.java.net  Fri May  8 19:14:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 19:14:59 GMT
Subject: RFR: 8244417: support static build for Windows
In-Reply-To: <4BtgTJRnDKOs51VtJHmQZpwLfHPPQJhEOheNYMJu7nE=.f96127d3-721b-42ee-89c2-d5ba0ac0aab7@github.com>
References: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
 <4BtgTJRnDKOs51VtJHmQZpwLfHPPQJhEOheNYMJu7nE=.f96127d3-721b-42ee-89c2-d5ba0ac0aab7@github.com>
Message-ID: <rSB770u9uCAs2Tz1bp_9baNb-4WK7Ny8CqNcZrfuqlM=.2a5d6c52-789b-45be-b745-01ee68b9844c@github.com>

On Fri, 8 May 2020 19:01:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Adds support for building static libraries of the OpenJFX modules for the Windows platform. Building static libraries
>> is done by providing the gradle property `-PSTATIC_BUILD=true`.
>> Changes include:
>> 
>> - add static flags for the compiler and linker
>> - use `lib` for linking instead of `link`
>> - only build and include version.rc once (from GlassResources.rc)
>> - include library specific `JNI_OnLoad_xxx` methods
>> - functionality loaded via `DllMain` has been implemented at a different location
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DPipeline.cc line 39:
> 
>> 38:
>> 39: static jboolean checkAndClearException(JNIEnv *env) {
>> 40:     if (!env->ExceptionCheck()) {
> 
> while this looks ok to me, I'm not sure why the old code had `extern` followed by the implementation. There might be
> reasons I don't understand, and in that case it might be safer to #ifdef here with STATIC_BUILD. But maybe
> @kevinrushforth  knows why this construct is here?

I suspect it was either a copy/paste or else a holdover from when it really was used from more than one file. I think
it should be fine to make it static.

There is a function of the same name in two other places: native-prism-font and native-iio. In native-prism-font it
really is defined in one place and used in multiple files. In native-iio it is only used in a single file and defined
as a static function.

I'll test this with a default (non-static) build to make sure there are no unintended changes.

-------------

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

From youngty1997 at gmail.com  Fri May  8 19:11:20 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 8 May 2020 14:11:20 -0500
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>
References: <CAHifg5d8i=E9X-mEJJgorg8kWLbUjxPF9+05N4r+HDHvfmCMxA@mail.gmail.com>
 <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>
Message-ID: <c8091dc5-b815-a4c9-4c13-ba3084a2512d@gmail.com>

On the topic of private APIs that should probably be public... can the 
performance tracker class be made public too? I'd very much like to know 
the FPS at which my application is running at.


From philip.race at oracle.com  Fri May  8 19:39:01 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 08 May 2020 12:39:01 -0700
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <919A8E16-25BF-435E-92CF-DA5C2AC69A57@gmail.com>
References: <578860dc-8174-ab71-6786-25fa4ddfc406@oracle.com>
 <919A8E16-25BF-435E-92CF-DA5C2AC69A57@gmail.com>
Message-ID: <5EB5B555.5020808@oracle.com>

The current path is defined by the application - you - and yet you don't 
know what it is  ?
You do say
 > I have other workarounds where I have to maintain a path as I?m 
drawing in the canvas

Why can't you do that ? No internal API digging.

-phil

On 5/8/20, 12:02 PM, jfx user2 wrote:
> Ok, then please consider the GraphicsContext request that I?ve made.  It simply enables you to get the Path from the context without exposing com classes at all.  I have other workarounds where I have to maintain a path as I?m drawing in the canvas or I have to do hit testing on a non vector image to determine the path but these are way more expensive than simply creating a Path object from the Path2D that is already in the GraphicContext.  That path can be used in drag and drop scenarios, fast secondary rendering under heavy gc use, edge tracing, and the list goes on.
>
> The same is true for the Shape class.  I?d like to request that the following be added to Shape:
> public Path getPath() {
>      return Shape.createFromGeomShape(getTransformedArea());
> }
>
> That?s it.  The underlying methods are there but the public api doesn?t expose them.  This gives you a vector outline of the Shape as Path.l on demand, not stored.
>
> There are expensive workarounds for performing these tasks and I spent a long time trying... until I discovers the private apis already had the capability but simply did. It expose it.
>
> I?d these are not supported, I?ll have to stick with reflection,  bytebuddy, or forking - non of which will be easily maintained or portable.
>
> Ps I will post additional concerns over time.  The next one likely has to do with the mismatch between javafx canvas (gc) and other canvases such as svg, html2.  I think there is private api that would help in this case.
>
>> On May 8, 2020, at 2:41 PM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>
>> ?Since Canvas is an immediate mode graphics API, I presume you are interested in the most recent drawing primitive? (we don't keep the composite shape for all drawing primitives -- that would be both too expensive and not really appropriate). How would you expect current rendering attributes (e.g., transforms) to affect the results? These are all questions that need to be addressed.
>>
>> As for the bigger picture, we intentionally have a separate render graph with "peers" for each node, although some of the duplication of classes is historical (we used to have a looser decoupling before Prism became the only backend). Unless there is a compelling need, we are unlikely to consider changing this in the general case, but perhaps could look at specific cases if it made sense. This is a separate issue, though, from public API and the two shouldn't be conflated.
>>
>> Btw, JavaFX has been fully open-sourced since 2013, although the design of Prism predates that.
>>
>> -- Kevin
>>
>>
>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>>> Kevin, go easy please :0).  There is a need.
>>>
>>> Access to the outline of the path in the canvas is great for edge following, node attachment points, animating around the non-rectangular border of what?s actually displayed, etc.
>>>
>>> The other request that I haven?t posted yet is to do the same for Shape.   I?ve tested both of these enhancements and it works as desired.  I?ll post the second request soon.
>>>
>>> But back to the bigger picture.  The requests that I?m making are only additions to return a path from javafx not com.  But there are other cases where geometry and convenience methods in com would be beneficial to the public api.  It also seems odd that there are two layers to begin with...  parallel apis often result in too much object creation or cpu overhead translating between them.  I?ll be more specific about these cases over time.   Part of my intention is to spark a discussion about the design since previously this was relatively closed source.
>>>
>>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>> ?While there is no plan to "open up" more of com.sun.javafx (and that isn't really the right way to look at it), if you have a proposed enhancement to the existing public javafx.* classes we could discuss it.
>>>>
>>>> As for your specific example, can you say more about what your use case is? The GraphicsContext object is a drawing context for a Canvas node, so it is not a natural place to put an API that computes or returns a path. I get the sense that you are looking at the existing internal implementation classes and saying "how can I get access to some information that might be useful to my application" rather than describing what your application is trying to do. Once we understand what you are trying to do, we can discuss whether the need is general enough to propose adding to the public API of JavaFX and what form such a new API might take.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>>>>> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>>>>>
>>>>> Please consider the example I provided as a feature request.
>>>>>
>>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>>>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>>>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>>>>>> in JavaFX?
>>>>>>>
>>>>>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>>>>>> in the javafx.scene.shape package?  Why are there missing features from
>>>>>>> Graphics2D?
>>>>>>>
>>>>>>> I have a specific example that prompted the question:
>>>>>>>
>>>>>>> Consider the following classes:
>>>>>>>
>>>>>>> javafx.scene.shape.Shape
>>>>>>>      private static Path
>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>>>>>
>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>      Path2D path;
>>>>>>>
>>>>>>> I want to write a line as follows:
>>>>>>> Path path = Path.createFromGeomShape(gc.path);
>>>>>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>>>>>
>>>>>>> However:
>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>>>>>> by the module.
>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>>>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>>>>>> an accessor.
>>>>>>>
>>>>>>> A possible solution is to add a new method:
>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>> public Path getPath() {
>>>>>>>      //implementation copied from
>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>>>>>> }
>>>>>>>
>>>>>>> That would solve my immediate problem but raises the question... why is
>>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>>>>>> in progress that will impact this design?
>>>>>>>
>>>>>>> PS my example is actually very important.  I currently use reflection and
>>>>>>> module opens in the build to get the path but if the getPath method could
>>>>>>> be added to GraphicsContext, that would be great.  For performance, it
>>>>>>> would be even better to get the PathIterator directly instead of
>>>>>>> translating into a javafx..Path but that is related to the bigger question.

From sykora at openjdk.java.net  Fri May  8 19:45:03 2020
From: sykora at openjdk.java.net (Joeri Sykora)
Date: Fri, 8 May 2020 19:45:03 GMT
Subject: RFR: 8244417: support static build for Windows
In-Reply-To: <rSB770u9uCAs2Tz1bp_9baNb-4WK7Ny8CqNcZrfuqlM=.2a5d6c52-789b-45be-b745-01ee68b9844c@github.com>
References: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
 <4BtgTJRnDKOs51VtJHmQZpwLfHPPQJhEOheNYMJu7nE=.f96127d3-721b-42ee-89c2-d5ba0ac0aab7@github.com>
 <rSB770u9uCAs2Tz1bp_9baNb-4WK7Ny8CqNcZrfuqlM=.2a5d6c52-789b-45be-b745-01ee68b9844c@github.com>
Message-ID: <h8oSjRWr5Bxwg4ZdfZKiYQi4LIXZIZe_xKb5kzvKWD0=.37dd7794-0abf-4a09-ba8c-aa96fb222b63@github.com>

On Fri, 8 May 2020 19:12:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-prism-d3d/D3DPipeline.cc line 39:
>> 
>>> 38:
>>> 39: static jboolean checkAndClearException(JNIEnv *env) {
>>> 40:     if (!env->ExceptionCheck()) {
>> 
>> while this looks ok to me, I'm not sure why the old code had `extern` followed by the implementation. There might be
>> reasons I don't understand, and in that case it might be safer to #ifdef here with STATIC_BUILD. But maybe
>> @kevinrushforth  knows why this construct is here?
>
> I suspect it was either a copy/paste or else a holdover from when it really was used from more than one file. I think
> it should be fine to make it static.
> There is a function of the same name in two other places: native-prism-font and native-iio. In native-prism-font it
> really is defined in one place and used in multiple files. In native-iio it is only used in a single file and defined
> as a static function.  I'll test this with a default (non-static) build to make sure there are no unintended changes.

The alternative is to prefix the method as is done in native-prism-sw. But using static instead looked like a cleaner
way.

I've also built both the regular and static version and they both worked without issues.

-------------

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

From kevin.rushforth at oracle.com  Fri May  8 19:51:26 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 May 2020 12:51:26 -0700
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <c8091dc5-b815-a4c9-4c13-ba3084a2512d@gmail.com>
References: <CAHifg5d8i=E9X-mEJJgorg8kWLbUjxPF9+05N4r+HDHvfmCMxA@mail.gmail.com>
 <368de27b-8ddb-d7e6-5451-8dd663cfbf7c@oracle.com>
 <c8091dc5-b815-a4c9-4c13-ba3084a2512d@gmail.com>
Message-ID: <7b037b54-75d2-f1d5-92ba-3df860fd4da0@oracle.com>

The performance tracker was identified back in the JDK 9 time frame as a 
possible candidate for a public API. The following request is tracking it:

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

If someone wants to spend the effort to take this feature request and 
drive it to completion, including discussing the feature, proposing a 
public API (which is not "just make the existing impl class public"), 
filing a CSR, implementing it (you can very likely leverage the existing 
internal implementation), testing it, and getting it reviewed, then that 
would be possible.

-- Kevin


On 5/8/2020 12:11 PM, Ty Young wrote:
> On the topic of private APIs that should probably be public... can the 
> performance tracker class be made public too? I'd very much like to 
> know the FPS at which my application is running at.
>


From jfxuser2 at gmail.com  Fri May  8 20:08:28 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 16:08:28 -0400
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <5EB5B555.5020808@oracle.com>
References: <5EB5B555.5020808@oracle.com>
Message-ID: <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>

No... given a Shape, create a Path that represents the outline of that shape.  If I had a Path I wouldn?t be requesting the new methods.

One of the workarounds for getting a Path from a GraphicsContext is to keep track of it as I?m drawing... however, this is overhead in the gc call that can become very expensive when you have a lot of gcs or if your gc is doing a lot of work.  The path is already there in Path2D along with a method to convert it to a public Path.  There?s no need for an expensive custom workaround.  All that?s required is a method on the GraphicsContext that returns a Path.  The same is true for getting a Path from a Shape.

Please note that this behavior is desirable for highly optimized use of GraphicsContext and Shapes where you need ?outlines? of things in vector format.  The private api is unnecessarily hiding this information.

> On May 8, 2020, at 3:38 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> ?The current path is defined by the application - you - and yet you don't know what it is  ?
> You do say
> > I have other workarounds where I have to maintain a path as I?m drawing in the canvas
> 
> Why can't you do that ? No internal API digging.
> 
> -phil
> 
>> On 5/8/20, 12:02 PM, jfx user2 wrote:
>> Ok, then please consider the GraphicsContext request that I?ve made.  It simply enables you to get the Path from the context without exposing com classes at all.  I have other workarounds where I have to maintain a path as I?m drawing in the canvas or I have to do hit testing on a non vector image to determine the path but these are way more expensive than simply creating a Path object from the Path2D that is already in the GraphicContext.  That path can be used in drag and drop scenarios, fast secondary rendering under heavy gc use, edge tracing, and the list goes on.
>> 
>> The same is true for the Shape class.  I?d like to request that the following be added to Shape:
>> public Path getPath() {
>>     return Shape.createFromGeomShape(getTransformedArea());
>> }
>> 
>> That?s it.  The underlying methods are there but the public api doesn?t expose them.  This gives you a vector outline of the Shape as Path.l on demand, not stored.
>> 
>> There are expensive workarounds for performing these tasks and I spent a long time trying... until I discovers the private apis already had the capability but simply did. It expose it.
>> 
>> I?d these are not supported, I?ll have to stick with reflection,  bytebuddy, or forking - non of which will be easily maintained or portable.
>> 
>> Ps I will post additional concerns over time.  The next one likely has to do with the mismatch between javafx canvas (gc) and other canvases such as svg, html2.  I think there is private api that would help in this case.
>> 
>>>> On May 8, 2020, at 2:41 PM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>> 
>>> ?Since Canvas is an immediate mode graphics API, I presume you are interested in the most recent drawing primitive? (we don't keep the composite shape for all drawing primitives -- that would be both too expensive and not really appropriate). How would you expect current rendering attributes (e.g., transforms) to affect the results? These are all questions that need to be addressed.
>>> 
>>> As for the bigger picture, we intentionally have a separate render graph with "peers" for each node, although some of the duplication of classes is historical (we used to have a looser decoupling before Prism became the only backend). Unless there is a compelling need, we are unlikely to consider changing this in the general case, but perhaps could look at specific cases if it made sense. This is a separate issue, though, from public API and the two shouldn't be conflated.
>>> 
>>> Btw, JavaFX has been fully open-sourced since 2013, although the design of Prism predates that.
>>> 
>>> -- Kevin
>>> 
>>> 
>>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>>>> Kevin, go easy please :0).  There is a need.
>>>> 
>>>> Access to the outline of the path in the canvas is great for edge following, node attachment points, animating around the non-rectangular border of what?s actually displayed, etc.
>>>> 
>>>> The other request that I haven?t posted yet is to do the same for Shape.   I?ve tested both of these enhancements and it works as desired.  I?ll post the second request soon.
>>>> 
>>>> But back to the bigger picture.  The requests that I?m making are only additions to return a path from javafx not com.  But there are other cases where geometry and convenience methods in com would be beneficial to the public api.  It also seems odd that there are two layers to begin with...  parallel apis often result in too much object creation or cpu overhead translating between them.  I?ll be more specific about these cases over time.   Part of my intention is to spark a discussion about the design since previously this was relatively closed source.
>>>> 
>>>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>>> ?While there is no plan to "open up" more of com.sun.javafx (and that isn't really the right way to look at it), if you have a proposed enhancement to the existing public javafx.* classes we could discuss it.
>>>>> 
>>>>> As for your specific example, can you say more about what your use case is? The GraphicsContext object is a drawing context for a Canvas node, so it is not a natural place to put an API that computes or returns a path. I get the sense that you are looking at the existing internal implementation classes and saying "how can I get access to some information that might be useful to my application" rather than describing what your application is trying to do. Once we understand what you are trying to do, we can discuss whether the need is general enough to propose adding to the public API of JavaFX and what form such a new API might take.
>>>>> 
>>>>> -- Kevin
>>>>> 
>>>>> 
>>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>>>>>> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>>>>>> 
>>>>>> Please consider the example I provided as a feature request.
>>>>>> 
>>>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>>>>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>>>>>> 
>>>>>>> -- Kevin
>>>>>>> 
>>>>>>> 
>>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>>>>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>>>>>>> in JavaFX?
>>>>>>>> 
>>>>>>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>>>>>>> in the javafx.scene.shape package?  Why are there missing features from
>>>>>>>> Graphics2D?
>>>>>>>> 
>>>>>>>> I have a specific example that prompted the question:
>>>>>>>> 
>>>>>>>> Consider the following classes:
>>>>>>>> 
>>>>>>>> javafx.scene.shape.Shape
>>>>>>>>     private static Path
>>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>>>>>> 
>>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>>     Path2D path;
>>>>>>>> 
>>>>>>>> I want to write a line as follows:
>>>>>>>> Path path = Path.createFromGeomShape(gc.path);
>>>>>>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>>>>>> 
>>>>>>>> However:
>>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>>>>>>> by the module.
>>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>>>>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>>>>>>> an accessor.
>>>>>>>> 
>>>>>>>> A possible solution is to add a new method:
>>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>> public Path getPath() {
>>>>>>>>     //implementation copied from
>>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>>>>>>> }
>>>>>>>> 
>>>>>>>> That would solve my immediate problem but raises the question... why is
>>>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>>>>>>> in progress that will impact this design?
>>>>>>>> 
>>>>>>>> PS my example is actually very important.  I currently use reflection and
>>>>>>>> module opens in the build to get the path but if the getPath method could
>>>>>>>> be added to GraphicsContext, that would be great.  For performance, it
>>>>>>>> would be even better to get the PathIterator directly instead of
>>>>>>>> translating into a javafx..Path but that is related to the bigger question.

From mp at jugs.org  Fri May  8 20:25:27 2020
From: mp at jugs.org (Michael Paus)
Date: Fri, 8 May 2020 22:25:27 +0200
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>
References: <5EB5B555.5020808@oracle.com>
 <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>
Message-ID: <ab8990d0-17b2-7421-488d-7e2284fca20b@jugs.org>

Hi,
I have to say that your requirements sound a little bit strange to me, 
but maybe you can make it clearer what your real use-case behind them is.
What I do not understand is why you are using the canvas at all. 
Conceptually the canvas is for direct mode rendering into an image. The 
fact that
this is handled a little bit different internally is an implementation 
detail, you should not rely on. Why don't you use the scene graph which 
seems
to provide many of the aspects that you need? I admit that there are a 
few hidden gems internally that I would also like to be made public 
(e.g. the flattening path iterator) but I definitely see these things 
more in the scene graph context but not for Canvas.
Just my two ?ent.
Michael

Am 08.05.20 um 22:08 schrieb jfx user2:
> No... given a Shape, create a Path that represents the outline of that shape.  If I had a Path I wouldn?t be requesting the new methods.
>
> One of the workarounds for getting a Path from a GraphicsContext is to keep track of it as I?m drawing... however, this is overhead in the gc call that can become very expensive when you have a lot of gcs or if your gc is doing a lot of work.  The path is already there in Path2D along with a method to convert it to a public Path.  There?s no need for an expensive custom workaround.  All that?s required is a method on the GraphicsContext that returns a Path.  The same is true for getting a Path from a Shape.
>
> Please note that this behavior is desirable for highly optimized use of GraphicsContext and Shapes where you need ?outlines? of things in vector format.  The private api is unnecessarily hiding this information.
>
>> On May 8, 2020, at 3:38 PM, Philip Race <philip.race at oracle.com> wrote:
>>
>> ?The current path is defined by the application - you - and yet you don't know what it is  ?
>> You do say
>>> I have other workarounds where I have to maintain a path as I?m drawing in the canvas
>> Why can't you do that ? No internal API digging.
>>
>> -phil
>>
>>> On 5/8/20, 12:02 PM, jfx user2 wrote:
>>> Ok, then please consider the GraphicsContext request that I?ve made.  It simply enables you to get the Path from the context without exposing com classes at all.  I have other workarounds where I have to maintain a path as I?m drawing in the canvas or I have to do hit testing on a non vector image to determine the path but these are way more expensive than simply creating a Path object from the Path2D that is already in the GraphicContext.  That path can be used in drag and drop scenarios, fast secondary rendering under heavy gc use, edge tracing, and the list goes on.
>>>
>>> The same is true for the Shape class.  I?d like to request that the following be added to Shape:
>>> public Path getPath() {
>>>      return Shape.createFromGeomShape(getTransformedArea());
>>> }
>>>
>>> That?s it.  The underlying methods are there but the public api doesn?t expose them.  This gives you a vector outline of the Shape as Path.l on demand, not stored.
>>>
>>> There are expensive workarounds for performing these tasks and I spent a long time trying... until I discovers the private apis already had the capability but simply did. It expose it.
>>>
>>> I?d these are not supported, I?ll have to stick with reflection,  bytebuddy, or forking - non of which will be easily maintained or portable.
>>>
>>> Ps I will post additional concerns over time.  The next one likely has to do with the mismatch between javafx canvas (gc) and other canvases such as svg, html2.  I think there is private api that would help in this case.
>>>
>>>>> On May 8, 2020, at 2:41 PM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>> ?Since Canvas is an immediate mode graphics API, I presume you are interested in the most recent drawing primitive? (we don't keep the composite shape for all drawing primitives -- that would be both too expensive and not really appropriate). How would you expect current rendering attributes (e.g., transforms) to affect the results? These are all questions that need to be addressed.
>>>>
>>>> As for the bigger picture, we intentionally have a separate render graph with "peers" for each node, although some of the duplication of classes is historical (we used to have a looser decoupling before Prism became the only backend). Unless there is a compelling need, we are unlikely to consider changing this in the general case, but perhaps could look at specific cases if it made sense. This is a separate issue, though, from public API and the two shouldn't be conflated.
>>>>
>>>> Btw, JavaFX has been fully open-sourced since 2013, although the design of Prism predates that.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>>>>> Kevin, go easy please :0).  There is a need.
>>>>>
>>>>> Access to the outline of the path in the canvas is great for edge following, node attachment points, animating around the non-rectangular border of what?s actually displayed, etc.
>>>>>
>>>>> The other request that I haven?t posted yet is to do the same for Shape.   I?ve tested both of these enhancements and it works as desired.  I?ll post the second request soon.
>>>>>
>>>>> But back to the bigger picture.  The requests that I?m making are only additions to return a path from javafx not com.  But there are other cases where geometry and convenience methods in com would be beneficial to the public api.  It also seems odd that there are two layers to begin with...  parallel apis often result in too much object creation or cpu overhead translating between them.  I?ll be more specific about these cases over time.   Part of my intention is to spark a discussion about the design since previously this was relatively closed source.
>>>>>
>>>>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>>>> ?While there is no plan to "open up" more of com.sun.javafx (and that isn't really the right way to look at it), if you have a proposed enhancement to the existing public javafx.* classes we could discuss it.
>>>>>>
>>>>>> As for your specific example, can you say more about what your use case is? The GraphicsContext object is a drawing context for a Canvas node, so it is not a natural place to put an API that computes or returns a path. I get the sense that you are looking at the existing internal implementation classes and saying "how can I get access to some information that might be useful to my application" rather than describing what your application is trying to do. Once we understand what you are trying to do, we can discuss whether the need is general enough to propose adding to the public API of JavaFX and what form such a new API might take.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>>>>>>> I am aware of this and that?s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>>>>>>>
>>>>>>> Please consider the example I provided as a feature request.
>>>>>>>
>>>>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth<kevin.rushforth at oracle.com>  wrote:
>>>>>>>> ?Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>>>>>>>
>>>>>>>> -- Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>>>>>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>>>>>>>> in JavaFX?
>>>>>>>>>
>>>>>>>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>>>>>>>> in the javafx.scene.shape package?  Why are there missing features from
>>>>>>>>> Graphics2D?
>>>>>>>>>
>>>>>>>>> I have a specific example that prompted the question:
>>>>>>>>>
>>>>>>>>> Consider the following classes:
>>>>>>>>>
>>>>>>>>> javafx.scene.shape.Shape
>>>>>>>>>      private static Path
>>>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>>>>>>>
>>>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>>>      Path2D path;
>>>>>>>>>
>>>>>>>>> I want to write a line as follows:
>>>>>>>>> Path path = Path.createFromGeomShape(gc.path);
>>>>>>>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>>>>>>>
>>>>>>>>> However:
>>>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>>>>>>>> by the module.
>>>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>>>>>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>>>>>>>> an accessor.
>>>>>>>>>
>>>>>>>>> A possible solution is to add a new method:
>>>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>>> public Path getPath() {
>>>>>>>>>      //implementation copied from
>>>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> That would solve my immediate problem but raises the question... why is
>>>>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>>>>>>>> in progress that will impact this design?
>>>>>>>>>
>>>>>>>>> PS my example is actually very important.  I currently use reflection and
>>>>>>>>> module opens in the build to get the path but if the getPath method could
>>>>>>>>> be added to GraphicsContext, that would be great.  For performance, it
>>>>>>>>> would be even better to get the PathIterator directly instead of
>>>>>>>>> translating into a javafx..Path but that is related to the bigger question.



From kcr at openjdk.java.net  Fri May  8 20:46:18 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 20:46:18 GMT
Subject: RFR: 8244417: support static build for Windows
In-Reply-To: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
References: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
Message-ID: <8iW7Y47Mqzq6TW5KLvyaAMIJOMrC82Qe9NWR_vnbjRk=.f4e60cb1-0300-4bc1-8cc4-9b3d7e8257f5@github.com>

On Thu, 7 May 2020 21:15:02 GMT, Joeri Sykora <sykora at openjdk.org> wrote:

> Adds support for building static libraries of the OpenJFX modules for the Windows platform. Building static libraries
> is done by providing the gradle property `-PSTATIC_BUILD=true`.
> Changes include:
> 
> - add static flags for the compiler and linker
> - use `lib` for linking instead of `link`
> - only build and include version.rc once (from GlassResources.rc)
> - include library specific `JNI_OnLoad_xxx` methods
> - functionality loaded via `DllMain` has been implemented at a different location

Marked as reviewed by kcr (Lead).

-------------

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

From jfxuser2 at gmail.com  Fri May  8 22:18:04 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Fri, 8 May 2020 18:18:04 -0400
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <ab8990d0-17b2-7421-488d-7e2284fca20b@jugs.org>
References: <5EB5B555.5020808@oracle.com>
 <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>
 <ab8990d0-17b2-7421-488d-7e2284fca20b@jugs.org>
Message-ID: <CAHifg5f4_AV7tj-eZCXOhfK1mDy2yeadBO3Zj30TNFSZmNJz4w@mail.gmail.com>

>From the JavaDoc "Canvas is an image that can be drawn on using a set of
graphics commands provided by a GraphicsContext."  This a bit of a
misnomer.  While canvas can be used to draw in image (actually
GraphicsContext not canvas itself), the image based methods of
GraphicsContext are far outweighed by the "vector" or path based methods.
The GraphicsContext gives you the ability to freely create dynamic graphics
without the constraints of the Scene Graph.  It can be highly performant
and scalable if done properly.  The Scene Graph will not perform like the
GraphicsContext.  If you haven't worked with highly dynamic graphics, you
might not have encountered any issues.  The Scene Graph works ok up to a
certain number of objects and it is not good at adding and removing objects
often.  GraphicsContext does not have the same restrictions.  It can
involve more work but the end result will scale far beyond what you can do
in a Scene Graph... I think this is already widely accepted.

The proposed method on the GraphicsContext simply returns what is already
there.  It would convert the already stored Path2D to a Path.  Why reinvent
what is already present and only private?  This in turn CAN be used in the
Scene Graph but it can also be used as a container to draw back onto the
GraphicsContext.  You see,  a Path that is calculated once and then used
repeatedly to draw in the GraphicsContext (possibly even transformed) is
better than sub-optimally calculating that Path on every pass through the
GraphicsContext or storing it as an image or Shape (those were some of my
workarounds).

Anyway, I'm requesting that a private API be used to create a new public
method.  This is really no different than existing public methods that use
private APIs.  I'm not asking to expose private APIs (not in this request
:o).  There isn't even much code.  It's reusing what's already there.

Ask Gerrit Grunwald about his experience with the Scene Graph vs
Canvas/GraphicsContext.


On Fri, May 8, 2020 at 4:27 PM Michael Paus <mp at jugs.org> wrote:

> Hi,
> I have to say that your requirements sound a little bit strange to me,
> but maybe you can make it clearer what your real use-case behind them is.
> What I do not understand is why you are using the canvas at all.
> Conceptually the canvas is for direct mode rendering into an image. The
> fact that
> this is handled a little bit different internally is an implementation
> detail, you should not rely on. Why don't you use the scene graph which
> seems
> to provide many of the aspects that you need? I admit that there are a
> few hidden gems internally that I would also like to be made public
> (e.g. the flattening path iterator) but I definitely see these things
> more in the scene graph context but not for Canvas.
> Just my two ?ent.
> Michael
>
> Am 08.05.20 um 22:08 schrieb jfx user2:
> > No... given a Shape, create a Path that represents the outline of that
> shape.  If I had a Path I wouldn?t be requesting the new methods.
> >
> > One of the workarounds for getting a Path from a GraphicsContext is to
> keep track of it as I?m drawing... however, this is overhead in the gc call
> that can become very expensive when you have a lot of gcs or if your gc is
> doing a lot of work.  The path is already there in Path2D along with a
> method to convert it to a public Path.  There?s no need for an expensive
> custom workaround.  All that?s required is a method on the GraphicsContext
> that returns a Path.  The same is true for getting a Path from a Shape.
> >
> > Please note that this behavior is desirable for highly optimized use of
> GraphicsContext and Shapes where you need ?outlines? of things in vector
> format.  The private api is unnecessarily hiding this information.
> >
> >> On May 8, 2020, at 3:38 PM, Philip Race <philip.race at oracle.com> wrote:
> >>
> >> ?The current path is defined by the application - you - and yet you
> don't know what it is  ?
> >> You do say
> >>> I have other workarounds where I have to maintain a path as I?m
> drawing in the canvas
> >> Why can't you do that ? No internal API digging.
> >>
> >> -phil
> >>
> >>> On 5/8/20, 12:02 PM, jfx user2 wrote:
> >>> Ok, then please consider the GraphicsContext request that I?ve made.
> It simply enables you to get the Path from the context without exposing com
> classes at all.  I have other workarounds where I have to maintain a path
> as I?m drawing in the canvas or I have to do hit testing on a non vector
> image to determine the path but these are way more expensive than simply
> creating a Path object from the Path2D that is already in the
> GraphicContext.  That path can be used in drag and drop scenarios, fast
> secondary rendering under heavy gc use, edge tracing, and the list goes on.
> >>>
> >>> The same is true for the Shape class.  I?d like to request that the
> following be added to Shape:
> >>> public Path getPath() {
> >>>      return Shape.createFromGeomShape(getTransformedArea());
> >>> }
> >>>
> >>> That?s it.  The underlying methods are there but the public api
> doesn?t expose them.  This gives you a vector outline of the Shape as
> Path.l on demand, not stored.
> >>>
> >>> There are expensive workarounds for performing these tasks and I spent
> a long time trying... until I discovers the private apis already had the
> capability but simply did. It expose it.
> >>>
> >>> I?d these are not supported, I?ll have to stick with reflection,
> bytebuddy, or forking - non of which will be easily maintained or portable.
> >>>
> >>> Ps I will post additional concerns over time.  The next one likely has
> to do with the mismatch between javafx canvas (gc) and other canvases such
> as svg, html2.  I think there is private api that would help in this case.
> >>>
> >>>>> On May 8, 2020, at 2:41 PM, Kevin Rushforth<
> kevin.rushforth at oracle.com>  wrote:
> >>>> ?Since Canvas is an immediate mode graphics API, I presume you are
> interested in the most recent drawing primitive? (we don't keep the
> composite shape for all drawing primitives -- that would be both too
> expensive and not really appropriate). How would you expect current
> rendering attributes (e.g., transforms) to affect the results? These are
> all questions that need to be addressed.
> >>>>
> >>>> As for the bigger picture, we intentionally have a separate render
> graph with "peers" for each node, although some of the duplication of
> classes is historical (we used to have a looser decoupling before Prism
> became the only backend). Unless there is a compelling need, we are
> unlikely to consider changing this in the general case, but perhaps could
> look at specific cases if it made sense. This is a separate issue, though,
> from public API and the two shouldn't be conflated.
> >>>>
> >>>> Btw, JavaFX has been fully open-sourced since 2013, although the
> design of Prism predates that.
> >>>>
> >>>> -- Kevin
> >>>>
> >>>>
> >>>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
> >>>>> Kevin, go easy please :0).  There is a need.
> >>>>>
> >>>>> Access to the outline of the path in the canvas is great for edge
> following, node attachment points, animating around the non-rectangular
> border of what?s actually displayed, etc.
> >>>>>
> >>>>> The other request that I haven?t posted yet is to do the same for
> Shape.   I?ve tested both of these enhancements and it works as desired.
> I?ll post the second request soon.
> >>>>>
> >>>>> But back to the bigger picture.  The requests that I?m making are
> only additions to return a path from javafx not com.  But there are other
> cases where geometry and convenience methods in com would be beneficial to
> the public api.  It also seems odd that there are two layers to begin
> with...  parallel apis often result in too much object creation or cpu
> overhead translating between them.  I?ll be more specific about these cases
> over time.   Part of my intention is to spark a discussion about the design
> since previously this was relatively closed source.
> >>>>>
> >>>>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth<
> kevin.rushforth at oracle.com>  wrote:
> >>>>>> ?While there is no plan to "open up" more of com.sun.javafx (and
> that isn't really the right way to look at it), if you have a proposed
> enhancement to the existing public javafx.* classes we could discuss it.
> >>>>>>
> >>>>>> As for your specific example, can you say more about what your use
> case is? The GraphicsContext object is a drawing context for a Canvas node,
> so it is not a natural place to put an API that computes or returns a path.
> I get the sense that you are looking at the existing internal
> implementation classes and saying "how can I get access to some information
> that might be useful to my application" rather than describing what your
> application is trying to do. Once we understand what you are trying to do,
> we can discuss whether the need is general enough to propose adding to the
> public API of JavaFX and what form such a new API might take.
> >>>>>>
> >>>>>> -- Kevin
> >>>>>>
> >>>>>>
> >>>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
> >>>>>>> I am aware of this and that?s why I am asking.  There are useful
> private features in com.sun.javafx and I explained one of them in my
> message.  I have an additional related example but the larger question is
> if there is a plan to open more of com.sun.javafx to the public api,
> documentation surrounding this, or possibly a complete replacement?
> >>>>>>>
> >>>>>>> Please consider the example I provided as a feature request.
> >>>>>>>
> >>>>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth<
> kevin.rushforth at oracle.com>  wrote:
> >>>>>>>> ?Only javafx.* packages are part of the public API. Anything
> else, including com.sun.javafx.*, is internal implementation details that
> an application should never call.
> >>>>>>>>
> >>>>>>>> -- Kevin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
> >>>>>>>>> Is there documentation around the packages (com.sun.javafx vs
> javafx) used
> >>>>>>>>> in JavaFX?
> >>>>>>>>>
> >>>>>>>>> For example, why is there a com.sun.javafx.geom that isn't fully
> mirrored
> >>>>>>>>> in the javafx.scene.shape package?  Why are there missing
> features from
> >>>>>>>>> Graphics2D?
> >>>>>>>>>
> >>>>>>>>> I have a specific example that prompted the question:
> >>>>>>>>>
> >>>>>>>>> Consider the following classes:
> >>>>>>>>>
> >>>>>>>>> javafx.scene.shape.Shape
> >>>>>>>>>      private static Path
> >>>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
> >>>>>>>>>
> >>>>>>>>> javafx.scene.canvas.GraphicsContext
> >>>>>>>>>      Path2D path;
> >>>>>>>>>
> >>>>>>>>> I want to write a line as follows:
> >>>>>>>>> Path path = Path.createFromGeomShape(gc.path);
> >>>>>>>>> b/c I want to inexpensively get the outline of the
> GraphicsContext.
> >>>>>>>>>
> >>>>>>>>> However:
> >>>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which
> isn't exported
> >>>>>>>>> by the module.
> >>>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
> >>>>>>>>> We can't access path in GraphicsContext b/c it's default and
> doesn't have
> >>>>>>>>> an accessor.
> >>>>>>>>>
> >>>>>>>>> A possible solution is to add a new method:
> >>>>>>>>> javafx.scene.canvas.GraphicsContext
> >>>>>>>>> public Path getPath() {
> >>>>>>>>>      //implementation copied from
> >>>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as
> the path
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> That would solve my immediate problem but raises the question...
> why is
> >>>>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is
> there any work
> >>>>>>>>> in progress that will impact this design?
> >>>>>>>>>
> >>>>>>>>> PS my example is actually very important.  I currently use
> reflection and
> >>>>>>>>> module opens in the build to get the path but if the getPath
> method could
> >>>>>>>>> be added to GraphicsContext, that would be great.  For
> performance, it
> >>>>>>>>> would be even better to get the PathIterator directly instead of
> >>>>>>>>> translating into a javafx..Path but that is related to the
> bigger question.
>
>
>

From kevin.rushforth at oracle.com  Fri May  8 23:01:52 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 May 2020 16:01:52 -0700
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <CAHifg5f4_AV7tj-eZCXOhfK1mDy2yeadBO3Zj30TNFSZmNJz4w@mail.gmail.com>
References: <5EB5B555.5020808@oracle.com>
 <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>
 <ab8990d0-17b2-7421-488d-7e2284fca20b@jugs.org>
 <CAHifg5f4_AV7tj-eZCXOhfK1mDy2yeadBO3Zj30TNFSZmNJz4w@mail.gmail.com>
Message-ID: <2921b669-24b7-27eb-cdd2-f20e02598517@oracle.com>

I can see the value in a Shape.toPath() method (or alternatively? a 
Path.of(Shape) method). I'm still not sold on the value proposition of a 
similar method to GraphicsContext (and "just make this internal 
information public" isn't a recipe for adding new API).

You can file an Enhancement request or two if you want. They aren't 
likely to be high on our list to look at. If you are willing to put in 
the effort to define and implement the feature yourself including: 
getting consensus that it is worth adding as a supported public API, 
specifying the API, implementing it (this is the one step where the fact 
that there is existing implementation is even relevant), writing 
automated tests for it, etc., then that might be a way forward. In that 
case, I refer you to the CONTRIBUTING [1] guidelines for the project.

-- Kevin

[1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md


On 5/8/2020 3:18 PM, jfx user2 wrote:
>  From the JavaDoc "Canvas is an image that can be drawn on using a set of
> graphics commands provided by a GraphicsContext."  This a bit of a
> misnomer.  While canvas can be used to draw in image (actually
> GraphicsContext not canvas itself), the image based methods of
> GraphicsContext are far outweighed by the "vector" or path based methods.
> The GraphicsContext gives you the ability to freely create dynamic graphics
> without the constraints of the Scene Graph.  It can be highly performant
> and scalable if done properly.  The Scene Graph will not perform like the
> GraphicsContext.  If you haven't worked with highly dynamic graphics, you
> might not have encountered any issues.  The Scene Graph works ok up to a
> certain number of objects and it is not good at adding and removing objects
> often.  GraphicsContext does not have the same restrictions.  It can
> involve more work but the end result will scale far beyond what you can do
> in a Scene Graph... I think this is already widely accepted.
>
> The proposed method on the GraphicsContext simply returns what is already
> there.  It would convert the already stored Path2D to a Path.  Why reinvent
> what is already present and only private?  This in turn CAN be used in the
> Scene Graph but it can also be used as a container to draw back onto the
> GraphicsContext.  You see,  a Path that is calculated once and then used
> repeatedly to draw in the GraphicsContext (possibly even transformed) is
> better than sub-optimally calculating that Path on every pass through the
> GraphicsContext or storing it as an image or Shape (those were some of my
> workarounds).
>
> Anyway, I'm requesting that a private API be used to create a new public
> method.  This is really no different than existing public methods that use
> private APIs.  I'm not asking to expose private APIs (not in this request
> :o).  There isn't even much code.  It's reusing what's already there.
>
> Ask Gerrit Grunwald about his experience with the Scene Graph vs
> Canvas/GraphicsContext.
>
>
> On Fri, May 8, 2020 at 4:27 PM Michael Paus <mp at jugs.org> wrote:
>
>> Hi,
>> I have to say that your requirements sound a little bit strange to me,
>> but maybe you can make it clearer what your real use-case behind them is.
>> What I do not understand is why you are using the canvas at all.
>> Conceptually the canvas is for direct mode rendering into an image. The
>> fact that
>> this is handled a little bit different internally is an implementation
>> detail, you should not rely on. Why don't you use the scene graph which
>> seems
>> to provide many of the aspects that you need? I admit that there are a
>> few hidden gems internally that I would also like to be made public
>> (e.g. the flattening path iterator) but I definitely see these things
>> more in the scene graph context but not for Canvas.
>> Just my two ?ent.
>> Michael
>>
>> Am 08.05.20 um 22:08 schrieb jfx user2:
>>> No... given a Shape, create a Path that represents the outline of that
>> shape.  If I had a Path I wouldn?t be requesting the new methods.
>>> One of the workarounds for getting a Path from a GraphicsContext is to
>> keep track of it as I?m drawing... however, this is overhead in the gc call
>> that can become very expensive when you have a lot of gcs or if your gc is
>> doing a lot of work.  The path is already there in Path2D along with a
>> method to convert it to a public Path.  There?s no need for an expensive
>> custom workaround.  All that?s required is a method on the GraphicsContext
>> that returns a Path.  The same is true for getting a Path from a Shape.
>>> Please note that this behavior is desirable for highly optimized use of
>> GraphicsContext and Shapes where you need ?outlines? of things in vector
>> format.  The private api is unnecessarily hiding this information.
>>>> On May 8, 2020, at 3:38 PM, Philip Race <philip.race at oracle.com> wrote:
>>>>
>>>> ?The current path is defined by the application - you - and yet you
>> don't know what it is  ?
>>>> You do say
>>>>> I have other workarounds where I have to maintain a path as I?m
>> drawing in the canvas
>>>> Why can't you do that ? No internal API digging.
>>>>
>>>> -phil
>>>>
>>>>> On 5/8/20, 12:02 PM, jfx user2 wrote:
>>>>> Ok, then please consider the GraphicsContext request that I?ve made.
>> It simply enables you to get the Path from the context without exposing com
>> classes at all.  I have other workarounds where I have to maintain a path
>> as I?m drawing in the canvas or I have to do hit testing on a non vector
>> image to determine the path but these are way more expensive than simply
>> creating a Path object from the Path2D that is already in the
>> GraphicContext.  That path can be used in drag and drop scenarios, fast
>> secondary rendering under heavy gc use, edge tracing, and the list goes on.
>>>>> The same is true for the Shape class.  I?d like to request that the
>> following be added to Shape:
>>>>> public Path getPath() {
>>>>>       return Shape.createFromGeomShape(getTransformedArea());
>>>>> }
>>>>>
>>>>> That?s it.  The underlying methods are there but the public api
>> doesn?t expose them.  This gives you a vector outline of the Shape as
>> Path.l on demand, not stored.
>>>>> There are expensive workarounds for performing these tasks and I spent
>> a long time trying... until I discovers the private apis already had the
>> capability but simply did. It expose it.
>>>>> I?d these are not supported, I?ll have to stick with reflection,
>> bytebuddy, or forking - non of which will be easily maintained or portable.
>>>>> Ps I will post additional concerns over time.  The next one likely has
>> to do with the mismatch between javafx canvas (gc) and other canvases such
>> as svg, html2.  I think there is private api that would help in this case.
>>>>>>> On May 8, 2020, at 2:41 PM, Kevin Rushforth<
>> kevin.rushforth at oracle.com>  wrote:
>>>>>> ?Since Canvas is an immediate mode graphics API, I presume you are
>> interested in the most recent drawing primitive? (we don't keep the
>> composite shape for all drawing primitives -- that would be both too
>> expensive and not really appropriate). How would you expect current
>> rendering attributes (e.g., transforms) to affect the results? These are
>> all questions that need to be addressed.
>>>>>> As for the bigger picture, we intentionally have a separate render
>> graph with "peers" for each node, although some of the duplication of
>> classes is historical (we used to have a looser decoupling before Prism
>> became the only backend). Unless there is a compelling need, we are
>> unlikely to consider changing this in the general case, but perhaps could
>> look at specific cases if it made sense. This is a separate issue, though,
>> from public API and the two shouldn't be conflated.
>>>>>> Btw, JavaFX has been fully open-sourced since 2013, although the
>> design of Prism predates that.
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>>>>>>> Kevin, go easy please :0).  There is a need.
>>>>>>>
>>>>>>> Access to the outline of the path in the canvas is great for edge
>> following, node attachment points, animating around the non-rectangular
>> border of what?s actually displayed, etc.
>>>>>>> The other request that I haven?t posted yet is to do the same for
>> Shape.   I?ve tested both of these enhancements and it works as desired.
>> I?ll post the second request soon.
>>>>>>> But back to the bigger picture.  The requests that I?m making are
>> only additions to return a path from javafx not com.  But there are other
>> cases where geometry and convenience methods in com would be beneficial to
>> the public api.  It also seems odd that there are two layers to begin
>> with...  parallel apis often result in too much object creation or cpu
>> overhead translating between them.  I?ll be more specific about these cases
>> over time.   Part of my intention is to spark a discussion about the design
>> since previously this was relatively closed source.
>>>>>>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth<
>> kevin.rushforth at oracle.com>  wrote:
>>>>>>>> ?While there is no plan to "open up" more of com.sun.javafx (and
>> that isn't really the right way to look at it), if you have a proposed
>> enhancement to the existing public javafx.* classes we could discuss it.
>>>>>>>> As for your specific example, can you say more about what your use
>> case is? The GraphicsContext object is a drawing context for a Canvas node,
>> so it is not a natural place to put an API that computes or returns a path.
>> I get the sense that you are looking at the existing internal
>> implementation classes and saying "how can I get access to some information
>> that might be useful to my application" rather than describing what your
>> application is trying to do. Once we understand what you are trying to do,
>> we can discuss whether the need is general enough to propose adding to the
>> public API of JavaFX and what form such a new API might take.
>>>>>>>> -- Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>>>>>>>>> I am aware of this and that?s why I am asking.  There are useful
>> private features in com.sun.javafx and I explained one of them in my
>> message.  I have an additional related example but the larger question is
>> if there is a plan to open more of com.sun.javafx to the public api,
>> documentation surrounding this, or possibly a complete replacement?
>>>>>>>>> Please consider the example I provided as a feature request.
>>>>>>>>>
>>>>>>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth<
>> kevin.rushforth at oracle.com>  wrote:
>>>>>>>>>> ?Only javafx.* packages are part of the public API. Anything
>> else, including com.sun.javafx.*, is internal implementation details that
>> an application should never call.
>>>>>>>>>> -- Kevin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>>>>>>>>>> Is there documentation around the packages (com.sun.javafx vs
>> javafx) used
>>>>>>>>>>> in JavaFX?
>>>>>>>>>>>
>>>>>>>>>>> For example, why is there a com.sun.javafx.geom that isn't fully
>> mirrored
>>>>>>>>>>> in the javafx.scene.shape package?  Why are there missing
>> features from
>>>>>>>>>>> Graphics2D?
>>>>>>>>>>>
>>>>>>>>>>> I have a specific example that prompted the question:
>>>>>>>>>>>
>>>>>>>>>>> Consider the following classes:
>>>>>>>>>>>
>>>>>>>>>>> javafx.scene.shape.Shape
>>>>>>>>>>>       private static Path
>>>>>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>>>>>>>>>
>>>>>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>>>>>       Path2D path;
>>>>>>>>>>>
>>>>>>>>>>> I want to write a line as follows:
>>>>>>>>>>> Path path = Path.createFromGeomShape(gc.path);
>>>>>>>>>>> b/c I want to inexpensively get the outline of the
>> GraphicsContext.
>>>>>>>>>>> However:
>>>>>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which
>> isn't exported
>>>>>>>>>>> by the module.
>>>>>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>>>>>>>>>>> We can't access path in GraphicsContext b/c it's default and
>> doesn't have
>>>>>>>>>>> an accessor.
>>>>>>>>>>>
>>>>>>>>>>> A possible solution is to add a new method:
>>>>>>>>>>> javafx.scene.canvas.GraphicsContext
>>>>>>>>>>> public Path getPath() {
>>>>>>>>>>>       //implementation copied from
>>>>>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as
>> the path
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> That would solve my immediate problem but raises the question...
>> why is
>>>>>>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is
>> there any work
>>>>>>>>>>> in progress that will impact this design?
>>>>>>>>>>>
>>>>>>>>>>> PS my example is actually very important.  I currently use
>> reflection and
>>>>>>>>>>> module opens in the build to get the path but if the getPath
>> method could
>>>>>>>>>>> be added to GraphicsContext, that would be great.  For
>> performance, it
>>>>>>>>>>> would be even better to get the PathIterator directly instead of
>>>>>>>>>>> translating into a javafx..Path but that is related to the
>> bigger question.
>>
>>
>>


From mp at jugs.org  Fri May  8 23:13:21 2020
From: mp at jugs.org (Michael Paus)
Date: Sat, 9 May 2020 01:13:21 +0200
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <CAHifg5f4_AV7tj-eZCXOhfK1mDy2yeadBO3Zj30TNFSZmNJz4w@mail.gmail.com>
References: <5EB5B555.5020808@oracle.com>
 <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>
 <ab8990d0-17b2-7421-488d-7e2284fca20b@jugs.org>
 <CAHifg5f4_AV7tj-eZCXOhfK1mDy2yeadBO3Zj30TNFSZmNJz4w@mail.gmail.com>
Message-ID: <a054de37-758f-4789-7f9b-a0e3cd88b59a@jugs.org>

I think I know quite a bit about JavaFX graphics and I do not generally 
agree with your statements.
Especially the statement that the Canvas is so much superior is a myth 
from the old days of Java 8
where there were a few performance bugs in the scene graph handling. But 
that's a long time ago.
(I even gave a workshop on this at the JavaLand conference some time 
ago.) Maybe you could present
a few more details about your use-case and not so much about the 
technique that you think is the
best fit for it. Maybe even some demo code somewhere. I am always 
interested in a discussion about
graphics as long as it is supported by facts. Neither the scene graph 
nor the canvas is a silver bullet.
It always depends on your use-case.
Michael

Am 09.05.20 um 00:18 schrieb jfx user2:
> From the JavaDoc "Canvas is an image that can be drawn on using a set 
> of graphics commands provided by a GraphicsContext." ?This a bit of a 
> misnomer.? While canvas can be used to draw in image (actually 
> GraphicsContext not canvas itself), the image based methods of 
> GraphicsContext are far outweighed by the "vector" or path based 
> methods.? The GraphicsContext gives you the ability to freely create 
> dynamic graphics without the constraints of the Scene Graph.? It can 
> be highly performant and scalable if done properly.? The Scene Graph 
> will not perform like the GraphicsContext.? If you haven't worked with 
> highly dynamic graphics, you might not have encountered any issues.? 
> The Scene Graph works ok up to a certain number of objects and it is 
> not good at adding and removing objects often.? GraphicsContext does 
> not have the same restrictions.? It can involve more work but the end 
> result will scale far beyond what you can do in a Scene Graph... I 
> think this is already widely accepted.
>
> The proposed method on the GraphicsContext simply returns what is 
> already there.? It would convert the already stored Path2D to a Path.? 
> Why reinvent what is already present and only private? This in turn 
> CAN be used in the Scene Graph but it can also be used as a container 
> to draw back onto the GraphicsContext.? You see, ?a Path that is 
> calculated once and then used repeatedly to draw in the 
> GraphicsContext (possibly even transformed) is better than 
> sub-optimally calculating that Path on every pass through the 
> GraphicsContext or storing it as an image or Shape (those were some of 
> my workarounds).
>
> Anyway, I'm requesting that a private API be used to create a new 
> public method.? This is really no different than existing public 
> methods that use private APIs.? I'm not asking to expose private APIs 
> (not in this request :o).? There isn't even much code.? It's reusing 
> what's already there.
>
> Ask Gerrit Grunwald about his experience with the Scene Graph vs 
> Canvas/GraphicsContext.
>
>
> On Fri, May 8, 2020 at 4:27 PM Michael Paus <mp at jugs.org 
> <mailto:mp at jugs.org>> wrote:
>
>     Hi,
>     I have to say that your requirements sound a little bit strange to
>     me,
>     but maybe you can make it clearer what your real use-case behind
>     them is.
>     What I do not understand is why you are using the canvas at all.
>     Conceptually the canvas is for direct mode rendering into an
>     image. The
>     fact that
>     this is handled a little bit different internally is an
>     implementation
>     detail, you should not rely on. Why don't you use the scene graph
>     which
>     seems
>     to provide many of the aspects that you need? I admit that there
>     are a
>     few hidden gems internally that I would also like to be made public
>     (e.g. the flattening path iterator) but I definitely see these things
>     more in the scene graph context but not for Canvas.
>     Just my two ?ent.
>     Michael
>
>     Am 08.05.20 um 22:08 schrieb jfx user2:
>     > No... given a Shape, create a Path that represents the outline
>     of that shape.? If I had a Path I wouldn?t be requesting the new
>     methods.
>     >
>     > One of the workarounds for getting a Path from a GraphicsContext
>     is to keep track of it as I?m drawing... however, this is overhead
>     in the gc call that can become very expensive when you have a lot
>     of gcs or if your gc is doing a lot of work.? The path is already
>     there in Path2D along with a method to convert it to a public
>     Path.? There?s no need for an expensive custom workaround.? All
>     that?s required is a method on the GraphicsContext that returns a
>     Path.? The same is true for getting a Path from a Shape.
>     >
>     > Please note that this behavior is desirable for highly optimized
>     use of GraphicsContext and Shapes where you need ?outlines? of
>     things in vector format.? The private api is unnecessarily hiding
>     this information.
>     >
>     >> On May 8, 2020, at 3:38 PM, Philip Race <philip.race at oracle.com
>     <mailto:philip.race at oracle.com>> wrote:
>     >>
>     >> ?The current path is defined by the application - you - and yet
>     you don't know what it is? ?
>     >> You do say
>     >>> I have other workarounds where I have to maintain a path as
>     I?m drawing in the canvas
>     >> Why can't you do that ? No internal API digging.
>     >>
>     >> -phil
>     >>
>     >>> On 5/8/20, 12:02 PM, jfx user2 wrote:
>     >>> Ok, then please consider the GraphicsContext request that I?ve
>     made.? It simply enables you to get the Path from the context
>     without exposing com classes at all.? I have other workarounds
>     where I have to maintain a path as I?m drawing in the canvas or I
>     have to do hit testing on a non vector image to determine the path
>     but these are way more expensive than simply creating a Path
>     object from the Path2D that is already in the GraphicContext.?
>     That path can be used in drag and drop scenarios, fast secondary
>     rendering under heavy gc use, edge tracing, and the list goes on.
>     >>>
>     >>> The same is true for the Shape class.? I?d like to request
>     that the following be added to Shape:
>     >>> public Path getPath() {
>     >>>? ? ? return Shape.createFromGeomShape(getTransformedArea());
>     >>> }
>     >>>
>     >>> That?s it.? The underlying methods are there but the public
>     api doesn?t expose them.? This gives you a vector outline of the
>     Shape as Path.l on demand, not stored.
>     >>>
>     >>> There are expensive workarounds for performing these tasks and
>     I spent a long time trying... until I discovers the private apis
>     already had the capability but simply did. It expose it.
>     >>>
>     >>> I?d these are not supported, I?ll have to stick with
>     reflection,? bytebuddy, or forking - non of which will be easily
>     maintained or portable.
>     >>>
>     >>> Ps I will post additional concerns over time. The next one
>     likely has to do with the mismatch between javafx canvas (gc) and
>     other canvases such as svg, html2.? I think there is private api
>     that would help in this case.
>     >>>
>     >>>>> On May 8, 2020, at 2:41 PM, Kevin
>     Rushforth<kevin.rushforth at oracle.com
>     <mailto:kevin.rushforth at oracle.com>> wrote:
>     >>>> ?Since Canvas is an immediate mode graphics API, I presume
>     you are interested in the most recent drawing primitive? (we don't
>     keep the composite shape for all drawing primitives -- that would
>     be both too expensive and not really appropriate). How would you
>     expect current rendering attributes (e.g., transforms) to affect
>     the results? These are all questions that need to be addressed.
>     >>>>
>     >>>> As for the bigger picture, we intentionally have a separate
>     render graph with "peers" for each node, although some of the
>     duplication of classes is historical (we used to have a looser
>     decoupling before Prism became the only backend). Unless there is
>     a compelling need, we are unlikely to consider changing this in
>     the general case, but perhaps could look at specific cases if it
>     made sense. This is a separate issue, though, from public API and
>     the two shouldn't be conflated.
>     >>>>
>     >>>> Btw, JavaFX has been fully open-sourced since 2013, although
>     the design of Prism predates that.
>     >>>>
>     >>>> -- Kevin
>     >>>>
>     >>>>
>     >>>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>     >>>>> Kevin, go easy please :0).? There is a need.
>     >>>>>
>     >>>>> Access to the outline of the path in the canvas is great for
>     edge following, node attachment points, animating around the
>     non-rectangular border of what?s actually displayed, etc.
>     >>>>>
>     >>>>> The other request that I haven?t posted yet is to do the
>     same for Shape.? ?I?ve tested both of these enhancements and it
>     works as desired.? I?ll post the second request soon.
>     >>>>>
>     >>>>> But back to the bigger picture.? The requests that I?m
>     making are only additions to return a path from javafx not com.?
>     But there are other cases where geometry and convenience methods
>     in com would be beneficial to the public api.? It also seems odd
>     that there are two layers to begin with...? parallel apis often
>     result in too much object creation or cpu overhead translating
>     between them.? I?ll be more specific about these cases over time.?
>     ?Part of my intention is to spark a discussion about the design
>     since previously this was relatively closed source.
>     >>>>>
>     >>>>>>> On May 8, 2020, at 1:12 PM, Kevin
>     Rushforth<kevin.rushforth at oracle.com
>     <mailto:kevin.rushforth at oracle.com>> wrote:
>     >>>>>> ?While there is no plan to "open up" more of com.sun.javafx
>     (and that isn't really the right way to look at it), if you have a
>     proposed enhancement to the existing public javafx.* classes we
>     could discuss it.
>     >>>>>>
>     >>>>>> As for your specific example, can you say more about what
>     your use case is? The GraphicsContext object is a drawing context
>     for a Canvas node, so it is not a natural place to put an API that
>     computes or returns a path. I get the sense that you are looking
>     at the existing internal implementation classes and saying "how
>     can I get access to some information that might be useful to my
>     application" rather than describing what your application is
>     trying to do. Once we understand what you are trying to do, we can
>     discuss whether the need is general enough to propose adding to
>     the public API of JavaFX and what form such a new API might take.
>     >>>>>>
>     >>>>>> -- Kevin
>     >>>>>>
>     >>>>>>
>     >>>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>     >>>>>>> I am aware of this and that?s why I am asking.? There are
>     useful private features in com.sun.javafx and I explained one of
>     them in my message.? I have an additional related example but the
>     larger question is if there is a plan to open more of
>     com.sun.javafx to the public api, documentation surrounding this,
>     or possibly a complete replacement?
>     >>>>>>>
>     >>>>>>> Please consider the example I provided as a feature request.
>     >>>>>>>
>     >>>>>>>>> On May 8, 2020, at 9:39 AM, Kevin
>     Rushforth<kevin.rushforth at oracle.com
>     <mailto:kevin.rushforth at oracle.com>> wrote:
>     >>>>>>>> ?Only javafx.* packages are part of the public API.
>     Anything else, including com.sun.javafx.*, is internal
>     implementation details that an application should never call.
>     >>>>>>>>
>     >>>>>>>> -- Kevin
>     >>>>>>>>
>     >>>>>>>>
>     >>>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>     >>>>>>>>> Is there documentation around the packages
>     (com.sun.javafx vs javafx) used
>     >>>>>>>>> in JavaFX?
>     >>>>>>>>>
>     >>>>>>>>> For example, why is there a com.sun.javafx.geom that
>     isn't fully mirrored
>     >>>>>>>>> in the javafx.scene.shape package?? Why are there
>     missing features from
>     >>>>>>>>> Graphics2D?
>     >>>>>>>>>
>     >>>>>>>>> I have a specific example that prompted the question:
>     >>>>>>>>>
>     >>>>>>>>> Consider the following classes:
>     >>>>>>>>>
>     >>>>>>>>> javafx.scene.shape.Shape
>     >>>>>>>>>? ? ? private static Path
>     >>>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>     >>>>>>>>>
>     >>>>>>>>> javafx.scene.canvas.GraphicsContext
>     >>>>>>>>>? ? ? Path2D path;
>     >>>>>>>>>
>     >>>>>>>>> I want to write a line as follows:
>     >>>>>>>>> Path path = Path.createFromGeomShape(gc.path);
>     >>>>>>>>> b/c I want to inexpensively get the outline of the
>     GraphicsContext.
>     >>>>>>>>>
>     >>>>>>>>> However:
>     >>>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom
>     which isn't exported
>     >>>>>>>>> by the module.
>     >>>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>     >>>>>>>>> We can't access path in GraphicsContext b/c it's default
>     and doesn't have
>     >>>>>>>>> an accessor.
>     >>>>>>>>>
>     >>>>>>>>> A possible solution is to add a new method:
>     >>>>>>>>> javafx.scene.canvas.GraphicsContext
>     >>>>>>>>> public Path getPath() {
>     >>>>>>>>>? ? ? //implementation copied from
>     >>>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use
>     gc.path as the path
>     >>>>>>>>> }
>     >>>>>>>>>
>     >>>>>>>>> That would solve my immediate problem but raises the
>     question... why is
>     >>>>>>>>> com.sun.javafx hidden? What's the architectural reason??
>     Is there any work
>     >>>>>>>>> in progress that will impact this design?
>     >>>>>>>>>
>     >>>>>>>>> PS my example is actually very important.? I currently
>     use reflection and
>     >>>>>>>>> module opens in the build to get the path but if the
>     getPath method could
>     >>>>>>>>> be added to GraphicsContext, that would be great.? For
>     performance, it
>     >>>>>>>>> would be even better to get the PathIterator directly
>     instead of
>     >>>>>>>>> translating into a javafx..Path but that is related to
>     the bigger question.
>
>


From kcr at openjdk.java.net  Fri May  8 23:50:47 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 8 May 2020 23:50:47 GMT
Subject: RFR: 8218973: SVG with masking is not rendering image with mask
 effect
In-Reply-To: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
Message-ID: <ay2Qgeb2XQbzwo2GRjYAp3paXKYodnGhTJ8qZynQqLc=.2b4335ac-643a-45c3-9dd2-d88eb971bb9c@github.com>

On Thu, 7 May 2020 09:19:28 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
> otherwise use usual way of rendering.

I verified that this does fix the bug, although there is a resource issue you will need to address. When I run a simple
test (the one attached to the bug report) I get the following warning messages:

Outstanding resource locks detected:
D3D Vram Pool: 21,073,412 used (3.9%), 67,108,864 target (12.5%), 536,870,912 max
13 total resources being managed
average resource age is 0.6 frames
0 resources at maximum supported age (0.0%)
5 resources marked permanent (38.5%)
3 resources have had mismatched locks (23.1%)
3 resources locked (23.1%)
8 resources contain interesting data (61.5%)
0 resources disappeared (0.0%)

You need to `unlock()` and `dispose()` the temporary RTTs when you are done with them. You should also `dispose()` the
temporary Texture.

I left a couple inline comments as well, the main question being about whether we really need a second RTT for the mask
texture.

modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 549:

> 548:                             Texture.WrapMode.CLAMP_NOT_NEEDED);
> 549:                     RTTexture maskRtTexture = g.getResourceFactory().createRTTexture(nativeMaskImage.getWidth(),
> 550:                             nativeMaskImage.getHeight(), Texture.WrapMode.CLAMP_NOT_NEEDED);

Why do you need to create a second RTT here? I would have thought you could use the mask texture directly (you may need
to scale the image in order to do that).

modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 566:

> 565:                             filterContext = PrFilterContext.getInstance(screen);
> 566:                         }
> 567:                         PrDrawable imagePrDrawable = PrDrawable.create(filterContext, paintRtTexture);

Did you test both the SW pipeline and printing paths?

-------------

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

From kcr at openjdk.java.net  Sat May  9 14:10:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 9 May 2020 14:10:46 GMT
Subject: [Rev 01] RFR: 8242861: Update ImagePattern to apply SVG pattern
 transforms
In-Reply-To: <S8iddT7x_rivZvqZ7aVs04OoelN4r1kiy50gmGCrKJk=.415e611a-3280-409d-95e3-3577017c3b91@github.com>
References: <f08XfTtcIW6UNTnycmJf8EUleQtbn76CZGFMnc3_vdQ=.6c803b83-6794-41dd-867e-ceb5f6c43bf6@github.com>
 <S8iddT7x_rivZvqZ7aVs04OoelN4r1kiy50gmGCrKJk=.415e611a-3280-409d-95e3-3577017c3b91@github.com>
Message-ID: <cjkDZnuSEOlT44JJADk1EekM6Bgiv4YyxR0k27Rr2XQ=.9187f583-683d-45b9-bdb6-9897eed38caa@github.com>

On Thu, 23 Apr 2020 12:31:34 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

>> fillPath() and fillRect() functions in
>> [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp)
>> use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as
>> ImagePattern doesn't have the same attribute. So, the final image won't be transformed.
>
> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CanvasTest

This works for the HW accelerated pipeline, but you need to also modify the SW pipeline and J2D pipeline (used for
printing). See
[SWPaint::computeImagePatternTransform](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWPaint.java#L280)
and the ImagePattern case in
[J2DPrismGraphics::toJ2DPaint](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java#L282).
In the J2D pipeline case, you will have more work to do, since it doesn't use a pattern transform that I can see.

-------------

Changes requested by kcr (Lead).

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

From kevin.rushforth at oracle.com  Sat May  9 15:16:46 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 9 May 2020 08:16:46 -0700
Subject: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP
 (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for
 review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script
 engines implement javax.script.Compilabel compile scripts"
In-Reply-To: <34d30efa-a87c-261e-36b3-e5f68f38c389@wu.ac.at>
References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>
 <d237cbbe-f1fe-519b-e378-ad576a4944ff@oracle.com>
 <bd3eb6ef-154f-811d-936a-37543a2a244c@wu.ac.at>
 <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at>
 <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com>
 <eb73c12e-0d76-0570-7903-0288696fe57a@wu.ac.at>
 <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at>
 <e08195ad-c924-3fba-5407-cfeb3e91fa63@oracle.com>
 <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at>
 <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at>
 <b27d7276-2a52-e756-baa6-18678048e226@wu.ac.at>
 <34d30efa-a87c-261e-36b3-e5f68f38c389@wu.ac.at>
Message-ID: <2a2007be-8ffa-e0c1-c252-0e9a5281ef3b@oracle.com>

Hi Rony,

I'm finally getting back to this. I took a look at 
https://github.com/openjdk/jfx/pull/192 and I like that as the direction 
for this enhancement.

The initial CSR you have is a good start.

Next steps are:

1. Update the "Introduction to FXML" specification (see my comment in 
the PR)
2. Update PR 192 with the draft CSR as a comment, modifying it to 
include the above additions to "Introduction to FXML"
3. Remove WIP from the title

You can then close the other two PRs (129 and 187).

Thanks.

-- Kevin


On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>
> Hi Kevin,
>
> what should be the next steps?
>
> Should I remove "WIP" from the title in 
> <https://github.com/openjdk/jfx/pull/192> and add the CSR draft text 
> of my last e-mail as a "CSR" comment with PR # 192, thereby requesting 
> it to be added to 
> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>
> Please advise.
>
> TIA,
>
> ---rony
>
> P.S.: This is the RFE:
>
>   * RFE (2020-01-24):
>     <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>
> These are the three versions (all with appropriate unit tests) that I 
> came up with chronologically to implement the RFE, would prefer the 
> latest version (PR # 192):
>
>   * Compile if Compilable implemented (2020-02-28):
>     <https://github.com/openjdk/jfx/pull/129>
>   * Compile if compile PI and Compilable is implemented (2020-04-11):
>     <https://github.com/openjdk/jfx/pull/187>
>   * Compile with fallback, if Compilable is implemented, compile PI
>     for fine-grained control (2020-04-14):
>     <https://github.com/openjdk/jfx/pull/192>
>
>
> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>> Hi Kevin,
>>
>> as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes:
>>
>>      Summary
>>      =======
>>      Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
>>      implements the javax.script.Compilable interface to speed up execution. In case compilation
>>      throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
>>      control of script compilation with a "compile" PI for FXML files.
>>
>>      Problem
>>      =======
>>      javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>>      (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
>>
>>      If a script engine implements the javax.script.Compilable interface, then such scripts could be
>>      compiled and the resulting javax.script.CompiledScript could be executed instead using its
>>      eval() methods.
>>
>>      Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
>>      invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
>>      onMouseMove) which may be repetitively invoked and evaluated.
>>
>>      Solution
>>      ========
>>      Before evaluating the script code test whether the javax.script.ScriptEngine implements
>>      javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
>>      and then use its eval() method to evaluate the script, otherwise continue to use the
>>      javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
>>      (unexpectedly) a javax.script.ScriptException then fall back to using the
>>      javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
>>      the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
>>      files.
>>
>>      Specification
>>      =============
>>      If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
>>      compile() method to compile the script to a javax.script.CompiledScript object and use its
>>      eval() method to run the script. In the case that the compilation throws (unexpectedly) a
>>      javax.script.ScriptException log a warning and fall back to using the
>>      javax.script.ScriptEngine's eval() method instead.
>>      To allow setting this feature off and on while processing the FXML file a "compile" process
>>      instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
>>      compilation off and on throughout a FXML file.
>>
>> Having never seen a real CSR I hope that this matches what is expected and is helpful for
>> assessment. If not please advise (got the name of these fields from [1]).
>>
>> ---
>>
>> Also added brief information about the respective test units (what they test and yield) in the WIP? [2].
>>
>> ---rony
>>
>> [1] "CSR-FAQ":<https://wiki.openjdk.java.net/display/csr/CSR+FAQs>
>>
>> [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement
>> javax.script.Compilable compile scripts #192":<https://github.com/openjdk/jfx/pull/192>
>>
>>
>> On 20.04.2020 14:58, Rony G. Flatscher wrote:
>>> There is a new WIP at<https://github.com/openjdk/jfx/pull/192>:
>>>
>>>      This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a
>>>      warning gets issued about this fact and evaluation of the script will be done without
>>>      compilation. Because of the fallback scripts get compiled with this version by default. It
>>>      extends PR 187 #187.
>>>
>>>      To further ease spotting scripts that cause a ScriptException a message in the form of
>>>      "filename: caused ScriptException" gets added to the exception handling in either of the three
>>>      locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three
>>>      different kinds of reporting ScriptExceptions may be questioned, however none of these tear down
>>>      the FXML GUI).
>>>
>>> This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged
>>> whenever a script cannot be compiled and the fallback gets used.
>>>
>>> It is suggested to use this WIP as it includes the compilation by default with a safe fallback to
>>> evaluate the uncompiled script, if compilation (unexpectedly) fails.
>>>
>>> Again, any feedback, discussion welcome!
>>>
>>> ---rony
>>>
>>> P.S.: In the log history there is a commit message "Make message more pregnant.", it should have
>>> read "Make messages more terse." instead|.||
>>> |
>>>
>>>
>>> On 17.04.2020 19:37, Rony G. Flatscher wrote:
>>>> There is a new WIP at<https://github.com/openjdk/jfx/pull/187>  which adds a compile PI (process
>>>> instruction) for turning on and off script compilation if the script engine implements the
>>>> Compilable interface.
>>>>
>>>> By default compilation is off (no compilation), such that one needs to add a compile PI
>>>> ("<?compile?>") at the top to activate this feature. Supplying "true" (default) or "false" as the PI
>>>> data turns this feature on and off.
>>>>
>>>> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off",
>>>> alternating using "compile on and off", and alternating using "compile off and on". This will test
>>>> all variants of applying the compile PI for all categories of scripts.
>>>>
>>>> Any feedback appreciated!
>>>>
>>>> ---rony
>>>>
>>>> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get
>>>> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes.
>>>>
>>>> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a
>>>> fallback solution in case a compilation is (unexpectedly) not successful, reverting to
>>>> (interpretative) evaluation/execution of the script. In that version it is planned to have
>>>> compilation on by default as in the case of a compilation failure there will be a safe backup solution.
>>>>
>>>>
>>>> On 14.04.2020 19:52, Kevin Rushforth wrote:
>>>>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to
>>>>> create the CSR until the review is far enough along to know which direction we intend to go.
>>>>>
>>>>> Unless there is a real concern about possible regressions if scripts are compiled by default, I
>>>>> think "enabled by default" is the way to go. Your argument that such script engines are broken
>>>>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable
>>>>> in the first place. We still might want to add way to turn compilation off for individual scripts.
>>>>> One other thing to consider is that if compilation fails, it might make sense to log a warning and
>>>>> fall back to the existing interpreted mode.
>>>>>
>>>>> Does anyone else have any concerns with this?
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days
>>>>>> with the PR as per Kevin's suggestion.
>>>>>>
>>>>>> (For the case that this feature should not be active by default, the CSR will suggest to define a
>>>>>> new "compile" PI in the form <?compile [true|false] ?> (default, if no PI data given: true), which
>>>>>> is independent of the existence of a language PI (this way it becomes also possible to allow
>>>>>> compilation of external scripts denoted with the script-element, which do not need a page language
>>>>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for
>>>>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI
>>>>>> <?compile?> or <?compile true?>? to FXML files (and <?compile false?> to turn off), which seems to
>>>>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation
>>>>>> of scripts on and off throughout an FXML file.)
>>>>>>
>>>>>> ---rony
>>>>>>
>>>>>>
>>>>>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>>>>>
>>>>>>> Hi Kevin,
>>>>>>>
>>>>>>> On 03.04.2020 01:21, Kevin Rushforth wrote:
>>>>>>>> I see that you updated the PR and sent it for review.
>>>>>>>>
>>>>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful
>>>>>>>> feature, and if so, what form this feature should take.
>>>>>>>>
>>>>>>>>  ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit
>>>>>>>> from it?
>>>>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code
>>>>>>> may
>>>>>>> benefit.
>>>>>>>
>>>>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the
>>>>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit
>>>>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause
>>>>>>> the reparsing of that script's source and interpreting it on each invocation, which may be
>>>>>>> expensive
>>>>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the
>>>>>>> compiled
>>>>>>> script by the script engine.
>>>>>>>
>>>>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in
>>>>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons?
>>>>>>> In principle there are three possibilities:
>>>>>>>
>>>>>>>  ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the
>>>>>>>  ???? compiled version. In the case of event handlers compile and buffer the compiled script and
>>>>>>>  ???? execute the compiled script each time its registered event fires.
>>>>>>>
>>>>>>>  ?????? o Pro: immediately benefits all existing FXML pages that host scripts
>>>>>>>  ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail
>>>>>>>  ???????? compiling but have been employed successfully in interpreted mode
>>>>>>>
>>>>>>>  ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML
>>>>>>>  ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script
>>>>>>>  ???? engine implements the javax.script.Compilable interface. If missing it would default to
>>>>>>> "false".
>>>>>>>  ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the
>>>>>>>  ???? script engine supports it. It would be an error if the "compile" PI was present, but the
>>>>>>>  ???? "language" PI was not.)
>>>>>>>
>>>>>>>  ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the
>>>>>>> language
>>>>>>>  ???????? PI gets changed
>>>>>>>  ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts
>>>>>>>
>>>>>>>  ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script
>>>>>>> and
>>>>>>>  ???? node elements and only compile the scripts, if the property is set to true
>>>>>>>
>>>>>>>  ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed
>>>>>>>  ???????? accordingly
>>>>>>>  ?????? o Con: potential benefit not made available automatically to existing FXML pages that
>>>>>>> host scripts
>>>>>>>
>>>>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be
>>>>>>> overruled individually by 3.
>>>>>>>
>>>>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that
>>>>>>> compilation
>>>>>>> of scripts by the script engines would find the same errors as while interpreting the very same
>>>>>>> scripts (if not, the script engine is badly broken and it could be argued that then the
>>>>>>> interpretation part of the script engine might be expected to be broken as well which would be
>>>>>>> quite
>>>>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the
>>>>>>> compiled script would behave differently to interpreting the very same script by the same script
>>>>>>> engine).
>>>>>>>
>>>>>>> The current WIP implements 1 above and includes an appropriate test unit.
>>>>>>>
>>>>>>>> What do others think?
>>>>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the
>>>>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine,
>>>>>>>> but we would need to ensure that.
>>>>>>> The compilation of scripts needs to be done by the Java script engines (implementing both,
>>>>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled
>>>>>>> scripts ([javax.script.CompiledScript]
>>>>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)).
>>>>>>>
>>>>>>>
>>>>>>> ---rony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>>>>>>>>> After merging master, applying some fixes and changing the title to reflect the change from
>>>>>>>>> WIP to a
>>>>>>>>> pull request I would kindly request a review of this pull request!
>>>>>>>>>
>>>>>>>>> Here the URL:<https://github.com/openjdk/jfx/pull/129>, title changed to: "8238080:
>>>>>>>>> FXMLLoader: if
>>>>>>>>> script engines implement javax.script.Compilable compile scripts".
>>>>>>>>>
>>>>>>>>> ---rony
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote:
>>>>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in
>>>>>>>>>> review, and
>>>>>>>>>> has an appropriate test unit going with it as well, please review.
>>>>>>>>>>
>>>>>>>>>> There should be no compatibility issue with this implementation.
>>>>>>>>>>
>>>>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new
>>>>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML
>>>>>>>>>> files.
>>>>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts
>>>>>>>>>> if the
>>>>>>>>>> language process instruction (e.g. <?language rexx?>) contains an appropriate attribute with a
>>>>>>>>>> value
>>>>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML
>>>>>>>>>> with
>>>>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up
>>>>>>>>>> with a
>>>>>>>>>> respective solution as well.
>>>>>>>>>>
>>>>>>>>>> ---rony
>>>>>>>>>>
>>>>>>>>>> [1] "Implementation and test unit":<https://github.com/openjdk/jfx/pull/129>
>>>>>>>>>>
>>>>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile
>>>>>>>>>> scripts":
>>>>>>>>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>>>>>>>>
>>>>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
>>>>>>>>>> <https://github.com/openjdk/jfx/pull/122/commits>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote:
>>>>>>>>>>
>>>>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this
>>>>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to
>>>>>>>>>>> illustrate
>>>>>>>>>>> the concept).
>>>>>>>>>>>
>>>>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility
>>>>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML.
>>>>>>>>>>>
>>>>>>>>>>> -- Kevin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>> Just filed a RFE with the following information:
>>>>>>>>>>>>
>>>>>>>>>>>>  ???? * Component:
>>>>>>>>>>>>  ???????? o JavaFX
>>>>>>>>>>>>
>>>>>>>>>>>>  ???? * Subcomponent:
>>>>>>>>>>>>  ???????? o fxml: JavaFX FXML
>>>>>>>>>>>>
>>>>>>>>>>>>  ???? * Synopsis:
>>>>>>>>>>>>  ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"
>>>>>>>>>>>>
>>>>>>>>>>>>  ???? * Descriptions:
>>>>>>>>>>>>  ???????? o "FXMLLoader is able to execute scripts in Java script languages
>>>>>>>>>>>> (javax.script.ScriptEngine
>>>>>>>>>>>>  ?????????? implementations) if such a Java script language gets defined as the controller
>>>>>>>>>>>> language in
>>>>>>>>>>>>  ?????????? the FXML file.
>>>>>>>>>>>>
>>>>>>>>>>>>  ?????????? If a script engine implements the javax.script.Compilable interface, then such
>>>>>>>>>>>> scripts
>>>>>>>>>>>> could
>>>>>>>>>>>>  ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead
>>>>>>>>>>>> using
>>>>>>>>>>>>  ?????????? its eval() methods.
>>>>>>>>>>>>
>>>>>>>>>>>>  ?????????? Evaluating the CompiledScript objects may help speed up the execution of script
>>>>>>>>>>>> invocations,
>>>>>>>>>>>>  ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>>>>>>>> onMouseMove)
>>>>>>>>>>>>  ?????????? which may be repetitevly invoked and evaluated."
>>>>>>>>>>>>
>>>>>>>>>>>>  ???? * System /OS/Java Runtime Information:
>>>>>>>>>>>>  ???????? o "All systems."
>>>>>>>>>>>>
>>>>>>>>>>>> Received the internal review ID: "9063426"
>>>>>>>>>>>>
>>>>>>>>>>>> ---rony
>


From kevin.rushforth at oracle.com  Sat May  9 15:23:22 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 9 May 2020 08:23:22 -0700
Subject: Questions ad JavaScript in JavaFX' WebEngine
In-Reply-To: <ddb1f55d-e9fa-eaea-a3dc-d73a72732a76@wu.ac.at>
References: <ddb1f55d-e9fa-eaea-a3dc-d73a72732a76@wu.ac.at>
Message-ID: <0b0d08fd-992b-6dc9-09c5-9589c7a9b805@oracle.com>

WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The 
sources are in the jfx repo, along with the JavaFX-specific classes that 
implement the two-way Java <--> JavaScript bridge. Other than the public 
API docs for WebEngine, which you referred to in your message, there 
isn't any documentation of the interface. What sort of information are 
you looking for?

-- Kevin


On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
> Wondering which JavaScript engine gets referred to in WebEngine [1].
>
> In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn gets removed from the
> next [3] version? In case it is WebKit's JavaScriptCore [4] where can one study the interface from
> WebEngine to it?
>
> ---rony
>
> [1] WebEngine: <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html>
> [2] Nashorn: <https://openjdk.java.net/projects/nashorn/>
> [3] Nashorn removal from JDK 15: <https://openjdk.java.net/jeps/372>
> [4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore>
>
>


From kcr at openjdk.java.net  Sat May  9 18:51:11 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 9 May 2020 18:51:11 GMT
Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot
 rendering
In-Reply-To: <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
References: <hSZLFZkdZCDK6SvfDoDbflPQ0uQwDMRo--EyPI-x9KA=.9b7ff341-636f-48ec-b1d3-16263be6b3b1@github.com>
 <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
Message-ID: <TgX4954Ekr_lCzK29IkHXF16ix5nzWg53R3tWh01q_E=.e53f33df-35a6-4a2f-9ac2-77cb51cfb64d@github.com>

On Tue, 17 Mar 2020 11:43:16 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be
>> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around
>> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is
>> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk
>> of regressions, either in terms of performances and correctness, while still offering some relief to the original
>> issue.  This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best
>> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is
>> necessary while still introducing no regressions compared to the original solution.
>
> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in import statements

Overall, this looks quite good. In particular the tiled rendering, as implemented by the `renderTile` method, should be
reasonably efficient.

My only high-level comment is that I'm somewhat skeptical of `computeOptimumTileSize` to determine the size and
direction of tiling. I note that in the case of an image that is tiled in both X and Y, there are at most 4 distinct
tile sizes if it doesn't fit evenly. In the case where only one of X or Y is tiled, there are at most 2 distinct tile
sizes. Here is an example:

+-----------+-----------+  .  +-------+
|           |           |  .  |       |
|     M     |     M     |  .  |   R   |
|           |           |  .  |       |
+-----------+-----------+  .  +-------+
|           |           |  .  |       |
|     M     |     M     |  .  |   R   |
|           |           |  .  |       |
+-----------+-----------+  .  +-------+
      .           .        .      .
+-----------+-----------+  .  +-------+
|           |           |  .  |       |
|     M     |     M     |  .  |   R   |
|           |           |  .  |       |
+-----------+-----------+  .  +-------+
|     B     |     B     |  .  |   C   |
+-----------+-----------+  .  +-------+

Where `M` represents the middle set of tiles each with a size of `tileW x tileH`. `R` is the right hand column of
tiles, `B` is bottom row, and `C` is corner.

Recognizing this, I wonder if it might be better to always use the maximum tile size, but fill all of the middle tiles
of that size first, and then pick up the right and/or bottom edges as needed. This will minimize thrashing (no more
than 3 changes of tile size), while avoiding the more complicated logic that tries to keep the tiles all the same size
at the cost of smaller tiles, and which has to fall back to using uneven tiles anyway. If you do it this way, there is
also no need to have code that switches the order of the inner loop. It will naturally handle that.

Either way, I'd like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting
exactly (and if you stick with your current approach, X or Y as the inner loop).

I left a couple inline comments as well.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1495:

> 1494:                 }
> 1495:                 //Copy tile's pixel into the target image
> 1496:                 targetImg.image.setPixels(xOffset, yOffset, w, h,

Typo: should be "pixels" (plural)

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1523:

> 1522:
> 1523:             private int computeOptimumTileSize(int size, int maxSize){
> 1524:                 return computeOptimumTileSize(size, maxSize, null);

Minor: add a space before the `{` , although this will become a moot point if you take my suggestion of eliminating
this method entirely.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1527:

> 1526:
> 1527:             private int computeOptimumTileSize(int size, int maxSize, AtomicBoolean isDivExact) {
> 1528:                 // This method attempts to find the smallest exact divider for the provided `size`

I don't care for the use of `AtomicBoolean` to effect a pass-by-reference. You aren't relying on the atomic nature, so
it just ends up being confusing. I recommend using `boolean[]`, although this will become a moot point if you take my
suggestion of eliminating this method entirely.

-------------

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

From youngty1997 at gmail.com  Sun May 10 01:57:07 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 9 May 2020 20:57:07 -0500
Subject: Missing tick marks on charts
Message-ID: <d9ef3346-9300-90be-8c8c-e0c6ad93ae5f@gmail.com>

Does anyone know whats going on with this:


https://imgur.com/a/g7Ti3Zc


It doesn't seem to be a space issue, even the top tick mark is missing 
on the one chart...


From github.com+2720909+jskov at openjdk.java.net  Sun May 10 08:59:51 2020
From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov)
Date: Sun, 10 May 2020 08:59:51 GMT
Subject: RFR: 8244212: Optionally download media and webkit libraries from
 latest openjfx EA build
Message-ID: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>

I have tested on Linux (Fedora 31) only.
It works as intended (with one test failure due to 15-ea+4 being too old now).

UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache.
But as I could not find anything about it, that section in the documentation may need some love.

-------------

Commit messages:
 - Add build tooling note
 - Downloaded from MavenCentral note in build file
 - Review fixes
 - Allow use of official WebKit/Media libraries for stubs

Changes: https://git.openjdk.java.net/jfx/pull/202/files
 Webrev: https://webrevs.openjdk.java.net/jfx/202/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244212
  Stats: 106 lines in 2 files changed: 97 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/202.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/202/head:pull/202

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

From kcr at openjdk.java.net  Sun May 10 08:59:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sun, 10 May 2020 08:59:53 GMT
Subject: RFR: 8244212: Optionally download media and webkit libraries from
 latest openjfx EA build
In-Reply-To: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>
References: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>
Message-ID: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com>

On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov <github.com+2720909+jskov at openjdk.org> wrote:

> I have tested on Linux (Fedora 31) only.
> It works as intended (with one test failure due to 15-ea+4 being too old now).
> 
> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache.
> But as I could not find anything about it, that section in the documentation may need some love.

Here are a few preliminary comments:

I filed the following JBS bug to track this enhancement:

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

When you are ready for a formal review, you can change the title to:

8244212: Optionally download media and webkit libraries from latest openjfx EA build

WEBKIT-MEDIA-STUBS.md line 22:

> 21:
> 22: * Unix libraries (*.so or *.dynlib files)
> 23: ````

typo: should be "dylib"

WEBKIT-MEDIA-STUBS.md line 24:

> 23: ````
> 24:     $projectDir/../caches/sdk/lib
> 25:     $projectDir/../caches/modular-sdk/modules_libs/$module

I would just list this one and not the other two. In particular, I don't want to encourage developers to copy these
libraries into the JDK since it could cause unexpected results if those libraries were loaded at runtime.

WEBKIT-MEDIA-STUBS.md line 36:

> 35:
> 36: ## Officially released libraries
> 37:

I recommend that you add a comment that gradle will download these for you from Maven Central.

By the same token, you could indicate in the above section that copying them to `../caches/sdk` is a manual step.

WEBKIT-MEDIA-STUBS.md line 53:

> 52:
> 53: Note that this is fine for local work. But a full test *is* required before submitting a PR, see CONTRIBUTING.md.

Can you add a hyperlink to CONTRIBUTING.md?

build.gradle line 1252:

> 1251:
> 1252: // Allows automatic provisioning of webkit+media shared libraries from an official OpenJfx build
> 1253: defineProperty("STUB_RUNTIME_OPENJFX", "")

If you are going to capitalize it, then it should be "OpenJFX".

Can you add "from Maven Central" ?

build.gradle line 1259:

> 1258: def String jdkStubRuntime = cygpath("$JDK_HOME")
> 1259: def String openjfxStubRuntime = cygpath("$projectDir") + "/build/openjfxStub"
> 1260:

I might suggest `buildSrc/build/openjfxStub` so it doesn't get removed by `gradle clean`.

build.gradle line 3391:

> 3390:         doFirst {
> 3391:             if (IS_STUB_RUNTIME_OPENJFX) {
> 3392:                 println "********************************************************"

Perhaps this should be inside the `if (!IS_COMPILE_WEBKIT)` ?

build.gradle line 4338:

> 4337:  *                                                                            *
> 4338:  *                             OpenJfx Stubs                                  *
> 4339:  *                                                                            *

OpenJFX

-------------

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

From kcr at openjdk.java.net  Sun May 10 08:59:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sun, 10 May 2020 08:59:53 GMT
Subject: RFR: 8244212: Optionally download media and webkit libraries from
 latest openjfx EA build
In-Reply-To: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com>
References: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>
 <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com>
Message-ID: <bXuhMP73CRtpFvVFLUa-m8JYNAVuTdo3QgeHXNfVwU8=.44c46d5f-e85b-4746-add8-615c2dda61cc@github.com>

On Thu, 30 Apr 2020 19:51:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I have tested on Linux (Fedora 31) only.
>> It works as intended (with one test failure due to 15-ea+4 being too old now).
>> 
>> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache.
>> But as I could not find anything about it, that section in the documentation may need some love.
>
> I filed the following JBS bug to track this enhancement:
> 
> https://bugs.openjdk.java.net/browse/JDK-8244212
> 
> When you are ready for a formal review, you can change the title to:
> 
> 8244212: Optionally download media and webkit libraries from latest openjfx EA build

I'll take a closer look look once it's out for formal review, but will leave a few preliminary comments now. To answer
one question:

> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache.

Yeah, this bit of magic was in our closed repo. I'll see if there is some refactoring that might make sense (probably
not, since that bit is done by triggering an `ant` task).

-------------

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

From github.com+2720909+jskov at openjdk.java.net  Sun May 10 08:59:54 2020
From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov)
Date: Sun, 10 May 2020 08:59:54 GMT
Subject: RFR: 8244212: Optionally download media and webkit libraries from
 latest openjfx EA build
In-Reply-To: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com>
References: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>
 <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com>
Message-ID: <VWZiKfapyvbt9t1FjZ6c9v8Dw0eByOa1gY51PsQVgj4=.21f1b6da-a0c6-4dd0-ade6-63f3fb58495b@github.com>

On Thu, 30 Apr 2020 20:10:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I have tested on Linux (Fedora 31) only.
>> It works as intended (with one test failure due to 15-ea+4 being too old now).
>> 
>> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache.
>> But as I could not find anything about it, that section in the documentation may need some love.
>
> build.gradle line 1259:
> 
>> 1258: def String jdkStubRuntime = cygpath("$JDK_HOME")
>> 1259: def String openjfxStubRuntime = cygpath("$projectDir") + "/build/openjfxStub"
>> 1260:
> 
> I might suggest `buildSrc/build/openjfxStub` so it doesn't get removed by `gradle clean`.

Neat. I did not know that was a thing. Done.

> build.gradle line 3391:
> 
>> 3390:         doFirst {
>> 3391:             if (IS_STUB_RUNTIME_OPENJFX) {
>> 3392:                 println "********************************************************"
> 
> Perhaps this should be inside the `if (!IS_COMPILE_WEBKIT)` ?

I assume you mean like this:
`
            if (!IS_COMPILE_WEBKIT) {
                if (IS_STUB_RUNTIME_OPENJFX) {
                   println ...
                } else {
                   println ...
		}
            }
`
I do not like the additional indentation level, so I have left it as is.

The semantics should be the same, as long as no one use stubs *and* compile webkit.
Which should maybe rather cause a build exception?

But it is not something I feel strongly for, so I am happy to change it :)

-------------

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

From jvos at openjdk.java.net  Sun May 10 08:59:54 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Sun, 10 May 2020 08:59:54 GMT
Subject: RFR: 8244212: Optionally download media and webkit libraries from
 latest openjfx EA build
In-Reply-To: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>
References: <huYvIfqxjKg6VEWxI14OE3OxfOK8LLernhB076yF4Ls=.72af7310-bbb6-47ee-94c0-dcae2e0e8b94@github.com>
Message-ID: <01F2yPzenCOwK9w9BFg1Kx6JND1jifx2wqJW-K35ces=.8e177a40-a33f-4c7a-b1f0-21980b5ce303@github.com>

On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov <github.com+2720909+jskov at openjdk.org> wrote:

> I have tested on Linux (Fedora 31) only.
> It works as intended (with one test failure due to 15-ea+4 being too old now).
> 
> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache.
> But as I could not find anything about it, that section in the documentation may need some love.

WEBKIT-MEDIA-STUBS.md line 13:

> 12:
> 13: Note that these take some time to build.
> 14:

... and they have additional requirements for build tools (e.g. cmake)

-------------

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

From nlisker at gmail.com  Sun May 10 14:05:18 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 10 May 2020 17:05:18 +0300
Subject: Mac: Supported MacOS JDKs
In-Reply-To: <CA+4mSqZJVqurrXGzS8yBy1kFHV7X7Xyw8S-HJ07OUUrkg3y-+w@mail.gmail.com>
References: <CA+4mSqZJVqurrXGzS8yBy1kFHV7X7Xyw8S-HJ07OUUrkg3y-+w@mail.gmail.com>
Message-ID: <CA+0ynh-3YayfrfxcWD+8GJya8L0ityVqbBJG66J5B0_=CzTguA@mail.gmail.com>

if this is confirmed I can update the page.

On Tue, Apr 14, 2020 at 1:18 PM Florian Kirmaier <florian.kirmaier at gmail.com>
wrote:

> Hi everyone,
>
> it seems to me, that the newest JDK for Mac (MacOSX10.15.sdk) doesn't work
> to build JavaFX.
> It works for me with 10.14 but not with 10.15.
> Can anyone confirm this?
> It would be great to mention this in the build instructions here:
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>
> Greetings Florian Kirmaier
>

From nlisker at gmail.com  Sun May 10 15:30:52 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 10 May 2020 18:30:52 +0300
Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553
In-Reply-To: <cfcf5994-a380-da36-8069-0b0fd2b5747c@oracle.com>
References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com>
 <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu>
 <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com>
 <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu>
 <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com>
 <20200421130647.Horde.9OZ6De4A76UMi5Og6Hg7Lg1@webmail.df.eu>
 <6AAD16E5-93C7-4F35-A3C8-D85AEE34413A@oracle.com>
 <cfcf5994-a380-da36-8069-0b0fd2b5747c@oracle.com>
Message-ID: <CA+0ynh_iN0DB1kVyDZzPPQKmTkrf7vehUCJyESqe5omJ6XetNA@mail.gmail.com>

I would say that for doubles, the minimum step size is the one given by ulp
= Math.ulp(double). Then the double case should behave like the
integer case where the ulp is 1 I think.
So, for the angle case of [0, 360), if we are at 360 - ulp, incrementing by
N * ulp will get us to (N-1) * ulp.

On Wed, Apr 22, 2020 at 3:41 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Hi Ajit,
>
> Thanks for writing this up. I think we are clear on what should happen
> for IntegerSpinnerValueFactory and ListSpinnerValueFactory. To answer
> your two questions, I'll take the second one first:
>
> > 2. Do we really care about negative values in no of steps OR
> > amountToStepBy?
> > I am asking this as we already have separate increment() and
> > decrement() methods. Should we bar such negative values? That?s
> > another behavior change though :)
>
> Once you switch to a proper modulo function, the easy answer is that
> negative values will "just work". A negative amountToStepBy might even
> make sense in some use cases (think of an increasing debt value), so
> there is no reason not to support it. A negative number of steps doesn't
> really make sense, since if you want to call increment(-N) you could
> equivalently call decrement(N), but again, it will "just work" as
> expected once the wrapping function is fixed. If we were designing from
> scratch I'd specify that nsteps must be >= 0, but it isn't worth it to
> make the change now (which would require a CSR) to prohibit it.
>
> > 1. Need to decide what would be better way to fix
> > DoubleSpinnerValueFactory wrapAround behavior?
>
> It might be helpful to compare it to the Integer flavor. By definition,
> IntegerSpinnerValueFactory represents a set of discrete values: min and
> max are two distinct values, and there is a well-defined ordering when
> wrapping. If you wrap, it should be a continuous (in both positive and
> negative directions) list of values like so:
>
> min, min+1, min+2, ... max-2, max-1, max, min, min+1, min+2, ...
>
> The formula is simple. After incrementing or decrementing by N *
> amountToStepBy, do the following if wrapAround is true:
>
>      if (val < min || val > max) val = (val - min) % (max - min + 1) + min;
>
> The above works regardless of step size because integers are naturally
> discrete values. It is well-behaved and natural to consider max and min
> being 1 apart from each other when wrapping.
>
> By contrast, it's harder to know what the right answer is for
> DoubleSpinnerValueFactory. It's quite possible that in some cases, the
> app expects the values of DoubleValue factory to also be discrete when
> it comes to wrapping, meaning that min and max are distinct values such
> that if your step was 1.0, you might expect to go from max-1.0 to max to
> min to min+1.0 (although even that definition has problems for
> non-integer values of amountToStepBy, but it's (mostly) solvable). It's
> also quite likely for other cases -- especially ones that would lend
> themselves to wrapAround mode in graphical apps -- where it isn't a set
> of discrete values, but rather is such that min and max represent the
> same value (i.e., the same end result). The simplest example is an angle
> in degrees where 0.0 and 360.0 mean the same thing when used as a
> rotation angle. In this latter use case, stepping from 359.0 to 360.0 to
> 0.0 to 1.0 would cause a discontinuous pause in motion if you mapped the
> output to a rotation angle.
>
> I'm not sure what the right answer is, but the latter seems like a valid
> use case and I would guess at least as common as a "set of discrete
> values" for doubles. Another thing to consider is that even in what I
> will call "discrete" mode (no I'm not really proposing that we add a
> property to control it), you have to take the step size into account;
> otherwise when the step size is < 0.5 you will get stuck at max when
> incrementing by 1 amountToStepBy, unless you have special case logic for
> that.
>
> Any thoughts from other developers?
>
> -- Kevin
>

From youngty1997 at gmail.com  Sun May 10 17:43:44 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 10 May 2020 12:43:44 -0500
Subject: Unable to allocate direct buffer memory
In-Reply-To: <cec5b299-a6a6-138d-830d-da43aa774083@oracle.com>
References: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
 <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
 <cec5b299-a6a6-138d-830d-da43aa774083@oracle.com>
Message-ID: <8034f14d-bda2-0cff-eaae-fef078532562@gmail.com>


On 5/7/20 3:44 PM, Kevin Rushforth wrote:
> This suggests that there might be a memory leak (possibly in uploading 
> painter which I see you are using). Is this easily reproducible?
>
>

I tried doing software rendering just to see if it made any difference.


I don't know if it fixed any of the other issues, but it definitely made 
things worse. Everytime I resize the application it leaks on-heap memory 
and eventually hits an OutOfMemory exception.


It looks like a bunch of int arrays are being allocated and never 
released. What the hell?


From github.com+4208131+bhaweshkc at openjdk.java.net  Sun May 10 19:53:10 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Sun, 10 May 2020 19:53:10 GMT
Subject: [Rev 01] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
Message-ID: <LXqJxxyTKptPcd4uP1FfbZ1SLJc5ZtI1hqzNp4d1Ufg=.e940705f-0273-4dad-9f25-f28471dc17be@github.com>

> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
> otherwise use usual way of rendering.

Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:

  added dispose of resources

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/213/files
  - new: https://git.openjdk.java.net/jfx/pull/213/files/c2729a9c..e66fa3bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/213/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.00-01

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

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Sun May 10 20:49:07 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Sun, 10 May 2020 20:49:07 GMT
Subject: [Rev 02] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
Message-ID: <Spm3_XbWn8yaTelufY0rHr8DOn_JyZDvmsi8DP74CtE=.ecc917e5-6330-4ca5-a92b-101c94b3f61d@github.com>

> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
> otherwise use usual way of rendering.

Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:

  Moved Printing drawing path to non MaskTextureGraphics interface

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/213/files
  - new: https://git.openjdk.java.net/jfx/pull/213/files/e66fa3bc..5b85b47d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/213/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.01-02

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

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

From hjohn at xs4all.nl  Sun May 10 20:52:41 2020
From: hjohn at xs4all.nl (John Hendrikx)
Date: Sun, 10 May 2020 22:52:41 +0200
Subject: Unable to allocate direct buffer memory
In-Reply-To: <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
References: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
 <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
Message-ID: <65029402-ce20-09dc-2eb9-79860177ae08@xs4all.nl>

They're related.  32767x1137x4 = 149024316.

It would help to know what your app might be doing.  Although it could 
be a bug in JavaFX, it seems more likely that a canvas/image or cached 
group or something is a bit bigger than reasonable.

I think I've seen such errors in my app before I restricted maximum 
sizes of images which were supplied from uncontrolled sources.

--John

On 07/05/2020 20:51, Ty Young wrote:
>
> On 5/6/20 12:39 PM, Ty Young wrote:
>> After hours of running my JavaFX application I start getting this
>> error spammed in console:
>>
>>
>> java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct
>> buffer memory (allocated: 149066725, limit: 209715200)
>>     at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
>>     at
>> java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:120)
>>     at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329)
>>     at
>> javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90)
>>
>>     at
>> javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121)
>>
>>     at
>> javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155)
>>
>>     at
>> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156)
>>
>>     at
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>
>>     at
>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
>>
>>     at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>>     at
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>>
>>     at
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>>
>>     at
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
>>
>>     at java.base/java.lang.Thread.run(Thread.java:832)
>>
>>
>> Ironically every single error is about allocating the exact same
>> amount of bytes.
>
>
> Anything on this? I'm also getting:
>
>
> java.lang.RuntimeException: Requested texture dimensions (32767x1137)
> require dimensions (0x1137) that exceed maximum texture size (16384)
>     at
> javafx.graphics/com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
>
>     at
> javafx.graphics/com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:165)
>
>     at
> javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:124)
>
>     at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>
>     at
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
>     at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>     at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>
>     at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>
>     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
>
>     at java.base/java.lang.Thread.run(Thread.java:832)
>
>
> spammed alternatively.
>

From youngty1997 at gmail.com  Sun May 10 23:05:20 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 10 May 2020 18:05:20 -0500
Subject: Unable to allocate direct buffer memory
In-Reply-To: <65029402-ce20-09dc-2eb9-79860177ae08@xs4all.nl>
References: <a023abb6-476a-a667-dc1a-8be629bb0782@gmail.com>
 <f44d86c0-5365-e9cd-ceb9-6ebe32b58bd5@gmail.com>
 <65029402-ce20-09dc-2eb9-79860177ae08@xs4all.nl>
Message-ID: <b73a4947-ae90-7edf-d8db-c527f9c85149@gmail.com>


On 5/10/20 3:52 PM, John Hendrikx wrote:
> They're related.? 32767x1137x4 = 149024316.
>
> It would help to know what your app might be doing.? Although it could 
> be a bug in JavaFX, it seems more likely that a canvas/image or cached 
> group or something is a bit bigger than reasonable.
>
> I think I've seen such errors in my app before I restricted maximum 
> sizes of images which were supplied from uncontrolled sources.
>
> --John
>


No images are used. The only questionable thing is that 
TilePane/GridPane is used in order to achieve a more responsive UI. I 
don't remember this being an issue in earlier versions either.


From arapte at openjdk.java.net  Mon May 11 04:12:22 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 11 May 2020 04:12:22 GMT
Subject: [Rev 01] RFR: 8237602: TabPane doesn't respect order of
 TabPane.getTabs() list
In-Reply-To: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
Message-ID: <5m9VY4PZGGkZibnrwUwEJcgTOqu5ev2A9UqudtACvik=.faf778f8-15a2-4e53-b52c-0016d68dd05d@github.com>

> Issue:
> When tabs are permuted as mentioned in the issue description as,
> 1. TabPane.getTabs().setAll(tab0, tab1)
> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
> 
> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
> => but are show in order as  tab2, tab3, tab0, tab1
> 
> Cause:
> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
> Fix:
> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
> 
> Verification:
> No existing tests fail due to this change.
> Added a system test which fails without and pass with fix.

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  review-update: change test name

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/201/files
  - new: https://git.openjdk.java.net/jfx/pull/201/files/68e8efd2..548badaa

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/201/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/201/webrev.00-01

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

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

From arapte at openjdk.java.net  Mon May 11 04:13:48 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 11 May 2020 04:13:48 GMT
Subject: [Rev 01] RFR: 8237602: TabPane doesn't respect order of
 TabPane.getTabs() list
In-Reply-To: <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
 <Vtw7SJUCjMoQPhfMeTvd07WfOctzzEWPaTTgBQBE6jw=.f41b5e67-5ae4-4b31-92f6-9cdae21c5934@github.com>
Message-ID: <zRravIAPdahxMTllFhwfVerp2Cel2ZlkeaM3BjN7fs8=.c2d9d890-b37a-4c5f-a43f-e02124a96a81@github.com>

On Fri, 1 May 2020 14:42:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review-update: change test name
>
> tests/system/src/test/java/test/robot/javafx/scene/TabPanePermuteGetTabsTest.java line 194:
> 
>> 193:     @Test
>> 194:     public void testPermutGetTabsWithMoreTabs1() {
>> 195:         // Step #1
> 
> Typo: Permut --> Permute
> 
> (or, as long as you are changing it anyway, you could rename it now to something other than "permute" since it isn't).

Changed the test name to `testAddingNewTabsWithExistingTabsAtSameIndex`. While converting to unit tests, we will have
to change the names of other test from this file.

-------------

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

From arapte at openjdk.java.net  Mon May 11 04:46:41 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 11 May 2020 04:46:41 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
Message-ID: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>

On Fri, 24 Apr 2020 00:58:30 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
> of methods. Summery of changes:
> ### Animation
> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
> * Added `runHandler` method to deal with running the handler.
> * Moved methods to be grouped closer to where they are used rather than by visibility.
> * Removed the static import for `TickCalculation`.
> * Various small subjective readability changes.
> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>   initializing the `cuePoints` map.
> 
> ### Clip Envelopes
> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
> * Rearranged methods order to be consistent.
> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
> * Renamed `pos` to `cyclePos`.
> * Extracted common methods: `changedDirection` and `ticksRateChange`
> * Added internal documentation.
> 
> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.

Overall looks good to me, Added few minor comments.

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java line 48:

> 47:
> 48:     protected boolean autoReverse() {
> 49:         return autoReverse;

I would suggest the name to be `isAutoReverese`

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java line 46:

> 45:  */
> 46: public abstract class ClipEnvelope {
> 47:

I think the removal of line 46 was unintended change.

modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 142:

> 141:     }
> 142:
> 143:     /*

Both these methods seem like they belong to Utils.java. If moved to Utils.java then the all the calls
`(Math.abs(currentRate - rate) < EPSILON)` can be changed to use these methods from Utils.java. If we move these
methods then, Utils.java also needs to declare  `static final double EPSILON = 1e-12;`  and the EPSILON here can be
initialized as `private static final double EPSILON = Utils.EPSILON;`

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java line 61:

> 60:
> 61:     protected boolean changedDirection(double newRate) {
> 62:         return newRate * rate < 0;

I would recommend to name as `isDirectionChanged`

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java line 102:

> 101:             long ticksChange = Math.round(currentTick * currentRate);
> 102:             ticks = Utils.clamp(0, deltaTicks + ticksChange, cycleTicks);
> 103:             AnimationAccessor.getDefault().playTo(animation, ticks, cycleTicks);

This could remain unchanged. The `ticksChange` value is not really used elsewhere here.

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java line 59:

> 58:         return Math.round((ticks - deltaTicks) * Math.abs(newRate / rate));
> 59:      }
> 60:

This is similar to `ClipEnvelope.ticksRateChange()` with a minor difference. Can this be removed from here and
`ClipEnvelope.ticksRateChange()` be reused ?

-------------

Changes requested by arapte (Reviewer).

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

From arapte at openjdk.java.net  Mon May 11 04:52:29 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 11 May 2020 04:52:29 GMT
Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3
In-Reply-To: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
References: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
Message-ID: <VsvDeh_SgWzawEZdhs57Vd93sWK6trPuha9i5EZ3CuI=.a2b4b6b1-3ed5-4b4c-bab7-925bce24653a@github.com>

On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019
> (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see
> [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214).  I have run a full build and test using this new
> compiler.
> NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which
> is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by
> this PR.

lgtm, verified a local build on Windows10.

-------------

Marked as reviewed by arapte (Reviewer).

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

From rlichten at openjdk.java.net  Mon May 11 04:56:55 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Mon, 11 May 2020 04:56:55 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
 <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
Message-ID: <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>

On Fri, 8 May 2020 18:50:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I wasn't aware of PR #73, I only saw the (very old) issue in the JDK Bug System and started to look into the issue.
>> The fact that two different people start to look into the same issue shows it is important however :-).
>> Should I close this PR and participate in PR #73?
>
> @effad I just closed PR #73 due to inactivity. If you are interested interested in pursuing this, go ahead and reopen
> this (although you would need to address the feedback that clamping is insufficient).

We're in the process of finishing our products' release. If I find time
I will try and give this (rather nasty) Problem another shot.

On 2020-05-08 20:51, Kevin Rushforth wrote:
>
> @effad <https://github.com/effad> I just closed PR #73
> <https://github.com/openjdk/jfx/pull/73> due to inactivity. If you are
> interested interested in pursuing this, go ahead and reopen this
> (although you would need to address the feedback that clamping is
> insufficient).
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jfx/pull/138#issuecomment-625963496>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCKAQ6JRLHJSGPI3U2YTNLRQRIB7ANCNFSM4LCNBSIA>.
>

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Mon May 11 05:32:17 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Mon, 11 May 2020 05:32:17 GMT
Subject: [Rev 02] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <ay2Qgeb2XQbzwo2GRjYAp3paXKYodnGhTJ8qZynQqLc=.2b4335ac-643a-45c3-9dd2-d88eb971bb9c@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
 <ay2Qgeb2XQbzwo2GRjYAp3paXKYodnGhTJ8qZynQqLc=.2b4335ac-643a-45c3-9dd2-d88eb971bb9c@github.com>
Message-ID: <7ujzcmnYJY1OnN_OTgtw1SNDnyNs04H-UqjIlHOkm0k=.b234e8b9-e6d9-446a-83ee-20e460197e3c@github.com>

On Fri, 8 May 2020 23:25:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved Printing drawing path to non MaskTextureGraphics interface
>
> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 549:
> 
>> 548:                             Texture.WrapMode.CLAMP_NOT_NEEDED);
>> 549:                     RTTexture maskRtTexture = g.getResourceFactory().createRTTexture(nativeMaskImage.getWidth(),
>> 550:                             nativeMaskImage.getHeight(), Texture.WrapMode.CLAMP_NOT_NEEDED);
> 
> Why do you need to create a second RTT here? I would have thought you could use the mask texture directly (you may need
> to scale the image in order to do that).

main problem with not using second RTTexture is the interface MaskTextureGraphics, which accept RTTexture only. also it
difficult to add new API taking Texture instead of RTTexture given that SW Pipeline and J2D pipeline has direct
dependency on RTTexture interface.

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Mon May 11 05:37:32 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Mon, 11 May 2020 05:37:32 GMT
Subject: [Rev 02] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <ay2Qgeb2XQbzwo2GRjYAp3paXKYodnGhTJ8qZynQqLc=.2b4335ac-643a-45c3-9dd2-d88eb971bb9c@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
 <ay2Qgeb2XQbzwo2GRjYAp3paXKYodnGhTJ8qZynQqLc=.2b4335ac-643a-45c3-9dd2-d88eb971bb9c@github.com>
Message-ID: <IPQC4v9rr9T23-qu7NJu1MYKHUFfk2WfxagoyqjVu_k=.44c23672-7ce9-48e5-a192-556b3e132d3c@github.com>

On Fri, 8 May 2020 23:37:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved Printing drawing path to non MaskTextureGraphics interface
>
> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 566:
> 
>> 565:                             filterContext = PrFilterContext.getInstance(screen);
>> 566:                         }
>> 567:                         PrDrawable imagePrDrawable = PrDrawable.create(filterContext, paintRtTexture);
> 
> Did you test both the SW pipeline and printing paths?

Yes, used -Dprism.order=sw to run HelloWebView test to verify SW Pipeline
Yes, i have added a modified HelloWebView test in attached bug which is used to test printing paths.
https://bugs.openjdk.java.net/secure/attachment/88102/HelloWebView.java

-------------

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

From Rony.Flatscher at wu.ac.at  Mon May 11 12:17:07 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Mon, 11 May 2020 14:17:07 +0200
Subject: Questions ad JavaScript in JavaFX' WebEngine
In-Reply-To: <0b0d08fd-992b-6dc9-09c5-9589c7a9b805@oracle.com>
References: <ddb1f55d-e9fa-eaea-a3dc-d73a72732a76@wu.ac.at>
 <0b0d08fd-992b-6dc9-09c5-9589c7a9b805@oracle.com>
Message-ID: <0233cb09-a33e-fd54-4399-436165747200@wu.ac.at>

On 09.05.2020 17:23, Kevin Rushforth wrote:
> WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The sources are in the jfx repo,
> along with the JavaFX-specific classes that implement the two-way Java <--> JavaScript bridge.
> Other than the public API docs for WebEngine, which you referred to in your message, there isn't
> any documentation of the interface. 

OK, thank you very much, this is reassuring! :)

> What sort of information are you looking for?

Well, as event handlers and script tags in HTML have a type attribute that allows to denote script
languages other than JavaScript, I am interested in evaluating what WebEngine/WebView allows for to
support this with any of the Java script engines.

---rony


> On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
>> Wondering which JavaScript engine gets referred to in WebEngine [1].
>>
>> In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn gets removed from the
>> next [3] version? In case it is WebKit's JavaScriptCore [4] where can one study the interface from
>> WebEngine to it?
>>
>> ---rony
>>
>> [1] WebEngine: <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html>
>> [2] Nashorn: <https://openjdk.java.net/projects/nashorn/>
>> [3] Nashorn removal from JDK 15: <https://openjdk.java.net/jeps/372>
>> [4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore> 


From Rony.Flatscher at wu.ac.at  Mon May 11 12:12:09 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Mon, 11 May 2020 14:12:09 +0200
Subject: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP
 (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for
 review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script
 engines implement javax.script.Compilabel compile scripts"
In-Reply-To: <2a2007be-8ffa-e0c1-c252-0e9a5281ef3b@oracle.com>
References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>
 <d237cbbe-f1fe-519b-e378-ad576a4944ff@oracle.com>
 <bd3eb6ef-154f-811d-936a-37543a2a244c@wu.ac.at>
 <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at>
 <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com>
 <eb73c12e-0d76-0570-7903-0288696fe57a@wu.ac.at>
 <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at>
 <e08195ad-c924-3fba-5407-cfeb3e91fa63@oracle.com>
 <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at>
 <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at>
 <b27d7276-2a52-e756-baa6-18678048e226@wu.ac.at>
 <34d30efa-a87c-261e-36b3-e5f68f38c389@wu.ac.at>
 <2a2007be-8ffa-e0c1-c252-0e9a5281ef3b@oracle.com>
Message-ID: <53e68e19-5e13-4d4d-b90a-d743ecbd6cc9@wu.ac.at>

Hi Kevin,

On 09.05.2020 17:16, Kevin Rushforth wrote:
> I'm finally getting back to this. I took a look at https://github.com/openjdk/jfx/pull/192 and I
> like that as the direction for this enhancement.
>
> The initial CSR you have is a good start.

Thank you!

> Next steps are:
>
> 1. Update the "Introduction to FXML" specification (see my comment in the PR)
> 2. Update PR 192 with the draft CSR as a comment, modifying it to include the above additions to
> "Introduction to FXML"
> 3. Remove WIP from the title
>
> You can then close the other two PRs (129 and 187).

will do (may take a little bit).

Cheers

---rony


> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>
>> Hi Kevin,
>>
>> what should be the next steps?
>>
>> Should I remove "WIP" from the title in <https://github.com/openjdk/jfx/pull/192> and add the CSR
>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby requesting it to be added
>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>
>> Please advise.
>>
>> TIA,
>>
>> ---rony
>>
>> P.S.: This is the RFE:
>>
>>   * RFE (2020-01-24): <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>
>> These are the three versions (all with appropriate unit tests) that I came up with
>> chronologically to implement the RFE, would prefer the latest version (PR # 192):
>>
>>   * Compile if Compilable implemented (2020-02-28): <https://github.com/openjdk/jfx/pull/129>
>>   * Compile if compile PI and Compilable is implemented (2020-04-11):
>>     <https://github.com/openjdk/jfx/pull/187>
>>   * Compile with fallback, if Compilable is implemented, compile PI for fine-grained control
>>     (2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>
>>
>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>> Hi Kevin,
>>>
>>> as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes:
>>>
>>>     Summary
>>>     =======
>>>     Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
>>>     implements the javax.script.Compilable interface to speed up execution. In case compilation
>>>     throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
>>>     control of script compilation with a "compile" PI for FXML files.
>>>
>>>     Problem
>>>     =======
>>>     javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>>>     (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
>>>
>>>     If a script engine implements the javax.script.Compilable interface, then such scripts could be
>>>     compiled and the resulting javax.script.CompiledScript could be executed instead using its
>>>     eval() methods.
>>>
>>>     Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
>>>     invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
>>>     onMouseMove) which may be repetitively invoked and evaluated.
>>>
>>>     Solution?
>>>     ========
>>>     Before evaluating the script code test whether the javax.script.ScriptEngine implements
>>>     javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
>>>     and then use its eval() method to evaluate the script, otherwise continue to use the
>>>     javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
>>>     (unexpectedly) a javax.script.ScriptException then fall back to using the
>>>     javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
>>>     the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
>>>     files.
>>>
>>>     Specification
>>>     =============
>>>     If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
>>>     compile() method to compile the script to a javax.script.CompiledScript object and use its
>>>     eval() method to run the script. In the case that the compilation throws (unexpectedly) a
>>>     javax.script.ScriptException log a warning and fall back to using the
>>>     javax.script.ScriptEngine's eval() method instead.
>>>     To allow setting this feature off and on while processing the FXML file a "compile" process
>>>     instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
>>>     compilation off and on throughout a FXML file.
>>>
>>> Having never seen a real CSR I hope that this matches what is expected and is helpful for
>>> assessment. If not please advise (got the name of these fields from [1]).
>>>
>>> ---
>>>
>>> Also added brief information about the respective test units (what they test and yield) in the WIP? [2].
>>>
>>> ---rony
>>>
>>> [1] "CSR-FAQ": <https://wiki.openjdk.java.net/display/csr/CSR+FAQs>
>>>
>>> [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement
>>> javax.script.Compilable compile scripts #192":? <https://github.com/openjdk/jfx/pull/192>
>>>
>>>
>>> On 20.04.2020 14:58, Rony G. Flatscher wrote:
>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:
>>>>
>>>>     This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a
>>>>     warning gets issued about this fact and evaluation of the script will be done without
>>>>     compilation. Because of the fallback scripts get compiled with this version by default. It
>>>>     extends PR 187 #187.
>>>>
>>>>     To further ease spotting scripts that cause a ScriptException a message in the form of
>>>>     "filename: caused ScriptException" gets added to the exception handling in either of the three
>>>>     locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three
>>>>     different kinds of reporting ScriptExceptions may be questioned, however none of these tear down
>>>>     the FXML GUI).
>>>>
>>>> This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged
>>>> whenever a script cannot be compiled and the fallback gets used.
>>>>
>>>> It is suggested to use this WIP as it includes the compilation by default with a safe fallback to
>>>> evaluate the uncompiled script, if compilation (unexpectedly) fails.
>>>>
>>>> Again, any feedback, discussion welcome!
>>>>
>>>> ---rony
>>>>
>>>> P.S.: In the log history there is a commit message "Make message more pregnant.", it should have
>>>> read "Make messages more terse." instead|.||
>>>> |
>>>>
>>>>
>>>> On 17.04.2020 19:37, Rony G. Flatscher wrote:
>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a compile PI (process
>>>>> instruction) for turning on and off script compilation if the script engine implements the
>>>>> Compilable interface.
>>>>>
>>>>> By default compilation is off (no compilation), such that one needs to add a compile PI
>>>>> ("<?compile?>") at the top to activate this feature. Supplying "true" (default) or "false" as the PI
>>>>> data turns this feature on and off.
>>>>>
>>>>> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off",
>>>>> alternating using "compile on and off", and alternating using "compile off and on". This will test
>>>>> all variants of applying the compile PI for all categories of scripts.
>>>>>
>>>>> Any feedback appreciated!
>>>>>
>>>>> ---rony
>>>>>
>>>>> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get
>>>>> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes.
>>>>>
>>>>> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a
>>>>> fallback solution in case a compilation is (unexpectedly) not successful, reverting to
>>>>> (interpretative) evaluation/execution of the script. In that version it is planned to have
>>>>> compilation on by default as in the case of a compilation failure there will be a safe backup solution.
>>>>>
>>>>>
>>>>> On 14.04.2020 19:52, Kevin Rushforth wrote:
>>>>>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to
>>>>>> create the CSR until the review is far enough along to know which direction we intend to go.
>>>>>>
>>>>>> Unless there is a real concern about possible regressions if scripts are compiled by default, I
>>>>>> think "enabled by default" is the way to go. Your argument that such script engines are broken
>>>>>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable
>>>>>> in the first place. We still might want to add way to turn compilation off for individual scripts.
>>>>>> One other thing to consider is that if compilation fails, it might make sense to log a warning and
>>>>>> fall back to the existing interpreted mode.
>>>>>>
>>>>>> Does anyone else have any concerns with this?
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days
>>>>>>> with the PR as per Kevin's suggestion.
>>>>>>>
>>>>>>> (For the case that this feature should not be active by default, the CSR will suggest to define a
>>>>>>> new "compile" PI in the form <?compile [true|false] ?> (default, if no PI data given: true), which
>>>>>>> is independent of the existence of a language PI (this way it becomes also possible to allow
>>>>>>> compilation of external scripts denoted with the script-element, which do not need a page language
>>>>>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for
>>>>>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI
>>>>>>> <?compile?> or <?compile true?>? to FXML files (and <?compile false?> to turn off), which seems to
>>>>>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation
>>>>>>> of scripts on and off throughout an FXML file.)
>>>>>>>
>>>>>>> ---rony
>>>>>>>
>>>>>>>
>>>>>>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>>>>>>
>>>>>>>> Hi Kevin,
>>>>>>>>
>>>>>>>> On 03.04.2020 01:21, Kevin Rushforth wrote:
>>>>>>>>> I see that you updated the PR and sent it for review.
>>>>>>>>>
>>>>>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful
>>>>>>>>> feature, and if so, what form this feature should take.
>>>>>>>>>
>>>>>>>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit
>>>>>>>>> from it?
>>>>>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code
>>>>>>>> may
>>>>>>>> benefit.
>>>>>>>>
>>>>>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the
>>>>>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit
>>>>>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause
>>>>>>>> the reparsing of that script's source and interpreting it on each invocation, which may be
>>>>>>>> expensive
>>>>>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the
>>>>>>>> compiled
>>>>>>>> script by the script engine.
>>>>>>>>
>>>>>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in
>>>>>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons?
>>>>>>>> In principle there are three possibilities:
>>>>>>>>
>>>>>>>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the
>>>>>>>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and
>>>>>>>> ???? execute the compiled script each time its registered event fires.
>>>>>>>>
>>>>>>>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts
>>>>>>>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail
>>>>>>>> ???????? compiling but have been employed successfully in interpreted mode
>>>>>>>>
>>>>>>>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML
>>>>>>>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script
>>>>>>>> ???? engine implements the javax.script.Compilable interface. If missing it would default to
>>>>>>>> "false".
>>>>>>>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the
>>>>>>>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the
>>>>>>>> ???? "language" PI was not.)
>>>>>>>>
>>>>>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the
>>>>>>>> language
>>>>>>>> ???????? PI gets changed
>>>>>>>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts
>>>>>>>>
>>>>>>>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script
>>>>>>>> and
>>>>>>>> ???? node elements and only compile the scripts, if the property is set to true
>>>>>>>>
>>>>>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed
>>>>>>>> ???????? accordingly
>>>>>>>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that
>>>>>>>> host scripts
>>>>>>>>
>>>>>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be
>>>>>>>> overruled individually by 3.
>>>>>>>>
>>>>>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that
>>>>>>>> compilation
>>>>>>>> of scripts by the script engines would find the same errors as while interpreting the very same
>>>>>>>> scripts (if not, the script engine is badly broken and it could be argued that then the
>>>>>>>> interpretation part of the script engine might be expected to be broken as well which would be
>>>>>>>> quite
>>>>>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the
>>>>>>>> compiled script would behave differently to interpreting the very same script by the same script
>>>>>>>> engine).
>>>>>>>>
>>>>>>>> The current WIP implements 1 above and includes an appropriate test unit.
>>>>>>>>
>>>>>>>>> What do others think?
>>>>>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the
>>>>>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine,
>>>>>>>>> but we would need to ensure that.
>>>>>>>> The compilation of scripts needs to be done by the Java script engines (implementing both,
>>>>>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled
>>>>>>>> scripts ([javax.script.CompiledScript]
>>>>>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)).
>>>>>>>>
>>>>>>>>
>>>>>>>> ---rony
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>>>>>>>>>> After merging master, applying some fixes and changing the title to reflect the change from
>>>>>>>>>> WIP to a
>>>>>>>>>> pull request I would kindly request a review of this pull request!
>>>>>>>>>>
>>>>>>>>>> Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: "8238080:
>>>>>>>>>> FXMLLoader: if
>>>>>>>>>> script engines implement javax.script.Compilable compile scripts".
>>>>>>>>>>
>>>>>>>>>> ---rony
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote:
>>>>>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in
>>>>>>>>>>> review, and
>>>>>>>>>>> has an appropriate test unit going with it as well, please review.
>>>>>>>>>>>
>>>>>>>>>>> There should be no compatibility issue with this implementation.
>>>>>>>>>>>
>>>>>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new
>>>>>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML
>>>>>>>>>>> files.
>>>>>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts
>>>>>>>>>>> if the
>>>>>>>>>>> language process instruction (e.g. <?language rexx?>) contains an appropriate attribute with a
>>>>>>>>>>> value
>>>>>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML
>>>>>>>>>>> with
>>>>>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up
>>>>>>>>>>> with a
>>>>>>>>>>> respective solution as well.
>>>>>>>>>>>
>>>>>>>>>>> ---rony
>>>>>>>>>>>
>>>>>>>>>>> [1] "Implementation and test unit": <https://github.com/openjdk/jfx/pull/129>
>>>>>>>>>>>
>>>>>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile
>>>>>>>>>>> scripts":
>>>>>>>>>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>>>>>>>>>
>>>>>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
>>>>>>>>>>> <https://github.com/openjdk/jfx/pull/122/commits>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this
>>>>>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to
>>>>>>>>>>>> illustrate
>>>>>>>>>>>> the concept).
>>>>>>>>>>>>
>>>>>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility
>>>>>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Kevin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>>> Just filed a RFE with the following information:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ???? * Component:
>>>>>>>>>>>>> ???????? o JavaFX
>>>>>>>>>>>>>
>>>>>>>>>>>>> ???? * Subcomponent:
>>>>>>>>>>>>> ???????? o fxml: JavaFX FXML
>>>>>>>>>>>>>
>>>>>>>>>>>>> ???? * Synopsis:
>>>>>>>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"
>>>>>>>>>>>>>
>>>>>>>>>>>>> ???? * Descriptions:
>>>>>>>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages
>>>>>>>>>>>>> (javax.script.ScriptEngine
>>>>>>>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller
>>>>>>>>>>>>> language in
>>>>>>>>>>>>> ?????????? the FXML file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such
>>>>>>>>>>>>> scripts
>>>>>>>>>>>>> could
>>>>>>>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead
>>>>>>>>>>>>> using
>>>>>>>>>>>>> ?????????? its eval() methods.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script
>>>>>>>>>>>>> invocations,
>>>>>>>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>>>>>>>>> onMouseMove)
>>>>>>>>>>>>> ?????????? which may be repetitevly invoked and evaluated."
>>>>>>>>>>>>>
>>>>>>>>>>>>> ???? * System /OS/Java Runtime Information:
>>>>>>>>>>>>> ???????? o "All systems."
>>>>>>>>>>>>>
>>>>>>>>>>>>> Received the internal review ID: "9063426"
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---rony


From jpereda at openjdk.java.net  Mon May 11 12:56:57 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Mon, 11 May 2020 12:56:57 GMT
Subject: RFR: 8244735: Error on iOS passing keys with unicode values greater
 than 255
Message-ID: <R9iAuo45WgRsjv0MZqbLaad4v--9ja7hwYzU0PMnKXc=.7d85d351-ae2d-4b01-b92e-16e24eb35a90@github.com>

With this PR, we pass directly the 16-bit unsigned short for a character (unicode value) to the Java layer, avoiding
the cast with the C++ 8-bit char, that fails for non-ascii characters like euro (?) or quote (").

We also avoid the mapping between iOS keys and JavaFX `KeyCode`, except for `ENTER` and `BACK_SPACE`, as the mapping
for some keys was wrong, like for "%", with ascii value 0x25, that was mapped to KeyCode.LEFT.

Finally, the iOS keyboard is set to `UIKeyboardTypeASCIICapable`, to prevent the display of the emoji keyboard, that
can't be currently processed.

-------------

Commit messages:
 - Set iOS keyboard type
 - Pass the unicode value of iOS 16-bit chars directly to the Java layer, without keyCode value (except for enter and backspace)

Changes: https://git.openjdk.java.net/jfx/pull/217/files
 Webrev: https://webrevs.openjdk.java.net/jfx/217/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244735
  Stats: 39 lines in 6 files changed: 20 ins; 7 del; 12 mod
  Patch: https://git.openjdk.java.net/jfx/pull/217.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/217/head:pull/217

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

From kevin.rushforth at oracle.com  Mon May 11 13:29:41 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 11 May 2020 06:29:41 -0700
Subject: Mac: Supported MacOS JDKs
In-Reply-To: <CA+0ynh-3YayfrfxcWD+8GJya8L0ityVqbBJG66J5B0_=CzTguA@mail.gmail.com>
References: <CA+4mSqZJVqurrXGzS8yBy1kFHV7X7Xyw8S-HJ07OUUrkg3y-+w@mail.gmail.com>
 <CA+0ynh-3YayfrfxcWD+8GJya8L0ityVqbBJG66J5B0_=CzTguA@mail.gmail.com>
Message-ID: <81348899-39e2-dc14-0ca0-cf9c713bbdf7@oracle.com>

I built FX with Xcode 11.3.1 + MacOSX10.15.sdk last week and it works 
fine for me.

-- Kevin


On 5/10/2020 7:05 AM, Nir Lisker wrote:
> if this is confirmed I can update the page.
>
> On Tue, Apr 14, 2020 at 1:18 PM Florian Kirmaier <florian.kirmaier at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> it seems to me, that the newest JDK for Mac (MacOSX10.15.sdk) doesn't work
>> to build JavaFX.
>> It works for me with 10.14 but not with 10.15.
>> Can anyone confirm this?
>> It would be great to mention this in the build instructions here:
>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>>
>> Greetings Florian Kirmaier
>>


From johan.vos at gluonhq.com  Mon May 11 14:39:59 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 11 May 2020 16:39:59 +0200
Subject: backport request: JDK-8200224
Message-ID: <CABxFH2E+Hji_ppWX=62pzQudyjZHAa2bem56pQdtEeBSJyhaEg@mail.gmail.com>

Hi Kevin,

I ask permission to backport JDK-8200224 (Multiple press event when
JFXPanel gains focus) to JavaFX 11-dev

Thanks,

- Johan

From kevin.rushforth at oracle.com  Mon May 11 14:41:26 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 11 May 2020 07:41:26 -0700
Subject: backport request: JDK-8200224
In-Reply-To: <CABxFH2E+Hji_ppWX=62pzQudyjZHAa2bem56pQdtEeBSJyhaEg@mail.gmail.com>
References: <CABxFH2E+Hji_ppWX=62pzQudyjZHAa2bem56pQdtEeBSJyhaEg@mail.gmail.com>
Message-ID: <4f6d708c-a246-a31b-31bd-6cf34f2d6815@oracle.com>

+1

-- Kevin

On 5/11/2020 7:39 AM, Johan Vos wrote:
> Hi Kevin,
>
> I ask permission to backport JDK-8200224 (Multiple press event when
> JFXPanel gains focus) to JavaFX 11-dev
>
> Thanks,
>
> - Johan


From nlisker at openjdk.java.net  Mon May 11 18:02:08 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Mon, 11 May 2020 18:02:08 GMT
Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot
 rendering
In-Reply-To: <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
References: <hSZLFZkdZCDK6SvfDoDbflPQ0uQwDMRo--EyPI-x9KA=.9b7ff341-636f-48ec-b1d3-16263be6b3b1@github.com>
 <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
Message-ID: <xFYLzN1KHqYJT1kwu8hUUc0kyUtQkmr6y40VCtqSavE=.9fe6a394-482b-49e9-81fd-1d0b49a24268@github.com>

On Tue, 17 Mar 2020 11:43:16 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be
>> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around
>> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is
>> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk
>> of regressions, either in terms of performances and correctness, while still offering some relief to the original
>> issue.  This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best
>> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is
>> necessary while still introducing no regressions compared to the original solution.
>
> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in import statements

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1483:

> 1482:                                     IntBuffer buffer, ResourceFactory rf, QuantumImage tileImg, QuantumImage
> targetImg) { 1483:                 com.sun.prism.RTTexture rt = tileImg.getRT(w, h, rf);
> 1484:                 if (rt == null) {

Any reason why the fully qualified name is needed?

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1502:

> 1501:             private void renderWholeImage(int x, int y, int w, int h, ResourceFactory rf, QuantumImage pImage) {
> 1502:                 com.sun.prism.RTTexture rt = pImage.getRT(w, h, rf);
> 1503:                 if (rt == null) {

Same questions for `RTTexture`

-------------

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

From kcr at openjdk.java.net  Mon May 11 20:13:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 11 May 2020 20:13:06 GMT
Subject: [Integrated] RFR: 8244487: One Windows 10 SDK file missing from
 FX build
In-Reply-To: <SXttMK8EqjzIvStVnOe8udVnJS1vIhS2EvPuC4tIe3U=.0c7788ca-598a-4c8f-a768-f0f336bf37cc@github.com>
References: <SXttMK8EqjzIvStVnOe8udVnJS1vIhS2EvPuC4tIe3U=.0c7788ca-598a-4c8f-a768-f0f336bf37cc@github.com>
Message-ID: <mUE2W4r_6aVjQDLkR32X8oN6qa2mMtEOTjj4pz5M6J4=.394ab129-cb7d-4132-95c9-92bb16a01770@github.com>

On Wed, 6 May 2020 17:34:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> While auditing the list of redistributed Microsoft files in the JDK versus FX, I discovered one file that the JDK ships
> that FX does not:
> api-ms-win-core-console-l1-2-0.dll
> 
> I checked the Redist directory in the Windows 10 SDK and this is the only one we are missing.
> 
> Root cause: the current version of the Windows 10 SDK has 41 redistributable `api-ms-win-*` files. There were 40 when
> we first upgraded to VS 2017 and Windows 10 SDK three years ago. We didn't reexamine the list when upgrading to a later
> minor version of VS 2017 and the Windows 10 SDK.  We haven't yet seen any problems as a result, but since we are
> getting ready to upgrade to VS 2019 see [JDK-8242508](https://bugs.openjdk.java.net/browse/JDK-8242508) -- we should
> correct this so it doesn't cause problems in the future.

This pull request has now been integrated.

Changeset: 0f87d20f
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/0f87d20f
Stats:     2 lines in 2 files changed: 0 ins; 2 del; 0 mod

8244487: One Windows 10 SDK file missing from FX build

Reviewed-by: jvos

-------------

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

From kcr at openjdk.java.net  Mon May 11 20:13:48 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 11 May 2020 20:13:48 GMT
Subject: [Integrated] RFR: 8242508: Upgrade to Visual Studio 2019 version
 16.5.3
In-Reply-To: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
References: <nG91riO4irBXtuwEQrzxisF9bYPhllUHDMehsC993qo=.bc491082-1751-4c70-9565-db5834cb0937@github.com>
Message-ID: <OoRT9_n7-K677Grsulr1JOQMAuk5tryMg0x9VnZx4rw=.34bb56fa-01fa-4bcb-a2dd-3acdf79be3e6@github.com>

On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019
> (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see
> [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214).  I have run a full build and test using this new
> compiler.
> NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which
> is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by
> this PR.

This pull request has now been integrated.

Changeset: b0d66d0d
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/b0d66d0d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8242508: Upgrade to Visual Studio 2019 version 16.5.3

Reviewed-by: jvos, arapte

-------------

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

From nlisker at openjdk.java.net  Tue May 12 04:53:19 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 12 May 2020 04:53:19 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <QZ0E_MGhzgEniRfDuSbWlNrE3q3tyKFs_uYEYZQD4yg=.f18a7e31-d6c7-4f49-97a9-1ce45d91d340@github.com>
 <iZ_VKNDGhAubihs6UADT1FIt2uiCtvyhMZ2CamQ9O_Q=.5cebb3e4-7f01-442d-8df5-131eda2e88ca@github.com>
 <CrlqE2AOM48IdHVVJi4YKpWjOPRDQMPwHUATqfFICOo=.77648651-e422-4c07-b2f7-967ca0175a0a@github.com>
 <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
Message-ID: <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>

On Tue, 28 Apr 2020 00:00:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I will review this too anyway.
>
>> I will review this too anyway.
> 
> Thank you. That will be helpful.

As I started my review I noticed that `unbind` does not null-check its argument `dependencies` like `bind` does and it
can lead to NPEs. If it is out of scope for this PR to fix this, a new issue should be filed.

-------------

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

From jvos at openjdk.java.net  Tue May 12 08:56:23 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 12 May 2020 08:56:23 GMT
Subject: RFR: 8244735: Error on iOS passing keys with unicode values
 greater than 255
In-Reply-To: <R9iAuo45WgRsjv0MZqbLaad4v--9ja7hwYzU0PMnKXc=.7d85d351-ae2d-4b01-b92e-16e24eb35a90@github.com>
References: <R9iAuo45WgRsjv0MZqbLaad4v--9ja7hwYzU0PMnKXc=.7d85d351-ae2d-4b01-b92e-16e24eb35a90@github.com>
Message-ID: <1F5bfFuQlGuTs66BTXIeyswU1NHVsg1uEYD6F8QThUQ=.245887cd-8464-4ef9-8591-f4d96bcecfff@github.com>

On Mon, 11 May 2020 12:50:48 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> With this PR, we pass directly the 16-bit unsigned short for a character (unicode value) to the Java layer, avoiding
> the cast with the C++ 8-bit char, that fails for non-ascii characters like euro (?) or quote (").
> We also avoid the mapping between iOS keys and JavaFX `KeyCode`, except for `ENTER` and `BACK_SPACE`, as the mapping
> for some keys was wrong, like for "%", with ascii value 0x25, that was mapped to KeyCode.LEFT.
> Finally, the iOS keyboard is set to `UIKeyboardTypeASCIICapable`, to prevent the display of the emoji keyboard, that
> can't be currently processed.

This indeed fixes JDK-8244735.
It only touches ios-specific files, hence there is no impact on other platforms.

-------------

Marked as reviewed by jvos (Reviewer).

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

From tschindl at openjdk.java.net  Tue May 12 12:05:50 2020
From: tschindl at openjdk.java.net (Tom Schindl)
Date: Tue, 12 May 2020 12:05:50 GMT
Subject: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard
 modifiers in events.
In-Reply-To: <IuIGv4ubZwQTs97FC8anxE_5I6BbrquE5x4dclxyFhw=.5675d63c-a91a-433a-bb02-db16e2c16630@github.com>
References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com>
 <xl4IlVlcsSwl40KTNm25M4Pho4mq13iaCFeBs9zGoM8=.90e0f453-a306-4216-93c2-c73351342f22@github.com>
 <IuIGv4ubZwQTs97FC8anxE_5I6BbrquE5x4dclxyFhw=.5675d63c-a91a-433a-bb02-db16e2c16630@github.com>
Message-ID: <hkeTE2MV_J1gqjDkhVKz3U8U15HdYdhb2d67Qu73I7o=.8e4e1772-d37a-4838-8941-a6dafe776ad4@github.com>

On Tue, 28 Apr 2020 22:36:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Tom Schindl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
>>   
>>   Fix whitespace errors
>
> Looks good to me. I verified that the new test fails without your fix and passes with your fix.
> 
> In case anyone else is looking at this and wants to run the test, it isn't enabled by default, so you need to run it
> like this:
> gradle -PUNSTABLE_TEST=true -PFULL_TEST=true -PUSE_ROBOT=true \
>     :systemTests:test --tests test.robot.com.sun.glass.ui.monocle.RobotTest

@kevinrushforth is there anything left todo or did you simply forget to merge it?

-------------

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

From jpereda at openjdk.java.net  Tue May 12 12:16:13 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Tue, 12 May 2020 12:16:13 GMT
Subject: [Integrated] RFR: 8244735: Error on iOS passing keys with unicode
 values greater than 255
In-Reply-To: <R9iAuo45WgRsjv0MZqbLaad4v--9ja7hwYzU0PMnKXc=.7d85d351-ae2d-4b01-b92e-16e24eb35a90@github.com>
References: <R9iAuo45WgRsjv0MZqbLaad4v--9ja7hwYzU0PMnKXc=.7d85d351-ae2d-4b01-b92e-16e24eb35a90@github.com>
Message-ID: <rlxBHWG7Pn2ybSoT_7kxyjKpohvz2t5WwF-VeKGXkso=.894e84d6-22ac-4af3-aa3e-7e6df2597e1d@github.com>

On Mon, 11 May 2020 12:50:48 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> With this PR, we pass directly the 16-bit unsigned short for a character (unicode value) to the Java layer, avoiding
> the cast with the C++ 8-bit char, that fails for non-ascii characters like euro (?) or quote (").
> We also avoid the mapping between iOS keys and JavaFX `KeyCode`, except for `ENTER` and `BACK_SPACE`, as the mapping
> for some keys was wrong, like for "%", with ascii value 0x25, that was mapped to KeyCode.LEFT.
> Finally, the iOS keyboard is set to `UIKeyboardTypeASCIICapable`, to prevent the display of the emoji keyboard, that
> can't be currently processed.

This pull request has now been integrated.

Changeset: b14e0858
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/b14e0858
Stats:     39 lines in 6 files changed: 7 ins; 20 del; 12 mod

8244735: Error on iOS passing keys with unicode values greater than 255

Reviewed-by: jvos

-------------

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

From kcr at openjdk.java.net  Tue May 12 12:24:13 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 12 May 2020 12:24:13 GMT
Subject: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard
 modifiers in events.
In-Reply-To: <hkeTE2MV_J1gqjDkhVKz3U8U15HdYdhb2d67Qu73I7o=.8e4e1772-d37a-4838-8941-a6dafe776ad4@github.com>
References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com>
 <xl4IlVlcsSwl40KTNm25M4Pho4mq13iaCFeBs9zGoM8=.90e0f453-a306-4216-93c2-c73351342f22@github.com>
 <IuIGv4ubZwQTs97FC8anxE_5I6BbrquE5x4dclxyFhw=.5675d63c-a91a-433a-bb02-db16e2c16630@github.com>
 <hkeTE2MV_J1gqjDkhVKz3U8U15HdYdhb2d67Qu73I7o=.8e4e1772-d37a-4838-8941-a6dafe776ad4@github.com>
Message-ID: <2SDwXvqEnLGfytJWuLq5cPDOO3abTamxOJMMi9KLddQ=.7401711c-a3ab-4d86-b7a4-d83942c12cd9@github.com>

On Tue, 12 May 2020 12:03:36 GMT, Tom Schindl <tschindl at openjdk.org> wrote:

>> Looks good to me. I verified that the new test fails without your fix and passes with your fix.
>> 
>> In case anyone else is looking at this and wants to run the test, it isn't enabled by default, so you need to run it
>> like this:
>> gradle -PUNSTABLE_TEST=true -PFULL_TEST=true -PUSE_ROBOT=true \
>>     :systemTests:test --tests test.robot.com.sun.glass.ui.monocle.RobotTest
>
> @kevinrushforth is there anything left todo or did you simply forget to merge it?

@tomsontom Yes, there is something you need to do. As the author of the patch, you need to `/integrate` it after which
I'll `/sponsor` it.

-------------

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

From aghaisas at openjdk.java.net  Tue May 12 12:27:11 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 12 May 2020 12:27:11 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
Message-ID: <WmZDf0OUvv4fG4FWAgqXytPqMN73TfZ25iRLsvmu384=.4b97c674-04a2-4fc8-9fa7-a4476cc0b913@github.com>

> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244418
> 
> Root Cause :
> Incorrect assumption about menu list size.
> 
> Fix :
> Added check for empty menu list before trying to access it.
> 
> Test :
> Added a unit test that fails before fix and passes after it.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  review_fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/216/files
  - new: https://git.openjdk.java.net/jfx/pull/216/files/d37f9c14..15c4de98

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/216/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/216/webrev.00-01

  Stats: 12 lines in 1 file changed: 1 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/216.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/216/head:pull/216

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

From aghaisas at openjdk.java.net  Tue May 12 12:27:12 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 12 May 2020 12:27:12 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
Message-ID: <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>

On Fri, 8 May 2020 13:51:34 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review_fixes
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 485:
> 
>> 484:         }
>> 485:
>> 486:         if (focusedMenu != null && focusedMenuIndex != -1) {
> 
> don't quite understand why this change is necessary? The guard in the listener seems to be enough, at least the test
> passes without this. If it's needed to fix another potentially breaking path to this, would it be possible to add a
> test method that fails/passes before/after?

This was the place where exception was occurring. Hence, I added this check.
When I ran against the test, I still got the exception at caller lambda. I added that check later.
Wanted to remove this check - but simple code scan revealed this method gets called from engine.addTraverseListener()
listener with index = 0. Hence, I have kept this check. Covering this scenario in test seems tough.

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 307:
> 
>> 306:                 unSelectMenus();
>> 307:                 if (!container.getChildren().isEmpty()) {
>> 308:                     menuModeStart(0);
> 
> wondering whether this would be an appropriate time to simplify the logic a bit: as unSelectMenus is called in both if
> and else block, it could be condensed to
>     unSelectMenus();
>     if (t1 && !container.getChildren().isEmpty()) {
>        ...
>     }
> 
> might overlook something, though

Good suggestion. Fixed.

-------------

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

From jvos at openjdk.java.net  Tue May 12 13:23:25 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 12 May 2020 13:23:25 GMT
Subject: RFR: 8244417: support static build for Windows
In-Reply-To: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
References: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
Message-ID: <zBISFP2jc7PiVTUY5Xg4Iyfu6Rpx80_piaRZRyEia_A=.27615dd6-6751-4e99-a25e-1e5d2942ae3d@github.com>

On Thu, 7 May 2020 21:15:02 GMT, Joeri Sykora <sykora at openjdk.org> wrote:

> Adds support for building static libraries of the OpenJFX modules for the Windows platform. Building static libraries
> is done by providing the gradle property `-PSTATIC_BUILD=true`.
> Changes include:
> 
> - add static flags for the compiler and linker
> - use `lib` for linking instead of `link`
> - only build and include version.rc once (from GlassResources.rc)
> - include library specific `JNI_OnLoad_xxx` methods
> - functionality loaded via `DllMain` has been implemented at a different location

confirmed to work with VS2019 as well.

-------------

Marked as reviewed by jvos (Reviewer).

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

From aghaisas at openjdk.java.net  Tue May 12 13:47:00 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 12 May 2020 13:47:00 GMT
Subject: [Rev 03] RFR: 8242548: Wrapped labeled controls using
 -fx-line-spacing cut text off
In-Reply-To: <S0R0eIoNBJ5aWYURVS7dARmGiLQLJ7lQ3d99ypcDMlM=.ed6fb023-ad68-4bfd-89c1-3fe68330aa3f@github.com>
References: <fITqSHYVPaCgMLBQjDJyU4Spp31LMRrxRdF8sD-JJec=.b60e407c-0d0b-4d84-bba5-f00711bac67d@github.com>
 <hHIeTvdz3LP2jHSfnUX3b_NB3xEcUXB9nat0g94wNwk=.49c40cb3-9d8f-4daa-a35a-fc7abf9a49e1@github.com>
 <S0R0eIoNBJ5aWYURVS7dARmGiLQLJ7lQ3d99ypcDMlM=.ed6fb023-ad68-4bfd-89c1-3fe68330aa3f@github.com>
Message-ID: <363XKZnSJ4lc3Rj_JRp1iV2jRrUobC7GncecmPtM3XY=.ce85e18a-e92b-41da-b525-5d1cca6106ad@github.com>

On Fri, 1 May 2020 12:33:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in comment
>
> Marked as reviewed by kcr (Lead).

@hjohn, this PR is ready to be merged.
You need to comment /integrate on this PR as instructed by the bot above. I will sponsor it once you do it.

-------------

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

From sykora at openjdk.java.net  Tue May 12 14:12:16 2020
From: sykora at openjdk.java.net (Joeri Sykora)
Date: Tue, 12 May 2020 14:12:16 GMT
Subject: [Integrated] RFR: 8244417: support static build for Windows
In-Reply-To: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
References: <fdEctDn6-Lrnvv7fK8tLBXx8VFp0YkMHbcjwfjtDhKc=.db1da69c-0ff8-4300-a44c-b45ea1ca122d@github.com>
Message-ID: <539X9XsPO97MiL8055ao4BjEpHx9cH7jxZjAD0PLX4g=.7620152e-c1ae-47d1-9078-569c4ff6086c@github.com>

On Thu, 7 May 2020 21:15:02 GMT, Joeri Sykora <sykora at openjdk.org> wrote:

> Adds support for building static libraries of the OpenJFX modules for the Windows platform. Building static libraries
> is done by providing the gradle property `-PSTATIC_BUILD=true`.
> Changes include:
> 
> - add static flags for the compiler and linker
> - use `lib` for linking instead of `link`
> - only build and include version.rc once (from GlassResources.rc)
> - include library specific `JNI_OnLoad_xxx` methods
> - functionality loaded via `DllMain` has been implemented at a different location

This pull request has now been integrated.

Changeset: c14cc44e
Author:    Joeri Sykora <sykora at openjdk.org>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/c14cc44e
Stats:     83 lines in 9 files changed: 2 ins; 69 del; 12 mod

8244417: support static build for Windows

Reviewed-by: kcr, jvos

-------------

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

From nlisker at openjdk.java.net  Tue May 12 15:58:48 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 12 May 2020 15:58:48 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <QZ0E_MGhzgEniRfDuSbWlNrE3q3tyKFs_uYEYZQD4yg=.f18a7e31-d6c7-4f49-97a9-1ce45d91d340@github.com>
 <iZ_VKNDGhAubihs6UADT1FIt2uiCtvyhMZ2CamQ9O_Q=.5cebb3e4-7f01-442d-8df5-131eda2e88ca@github.com>
 <CrlqE2AOM48IdHVVJi4YKpWjOPRDQMPwHUATqfFICOo=.77648651-e422-4c07-b2f7-967ca0175a0a@github.com>
 <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
 <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
Message-ID: <QqSN4jRyt7uhADiM6eH4FhoW3z9HhihnfoA9xS9MXTo=.b960f8f5-23d2-4a6a-bce2-04cf6774fbc3@github.com>

On Mon, 11 May 2020 22:27:27 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>>> I will review this too anyway.
>> 
>> Thank you. That will be helpful.
>
> As I started my review I noticed that `unbind` does not null-check its argument `dependencies` like `bind` does and it
> can lead to NPEs. If it is out of scope for this PR to fix this, a new issue should be filed.

The fix looks correct and the tests pass. I just wonder why the change to reflection-based construction with
`bindingMockClassConstructor`?

-------------

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

From github.com+60214806+ronyfla at openjdk.java.net  Tue May 12 16:55:16 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Tue, 12 May 2020 16:55:16 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
Message-ID: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>

This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued
about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get
compiled with this version by default. It extends PR 187 <https://github.com/openjdk/jfx/pull/187>.

To further ease spotting scripts that cause a ScriptException a message in the form of "filename: caused
ScriptException" gets added to the exception handling in either of the three locations: an error message, a stack trace
or a wrap-up into a RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned,
however none of these tear down the FXML GUI).

-------------

Commit messages:
 - Document the compile processing instruction for scripts.
 - Add missing language processing instruction.
 - Correct typo, replace tabs, remove trailing blanks.
 - Make sure we test the default behaviour to compile script by leaving out the compile PI.
 - Revert temporary rename of test method.
 - Correct ModuleLauncherTest (remove non-existing test), correct formatting.
 - Always supply the script's filename in the error message first to further ease spotting the location of script exceptions.
 - Make message more pregnant.
 - Compile by default, have fallback if compilation fails, adapt/add test unig
 - add compile process instruction to control compilation of compilable scripts; PI data can be truei (default) or false
 - ... and 14 more: https://git.openjdk.java.net/jfx/compare/159f6516...44b0f9f8

Changes: https://git.openjdk.java.net/jfx/pull/192/files
 Webrev: https://webrevs.openjdk.java.net/jfx/192/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238080
  Stats: 2544 lines in 29 files changed: 2514 ins; 2 del; 28 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

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

From github.com+60214806+ronyfla at openjdk.java.net  Tue May 12 16:55:16 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Tue, 12 May 2020 16:55:16 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
Message-ID: <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>

On Mon, 20 Apr 2020 12:45:30 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

> This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued
> about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get
> compiled with this version by default. It extends PR 187 <https://github.com/openjdk/jfx/pull/187>.  To further ease
> spotting scripts that cause a ScriptException a message in the form of "filename: caused ScriptException" gets added to
> the exception handling in either of the three locations: an error message, a stack trace or a wrap-up into a
> RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned, however none of these
> tear down the FXML GUI).

============================ test units for: compile PI+fallback

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off.java
... use compile PI to set off compilation of scripts; each script code starts with "demo_02_"

tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off.fxml
... set compilation for scripts off ("<?compile false?>"), therefore no script gets compiled

---

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off_On.java
... alternatively uses compile PI to turn compilation off and on; the script code starts alternatively with "demo_02_"
and "RgfPseudoCompiledScript.eval(", depending on the state set with the PI

tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off_on.fxml
... starts out explicitly with "<?compile false?>" switching the state after each element containing a script

---

 tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On.java
 ... no compile PI given, hence compilation of scripts is on; each script code starts with
 "RgfPseudoCompiledScript.eval("
 
 tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on.fxml
... no compile PI given, starts out to compile scripts by default

---

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On_Off.java
... alternatively uses compile PI to turn compilation on and off; the script code starts alternatively with
"RgfPseudoCompiledScript.eval(", and "demo_02_" depending on the state set with the PI

tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on_off.fxml
... starts out explicitly with "<?compile true?>" switching the state after each element containing a script (sometimes
using PI "<?compile?>" to test setting it to true)

---

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java
... although compile scripts is on, none of the scripts get compiled as they all contain the string "FAIL COMPILATION"
which causes RgfPseudoScriptEngineCompilable.compile(...) to throw a ScriptException causing the fallback to be used;
all scripts therefore start with "demo_03_"

 tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_03_fail_compile.fxml
 ... explicitly turns on compilation (which is on by default anyway), adds "FAIL COMPILATION" to all inline scripts and
 to all external scripts with the filename that starts with "demo_03_"

-------------

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

From kcr at openjdk.java.net  Tue May 12 16:55:17 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 12 May 2020 16:55:17 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
 <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>
Message-ID: <JSIFzcCtP1mEAa4UFaZxPyNKxF_ks27fFkHoaSIkM9c=.5d8c29cf-a921-4bf2-a9dd-52004b8e5218@github.com>

On Wed, 22 Apr 2020 16:33:47 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

>> This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued
>> about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get
>> compiled with this version by default. It extends PR 187 <https://github.com/openjdk/jfx/pull/187>.  To further ease
>> spotting scripts that cause a ScriptException a message in the form of "filename: caused ScriptException" gets added to
>> the exception handling in either of the three locations: an error message, a stack trace or a wrap-up into a
>> RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned, however none of these
>> tear down the FXML GUI).
>
> ============================ test units for: compile PI+fallback
> 
> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off.java
> ... use compile PI to set off compilation of scripts; each script code starts with "demo_02_"
> 
> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off.fxml
> ... set compilation for scripts off ("<?compile false?>"), therefore no script gets compiled
> 
> ---
> 
> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off_On.java
> ... alternatively uses compile PI to turn compilation off and on; the script code starts alternatively with "demo_02_"
> and "RgfPseudoCompiledScript.eval(", depending on the state set with the PI
> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off_on.fxml
> ... starts out explicitly with "<?compile false?>" switching the state after each element containing a script
> 
> ---
> 
>  tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On.java
>  ... no compile PI given, hence compilation of scripts is on; each script code starts with
>  "RgfPseudoCompiledScript.eval("
>  tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on.fxml
> ... no compile PI given, starts out to compile scripts by default
> 
> ---
> 
> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On_Off.java
> ... alternatively uses compile PI to turn compilation on and off; the script code starts alternatively with
> "RgfPseudoCompiledScript.eval(", and "demo_02_" depending on the state set with the PI
> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on_off.fxml
> ... starts out explicitly with "<?compile true?>" switching the state after each element containing a script (sometimes
> using PI "<?compile?>" to test setting it to true)
> ---
> 
> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java
> ... although compile scripts is on, none of the scripts get compiled as they all contain the string "FAIL COMPILATION"
> which causes RgfPseudoScriptEngineCompilable.compile(...) to throw a ScriptException causing the fallback to be used;
> all scripts therefore start with "demo_03_"
>  tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_03_fail_compile.fxml
>  ... explicitly turns on compilation (which is on by default anyway), adds "FAIL COMPILATION" to all inline scripts and
>  to all external scripts with the filename that starts with "demo_03_"

I think the approach proposed in this PR is the best solution for this enhancement. Go ahead and remove the `WIP` from
the title, and we can proceed with the review.

The interface and behavior change will need to be specified in the API docs. This can be done by modifying the
[Introduction to
FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
document. I recommend documenting the new behavior and `<?compile>` attribute somewhere in the
[Scripting](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html#L769)
section.

As discussed on the mailing list, this will need a CSR, which should include the changes to the docs.

-------------

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

From github.com+60214806+ronyfla at openjdk.java.net  Tue May 12 16:55:17 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Tue, 12 May 2020 16:55:17 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <JSIFzcCtP1mEAa4UFaZxPyNKxF_ks27fFkHoaSIkM9c=.5d8c29cf-a921-4bf2-a9dd-52004b8e5218@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
 <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>
 <JSIFzcCtP1mEAa4UFaZxPyNKxF_ks27fFkHoaSIkM9c=.5d8c29cf-a921-4bf2-a9dd-52004b8e5218@github.com>
Message-ID: <yoeN3D9ZI-tobgB3snqlJTbdRbmA1ze54ALQpIBzxNk=.72ec4797-e1f4-450a-a8d4-b93ddbe6387b@github.com>

On Sat, 9 May 2020 15:15:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> ============================ test units for: compile PI+fallback
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off.java
>> ... use compile PI to set off compilation of scripts; each script code starts with "demo_02_"
>> 
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off.fxml
>> ... set compilation for scripts off ("<?compile false?>"), therefore no script gets compiled
>> 
>> ---
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off_On.java
>> ... alternatively uses compile PI to turn compilation off and on; the script code starts alternatively with "demo_02_"
>> and "RgfPseudoCompiledScript.eval(", depending on the state set with the PI
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off_on.fxml
>> ... starts out explicitly with "<?compile false?>" switching the state after each element containing a script
>> 
>> ---
>> 
>>  tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On.java
>>  ... no compile PI given, hence compilation of scripts is on; each script code starts with
>>  "RgfPseudoCompiledScript.eval("
>>  tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on.fxml
>> ... no compile PI given, starts out to compile scripts by default
>> 
>> ---
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On_Off.java
>> ... alternatively uses compile PI to turn compilation on and off; the script code starts alternatively with
>> "RgfPseudoCompiledScript.eval(", and "demo_02_" depending on the state set with the PI
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on_off.fxml
>> ... starts out explicitly with "<?compile true?>" switching the state after each element containing a script (sometimes
>> using PI "<?compile?>" to test setting it to true)
>> ---
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java
>> ... although compile scripts is on, none of the scripts get compiled as they all contain the string "FAIL COMPILATION"
>> which causes RgfPseudoScriptEngineCompilable.compile(...) to throw a ScriptException causing the fallback to be used;
>> all scripts therefore start with "demo_03_"
>>  tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_03_fail_compile.fxml
>>  ... explicitly turns on compilation (which is on by default anyway), adds "FAIL COMPILATION" to all inline scripts and
>>  to all external scripts with the filename that starts with "demo_03_"
>
> I think the approach proposed in this PR is the best solution for this enhancement. Go ahead and remove the `WIP` from
> the title, and we can proceed with the review.
> The interface and behavior change will need to be specified in the API docs. This can be done by modifying the
> [Introduction to
> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
> document. I recommend documenting the new behavior and `<?compile>` attribute somewhere in the
> [Scripting](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html#L769)
> section.  As discussed on the mailing list, this will need a CSR, which should include the changes to the docs.

Suggested CSR:

Summary
=======
Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
implements the javax.script.Compilable interface to speed up execution. In case compilation
throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
control of script compilation with a "compile" PI for FXML files.

Problem
=======
javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
(javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.

If a script engine implements the javax.script.Compilable interface, then such scripts could be
compiled and the resulting javax.script.CompiledScript could be executed instead using its
eval() methods.

Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
onMouseMove) which may be repetitively invoked and evaluated.

Solution
========
Before evaluating the script code test whether the javax.script.ScriptEngine implements
javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
and then use its eval() method to evaluate the script, otherwise continue to use the
javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
(unexpectedly) a javax.script.ScriptException then fall back to using the
javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
files.

Specification
=============
If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
compile() method to compile the script to a javax.script.CompiledScript object and use its
eval() method to run the script. In the case that the compilation throws (unexpectedly) a
javax.script.ScriptException log a warning and fall back to using the
javax.script.ScriptEngine's eval() method instead.
To allow setting this feature off and on while processing the FXML file a "compile" process
instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
compilation off and on throughout a FXML file.

-------------

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

From github.com+60214806+ronyfla at openjdk.java.net  Tue May 12 16:55:54 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Tue, 12 May 2020 16:55:54 GMT
Subject: [Closed] RFR: WIP 8238080: FXMLLoader: if script engines
 implement javax.script.Compilable compile scripts
In-Reply-To: <qDn4HRWe_IrwnryH-JBhuYQHJrJF8ZBDnTnY7G84VrQ=.7fe1fb1c-de1d-4453-90af-459a3ef0d9fe@github.com>
References: <qDn4HRWe_IrwnryH-JBhuYQHJrJF8ZBDnTnY7G84VrQ=.7fe1fb1c-de1d-4453-90af-459a3ef0d9fe@github.com>
Message-ID: <9LLj2jdYbWPnNKirkdI3xP0EL-LKhdy9R3nOZoFBqOQ=.016a8626-60b0-42d8-9b23-8f7efc7c7974@github.com>

On Fri, 28 Feb 2020 17:46:58 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

> TODO: ADD DESCRIPTION OF PROPOSED FIX HERE.

This pull request has been closed without being integrated.

-------------

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

From Rony.Flatscher at wu.ac.at  Tue May 12 17:18:27 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Tue, 12 May 2020 19:18:27 +0200
Subject: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP
 (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for
 review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script
 engines implement javax.script.Compilabel compile scripts"
In-Reply-To: <53e68e19-5e13-4d4d-b90a-d743ecbd6cc9@wu.ac.at>
References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>
 <d237cbbe-f1fe-519b-e378-ad576a4944ff@oracle.com>
 <bd3eb6ef-154f-811d-936a-37543a2a244c@wu.ac.at>
 <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at>
 <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com>
 <eb73c12e-0d76-0570-7903-0288696fe57a@wu.ac.at>
 <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at>
 <e08195ad-c924-3fba-5407-cfeb3e91fa63@oracle.com>
 <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at>
 <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at>
 <b27d7276-2a52-e756-baa6-18678048e226@wu.ac.at>
 <34d30efa-a87c-261e-36b3-e5f68f38c389@wu.ac.at>
 <2a2007be-8ffa-e0c1-c252-0e9a5281ef3b@oracle.com>
 <53e68e19-5e13-4d4d-b90a-d743ecbd6cc9@wu.ac.at>
Message-ID: <77bc0cae-bee1-c569-ca0b-abc4d7ca9be6@wu.ac.at>

Hi Kevin,

in the meantime I have tried to come up with a formulation for the "Introduction to FXML"
specification about the new compile processing instruction which is brief and complete. While being
there I fixed a typo in the document and added a missing language processing instruction to an
existing script example, hope that was o.k. as I have not filed an explicit bug for it.

Also closed the PR 129 and 187, removed the WIP from PR 192, and supplied the CSR draft as a comment.

If there is anything else I should do, please let me know.

Cheers,

---rony


On 11.05.2020 14:12, Rony G. Flatscher wrote:
> Hi Kevin,
>
> On 09.05.2020 17:16, Kevin Rushforth wrote:
>> I'm finally getting back to this. I took a look at https://github.com/openjdk/jfx/pull/192 and I
>> like that as the direction for this enhancement.
>>
>> The initial CSR you have is a good start.
> Thank you!
>
>> Next steps are:
>>
>> 1. Update the "Introduction to FXML" specification (see my comment in the PR)
>> 2. Update PR 192 with the draft CSR as a comment, modifying it to include the above additions to
>> "Introduction to FXML"
>> 3. Remove WIP from the title
>>
>> You can then close the other two PRs (129 and 187).
> will do (may take a little bit).
>
> Cheers
>
> ---rony
>
>
>> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>> Hi Kevin,
>>>
>>> what should be the next steps?
>>>
>>> Should I remove "WIP" from the title in <https://github.com/openjdk/jfx/pull/192> and add the CSR
>>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby requesting it to be added
>>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>>
>>> Please advise.
>>>
>>> TIA,
>>>
>>> ---rony
>>>
>>> P.S.: This is the RFE:
>>>
>>>   * RFE (2020-01-24): <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>
>>> These are the three versions (all with appropriate unit tests) that I came up with
>>> chronologically to implement the RFE, would prefer the latest version (PR # 192):
>>>
>>>   * Compile if Compilable implemented (2020-02-28): <https://github.com/openjdk/jfx/pull/129>
>>>   * Compile if compile PI and Compilable is implemented (2020-04-11):
>>>     <https://github.com/openjdk/jfx/pull/187>
>>>   * Compile with fallback, if Compilable is implemented, compile PI for fine-grained control
>>>     (2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>>
>>>
>>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>>> Hi Kevin,
>>>>
>>>> as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes:
>>>>
>>>>     Summary
>>>>     =======
>>>>     Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
>>>>     implements the javax.script.Compilable interface to speed up execution. In case compilation
>>>>     throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
>>>>     control of script compilation with a "compile" PI for FXML files.
>>>>
>>>>     Problem
>>>>     =======
>>>>     javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>>>>     (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
>>>>
>>>>     If a script engine implements the javax.script.Compilable interface, then such scripts could be
>>>>     compiled and the resulting javax.script.CompiledScript could be executed instead using its
>>>>     eval() methods.
>>>>
>>>>     Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
>>>>     invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>     onMouseMove) which may be repetitively invoked and evaluated.
>>>>
>>>>     Solution?
>>>>     ========
>>>>     Before evaluating the script code test whether the javax.script.ScriptEngine implements
>>>>     javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
>>>>     and then use its eval() method to evaluate the script, otherwise continue to use the
>>>>     javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
>>>>     (unexpectedly) a javax.script.ScriptException then fall back to using the
>>>>     javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
>>>>     the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
>>>>     files.
>>>>
>>>>     Specification
>>>>     =============
>>>>     If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
>>>>     compile() method to compile the script to a javax.script.CompiledScript object and use its
>>>>     eval() method to run the script. In the case that the compilation throws (unexpectedly) a
>>>>     javax.script.ScriptException log a warning and fall back to using the
>>>>     javax.script.ScriptEngine's eval() method instead.
>>>>     To allow setting this feature off and on while processing the FXML file a "compile" process
>>>>     instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
>>>>     compilation off and on throughout a FXML file.
>>>>
>>>> Having never seen a real CSR I hope that this matches what is expected and is helpful for
>>>> assessment. If not please advise (got the name of these fields from [1]).
>>>>
>>>> ---
>>>>
>>>> Also added brief information about the respective test units (what they test and yield) in the WIP? [2].
>>>>
>>>> ---rony
>>>>
>>>> [1] "CSR-FAQ": <https://wiki.openjdk.java.net/display/csr/CSR+FAQs>
>>>>
>>>> [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement
>>>> javax.script.Compilable compile scripts #192":? <https://github.com/openjdk/jfx/pull/192>
>>>>
>>>>
>>>> On 20.04.2020 14:58, Rony G. Flatscher wrote:
>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:
>>>>>
>>>>>     This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a
>>>>>     warning gets issued about this fact and evaluation of the script will be done without
>>>>>     compilation. Because of the fallback scripts get compiled with this version by default. It
>>>>>     extends PR 187 #187.
>>>>>
>>>>>     To further ease spotting scripts that cause a ScriptException a message in the form of
>>>>>     "filename: caused ScriptException" gets added to the exception handling in either of the three
>>>>>     locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three
>>>>>     different kinds of reporting ScriptExceptions may be questioned, however none of these tear down
>>>>>     the FXML GUI).
>>>>>
>>>>> This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged
>>>>> whenever a script cannot be compiled and the fallback gets used.
>>>>>
>>>>> It is suggested to use this WIP as it includes the compilation by default with a safe fallback to
>>>>> evaluate the uncompiled script, if compilation (unexpectedly) fails.
>>>>>
>>>>> Again, any feedback, discussion welcome!
>>>>>
>>>>> ---rony
>>>>>
>>>>> P.S.: In the log history there is a commit message "Make message more pregnant.", it should have
>>>>> read "Make messages more terse." instead|.||
>>>>> |
>>>>>
>>>>>
>>>>> On 17.04.2020 19:37, Rony G. Flatscher wrote:
>>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a compile PI (process
>>>>>> instruction) for turning on and off script compilation if the script engine implements the
>>>>>> Compilable interface.
>>>>>>
>>>>>> By default compilation is off (no compilation), such that one needs to add a compile PI
>>>>>> ("<?compile?>") at the top to activate this feature. Supplying "true" (default) or "false" as the PI
>>>>>> data turns this feature on and off.
>>>>>>
>>>>>> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off",
>>>>>> alternating using "compile on and off", and alternating using "compile off and on". This will test
>>>>>> all variants of applying the compile PI for all categories of scripts.
>>>>>>
>>>>>> Any feedback appreciated!
>>>>>>
>>>>>> ---rony
>>>>>>
>>>>>> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get
>>>>>> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes.
>>>>>>
>>>>>> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a
>>>>>> fallback solution in case a compilation is (unexpectedly) not successful, reverting to
>>>>>> (interpretative) evaluation/execution of the script. In that version it is planned to have
>>>>>> compilation on by default as in the case of a compilation failure there will be a safe backup solution.
>>>>>>
>>>>>>
>>>>>> On 14.04.2020 19:52, Kevin Rushforth wrote:
>>>>>>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to
>>>>>>> create the CSR until the review is far enough along to know which direction we intend to go.
>>>>>>>
>>>>>>> Unless there is a real concern about possible regressions if scripts are compiled by default, I
>>>>>>> think "enabled by default" is the way to go. Your argument that such script engines are broken
>>>>>>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable
>>>>>>> in the first place. We still might want to add way to turn compilation off for individual scripts.
>>>>>>> One other thing to consider is that if compilation fails, it might make sense to log a warning and
>>>>>>> fall back to the existing interpreted mode.
>>>>>>>
>>>>>>> Does anyone else have any concerns with this?
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days
>>>>>>>> with the PR as per Kevin's suggestion.
>>>>>>>>
>>>>>>>> (For the case that this feature should not be active by default, the CSR will suggest to define a
>>>>>>>> new "compile" PI in the form <?compile [true|false] ?> (default, if no PI data given: true), which
>>>>>>>> is independent of the existence of a language PI (this way it becomes also possible to allow
>>>>>>>> compilation of external scripts denoted with the script-element, which do not need a page language
>>>>>>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for
>>>>>>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI
>>>>>>>> <?compile?> or <?compile true?>? to FXML files (and <?compile false?> to turn off), which seems to
>>>>>>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation
>>>>>>>> of scripts on and off throughout an FXML file.)
>>>>>>>>
>>>>>>>> ---rony
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>>>>>>>
>>>>>>>>> Hi Kevin,
>>>>>>>>>
>>>>>>>>> On 03.04.2020 01:21, Kevin Rushforth wrote:
>>>>>>>>>> I see that you updated the PR and sent it for review.
>>>>>>>>>>
>>>>>>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful
>>>>>>>>>> feature, and if so, what form this feature should take.
>>>>>>>>>>
>>>>>>>>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit
>>>>>>>>>> from it?
>>>>>>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code
>>>>>>>>> may
>>>>>>>>> benefit.
>>>>>>>>>
>>>>>>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the
>>>>>>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit
>>>>>>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause
>>>>>>>>> the reparsing of that script's source and interpreting it on each invocation, which may be
>>>>>>>>> expensive
>>>>>>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the
>>>>>>>>> compiled
>>>>>>>>> script by the script engine.
>>>>>>>>>
>>>>>>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in
>>>>>>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons?
>>>>>>>>> In principle there are three possibilities:
>>>>>>>>>
>>>>>>>>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the
>>>>>>>>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and
>>>>>>>>> ???? execute the compiled script each time its registered event fires.
>>>>>>>>>
>>>>>>>>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts
>>>>>>>>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail
>>>>>>>>> ???????? compiling but have been employed successfully in interpreted mode
>>>>>>>>>
>>>>>>>>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML
>>>>>>>>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script
>>>>>>>>> ???? engine implements the javax.script.Compilable interface. If missing it would default to
>>>>>>>>> "false".
>>>>>>>>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the
>>>>>>>>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the
>>>>>>>>> ???? "language" PI was not.)
>>>>>>>>>
>>>>>>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the
>>>>>>>>> language
>>>>>>>>> ???????? PI gets changed
>>>>>>>>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts
>>>>>>>>>
>>>>>>>>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script
>>>>>>>>> and
>>>>>>>>> ???? node elements and only compile the scripts, if the property is set to true
>>>>>>>>>
>>>>>>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed
>>>>>>>>> ???????? accordingly
>>>>>>>>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that
>>>>>>>>> host scripts
>>>>>>>>>
>>>>>>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be
>>>>>>>>> overruled individually by 3.
>>>>>>>>>
>>>>>>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that
>>>>>>>>> compilation
>>>>>>>>> of scripts by the script engines would find the same errors as while interpreting the very same
>>>>>>>>> scripts (if not, the script engine is badly broken and it could be argued that then the
>>>>>>>>> interpretation part of the script engine might be expected to be broken as well which would be
>>>>>>>>> quite
>>>>>>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the
>>>>>>>>> compiled script would behave differently to interpreting the very same script by the same script
>>>>>>>>> engine).
>>>>>>>>>
>>>>>>>>> The current WIP implements 1 above and includes an appropriate test unit.
>>>>>>>>>
>>>>>>>>>> What do others think?
>>>>>>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the
>>>>>>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine,
>>>>>>>>>> but we would need to ensure that.
>>>>>>>>> The compilation of scripts needs to be done by the Java script engines (implementing both,
>>>>>>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled
>>>>>>>>> scripts ([javax.script.CompiledScript]
>>>>>>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---rony
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>>>>>>>>>>> After merging master, applying some fixes and changing the title to reflect the change from
>>>>>>>>>>> WIP to a
>>>>>>>>>>> pull request I would kindly request a review of this pull request!
>>>>>>>>>>>
>>>>>>>>>>> Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: "8238080:
>>>>>>>>>>> FXMLLoader: if
>>>>>>>>>>> script engines implement javax.script.Compilable compile scripts".
>>>>>>>>>>>
>>>>>>>>>>> ---rony
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote:
>>>>>>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in
>>>>>>>>>>>> review, and
>>>>>>>>>>>> has an appropriate test unit going with it as well, please review.
>>>>>>>>>>>>
>>>>>>>>>>>> There should be no compatibility issue with this implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new
>>>>>>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML
>>>>>>>>>>>> files.
>>>>>>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts
>>>>>>>>>>>> if the
>>>>>>>>>>>> language process instruction (e.g. <?language rexx?>) contains an appropriate attribute with a
>>>>>>>>>>>> value
>>>>>>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML
>>>>>>>>>>>> with
>>>>>>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up
>>>>>>>>>>>> with a
>>>>>>>>>>>> respective solution as well.
>>>>>>>>>>>>
>>>>>>>>>>>> ---rony
>>>>>>>>>>>>
>>>>>>>>>>>> [1] "Implementation and test unit": <https://github.com/openjdk/jfx/pull/129>
>>>>>>>>>>>>
>>>>>>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile
>>>>>>>>>>>> scripts":
>>>>>>>>>>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>>>>>>>>>>
>>>>>>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
>>>>>>>>>>>> <https://github.com/openjdk/jfx/pull/122/commits>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this
>>>>>>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to
>>>>>>>>>>>>> illustrate
>>>>>>>>>>>>> the concept).
>>>>>>>>>>>>>
>>>>>>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility
>>>>>>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Kevin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>>>> Just filed a RFE with the following information:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ???? * Component:
>>>>>>>>>>>>>> ???????? o JavaFX
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ???? * Subcomponent:
>>>>>>>>>>>>>> ???????? o fxml: JavaFX FXML
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ???? * Synopsis:
>>>>>>>>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ???? * Descriptions:
>>>>>>>>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages
>>>>>>>>>>>>>> (javax.script.ScriptEngine
>>>>>>>>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller
>>>>>>>>>>>>>> language in
>>>>>>>>>>>>>> ?????????? the FXML file.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such
>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> ?????????? its eval() methods.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script
>>>>>>>>>>>>>> invocations,
>>>>>>>>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>>>>>>>>>> onMouseMove)
>>>>>>>>>>>>>> ?????????? which may be repetitevly invoked and evaluated."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ???? * System /OS/Java Runtime Information:
>>>>>>>>>>>>>> ???????? o "All systems."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Received the internal review ID: "9063426"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---rony


From github.com+60214806+ronyfla at openjdk.java.net  Tue May 12 17:35:20 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Tue, 12 May 2020 17:35:20 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <yoeN3D9ZI-tobgB3snqlJTbdRbmA1ze54ALQpIBzxNk=.72ec4797-e1f4-450a-a8d4-b93ddbe6387b@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
 <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>
 <JSIFzcCtP1mEAa4UFaZxPyNKxF_ks27fFkHoaSIkM9c=.5d8c29cf-a921-4bf2-a9dd-52004b8e5218@github.com>
 <yoeN3D9ZI-tobgB3snqlJTbdRbmA1ze54ALQpIBzxNk=.72ec4797-e1f4-450a-a8d4-b93ddbe6387b@github.com>
Message-ID: <oZiAmdeG3bPl7oCiYOrN3Xt9-wgXV60otnPb0iWxNUM=.5f55f234-3c05-4c78-ae51-d0e1f2f5895e@github.com>

On Tue, 12 May 2020 16:51:08 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

>> I think the approach proposed in this PR is the best solution for this enhancement. Go ahead and remove the `WIP` from
>> the title, and we can proceed with the review.
>> The interface and behavior change will need to be specified in the API docs. This can be done by modifying the
>> [Introduction to
>> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
>> document. I recommend documenting the new behavior and `<?compile>` attribute somewhere in the
>> [Scripting](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html#L769)
>> section.  As discussed on the mailing list, this will need a CSR, which should include the changes to the docs.
>
> Suggested CSR:
> 
> Summary
> =======
> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
> implements the javax.script.Compilable interface to speed up execution. In case compilation
> throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
> control of script compilation with a "compile" PI for FXML files.
> 
> Problem
> =======
> javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
> (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
> 
> If a script engine implements the javax.script.Compilable interface, then such scripts could be
> compiled and the resulting javax.script.CompiledScript could be executed instead using its
> eval() methods.
> 
> Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
> invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
> onMouseMove) which may be repetitively invoked and evaluated.
> 
> Solution
> ========
> Before evaluating the script code test whether the javax.script.ScriptEngine implements
> javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
> and then use its eval() method to evaluate the script, otherwise continue to use the
> javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
> (unexpectedly) a javax.script.ScriptException then fall back to using the
> javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
> the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
> files.
> 
> Specification
> =============
> If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
> compile() method to compile the script to a javax.script.CompiledScript object and use its
> eval() method to run the script. In the case that the compilation throws (unexpectedly) a
> javax.script.ScriptException log a warning and fall back to using the
> javax.script.ScriptEngine's eval() method instead.
> To allow setting this feature off and on while processing the FXML file a "compile" process
> instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
> compilation off and on throughout a FXML file.

Doc addition for the CSR:
=================
The following text was added to the [Introduction to
FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
at two locations, the "Script Event Handlers" ("#script_event_handlers") and the "Scripting" (#scripting") sections:

> <p>Hint: to turn off automatic compilation of script code place the processing instruction <span
> class="code">&lt;?compile false?&gt;</span> before the script. To turn on compilation of script code again use the
> processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
> of script code off and on.</p>

This documents the compile processing instruction, that it compilation is on by default and that it can be turned off
and on repeatedly. It is hoped that this formulation plays well with the context where this paragraph got introduced.

-------------

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

From jhendrikx at openjdk.java.net  Tue May 12 17:49:36 2020
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Tue, 12 May 2020 17:49:36 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <QqSN4jRyt7uhADiM6eH4FhoW3z9HhihnfoA9xS9MXTo=.b960f8f5-23d2-4a6a-bce2-04cf6774fbc3@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <QZ0E_MGhzgEniRfDuSbWlNrE3q3tyKFs_uYEYZQD4yg=.f18a7e31-d6c7-4f49-97a9-1ce45d91d340@github.com>
 <iZ_VKNDGhAubihs6UADT1FIt2uiCtvyhMZ2CamQ9O_Q=.5cebb3e4-7f01-442d-8df5-131eda2e88ca@github.com>
 <CrlqE2AOM48IdHVVJi4YKpWjOPRDQMPwHUATqfFICOo=.77648651-e422-4c07-b2f7-967ca0175a0a@github.com>
 <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
 <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
 <QqSN4jRyt7uhADiM6eH4FhoW3z9HhihnfoA9xS9MXTo=.b960f8f5-23d2-4a6a-bce2-04cf6774fbc3@github.com>
Message-ID: <8jwWssE3dyUHaKMjRA0srzp8Q8Hdjuiu4yo4JcnH7bA=.7cb9ad32-f37a-40b9-b745-1a7ef361df62@github.com>

On Tue, 12 May 2020 15:56:32 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> The fix looks correct and the tests pass. I just wonder why the change to reflection-based construction with
> `bindingMockClassConstructor`?

The Parameterized test constructs some standard Binding objects to run multiple tests with.  This works fine if those
objects are immutable (or aren't modified during the tests).  My new test however does modify them, and other tests
would fail with such modified objects (as `unbind` was called on some).  So I rewrote this a little bit to construct
fresh objects for each test, and for that I used some reflection magic to avoid having to write a specific test for
each of the 8 binding types.

-------------

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

From jhendrikx at openjdk.java.net  Tue May 12 18:00:22 2020
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Tue, 12 May 2020 18:00:22 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <QZ0E_MGhzgEniRfDuSbWlNrE3q3tyKFs_uYEYZQD4yg=.f18a7e31-d6c7-4f49-97a9-1ce45d91d340@github.com>
 <iZ_VKNDGhAubihs6UADT1FIt2uiCtvyhMZ2CamQ9O_Q=.5cebb3e4-7f01-442d-8df5-131eda2e88ca@github.com>
 <CrlqE2AOM48IdHVVJi4YKpWjOPRDQMPwHUATqfFICOo=.77648651-e422-4c07-b2f7-967ca0175a0a@github.com>
 <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
 <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
Message-ID: <KzSfiCjfavbfvs-eGcaHt6RYJnPqxAqXRHGjSb8tuVg=.d4539e42-90b7-409a-ba9c-1e0c526378ec@github.com>

On Mon, 11 May 2020 22:27:27 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> As I started my review I noticed that `unbind` does not null-check its argument `dependencies` like `bind` does and it
> can lead to NPEs. If it is out of scope for this PR to fix this, a new issue should be filed.

I'm fine with doing a fix, but I need to know which one.  Avoiding NPE's and silently doing nothing is IMHO not very
desirable as this will give the user of the API no feedback that something went wrong.

So I would prefer to fix this by documenting that these cases will result in a NPE.

The `bind` method has a similar issue -- it doesn't check its array elements for `null`, and will throw a NPE when
attempting to add a listener to `null`.  Again, I would just document the NPE so what is clearly a mistake doesn't go
unnoticed.

-------------

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

From jhendrikx at openjdk.java.net  Tue May 12 18:02:59 2020
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Tue, 12 May 2020 18:02:59 GMT
Subject: [Rev 03] RFR: 8242548: Wrapped labeled controls using
 -fx-line-spacing cut text off
In-Reply-To: <363XKZnSJ4lc3Rj_JRp1iV2jRrUobC7GncecmPtM3XY=.ce85e18a-e92b-41da-b525-5d1cca6106ad@github.com>
References: <fITqSHYVPaCgMLBQjDJyU4Spp31LMRrxRdF8sD-JJec=.b60e407c-0d0b-4d84-bba5-f00711bac67d@github.com>
 <hHIeTvdz3LP2jHSfnUX3b_NB3xEcUXB9nat0g94wNwk=.49c40cb3-9d8f-4daa-a35a-fc7abf9a49e1@github.com>
 <S0R0eIoNBJ5aWYURVS7dARmGiLQLJ7lQ3d99ypcDMlM=.ed6fb023-ad68-4bfd-89c1-3fe68330aa3f@github.com>
 <363XKZnSJ4lc3Rj_JRp1iV2jRrUobC7GncecmPtM3XY=.ce85e18a-e92b-41da-b525-5d1cca6106ad@github.com>
Message-ID: <z-9V77O3Hhncn12LySUkEyJUncOEeIfhtOBZTjjiH7k=.607b2f8b-d5c2-42d5-9ca3-444709aea941@github.com>

On Tue, 12 May 2020 13:44:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Marked as reviewed by kcr (Lead).
>
> @hjohn, this PR is ready to be merged.
> You need to comment /integrate on this PR as instructed by the bot above. I will sponsor it once you do it.

Sorry I figured only a committer was allowed to use that command.

-------------

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

From nlisker at openjdk.java.net  Tue May 12 22:43:22 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 12 May 2020 22:43:22 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <KzSfiCjfavbfvs-eGcaHt6RYJnPqxAqXRHGjSb8tuVg=.d4539e42-90b7-409a-ba9c-1e0c526378ec@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <QZ0E_MGhzgEniRfDuSbWlNrE3q3tyKFs_uYEYZQD4yg=.f18a7e31-d6c7-4f49-97a9-1ce45d91d340@github.com>
 <iZ_VKNDGhAubihs6UADT1FIt2uiCtvyhMZ2CamQ9O_Q=.5cebb3e4-7f01-442d-8df5-131eda2e88ca@github.com>
 <CrlqE2AOM48IdHVVJi4YKpWjOPRDQMPwHUATqfFICOo=.77648651-e422-4c07-b2f7-967ca0175a0a@github.com>
 <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
 <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
 <KzSfiCjfavbfvs-eGcaHt6RYJnPqxAqXRHGjSb8tuVg=.d4539e42-90b7-409a-ba9c-1e0c526378ec@github.com>
Message-ID: <jCBB3wQ-xQD0WLrlPaWBMhwZCI9j9v8nKCXN7AYmfpA=.461d6d60-3957-4c64-8e50-1e6aaf333766@github.com>

On Tue, 12 May 2020 17:58:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I'm fine with doing a fix, but I need to know which one. Avoiding NPE's and silently doing nothing is IMHO not very
> desirable as this will give the user of the API no feedback that something went wrong.
> So I would prefer to fix this by documenting that these cases will result in a NPE.
> 
> The `bind` method has a similar issue -- it doesn't check its array elements for `null`, and will throw a NPE when
> attempting to add a listener to `null`. Again, I would just document the NPE so what is clearly a mistake doesn't go
> unnoticed.

I think that checking the array elements doesn't help much because by the time you can check them they will already be
used, and that will throw an NPE implicitly.

`bind` is no-op for `null` or 0-length arrays, but should have probably throw an NPE on the `null` case. The 0-length
check saves creating the `observer`, so I think it makes sense. `unbind` should probably only throw an NPE on `null`
arrays, but that happens implicitly anyway, so maybe there is no change needed unless it's for clarity because we can
add a custom error message.

-------------

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

From tschindl at openjdk.java.net  Tue May 12 22:48:20 2020
From: tschindl at openjdk.java.net (Tom Schindl)
Date: Tue, 12 May 2020 22:48:20 GMT
Subject: [Integrated] RFR: 8202296: Monocle MouseInput doesn't send
 keyboard modifiers in events.
In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com>
References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com>
Message-ID: <rkemK43nZuMy51lRzct6QPAX1_SewwCoBL-6Fua02fs=.da4661a2-af77-4219-bbad-bc6c86dc9f70@github.com>

On Fri, 10 Apr 2020 10:26:06 GMT, Tom Schindl <tschindl at openjdk.org> wrote:

> Extract keystate and add to the existing modifier mask, to support eg
> multi-select
> 
> https://bugs.openjdk.java.net/browse/JDK-8202296

This pull request has now been integrated.

Changeset: 435671ee
Author:    Tom Schindl <tschindl at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/435671ee
Stats:     74 lines in 2 files changed: 0 ins; 68 del; 6 mod

8202296: Monocle MouseInput doesn't send keyboard modifiers in events.

Reviewed-by: kcr

-------------

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

From john.scancella at gmail.com  Wed May 13 00:05:12 2020
From: john.scancella at gmail.com (John Scancella)
Date: Tue, 12 May 2020 20:05:12 -0400
Subject: TableView help
Message-ID: <CA+D2WM+CYSahysm-idbFdYiNm9TibhX0QAfJJXciA8Y1h2ecMQ@mail.gmail.com>

Hello All,

I am hoping to get some help with setting up a TableView. What I want is a
simple two column table with each column containing Strings. I want to be
able to double click to create a new row if I double clicked on empty
space. And I want to be able to edit any cell already in the table.

Currently I am struggling with editing the data already in the table. I can
click and edit, but then if I double click again on the cell it reverts
back to the original value. If I try and get the value programmatically, it
is still getting the original value, even though the display is showing the
new value.

You can see my code here: https://github.com/jscancella/heirloom
I am using java version "1.8.0_251"

Thank you in advance for any help!


-- 
~John Scancella

From nlisker at openjdk.java.net  Wed May 13 00:19:28 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 13 May 2020 00:19:28 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
Message-ID: <xixE99cLh2FPjM1c04I9Iht0H26V_HAXQtE4iO0cGr4=.c638d5a9-09af-4ecb-a828-fbb858f9b75b@github.com>

On Tue, 5 May 2020 11:19:55 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java line 46:
> 
>> 45:  */
>> 46: public abstract class ClipEnvelope {
>> 47:
> 
> I think the removal of line 46 was unintended change.

I think that there is no empty line between the docs and the declaration, but can revert.

-------------

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

From nlisker at openjdk.java.net  Wed May 13 00:25:36 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 13 May 2020 00:25:36 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
Message-ID: <q9iPCEOARjLA2IhbtskmxmDOnBHEFLoJwoP5C9e9M30=.c0ff53cc-bb0c-4dcc-a265-d66950a7cf14@github.com>

On Wed, 6 May 2020 14:18:06 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 142:
> 
>> 141:     }
>> 142:
>> 143:     /*
> 
> Both these methods seem like they belong to Utils.java. If moved to Utils.java then the all the calls
> `(Math.abs(currentRate - rate) < EPSILON)` can be changed to use these methods from Utils.java. If we move these
> methods then, Utils.java also needs to declare  `static final double EPSILON = 1e-12;`  and the EPSILON here can be
> initialized as `private static final double EPSILON = Utils.EPSILON;`

I agree that these methods are better suited there, but I'm not sure the same epsilon value will be suitable for other
places that will want to use these. That value is somewhat arbitrary anyway I think.

-------------

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

From nlisker at openjdk.java.net  Wed May 13 00:31:08 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 13 May 2020 00:31:08 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
Message-ID: <_3i3vAA9CM9zyv37iWmCl_xybwQvnQY8hChll8gyo7U=.2f3c3638-258e-4c52-8d37-87340f3b417a@github.com>

On Mon, 11 May 2020 04:30:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java line 59:
> 
>> 58:         return Math.round((ticks - deltaTicks) * Math.abs(newRate / rate));
>> 59:      }
>> 60:
> 
> This is similar to `ClipEnvelope.ticksRateChange()` with a minor difference. Can this be removed from here and
> `ClipEnvelope.ticksRateChange()` be reused ?

I think that in the next patches there will be another change here anyway that will make this more sensible. I just
tried to split the final patch into more manageable chunks so some changes need future vision.

-------------

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

From nlisker at openjdk.java.net  Wed May 13 00:40:14 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 13 May 2020 00:40:14 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
Message-ID: <B1lQkBujWgRTSJ84UgbmzGWQ3igj80xpEjWYEpovWXE=.1aa6a3b7-1294-4286-9b61-a3eebcb6687a@github.com>

On Tue, 5 May 2020 05:47:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java line 48:
> 
>> 47:
>> 48:     protected boolean autoReverse() {
>> 49:         return autoReverse;
> 
> I would suggest the name to be `isAutoReverese`

That would be the usual naming convention, yes, but I find that  this can be more fluent to read. Perhaps I'm
influenced by the upcoming `record`s feature. Can change.

-------------

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

From jhendrikx at openjdk.java.net  Wed May 13 04:29:56 2020
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Wed, 13 May 2020 04:29:56 GMT
Subject: [Integrated] RFR: 8242548: Wrapped labeled controls using
 -fx-line-spacing cut text off
In-Reply-To: <fITqSHYVPaCgMLBQjDJyU4Spp31LMRrxRdF8sD-JJec=.b60e407c-0d0b-4d84-bba5-f00711bac67d@github.com>
References: <fITqSHYVPaCgMLBQjDJyU4Spp31LMRrxRdF8sD-JJec=.b60e407c-0d0b-4d84-bba5-f00711bac67d@github.com>
Message-ID: <q0ttjeXlwsjPKAdnWXnYrlLTJKfzA1d7pTKhsEi57kU=.02d24abd-4289-4f70-b48c-73864eaf3c4c@github.com>

On Sun, 12 Apr 2020 21:21:07 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This is a solution for 8242548.  There was zero test coverage, so I added a few tests for this as well.

This pull request has now been integrated.

Changeset: 7b061900
Author:    John Hendrikx <jhendrikx at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/7b061900
Stats:     53 lines in 4 files changed: 0 ins; 48 del; 5 mod

8242548: Wrapped labeled controls using -fx-line-spacing cut text off

Reviewed-by: aghaisas, kcr

-------------

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

From jfxuser2 at gmail.com  Wed May 13 08:12:52 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Wed, 13 May 2020 04:12:52 -0400
Subject: com.sun.javafx vs javafx (with example/request)
In-Reply-To: <a054de37-758f-4789-7f9b-a0e3cd88b59a@jugs.org>
References: <5EB5B555.5020808@oracle.com>
 <E557FD89-F397-486C-9072-4E694EB6B242@gmail.com>
 <ab8990d0-17b2-7421-488d-7e2284fca20b@jugs.org>
 <CAHifg5f4_AV7tj-eZCXOhfK1mDy2yeadBO3Zj30TNFSZmNJz4w@mail.gmail.com>
 <a054de37-758f-4789-7f9b-a0e3cd88b59a@jugs.org>
Message-ID: <CAHifg5fv_F4qdL6Mp0+HwVdGmnEyFCS7KmJVGTzZpWmiXLO5jA@mail.gmail.com>

Turns out that I partially misunderstood the use of Path2D in
GraphicsContext.  I had been using appendSVGPath for nearly everything and
within a single beginPath/closePath.  Under those circumstances
 converting GraphicsContext.path from Path2D to Path (using code from
Shape.createFromGeomShape(Path2D p)) gives you a relatively simple path
that can be used as a simplified version of what is rendered in the
Canvas.  It can be used as a very "degraded" version of what was placed in
the canvas and is way faster than other solutions.

However, it would only apply to the last beginPath/closePath and it does
not include any of the other path methods in GraphicsContext.  Path IS used
by those methods but is empty after a call to e.g. fillRect.  That's
unfortunate... If path did retain everything, I'd continue to push for a
"getPath" method on GraphicsContext.  I'll have to stick with my current
implementations.

As for the performance of Canvas vs. the Scene, I'm also speaking from
experience.  But I'm referring to highly dynamic applications.  If you have
an app with lots of objects (and lots dynamic behavior such as motion of
all types, animation, and color) Canvas will be many times more performant
than the Scene graph.  I think Gerrit Grunwald's TileFX is a good example
(more complex usage of Canvas than most but still not even close to the
level of dynamic behavior that I'm referring to).

On Fri, May 8, 2020 at 7:13 PM Michael Paus <mp at jugs.org> wrote:

> I think I know quite a bit about JavaFX graphics and I do not generally
> agree with your statements.
> Especially the statement that the Canvas is so much superior is a myth
> from the old days of Java 8
> where there were a few performance bugs in the scene graph handling. But
> that's a long time ago.
> (I even gave a workshop on this at the JavaLand conference some time ago.)
> Maybe you could present
> a few more details about your use-case and not so much about the technique
> that you think is the
> best fit for it. Maybe even some demo code somewhere. I am always
> interested in a discussion about
> graphics as long as it is supported by facts. Neither the scene graph nor
> the canvas is a silver bullet.
> It always depends on your use-case.
> Michael
>
> Am 09.05.20 um 00:18 schrieb jfx user2:
>
> From the JavaDoc "Canvas is an image that can be drawn on using a set of
> graphics commands provided by a GraphicsContext."  This a bit of a
> misnomer.  While canvas can be used to draw in image (actually
> GraphicsContext not canvas itself), the image based methods of
> GraphicsContext are far outweighed by the "vector" or path based methods.
> The GraphicsContext gives you the ability to freely create dynamic graphics
> without the constraints of the Scene Graph.  It can be highly performant
> and scalable if done properly.  The Scene Graph will not perform like the
> GraphicsContext.  If you haven't worked with highly dynamic graphics, you
> might not have encountered any issues.  The Scene Graph works ok up to a
> certain number of objects and it is not good at adding and removing objects
> often.  GraphicsContext does not have the same restrictions.  It can
> involve more work but the end result will scale far beyond what you can do
> in a Scene Graph... I think this is already widely accepted.
>
> The proposed method on the GraphicsContext simply returns what is already
> there.  It would convert the already stored Path2D to a Path.  Why reinvent
> what is already present and only private?  This in turn CAN be used in the
> Scene Graph but it can also be used as a container to draw back onto the
> GraphicsContext.  You see,  a Path that is calculated once and then used
> repeatedly to draw in the GraphicsContext (possibly even transformed) is
> better than sub-optimally calculating that Path on every pass through the
> GraphicsContext or storing it as an image or Shape (those were some of my
> workarounds).
>
> Anyway, I'm requesting that a private API be used to create a new public
> method.  This is really no different than existing public methods that use
> private APIs.  I'm not asking to expose private APIs (not in this request
> :o).  There isn't even much code.  It's reusing what's already there.
>
> Ask Gerrit Grunwald about his experience with the Scene Graph vs
> Canvas/GraphicsContext.
>
>
> On Fri, May 8, 2020 at 4:27 PM Michael Paus <mp at jugs.org> wrote:
>
>> Hi,
>> I have to say that your requirements sound a little bit strange to me,
>> but maybe you can make it clearer what your real use-case behind them is.
>> What I do not understand is why you are using the canvas at all.
>> Conceptually the canvas is for direct mode rendering into an image. The
>> fact that
>> this is handled a little bit different internally is an implementation
>> detail, you should not rely on. Why don't you use the scene graph which
>> seems
>> to provide many of the aspects that you need? I admit that there are a
>> few hidden gems internally that I would also like to be made public
>> (e.g. the flattening path iterator) but I definitely see these things
>> more in the scene graph context but not for Canvas.
>> Just my two ?ent.
>> Michael
>>
>> Am 08.05.20 um 22:08 schrieb jfx user2:
>> > No... given a Shape, create a Path that represents the outline of that
>> shape.  If I had a Path I wouldn?t be requesting the new methods.
>> >
>> > One of the workarounds for getting a Path from a GraphicsContext is to
>> keep track of it as I?m drawing... however, this is overhead in the gc call
>> that can become very expensive when you have a lot of gcs or if your gc is
>> doing a lot of work.  The path is already there in Path2D along with a
>> method to convert it to a public Path.  There?s no need for an expensive
>> custom workaround.  All that?s required is a method on the GraphicsContext
>> that returns a Path.  The same is true for getting a Path from a Shape.
>> >
>> > Please note that this behavior is desirable for highly optimized use of
>> GraphicsContext and Shapes where you need ?outlines? of things in vector
>> format.  The private api is unnecessarily hiding this information.
>> >
>> >> On May 8, 2020, at 3:38 PM, Philip Race <philip.race at oracle.com>
>> wrote:
>> >>
>> >> ?The current path is defined by the application - you - and yet you
>> don't know what it is  ?
>> >> You do say
>> >>> I have other workarounds where I have to maintain a path as I?m
>> drawing in the canvas
>> >> Why can't you do that ? No internal API digging.
>> >>
>> >> -phil
>> >>
>> >>> On 5/8/20, 12:02 PM, jfx user2 wrote:
>> >>> Ok, then please consider the GraphicsContext request that I?ve made.
>> It simply enables you to get the Path from the context without exposing com
>> classes at all.  I have other workarounds where I have to maintain a path
>> as I?m drawing in the canvas or I have to do hit testing on a non vector
>> image to determine the path but these are way more expensive than simply
>> creating a Path object from the Path2D that is already in the
>> GraphicContext.  That path can be used in drag and drop scenarios, fast
>> secondary rendering under heavy gc use, edge tracing, and the list goes on.
>> >>>
>> >>> The same is true for the Shape class.  I?d like to request that the
>> following be added to Shape:
>> >>> public Path getPath() {
>> >>>      return Shape.createFromGeomShape(getTransformedArea());
>> >>> }
>> >>>
>> >>> That?s it.  The underlying methods are there but the public api
>> doesn?t expose them.  This gives you a vector outline of the Shape as
>> Path.l on demand, not stored.
>> >>>
>> >>> There are expensive workarounds for performing these tasks and I
>> spent a long time trying... until I discovers the private apis already had
>> the capability but simply did. It expose it.
>> >>>
>> >>> I?d these are not supported, I?ll have to stick with reflection,
>> bytebuddy, or forking - non of which will be easily maintained or portable.
>> >>>
>> >>> Ps I will post additional concerns over time.  The next one likely
>> has to do with the mismatch between javafx canvas (gc) and other canvases
>> such as svg, html2.  I think there is private api that would help in this
>> case.
>> >>>
>> >>>>> On May 8, 2020, at 2:41 PM, Kevin Rushforth<
>> kevin.rushforth at oracle.com>  wrote:
>> >>>> ?Since Canvas is an immediate mode graphics API, I presume you are
>> interested in the most recent drawing primitive? (we don't keep the
>> composite shape for all drawing primitives -- that would be both too
>> expensive and not really appropriate). How would you expect current
>> rendering attributes (e.g., transforms) to affect the results? These are
>> all questions that need to be addressed.
>> >>>>
>> >>>> As for the bigger picture, we intentionally have a separate render
>> graph with "peers" for each node, although some of the duplication of
>> classes is historical (we used to have a looser decoupling before Prism
>> became the only backend). Unless there is a compelling need, we are
>> unlikely to consider changing this in the general case, but perhaps could
>> look at specific cases if it made sense. This is a separate issue, though,
>> from public API and the two shouldn't be conflated.
>> >>>>
>> >>>> Btw, JavaFX has been fully open-sourced since 2013, although the
>> design of Prism predates that.
>> >>>>
>> >>>> -- Kevin
>> >>>>
>> >>>>
>> >>>>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>> >>>>> Kevin, go easy please :0).  There is a need.
>> >>>>>
>> >>>>> Access to the outline of the path in the canvas is great for edge
>> following, node attachment points, animating around the non-rectangular
>> border of what?s actually displayed, etc.
>> >>>>>
>> >>>>> The other request that I haven?t posted yet is to do the same for
>> Shape.   I?ve tested both of these enhancements and it works as desired.
>> I?ll post the second request soon.
>> >>>>>
>> >>>>> But back to the bigger picture.  The requests that I?m making are
>> only additions to return a path from javafx not com.  But there are other
>> cases where geometry and convenience methods in com would be beneficial to
>> the public api.  It also seems odd that there are two layers to begin
>> with...  parallel apis often result in too much object creation or cpu
>> overhead translating between them.  I?ll be more specific about these cases
>> over time.   Part of my intention is to spark a discussion about the design
>> since previously this was relatively closed source.
>> >>>>>
>> >>>>>>> On May 8, 2020, at 1:12 PM, Kevin Rushforth<
>> kevin.rushforth at oracle.com>  wrote:
>> >>>>>> ?While there is no plan to "open up" more of com.sun.javafx (and
>> that isn't really the right way to look at it), if you have a proposed
>> enhancement to the existing public javafx.* classes we could discuss it.
>> >>>>>>
>> >>>>>> As for your specific example, can you say more about what your use
>> case is? The GraphicsContext object is a drawing context for a Canvas node,
>> so it is not a natural place to put an API that computes or returns a path.
>> I get the sense that you are looking at the existing internal
>> implementation classes and saying "how can I get access to some information
>> that might be useful to my application" rather than describing what your
>> application is trying to do. Once we understand what you are trying to do,
>> we can discuss whether the need is general enough to propose adding to the
>> public API of JavaFX and what form such a new API might take.
>> >>>>>>
>> >>>>>> -- Kevin
>> >>>>>>
>> >>>>>>
>> >>>>>>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>> >>>>>>> I am aware of this and that?s why I am asking.  There are useful
>> private features in com.sun.javafx and I explained one of them in my
>> message.  I have an additional related example but the larger question is
>> if there is a plan to open more of com.sun.javafx to the public api,
>> documentation surrounding this, or possibly a complete replacement?
>> >>>>>>>
>> >>>>>>> Please consider the example I provided as a feature request.
>> >>>>>>>
>> >>>>>>>>> On May 8, 2020, at 9:39 AM, Kevin Rushforth<
>> kevin.rushforth at oracle.com>  wrote:
>> >>>>>>>> ?Only javafx.* packages are part of the public API. Anything
>> else, including com.sun.javafx.*, is internal implementation details that
>> an application should never call.
>> >>>>>>>>
>> >>>>>>>> -- Kevin
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>> >>>>>>>>> Is there documentation around the packages (com.sun.javafx vs
>> javafx) used
>> >>>>>>>>> in JavaFX?
>> >>>>>>>>>
>> >>>>>>>>> For example, why is there a com.sun.javafx.geom that isn't
>> fully mirrored
>> >>>>>>>>> in the javafx.scene.shape package?  Why are there missing
>> features from
>> >>>>>>>>> Graphics2D?
>> >>>>>>>>>
>> >>>>>>>>> I have a specific example that prompted the question:
>> >>>>>>>>>
>> >>>>>>>>> Consider the following classes:
>> >>>>>>>>>
>> >>>>>>>>> javafx.scene.shape.Shape
>> >>>>>>>>>      private static Path
>> >>>>>>>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>> >>>>>>>>>
>> >>>>>>>>> javafx.scene.canvas.GraphicsContext
>> >>>>>>>>>      Path2D path;
>> >>>>>>>>>
>> >>>>>>>>> I want to write a line as follows:
>> >>>>>>>>> Path path = Path.createFromGeomShape(gc.path);
>> >>>>>>>>> b/c I want to inexpensively get the outline of the
>> GraphicsContext.
>> >>>>>>>>>
>> >>>>>>>>> However:
>> >>>>>>>>> We can't access Path2D b/c it's in com.sun.javafx.geom which
>> isn't exported
>> >>>>>>>>> by the module.
>> >>>>>>>>> We can't access Path.createFromGeomShape b/c it's private.
>> >>>>>>>>> We can't access path in GraphicsContext b/c it's default and
>> doesn't have
>> >>>>>>>>> an accessor.
>> >>>>>>>>>
>> >>>>>>>>> A possible solution is to add a new method:
>> >>>>>>>>> javafx.scene.canvas.GraphicsContext
>> >>>>>>>>> public Path getPath() {
>> >>>>>>>>>      //implementation copied from
>> >>>>>>>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as
>> the path
>> >>>>>>>>> }
>> >>>>>>>>>
>> >>>>>>>>> That would solve my immediate problem but raises the
>> question... why is
>> >>>>>>>>> com.sun.javafx hidden?  What's the architectural reason?  Is
>> there any work
>> >>>>>>>>> in progress that will impact this design?
>> >>>>>>>>>
>> >>>>>>>>> PS my example is actually very important.  I currently use
>> reflection and
>> >>>>>>>>> module opens in the build to get the path but if the getPath
>> method could
>> >>>>>>>>> be added to GraphicsContext, that would be great.  For
>> performance, it
>> >>>>>>>>> would be even better to get the PathIterator directly instead of
>> >>>>>>>>> translating into a javafx..Path but that is related to the
>> bigger question.
>>
>>
>>
>

From jfxuser2 at gmail.com  Wed May 13 08:15:41 2020
From: jfxuser2 at gmail.com (jfx user2)
Date: Wed, 13 May 2020 04:15:41 -0400
Subject: HID multitouch display support in JavaFX
In-Reply-To: <CAHifg5f7S8uWcj3w+SabM-FkAD_iuaMOPpa55pQUGFnvoiUXSA@mail.gmail.com>
References: <CAHifg5f7S8uWcj3w+SabM-FkAD_iuaMOPpa55pQUGFnvoiUXSA@mail.gmail.com>
Message-ID: <CAHifg5eUJGdZTjCdk+mVY6x6eHQR2__24SM9-xkKSf1j6uJ36A@mail.gmail.com>

Nobody is biting... so is anyone else out there interested in using HID
touchscreens with JavaFX on OSX (or any other plaform) without using a
third party driver?

On Fri, May 8, 2020 at 4:18 AM jfx user2 <jfxuser2 at gmail.com> wrote:

> Multitouch display support JavaFX on Windows, iOS, and Android seems
> straightforward.  If the OS recognizes the display as multitouch, then the
> chances are that JavaFX will also work with it since it relies on the
> native multitouch support of the OS.
>
> When it comes to Linux and OSX, it's not always as easy.  Linux sometimes
> requires device mapping.  I'm not sure if it works at all in OSX unless you
> have specific drivers for the display.
>
> All of the platforms seem to support HID so maybe JavaFX could have direct
> support for HID devices (optionally) if they are present instead of just
> the current method.  It may also improve performance in cases where the OS
> is just piping HID events through their own API's to support multitouch.
> Why not just go straight to the HID source and bypass that conduit.
>
> This would vastly improve multitouch app development on OSX.  It would be
> possible to connect a HID display and use it for testing apps that are
> destined for platforms that formally support multitouch.
>
> Is there any work being done in this area?  Is there a bigger picture
> (e.g. better multi-display and connect/disconnect support in JavaFX)?
>
> ... coming from a frustrated OSX user with lots of HID displays and no
> easy JavaFX support.
>
> https://www.usb.org/hid
>

From dlemmermann at gmail.com  Wed May 13 08:30:03 2020
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 13 May 2020 10:30:03 +0200
Subject: TableView help
In-Reply-To: <CA+D2WM+CYSahysm-idbFdYiNm9TibhX0QAfJJXciA8Y1h2ecMQ@mail.gmail.com>
References: <CA+D2WM+CYSahysm-idbFdYiNm9TibhX0QAfJJXciA8Y1h2ecMQ@mail.gmail.com>
Message-ID: <E04D523E-B87E-4897-B1D3-B19BA7B3AF80@gmail.com>

Hi John,

the model class used by your TableView is called ?SimpleImmutableEntry?. The middle part of this name should be enough to tell you what the problem is :-)

Solution: create your own custom model class and provide setters and getters for ?key? and ?value?. Then the TableView will write back into your POJO.

In other news: this mailing list is meant for "Technical discussion related to the OpenJFX Project?, so you might wanna find a different place for support questions like this one. In this mailing list we discuss things like bugs in OpenJFX and their potential fixes.

Dirk

> On 13 May 2020, at 02:05, John Scancella <john.scancella at gmail.com> wrote:
> 
> Hello All,
> 
> I am hoping to get some help with setting up a TableView. What I want is a
> simple two column table with each column containing Strings. I want to be
> able to double click to create a new row if I double clicked on empty
> space. And I want to be able to edit any cell already in the table.
> 
> Currently I am struggling with editing the data already in the table. I can
> click and edit, but then if I double click again on the cell it reverts
> back to the original value. If I try and get the value programmatically, it
> is still getting the original value, even though the display is showing the
> new value.
> 
> You can see my code here: https://github.com/jscancella/heirloom
> I am using java version "1.8.0_251"
> 
> Thank you in advance for any help!
> 
> 
> -- 
> ~John Scancella


From github.com+60214806+ronyfla at openjdk.java.net  Wed May 13 08:46:11 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Wed, 13 May 2020 08:46:11 GMT
Subject: [Rev 01] RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
Message-ID: <5nK7rqiVIiR0-3z26cwaWJFfVGmUwuaz5OeYXnicOBU=.ff2d9fb7-6008-4cb0-a56c-9883b54f29b9@github.com>

> This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued
> about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get
> compiled with this version by default. It extends PR 187 <https://github.com/openjdk/jfx/pull/187>.  To further ease
> spotting scripts that cause a ScriptException a message in the form of "filename: caused ScriptException" gets added to
> the exception handling in either of the three locations: an error message, a stack trace or a wrap-up into a
> RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned, however none of these
> tear down the FXML GUI).

Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision:

  Reword the compile processing instructions (replace 'Hint' with 'Note:', adjust text to context), remove spurious empty
  line in script example code.

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/192/files
  - new: https://git.openjdk.java.net/jfx/pull/192/files/44b0f9f8..59a16c9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/192/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.00-01

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

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

From mp at jugs.org  Wed May 13 09:16:38 2020
From: mp at jugs.org (Michael Paus)
Date: Wed, 13 May 2020 11:16:38 +0200
Subject: HID multitouch display support in JavaFX
In-Reply-To: <CAHifg5eUJGdZTjCdk+mVY6x6eHQR2__24SM9-xkKSf1j6uJ36A@mail.gmail.com>
References: <CAHifg5f7S8uWcj3w+SabM-FkAD_iuaMOPpa55pQUGFnvoiUXSA@mail.gmail.com>
 <CAHifg5eUJGdZTjCdk+mVY6x6eHQR2__24SM9-xkKSf1j6uJ36A@mail.gmail.com>
Message-ID: <10df58dd-f163-9749-5e99-c3afa13b3855@jugs.org>

Having proper and consistent Multitouch support on all platforms is 
certainly
an interesting goal, especially if your development is targeting a 
mobile platform. If one
could test the input behavior already on the desktop, this would be an
enormous time saver because the turn-around times 
(edit-compile-build-deploy-debug-curse)
for mobile are currently still extremely high and thus not very 
development-friendly.
I learned from your mail that the situation on Windows seems to be better
than on macOS, which is my current development environment. That gives
me an idea :-)

Am 13.05.20 um 10:15 schrieb jfx user2:
> Nobody is biting... so is anyone else out there interested in using HID
> touchscreens with JavaFX on OSX (or any other plaform) without using a
> third party driver?
>
> On Fri, May 8, 2020 at 4:18 AM jfx user2 <jfxuser2 at gmail.com> wrote:
>
>> Multitouch display support JavaFX on Windows, iOS, and Android seems
>> straightforward.  If the OS recognizes the display as multitouch, then the
>> chances are that JavaFX will also work with it since it relies on the
>> native multitouch support of the OS.
>>
>> When it comes to Linux and OSX, it's not always as easy.  Linux sometimes
>> requires device mapping.  I'm not sure if it works at all in OSX unless you
>> have specific drivers for the display.
>>
>> All of the platforms seem to support HID so maybe JavaFX could have direct
>> support for HID devices (optionally) if they are present instead of just
>> the current method.  It may also improve performance in cases where the OS
>> is just piping HID events through their own API's to support multitouch.
>> Why not just go straight to the HID source and bypass that conduit.
>>
>> This would vastly improve multitouch app development on OSX.  It would be
>> possible to connect a HID display and use it for testing apps that are
>> destined for platforms that formally support multitouch.
>>
>> Is there any work being done in this area?  Is there a bigger picture
>> (e.g. better multi-display and connect/disconnect support in JavaFX)?
>>
>> ... coming from a frustrated OSX user with lots of HID displays and no
>> easy JavaFX support.
>>
>> https://www.usb.org/hid
>>


From aghaisas at openjdk.java.net  Wed May 13 09:18:10 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 13 May 2020 09:18:10 GMT
Subject: RFR: 8244647: Wrong first layout pass of Scrollbar controls on
 touch supported devices
In-Reply-To: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
References: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
Message-ID: <R0a3xaHiSt9K2yjjHe1hTGDkO97F1FJRt0KeSMkZ5mI=.76b588d7-469e-4e5d-baea-141568916485@github.com>

On Fri, 8 May 2020 11:25:03 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> There is a visual glitch when the scrollbar controls are laid out on touch enabled devices.
> 
> The first time they are laid out in the wrong location (20 px from right or bottom), while the next passes are correct
> (8 px from right or bottom).
> The reason for this glitch is the use of `getWidth()` or `getHeight()` in the `resizeRelocate` calls to relocate the
> bars before the controls have been properly resized yet: The initial w/h values are set to the default (20 px / 100
> px), while the pref values are correctly set to 8 px.  This PR fixes that, by using the same prefWidth/prefHeight for
> both resizing and relocating.
> It has been tested on Mac OS and Linux (with `-Dcom.sun.javafx.touch=true`), and on Android and iOS.

The changes look fine.
I have a minor comment on code formatting.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2449:

> 2448:                     double prefHeight = hbar.prefHeight(viewportBreadth);
> 2449:                     hbar.resizeRelocate(0, viewportLength-prefHeight,
> 2450:                             viewportBreadth, prefHeight);

Minor : Code formatting convention: Add spaces around '-' at 4 places in your changes.
It was not followed in earlier version, but let's correct it while touching these lines.

-------------

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

From github.com+60214806+ronyfla at openjdk.java.net  Wed May 13 09:24:37 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Wed, 13 May 2020 09:24:37 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <oZiAmdeG3bPl7oCiYOrN3Xt9-wgXV60otnPb0iWxNUM=.5f55f234-3c05-4c78-ae51-d0e1f2f5895e@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
 <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>
 <JSIFzcCtP1mEAa4UFaZxPyNKxF_ks27fFkHoaSIkM9c=.5d8c29cf-a921-4bf2-a9dd-52004b8e5218@github.com>
 <yoeN3D9ZI-tobgB3snqlJTbdRbmA1ze54ALQpIBzxNk=.72ec4797-e1f4-450a-a8d4-b93ddbe6387b@github.com>
 <oZiAmdeG3bPl7oCiYOrN3Xt9-wgXV60otnPb0iWxNUM=.5f55f234-3c05-4c78-ae51-d0e1f2f5895e@github.com>
Message-ID: <Hn2sObTFKChKxha07858aMRMIbGjwy96AMVrGnmAtLA=.51efb6e7-1d54-4a88-b9f7-07f43ca4977e@github.com>

On Tue, 12 May 2020 17:33:06 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

>> Suggested CSR:
>> 
>> Summary
>> =======
>> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
>> implements the javax.script.Compilable interface to speed up execution. In case compilation
>> throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
>> control of script compilation with a "compile" PI for FXML files.
>> 
>> Problem
>> =======
>> javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>> (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
>> 
>> If a script engine implements the javax.script.Compilable interface, then such scripts could be
>> compiled and the resulting javax.script.CompiledScript could be executed instead using its
>> eval() methods.
>> 
>> Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
>> invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
>> onMouseMove) which may be repetitively invoked and evaluated.
>> 
>> Solution
>> ========
>> Before evaluating the script code test whether the javax.script.ScriptEngine implements
>> javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
>> and then use its eval() method to evaluate the script, otherwise continue to use the
>> javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
>> (unexpectedly) a javax.script.ScriptException then fall back to using the
>> javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
>> the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
>> files.
>> 
>> Specification
>> =============
>> If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
>> compile() method to compile the script to a javax.script.CompiledScript object and use its
>> eval() method to run the script. In the case that the compilation throws (unexpectedly) a
>> javax.script.ScriptException log a warning and fall back to using the
>> javax.script.ScriptEngine's eval() method instead.
>> To allow setting this feature off and on while processing the FXML file a "compile" process
>> instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
>> compilation off and on throughout a FXML file.
>
> Doc addition for the CSR:
> =================
> The following text was added to the [Introduction to
> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
> at two locations, the "Script Event Handlers" ("#script_event_handlers") and the "Scripting" (#scripting") sections:
>> <p>Hint: to turn off automatic compilation of script code place the processing instruction <span
>> class="code">&lt;?compile false?&gt;</span> before the script. To turn on compilation of script code again use the
>> processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
>> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
>> of script code off and on.</p>
> 
> This documents the compile processing instruction, that it compilation is on by default and that it can be turned off
> and on repeatedly. It is hoped that this formulation plays well with the context where this paragraph got introduced.

Doc addition for the CSR (update)
-------------------------------------
In the event handler section:
> <p>Note: to turn off automatic compilation of script code place the processing instruction <span
> class="code">&lt;?compile false?&gt;</span> before the element that contains the script. To turn on compilation of
> script code again use the processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
> of script code off and on.</p>

In the Scripting section:
> <p>Note: to turn off automatic compilation of script code place the processing instruction <span
> class="code">&lt;?compile false?&gt;</span> before the script element. To turn on compilation of script code again use
> the processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
> of script code off and on.</p>

-------------

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

From jpereda at openjdk.java.net  Wed May 13 09:38:24 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Wed, 13 May 2020 09:38:24 GMT
Subject: [Rev 01] RFR: 8244647: Wrong first layout pass of Scrollbar
 controls on touch supported devices
In-Reply-To: <R0a3xaHiSt9K2yjjHe1hTGDkO97F1FJRt0KeSMkZ5mI=.76b588d7-469e-4e5d-baea-141568916485@github.com>
References: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
 <R0a3xaHiSt9K2yjjHe1hTGDkO97F1FJRt0KeSMkZ5mI=.76b588d7-469e-4e5d-baea-141568916485@github.com>
Message-ID: <z9wekFgxBjjnDboL0rq1sYE1RTKvd01Wx7McRHxyftY=.ca01364b-6e3a-49ea-b0ee-4738ef42672c@github.com>

On Wed, 13 May 2020 09:14:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply code formatting
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2449:
> 
>> 2448:                     double prefHeight = hbar.prefHeight(viewportBreadth);
>> 2449:                     hbar.resizeRelocate(0, viewportLength-prefHeight,
>> 2450:                             viewportBreadth, prefHeight);
> 
> Minor : Code formatting convention: Add spaces around '-' at 4 places in your changes.
> It was not followed in earlier version, but let's correct it while touching these lines.

Yes, makes sense, I thought about doing it while removing the unnecessary parenthesis but didn't want to be too
intrusive. Done.

-------------

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

From jpereda at openjdk.java.net  Wed May 13 09:38:23 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Wed, 13 May 2020 09:38:23 GMT
Subject: [Rev 01] RFR: 8244647: Wrong first layout pass of Scrollbar
 controls on touch supported devices
In-Reply-To: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
References: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
Message-ID: <5mXPz9Hnf44NnQFXicSXBWeCHJHCmv81LAxtaZHRxEg=.25321fb8-3805-4e5e-9d50-815f75b5271a@github.com>

> There is a visual glitch when the scrollbar controls are laid out on touch enabled devices.
> 
> The first time they are laid out in the wrong location (20 px from right or bottom), while the next passes are correct
> (8 px from right or bottom).
> The reason for this glitch is the use of `getWidth()` or `getHeight()` in the `resizeRelocate` calls to relocate the
> bars before the controls have been properly resized yet: The initial w/h values are set to the default (20 px / 100
> px), while the pref values are correctly set to 8 px.  This PR fixes that, by using the same prefWidth/prefHeight for
> both resizing and relocating.
> It has been tested on Mac OS and Linux (with `-Dcom.sun.javafx.touch=true`), and on Android and iOS.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Apply code formatting

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/215/files
  - new: https://git.openjdk.java.net/jfx/pull/215/files/fcce06aa..fea9d186

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/215/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/215/webrev.00-01

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

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

From aghaisas at openjdk.java.net  Wed May 13 09:53:49 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 13 May 2020 09:53:49 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
Message-ID: <jhNOx1yvA_1-IS9YYgb0gem4Kq2Ey1doziRlQjoRoCw=.ac0cc7aa-768c-49dd-af3f-024232c3a369@github.com>

On Wed, 6 May 2020 11:46:27 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
>> 
>> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
>> the controls package. Those that failed for the misbehaving skins before are passing after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup
>   
>   - corrected incorrect bug id in commented
>   - removed unrelated test change from TextAreaTest
>   - updated copyright year

Fix looks good. Nice test as well.
I have minor comments.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 221:

> 220:     @Override public void dispose() {
> 221:         // FIXME : JDK-8244112 - backout if we are already disposed
> 222:         // should check for getSkinnable to be null and return

Remove this FIXME comment.

modules/javafx.controls/src/shims/java/javafx/scene/control/ControlShim.java line 38:

> 37:      *
> 38:      * @param control the control the set the default skin on
> 39:      */

"the control the set the default skin on" --> "the control to set the default skin on"

-------------

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

From aghaisas at openjdk.java.net  Wed May 13 10:00:31 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 13 May 2020 10:00:31 GMT
Subject: [Rev 01] RFR: 8244647: Wrong first layout pass of Scrollbar
 controls on touch supported devices
In-Reply-To: <5mXPz9Hnf44NnQFXicSXBWeCHJHCmv81LAxtaZHRxEg=.25321fb8-3805-4e5e-9d50-815f75b5271a@github.com>
References: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
 <5mXPz9Hnf44NnQFXicSXBWeCHJHCmv81LAxtaZHRxEg=.25321fb8-3805-4e5e-9d50-815f75b5271a@github.com>
Message-ID: <JXEFPpMU-OYnSaD8SUV9R_LC45XG8QpEEdBi1HcFcA8=.74f57040-9c5c-4b31-bccd-dc01f4cc1682@github.com>

On Wed, 13 May 2020 09:38:23 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> There is a visual glitch when the scrollbar controls are laid out on touch enabled devices.
>> 
>> The first time they are laid out in the wrong location (20 px from right or bottom), while the next passes are correct
>> (8 px from right or bottom).
>> The reason for this glitch is the use of `getWidth()` or `getHeight()` in the `resizeRelocate` calls to relocate the
>> bars before the controls have been properly resized yet: The initial w/h values are set to the default (20 px / 100
>> px), while the pref values are correctly set to 8 px.  This PR fixes that, by using the same prefWidth/prefHeight for
>> both resizing and relocating.
>> It has been tested on Mac OS and Linux (with `-Dcom.sun.javafx.touch=true`), and on Android and iOS.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code formatting

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From arapte at openjdk.java.net  Wed May 13 10:17:57 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 13 May 2020 10:17:57 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
Message-ID: <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>

On Wed, 6 May 2020 11:46:27 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
>> 
>> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
>> the controls package. Those that failed for the misbehaving skins before are passing after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup
>   
>   - corrected incorrect bug id in commented
>   - removed unrelated test change from TextAreaTest
>   - updated copyright year

Eventually we might need to add this check to all the skin's dispose() which will be fixed for cleanup.
Looks good to me, suggested some minor changes.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 222:

> 221:         // FIXME : JDK-8244112 - backout if we are already disposed
> 222:         // should check for getSkinnable to be null and return
> 223:         if (getSkinnable() == null) return;

This comment can be removed. FIXME is getting fixed. :)

modules/javafx.controls/src/shims/java/javafx/scene/control/ControlShim.java line 38:

> 37:      *
> 38:      * @param control the control the set the default skin on
> 39:      */

typo:- the control the set => the control **to** set

modules/javafx.controls/src/shims/java/javafx/scene/control/ControlShim.java line 34:

> 33:      *
> 34:      * Note that this has no noticeable effect if the the control's
> 35:      * skin already is set to the default skin (see skinProperty for

typo:-  if the the control's => if the control's

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinDisposeContractTest.java line 159:

> 158:             {TreeTableView.class, },
> 159:             {TreeView.class, },
> 160:         };

Should these controls be included too: `Tooltip`, `HTMLEditor`, `ContextMenu` ?

-------------

Changes requested by arapte (Reviewer).

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

From arapte at openjdk.java.net  Wed May 13 10:21:47 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 13 May 2020 10:21:47 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
 <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>
Message-ID: <dEfVdDWut5JV_ZTkyp2-W2Ifu50574N8zx0RignULkE=.7947fcee-80ee-45ca-a14c-68ebae0ccb91@github.com>

On Mon, 11 May 2020 04:51:51 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>>   
>>   - corrected incorrect bug id in commented
>>   - removed unrelated test change from TextAreaTest
>>   - updated copyright year
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 222:
> 
>> 221:         // FIXME : JDK-8244112 - backout if we are already disposed
>> 222:         // should check for getSkinnable to be null and return
>> 223:         if (getSkinnable() == null) return;
> 
> This comment can be removed. FIXME is getting fixed. :)

Ajit has already commented about it, please resolve this comment.

-------------

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

From jpereda at openjdk.java.net  Wed May 13 10:22:44 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Wed, 13 May 2020 10:22:44 GMT
Subject: [Integrated] RFR: 8244647: Wrong first layout pass of Scrollbar
 controls on touch supported devices
In-Reply-To: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
References: <TpqrPWxwtU0Gc8hL_K7BMgPJ2pF0olBHhaZQ4czZous=.d5595068-8725-4546-9c39-66c0b57005b0@github.com>
Message-ID: <3JPNBdH9edxAtEdF3Jn5QmmkMerlWaunk-dCcapcYkc=.af838745-6659-47c0-bcc4-45ea0a6c1e2c@github.com>

On Fri, 8 May 2020 11:25:03 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> There is a visual glitch when the scrollbar controls are laid out on touch enabled devices.
> 
> The first time they are laid out in the wrong location (20 px from right or bottom), while the next passes are correct
> (8 px from right or bottom).
> The reason for this glitch is the use of `getWidth()` or `getHeight()` in the `resizeRelocate` calls to relocate the
> bars before the controls have been properly resized yet: The initial w/h values are set to the default (20 px / 100
> px), while the pref values are correctly set to 8 px.  This PR fixes that, by using the same prefWidth/prefHeight for
> both resizing and relocating.
> It has been tested on Mac OS and Linux (with `-Dcom.sun.javafx.touch=true`), and on Android and iOS.

This pull request has now been integrated.

Changeset: dbb64373
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/dbb64373
Stats:     10 lines in 1 file changed: 0 ins; 4 del; 6 mod

8244647: Wrong first layout pass of Scrollbar controls on touch supported devices

Reviewed-by: aghaisas

-------------

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

From fastegal at openjdk.java.net  Wed May 13 10:44:47 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 13 May 2020 10:44:47 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
 <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>
Message-ID: <W_nmBpDF9IAIgCPq2UNsej62tS2pd-XNpNYyj2l0VIc=.26bc8a64-117e-4b69-9d2d-09402d419a7b@github.com>

On Tue, 12 May 2020 12:21:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 485:
>> 
>>> 484:         }
>>> 485:
>>> 486:         if (focusedMenu != null && focusedMenuIndex != -1) {
>> 
>> don't quite understand why this change is necessary? The guard in the listener seems to be enough, at least the test
>> passes without this. If it's needed to fix another potentially breaking path to this, would it be possible to add a
>> test method that fails/passes before/after?
>
> This was the place where exception was occurring. Hence, I added this check.
> When I ran against the test, I still got the exception at caller lambda. I added that check later.
> Wanted to remove this check - but simple code scan revealed this method gets called from engine.addTraverseListener()
> listener with index = 0. Hence, I have kept this check. Covering this scenario in test seems tough.

Hmm .. re-reading my comment: was assuming and then formulating round a corner, sry. Will try again

My assumption (from the method implementation before the fix) was that the method expects only valid indices (either -1
or an index in range) such that

     assertEquals(focusedMenuIndex, getMenus().indexOf(focusedMenu);

Which would leave the validity check to the caller.

With that assumption, the old implementation were just fine. The one location that calls it with an invalid index is
the one you fixed (not called if empty), the other is the traversalListener (which I silently and incorrectly dropped
from my mind, because it's never notified anyway - which is nothing but a bold guess ;)

With the change, the constraint doesn't hold (as it didn't before if the caller passed in an invalid index) it just
doesn't blow. Not sure what - if any - bad might happen if we have a focusedMenuIndex >= getMenu().size() (in
particular empty menus).

The other way round: the method might take the responsibility to protect itself (no precondition and the postcondition
to guarantee the constraint above).

My preference would be to keep the method as is, and change the callers to check for a valid index. Hard to test, one
way or other ;)

-------------

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

From fastegal at openjdk.java.net  Wed May 13 11:22:38 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 13 May 2020 11:22:38 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
 <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>
Message-ID: <R_pSvj_QCcM5hM5SBytuyFDfY9Ilgyz84NOcYRWsDq8=.1d01e666-be4d-4a54-8cea-4a332583e12b@github.com>

On Wed, 13 May 2020 10:09:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>>   
>>   - corrected incorrect bug id in commented
>>   - removed unrelated test change from TextAreaTest
>>   - updated copyright year
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinDisposeContractTest.java line 159:
> 
>> 158:             {TreeTableView.class, },
>> 159:             {TreeView.class, },
>> 160:         };
> 
> Should these controls be included too: `Tooltip`, `HTMLEditor`, `ContextMenu` ?

good catch :)

Hmm .. thinking aloud:

- all in web is a bit very different as a small layer on top of the webEngine, usually off my radar
- the skinnable windows are no controls

so the easy way out - which I would tend take :) - is to narrow the issue to include only controls in controls. What do
you think?

-------------

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

From fastegal at openjdk.java.net  Wed May 13 11:31:04 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 13 May 2020 11:31:04 GMT
Subject: [Rev 02] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
Message-ID: <kI5zjXrqQ4e9QKlmxowEedzu7UGpAIh7CN00QFIvzWQ=.87e1fd98-1691-4cd0-b210-2d222d8ff709@github.com>

> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
> 
> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
> the controls package. Those that failed for the misbehaving skins before are passing after the fix.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  cleanup as per review

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/209/files
  - new: https://git.openjdk.java.net/jfx/pull/209/files/fe76204d..2a362614

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/209/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/209/webrev.01-02

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

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

From github.com+60214806+ronyfla at openjdk.java.net  Wed May 13 12:06:30 2020
From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher)
Date: Wed, 13 May 2020 12:06:30 GMT
Subject: RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <Hn2sObTFKChKxha07858aMRMIbGjwy96AMVrGnmAtLA=.51efb6e7-1d54-4a88-b9f7-07f43ca4977e@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
 <adZzjoeq9O95aHnPR4iGyNa9xeL1fo8y0xe3gg9umO8=.84bc0e26-88b5-4990-a87d-8706247f86d8@github.com>
 <JSIFzcCtP1mEAa4UFaZxPyNKxF_ks27fFkHoaSIkM9c=.5d8c29cf-a921-4bf2-a9dd-52004b8e5218@github.com>
 <yoeN3D9ZI-tobgB3snqlJTbdRbmA1ze54ALQpIBzxNk=.72ec4797-e1f4-450a-a8d4-b93ddbe6387b@github.com>
 <oZiAmdeG3bPl7oCiYOrN3Xt9-wgXV60otnPb0iWxNUM=.5f55f234-3c05-4c78-ae51-d0e1f2f5895e@github.com>
 <Hn2sObTFKChKxha07858aMRMIbGjwy96AMVrGnmAtLA=.51efb6e7-1d54-4a88-b9f7-07f43ca4977e@github.com>
Message-ID: <HW3v6plCIpGPwCrpHi-LB9lTqFirRvYiaXCLUX4PPTc=.e6605394-e9f6-44ab-9ea5-f096fc18207f@github.com>

On Wed, 13 May 2020 09:22:20 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

>> Doc addition for the CSR:
>> =================
>> The following text was added to the [Introduction to
>> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
>> at two locations, the "Script Event Handlers" ("#script_event_handlers") and the "Scripting" (#scripting") sections:
>>> <p>Hint: to turn off automatic compilation of script code place the processing instruction <span
>>> class="code">&lt;?compile false?&gt;</span> before the script. To turn on compilation of script code again use the
>>> processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
>>> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
>>> of script code off and on.</p>
>> 
>> This documents the compile processing instruction, that it compilation is on by default and that it can be turned off
>> and on repeatedly. It is hoped that this formulation plays well with the context where this paragraph got introduced.
>
> Doc addition for the CSR (update)
> -------------------------------------
> In the event handler section:
>> <p>Note: to turn off automatic compilation of script code place the processing instruction <span
>> class="code">&lt;?compile false?&gt;</span> before the element that contains the script. To turn on compilation of
>> script code again use the processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
>> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
>> of script code off and on.</p>
> 
> In the Scripting section:
>> <p>Note: to turn off automatic compilation of script code place the processing instruction <span
>> class="code">&lt;?compile false?&gt;</span> before the script element. To turn on compilation of script code again use
>> the processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
>> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
>> of script code off and on.</p>

/solves

-------------

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

From kcr at openjdk.java.net  Wed May 13 12:31:11 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 13 May 2020 12:31:11 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <xixE99cLh2FPjM1c04I9Iht0H26V_HAXQtE4iO0cGr4=.c638d5a9-09af-4ecb-a828-fbb858f9b75b@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
 <xixE99cLh2FPjM1c04I9Iht0H26V_HAXQtE4iO0cGr4=.c638d5a9-09af-4ecb-a828-fbb858f9b75b@github.com>
Message-ID: <oTXxITdInrquuVF7-Slni1A2BveCtqMwFL8f24i8hnU=.e103b948-9267-452b-9a59-92fa761e61cb@github.com>

On Wed, 13 May 2020 00:17:17 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java line 46:
>> 
>>> 45:  */
>>> 46: public abstract class ClipEnvelope {
>>> 47:
>> 
>> I think the removal of line 46 was unintended change.
>
> I think that there is no empty line between the docs and the declaration, but can revert.

Correct, so no need to revert.

>> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 142:
>> 
>>> 141:     }
>>> 142:
>>> 143:     /*
>> 
>> Both these methods seem like they belong to Utils.java. If moved to Utils.java then the all the calls
>> `(Math.abs(currentRate - rate) < EPSILON)` can be changed to use these methods from Utils.java. If we move these
>> methods then, Utils.java also needs to declare  `static final double EPSILON = 1e-12;`  and the EPSILON here can be
>> initialized as `private static final double EPSILON = Utils.EPSILON;`
>
> I agree that these methods are better suited there, but I'm not sure the same epsilon value will be suitable for other
> places that will want to use these. That value is somewhat arbitrary anyway I think.

Either is fine with me.

-------------

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

From nlisker at openjdk.java.net  Wed May 13 15:41:41 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 13 May 2020 15:41:41 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
Message-ID: <9djgT6xCywY-txTO94jiIRjZFx1DNEsoyC2O-94KQFs=.b31122b6-f708-4fd1-b4f5-c9ed62950b28@github.com>

On Thu, 7 May 2020 08:50:23 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java line 102:
> 
>> 101:             long ticksChange = Math.round(currentTick * currentRate);
>> 102:             ticks = Utils.clamp(0, deltaTicks + ticksChange, cycleTicks);
>> 103:             AnimationAccessor.getDefault().playTo(animation, ticks, cycleTicks);
> 
> This could remain unchanged. The `ticksChange` value is not really used elsewhere here.

This change was made with extracting similar code from the other clip envelopes in mind, though there would need to be
some future discussion about it. I think it also makes the code more readable anyway.

-------------

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

From nlisker at openjdk.java.net  Wed May 13 23:44:57 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 13 May 2020 23:44:57 GMT
Subject: [Rev 04] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4esypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <Aw2Z3oGdT0gQvyvUGkNfSR6STeTZaPwS2bD1evnoPDc=.631dc854-0d77-4798-940d-30e4de6f70f8@github.com>
 <YfreOsrII1rAA9imemEAOpvtyw9mKCJz4HKQ-BSYrts=.116f5896-e07f-4d65-8f8e-eb40b7ea58d3@github.com>
 <pxzCAjPskgO4hpx4PBj-it2SA217XvrY9VbImhOHgX4=.93d21009-f252-4d60-a8fd-41d9610b53cb@github.com>
 <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com>
 <KzsldmT4opxhH2nxGbGSpLm5vXfPl-U-6gZS8la-OKw=.196620b2-19de-463f-b7fa-6487b4c39113@github.com>
 <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com>
 <yXjCl57bw0Kj1tnrc5VblwDP5cxo0JhZMILeNTrsGb0=.9aef533c-d6db-4618-943b-72a0633725fb@github.com>
 <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com>
 <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es
 ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com>
Message-ID: <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com>

On Sat, 25 Apr 2020 17:07:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> We should make sure that we aren't seeing any significant performance drop when rendering spheres (at a couple
> different tessellation levels) or boxes.

I missed this. Do you mean that the test should create a mesh of a sphere instead of a flat surface?

-------------

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

From kcr at openjdk.java.net  Wed May 13 23:52:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 13 May 2020 23:52:59 GMT
Subject: [Rev 04] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <Aw2Z3oGdT0gQvyvUGkNfSR6STeTZaPwS2bD1evnoPDc=.631dc854-0d77-4798-940d-30e4de6f70f8@github.com>
 <YfreOsrII1rAA9imemEAOpvtyw9mKCJz4HKQ-BSYrts=.116f5896-e07f-4d65-8f8e-eb40b7ea58d3@github.com>
 <pxzCAjPskgO4hpx4PBj-it2SA217XvrY9VbImhOHgX4=.93d21009-f252-4d60-a8fd-41d9610b53cb@github.com>
 <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com>
 <KzsldmT4opxhH2nxGbGSpLm5vXfPl-U-6gZS8la-OKw=.196620b2-19de-463f-b7fa-6487b4c39113@github.com>
 <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com>
 <yXjCl57bw0Kj1tnrc5VblwDP5cxo0JhZMILeNTrsGb0=.9aef533c-d6db-4618-943b-72a0633725fb@github.com>
 <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com>
 <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es
 ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com>
 <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com>
Message-ID: <uw5efvWZ809te0Xq0a3TojTMXO7wShdgpGV9vjiJQTA=.ef7e7041-b681-4851-93c3-c6e53d5253e8@github.com>

On Wed, 13 May 2020 23:42:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> If this were an even remotely representative use case, then no, the performance hit would not be OK. The test was
>> designed as an artificial "worst-case" stress test: a single mesh with a large number of very large (window-sized)
>> quads stacked on top of each other. Any real-world use case won't do this.  We should make sure that we aren't seeing
>> any significant performance drop when rendering spheres (at a couple different tessellation levels) or boxes.
>
>> We should make sure that we aren't seeing any significant performance drop when rendering spheres (at a couple
>> different tessellation levels) or boxes.
> 
> I missed this. Do you mean that the test should create a mesh of a sphere instead of a flat surface?

I would say in addition to rather than instead of, since both are useful.

What might help is to add the sphere test plus the pathological test I put together into your test program so we can
select between them. And then get a few of us to run that updated program and post results.

-------------

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

From arapte at openjdk.java.net  Thu May 14 04:46:56 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 14 May 2020 04:46:56 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <R_pSvj_QCcM5hM5SBytuyFDfY9Ilgyz84NOcYRWsDq8=.1d01e666-be4d-4a54-8cea-4a332583e12b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
 <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>
 <R_pSvj_QCcM5hM5SBytuyFDfY9Ilgyz84NOcYRWsDq8=.1d01e666-be4d-4a54-8cea-4a332583e12b@github.com>
Message-ID: <O8Sgz67-TFE96LY5Y3sjuYgOA7QG_vHyJZJR2GWzw64=.dc1986ad-c193-4b24-ac85-986f2d91cb49@github.com>

On Wed, 13 May 2020 11:20:25 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinDisposeContractTest.java line 159:
>> 
>>> 158:             {TreeTableView.class, },
>>> 159:             {TreeView.class, },
>>> 160:         };
>> 
>> Should these controls be included too: `Tooltip`, `HTMLEditor`, `ContextMenu` ?
>
> good catch :)
> 
> Hmm .. thinking aloud:
> 
> - all in web is a bit very different as a small layer on top of the webEngine, usually off my radar
> - the skinnable windows are no controls
> 
> so the easy way out - which I would tend take :) - is to narrow the issue to include only controls in controls. What do
> you think?

Agree that HTMLEditorSkin is a web module. let's keep it off radar :)

TooltipSkin and ContextMenuSkin implement Skin and override the dispose() method. I think these Skins should also
behave similar to other and can be included here in test. and also should consider them under cleanup issue
[JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Both the dispose() seem safe from NPE.

-------------

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

From arapte at openjdk.java.net  Thu May 14 05:37:29 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 14 May 2020 05:37:29 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <B1lQkBujWgRTSJ84UgbmzGWQ3igj80xpEjWYEpovWXE=.1aa6a3b7-1294-4286-9b61-a3eebcb6687a@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
 <B1lQkBujWgRTSJ84UgbmzGWQ3igj80xpEjWYEpovWXE=.1aa6a3b7-1294-4286-9b61-a3eebcb6687a@github.com>
Message-ID: <9mYdLiWu43TC8V4SEP2xGsA58liM4j14klRb3JLNX5Q=.c2d6d98a-3804-4c2d-ad5f-5b8c265a5fe0@github.com>

On Wed, 13 May 2020 00:38:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java line 48:
>> 
>>> 47:
>>> 48:     protected boolean autoReverse() {
>>> 49:         return autoReverse;
>> 
>> I would suggest the name to be `isAutoReverese`
>
> That would be the usual naming convention, yes, but I find that  this can be more fluent to read. Perhaps I'm
> influenced by the upcoming `record`s feature. Can change.

Yes, please change.  Animation.java also has  `isAutoReverese` method, It would be good to be uniform.

-------------

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

From arapte at openjdk.java.net  Thu May 14 05:50:40 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 14 May 2020 05:50:40 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <oTXxITdInrquuVF7-Slni1A2BveCtqMwFL8f24i8hnU=.e103b948-9267-452b-9a59-92fa761e61cb@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
 <xixE99cLh2FPjM1c04I9Iht0H26V_HAXQtE4iO0cGr4=.c638d5a9-09af-4ecb-a828-fbb858f9b75b@github.com>
 <oTXxITdInrquuVF7-Slni1A2BveCtqMwFL8f24i8hnU=.e103b948-9267-452b-9a59-92fa761e61cb@github.com>
Message-ID: <WcDdRvt4D9Jz-k6M1Zgm8JLlLDk9GHgAo_QFwkM3SSo=.694b4248-6ea7-4f1f-b83f-d0f7018bd443@github.com>

On Wed, 13 May 2020 12:29:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I agree that these methods are better suited there, but I'm not sure the same epsilon value will be suitable for other
>> places that will want to use these. That value is somewhat arbitrary anyway I think.
>
> Either is fine with me.

> but I'm not sure the same epsilon value will be suitable for other places that will want to use these

True, EPSILON is defined in some other classes with different value. Only Animation classes define EPSILON as 1e-12. So
it may not be reasonable to include Animation specific helper method in common Util class. These methods would be more
suitable for Animation only util class. I think I am good with the current way.

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Thu May 14 08:26:59 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Thu, 14 May 2020 08:26:59 GMT
Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius properly
Message-ID: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com>

root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four
corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while
rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it
otherwise construct a path from given rounded rect and draw it.

-------------

Commit messages:
 - Formatting (File Mode Attribute change)
 - 8181775: JavaFX WebView does not calculate border-radius properly

Changes: https://git.openjdk.java.net/jfx/pull/218/files
 Webrev: https://webrevs.openjdk.java.net/jfx/218/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8181775
  Stats: 104 lines in 2 files changed: 95 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jfx/pull/218.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/218/head:pull/218

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

From fastegal at openjdk.java.net  Thu May 14 09:02:27 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 14 May 2020 09:02:27 GMT
Subject: [Rev 01] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <O8Sgz67-TFE96LY5Y3sjuYgOA7QG_vHyJZJR2GWzw64=.dc1986ad-c193-4b24-ac85-986f2d91cb49@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <SJNU1A-doPcBxaD2HvIKbj4DO_I48iev1tMxWgLmY04=.fe8553d8-1788-4e3a-8c37-f017bfc1951b@github.com>
 <IPwmrNPXFeuRQl0HDMc6BQ-jgZagzXuh9Q9P08Jl1YI=.27e70b11-5ca7-46d5-8858-cb8b86df8a1c@github.com>
 <R_pSvj_QCcM5hM5SBytuyFDfY9Ilgyz84NOcYRWsDq8=.1d01e666-be4d-4a54-8cea-4a332583e12b@github.com>
 <O8Sgz67-TFE96LY5Y3sjuYgOA7QG_vHyJZJR2GWzw64=.dc1986ad-c193-4b24-ac85-986f2d91cb49@github.com>
Message-ID: <pOjpD-yV_PnaWbjmme3eYiofKKX7Z04rcdVJTXTiyZs=.b9bb2535-9997-43b5-971a-98bc078e9a70@github.com>

On Thu, 14 May 2020 04:44:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> good catch :)
>> 
>> Hmm .. thinking aloud:
>> 
>> - all in web is a bit very different as a small layer on top of the webEngine, usually off my radar
>> - the skinnable windows are no controls
>> 
>> so the easy way out - which I would tend take :) - is to narrow the issue to include only controls in controls. What do
>> you think?
>
> Agree that HTMLEditorSkin is a web module. let's keep it off radar :)
> 
> TooltipSkin and ContextMenuSkin implement Skin and override the dispose() method. I think these Skins should also
> behave similar to other and can be included here in test. and also should consider them under cleanup issue
> [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Both the dispose() seem safe from NPE.

okay, added a separate test for ContextMenu/Tooltip (they don't fit into the binch test here :)

-------------

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

From fastegal at openjdk.java.net  Thu May 14 09:02:26 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 14 May 2020 09:02:26 GMT
Subject: [Rev 03] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
Message-ID: <3tNxrFLUp74cHvVLZo5dmgOgYmgM9IxcefPYgATWH5c=.e7c75a75-e8f4-4dc4-8694-125c4087e67c@github.com>

> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
> 
> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
> the controls package. Those that failed for the misbehaving skins before are passing after the fix.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  added test for ContextMenu/Tooltip skin as requested in review

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/209/files
  - new: https://git.openjdk.java.net/jfx/pull/209/files/2a362614..bd7e5b14

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/209/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/209/webrev.02-03

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

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

From arapte at openjdk.java.net  Thu May 14 09:44:42 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 14 May 2020 09:44:42 GMT
Subject: [Rev 03] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <3tNxrFLUp74cHvVLZo5dmgOgYmgM9IxcefPYgATWH5c=.e7c75a75-e8f4-4dc4-8694-125c4087e67c@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <3tNxrFLUp74cHvVLZo5dmgOgYmgM9IxcefPYgATWH5c=.e7c75a75-e8f4-4dc4-8694-125c4087e67c@github.com>
Message-ID: <jXKB8fGd275RJojbRv1skgtjStT6ZOia60M9L1QBw88=.192a2048-d6c8-43f6-ac02-724dcad7fc62@github.com>

On Thu, 14 May 2020 09:02:26 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
>> 
>> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
>> the controls package. Those that failed for the misbehaving skins before are passing after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test for ContextMenu/Tooltip skin as requested in review

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinPopupContractTest.java line 50:

> 49:     public void testContextMenuSkinDispose() {
> 50:         ContextMenu tooltip = new ContextMenu();
> 51:         tooltip.setSkin(new ContextMenuSkin(tooltip));

minor:  `tooltip` should be renamed as `contextMenu`.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu May 14 09:50:26 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 14 May 2020 09:50:26 GMT
Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot
 rendering
In-Reply-To: <xFYLzN1KHqYJT1kwu8hUUc0kyUtQkmr6y40VCtqSavE=.9fe6a394-482b-49e9-81fd-1d0b49a24268@github.com>
References: <hSZLFZkdZCDK6SvfDoDbflPQ0uQwDMRo--EyPI-x9KA=.9b7ff341-636f-48ec-b1d3-16263be6b3b1@github.com>
 <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
 <xFYLzN1KHqYJT1kwu8hUUc0kyUtQkmr6y40VCtqSavE=.9fe6a394-482b-49e9-81fd-1d0b49a24268@github.com>
Message-ID: <HEEEEcLjk3dOnLq5yxZ24YtH8xvziBlRW5gDBIaudx0=.6f5b1517-8b48-4928-8a8b-1d6100f25f6a@github.com>

On Mon, 11 May 2020 15:30:28 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes in import statements
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1483:
> 
>> 1482:                                     IntBuffer buffer, ResourceFactory rf, QuantumImage tileImg, QuantumImage
>> targetImg) { 1483:                 com.sun.prism.RTTexture rt = tileImg.getRT(w, h, rf);
>> 1484:                 if (rt == null) {
> 
> Any reason why the fully qualified name is needed?

Not that I can think of, probably some unfortunate copy/paste.
I'll fix that.

-------------

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

From fastegal at openjdk.java.net  Thu May 14 10:11:16 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 14 May 2020 10:11:16 GMT
Subject: [Rev 04] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
Message-ID: <McgZjY2JLiCqlr7N9Zw-Q5409k_b7jJP9kzKz_gcovw=.cb64a737-2235-44ac-aa38-849e40d0af58@github.com>

> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
> 
> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
> the controls package. Those that failed for the misbehaving skins before are passing after the fix.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  renamed misnamed local field

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/209/files
  - new: https://git.openjdk.java.net/jfx/pull/209/files/bd7e5b14..40ee4b96

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/209/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/209/webrev.03-04

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

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

From fastegal at openjdk.java.net  Thu May 14 10:11:17 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 14 May 2020 10:11:17 GMT
Subject: [Rev 03] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <jXKB8fGd275RJojbRv1skgtjStT6ZOia60M9L1QBw88=.192a2048-d6c8-43f6-ac02-724dcad7fc62@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <3tNxrFLUp74cHvVLZo5dmgOgYmgM9IxcefPYgATWH5c=.e7c75a75-e8f4-4dc4-8694-125c4087e67c@github.com>
 <jXKB8fGd275RJojbRv1skgtjStT6ZOia60M9L1QBw88=.192a2048-d6c8-43f6-ac02-724dcad7fc62@github.com>
Message-ID: <grXLATw-1shsuTYUenSnf6Mpq2k8gTaIZfFPM0eEegs=.bbbc402b-f2aa-47be-b45e-65a3d79ab777@github.com>

On Thu, 14 May 2020 09:42:21 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added test for ContextMenu/Tooltip skin as requested in review
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinPopupContractTest.java line 50:
> 
>> 49:     public void testContextMenuSkinDispose() {
>> 50:         ContextMenu tooltip = new ContextMenu();
>> 51:         tooltip.setSkin(new ContextMenuSkin(tooltip));
> 
> minor:  `tooltip` should be renamed as `contextMenu`.

haha .. spotted the c&p :)) Done and thanks!

-------------

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

From arapte at openjdk.java.net  Thu May 14 12:09:11 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 14 May 2020 12:09:11 GMT
Subject: [Rev 04] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <McgZjY2JLiCqlr7N9Zw-Q5409k_b7jJP9kzKz_gcovw=.cb64a737-2235-44ac-aa38-849e40d0af58@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <McgZjY2JLiCqlr7N9Zw-Q5409k_b7jJP9kzKz_gcovw=.cb64a737-2235-44ac-aa38-849e40d0af58@github.com>
Message-ID: <B-K01KP2fySb6rEGzKMqLTjmJNy3aZG9CXQYlMo7S5k=.6b1af124-66d4-455a-bb16-804054cb24ed@github.com>

On Thu, 14 May 2020 10:11:16 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
>> 
>> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
>> the controls package. Those that failed for the misbehaving skins before are passing after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed misnamed local field

Looks good to me...

-------------

Marked as reviewed by arapte (Reviewer).

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

From mike at plan99.net  Thu May 14 12:21:15 2020
From: mike at plan99.net (Mike Hearn)
Date: Thu, 14 May 2020 05:21:15 -0700
Subject: Questions ad JavaScript in JavaFX' WebEngine
In-Reply-To: <0233cb09-a33e-fd54-4399-436165747200@wu.ac.at>
References: <ddb1f55d-e9fa-eaea-a3dc-d73a72732a76@wu.ac.at>
 <0b0d08fd-992b-6dc9-09c5-9589c7a9b805@oracle.com>
 <0233cb09-a33e-fd54-4399-436165747200@wu.ac.at>
Message-ID: <CANEZrP1fFUyWFrn68_py68Qeamc+fWhEshsiAqZb-_5NOb=BLw@mail.gmail.com>

The WebKit binding code is some of the more complex code in JavaFX. Rather
than try to extend the script tag you could instead look at the code for
the <object> tag and the old support for Netscape-style plugins.

https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebCore/plugins

I've looked at this in the past to investigate embedding of arbitrary
JavaFX nodes into a web page. It doesn't look particularly unfeasible as
there's still a lot of old code lying around that used to do exactly that,
it's just not used much anymore. However wiring it up to the Java level
would require a fairly adventurous programmer with good knowledge of C++,
rendering engines and JavaFX internals.




On Mon, May 11, 2020 at 14:17:07, Rony G. Flatscher <Rony.Flatscher at wu.ac.at
> wrote:

> On 09.05.2020 17:23, Kevin Rushforth wrote:
>
> WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The
> sources are in the jfx repo, along with the JavaFX-specific classes that
> implement the two-way Java <--> JavaScript bridge. Other than the public
> API docs for WebEngine, which you referred to in your message, there isn't
> any documentation of the interface.
>
> OK, thank you very much, this is reassuring! :)
>
> What sort of information are you looking for?
>
> Well, as event handlers and script tags in HTML have a type attribute that
> allows to denote script languages other than JavaScript, I am interested in
> evaluating what WebEngine/WebView allows for to support this with any of
> the Java script engines.
>
> ---rony
>
> On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
>
> Wondering which JavaScript engine gets referred to in WebEngine [1].
>
> In case it is currently (JavaFX 14) Nashorn [2], what happens after
> Nashorn gets removed from the next [3] version? In case it is WebKit's
> JavaScriptCore [4] where can one study the interface from WebEngine to it?
>
> ---rony
>
> [1] WebEngine: <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/
> class-use/WebEngine.html>
> [2] Nashorn: <https://openjdk.java.net/projects/nashorn/>
> [3] Nashorn removal from JDK 15: <https://openjdk.java.net/jeps/372>
> [4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore>
>
>

From github.com+7450507+fthevenet at openjdk.java.net  Thu May 14 12:50:43 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 14 May 2020 12:50:43 GMT
Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot
 rendering
In-Reply-To: <TgX4954Ekr_lCzK29IkHXF16ix5nzWg53R3tWh01q_E=.e53f33df-35a6-4a2f-9ac2-77cb51cfb64d@github.com>
References: <hSZLFZkdZCDK6SvfDoDbflPQ0uQwDMRo--EyPI-x9KA=.9b7ff341-636f-48ec-b1d3-16263be6b3b1@github.com>
 <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
 <TgX4954Ekr_lCzK29IkHXF16ix5nzWg53R3tWh01q_E=.e53f33df-35a6-4a2f-9ac2-77cb51cfb64d@github.com>
Message-ID: <uXzTE7XB7IkiQeC6SDT5Et6__0ttVtkz0Bqtl9YDeYQ=.830580c6-bdfc-4ccb-bc7c-9239ac4d9bb2@github.com>

On Sat, 9 May 2020 17:28:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes in import statements
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1495:
> 
>> 1494:                 }
>> 1495:                 //Copy tile's pixel into the target image
>> 1496:                 targetImg.image.setPixels(xOffset, yOffset, w, h,
> 
> Typo: should be "pixels" (plural)

> 
> 
> Overall, this looks quite good. In particular the tiled rendering, as implemented by the `renderTile` method, should be
> reasonably efficient.
> My only high-level comment is that I'm somewhat skeptical of `computeOptimumTileSize` to determine the size and
> direction of tiling. I note that in the case of an image that is tiled in both X and Y, there are at most 4 distinct
> tile sizes if it doesn't fit evenly. In the case where only one of X or Y is tiled, there are at most 2 distinct tile
> sizes. Here is an example:  ``` +-----------+-----------+  .  +-------+
> |           |           |  .  |       |
> |     M     |     M     |  .  |   R   |
> |           |           |  .  |       |
> +-----------+-----------+  .  +-------+
> |           |           |  .  |       |
> |     M     |     M     |  .  |   R   |
> |           |           |  .  |       |
> +-----------+-----------+  .  +-------+
>       .           .        .      .
> +-----------+-----------+  .  +-------+
> |           |           |  .  |       |
> |     M     |     M     |  .  |   R   |
> |           |           |  .  |       |
> +-----------+-----------+  .  +-------+
> |     B     |     B     |  .  |   C   |
> +-----------+-----------+  .  +-------+
> ```
> 
> Where `M` represents the middle set of tiles each with a size of `tileW x tileH`. `R` is the right hand column of
> tiles, `B` is bottom row, and `C` is corner.
> Recognizing this, I wonder if it might be better to always use the maximum tile size, but fill all of the middle tiles
> of that size first, and then pick up the right and/or bottom edges as needed. This will minimize thrashing (no more
> than 3 changes of tile size), while avoiding the more complicated logic that tries to keep the tiles all the same size
> at the cost of smaller tiles, and which has to fall back to using uneven tiles anyway. If you do it this way, there is
> also no need to have code that switches the order of the inner loop. It will naturally handle that.  Either way, I'd
> like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly (and if you
> stick with your current approach, X or Y as the inner loop).  I left a couple inline comments as well.

I'll need to think about this a bit more, but maybe a good approach could be to generally adopt your solution, but
still attempt to see if any of the snapshot's dimension  can be divided equally by 2 or 3 (while being less than
maxTextureSize) , and use that a a tile size. As the number of tiles increases, it become less important to have same
sized tiles as you demonstrated so using maxTextureSize should be fine.

This way we get rid of the inner loop direction logic (which I agree is verbose and kind of confusing), and still have
a chance to optimize the case where tiled snapshots are made up of 4 tiles or less (which I see as being the most
frequent use case, in my experience anyway).

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu May 14 10:01:56 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 14 May 2020 10:01:56 GMT
Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot
 rendering
In-Reply-To: <HEEEEcLjk3dOnLq5yxZ24YtH8xvziBlRW5gDBIaudx0=.6f5b1517-8b48-4928-8a8b-1d6100f25f6a@github.com>
References: <hSZLFZkdZCDK6SvfDoDbflPQ0uQwDMRo--EyPI-x9KA=.9b7ff341-636f-48ec-b1d3-16263be6b3b1@github.com>
 <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
 <xFYLzN1KHqYJT1kwu8hUUc0kyUtQkmr6y40VCtqSavE=.9fe6a394-482b-49e9-81fd-1d0b49a24268@github.com>
 <HEEEEcLjk3dOnLq5yxZ24YtH8xvziBlRW5gDBIaudx0=.6f5b1517-8b48-4928-8a8b-1d6100f25f6a@github.com>
Message-ID: <3QyPvbrYiQ_fxGJR2d7WM2UEe6myHiDbd09dhrMFiIQ=.3071851a-c2c9-4798-8807-f80dc5720733@github.com>

On Thu, 14 May 2020 09: 48:14 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1483:
>> 
>>> 1482:                                     IntBuffer buffer, ResourceFactory rf, QuantumImage tileImg, QuantumImage
>>> targetImg) { 1483:                 com.sun.prism.RTTexture rt = tileImg.getRT(w, h, rf);
>>> 1484:                 if (rt == null) {
>> 
>> Any reason why the fully qualified name is needed?
>
> Not that I can think of, probably some unfortunate copy/paste.
> I'll fix that.

Indeed ` com.sun.prism.RTTexture rt` was present as is in `renderToImage` before this change, and I reused it
wholesale. I don't think it was needed back then either, maybe it's a left over from a prior refactor.

-------------

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

From aghaisas at openjdk.java.net  Thu May 14 15:48:34 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 14 May 2020 15:48:34 GMT
Subject: [Rev 04] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <McgZjY2JLiCqlr7N9Zw-Q5409k_b7jJP9kzKz_gcovw=.cb64a737-2235-44ac-aa38-849e40d0af58@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
 <McgZjY2JLiCqlr7N9Zw-Q5409k_b7jJP9kzKz_gcovw=.cb64a737-2235-44ac-aa38-849e40d0af58@github.com>
Message-ID: <8unemgCMRaQdW8FcA2QRY6ie_zJYRW1opkus47IhrfU=.e9a8d15d-56fe-435b-801a-b581c35cc54a@github.com>

On Thu, 14 May 2020 10:11:16 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
>> 
>> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
>> the controls package. Those that failed for the misbehaving skins before are passing after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed misnamed local field

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From github.com+3197675+abhinayagarwal at openjdk.java.net  Thu May 14 19:30:20 2020
From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal)
Date: Thu, 14 May 2020 19:30:20 GMT
Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has focus
Message-ID: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>

In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
condition fails in cases where the control already has focus but the keyboard is not visible.

Ideally, the keyboard should be shown again when the user taps on the TextInputControl.

This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
both editable and focused.

-------------

Commit messages:
 - Show keyboard when user taps on TextInput controls

Changes: https://git.openjdk.java.net/jfx/pull/219/files
 Webrev: https://webrevs.openjdk.java.net/jfx/219/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245053
  Stats: 32 lines in 2 files changed: 6 ins; 6 del; 20 mod
  Patch: https://git.openjdk.java.net/jfx/pull/219.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/219/head:pull/219

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

From fastegal at openjdk.java.net  Fri May 15 04:50:24 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 15 May 2020 04:50:24 GMT
Subject: [Integrated] RFR: 8244112: Skin implementations: must not violate
 contract of dispose
In-Reply-To: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
References: <Lv4i0JIV6tc5NvCeR84KRNK41jNBKc8aXjtFAupE1-Q=.d985975d-1842-4c27-ba66-3e203e85374b@github.com>
Message-ID: <sEl-W8e0MXM7Cp3i993b0byFMG9WQz1I8B75WF0nPlc=.a381932a-8c2a-4ef7-ac40-7e10e77da786@github.com>

On Wed, 6 May 2020 11:16:50 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> some skins have not been guarding themselves against multiple calls to dispose (see issue for details)
> 
> Fixed by backing out off dispose if skinnable is null. Added test (parameterized in control class) for all controls in
> the controls package. Those that failed for the misbehaving skins before are passing after the fix.

This pull request has now been integrated.

Changeset: bb243224
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/bb243224
Stats:     278 lines in 7 files changed: 1 ins; 273 del; 4 mod

8244112: Skin implementations: must not violate contract of dispose

Reviewed-by: aghaisas, arapte

-------------

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

From aghaisas at openjdk.java.net  Fri May 15 06:54:48 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 15 May 2020 06:54:48 GMT
Subject: RFR: 8244824: TableView : Incorrect German translation
Message-ID: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>

Issue : https://bugs.openjdk.java.net/browse/JDK-8244824

Fix : As simple as it gets !!!

-------------

Commit messages:
 - German translation bug fix

Changes: https://git.openjdk.java.net/jfx/pull/220/files
 Webrev: https://webrevs.openjdk.java.net/jfx/220/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244824
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/220.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/220/head:pull/220

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

From github.com+11281461+danielpeintner at openjdk.java.net  Fri May 15 07:20:37 2020
From: github.com+11281461+danielpeintner at openjdk.java.net (danielpeintner)
Date: Fri, 15 May 2020 07:20:37 GMT
Subject: RFR: 8244824: TableView : Incorrect German translation
In-Reply-To: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>
References: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>
Message-ID: <WziSBq0qso7XUtI4VJ5fei6UicGUTm61vGCw847z6WQ=.76485a0b-38db-41eb-8b94-10ae6359f6b3@github.com>

On Fri, 15 May 2020 06:49:04 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8244824
> 
> Fix : As simple as it gets !!!

FYI: While I agree "Inhalt" is better than "Content" the latter is not completely wrong (see
https://www.duden.de/rechtschreibung/Content)

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Fri May 15 07:47:22 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Fri, 15 May 2020 07:47:22 GMT
Subject: RFR: 8169501: GIF animation is too fast
Message-ID: <fOA-gJ-j9Ub8YSPU036f6RvaofKWMHirHmH9NvqPMpE=.114aa588-2478-41da-ab88-7322a23228d8@github.com>

issue is caused by the threshold value for frame duration used by javaFx before it gets normalized. JavaFx is using
threshold value 10 while other browser (Safari, Firefox) is using 50 due to which, value between 10 and 50 don't get
normalized and animation runs at faster speed. To fix the issue change frame duration normalization value to <= 50.
Safari : https://bugs.webkit.org/show_bug.cgi?id=14413 Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=386269

-------------

Commit messages:
 - 8169501: GIF animation is too fast

Changes: https://git.openjdk.java.net/jfx/pull/221/files
 Webrev: https://webrevs.openjdk.java.net/jfx/221/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8169501
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/221.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/221/head:pull/221

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

From aghaisas at openjdk.java.net  Fri May 15 09:21:33 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 15 May 2020 09:21:33 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <W_nmBpDF9IAIgCPq2UNsej62tS2pd-XNpNYyj2l0VIc=.26bc8a64-117e-4b69-9d2d-09402d419a7b@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
 <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>
 <W_nmBpDF9IAIgCPq2UNsej62tS2pd-XNpNYyj2l0VIc=.26bc8a64-117e-4b69-9d2d-09402d419a7b@github.com>
Message-ID: <c7RHR2S_u8CS604mJEn5AGpKAgMwbrunTEzx5trnvWo=.9bacb1a6-cf59-4ec6-b68f-03def550c527@github.com>

On Wed, 13 May 2020 10:42:41 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> This was the place where exception was occurring. Hence, I added this check.
>> When I ran against the test, I still got the exception at caller lambda. I added that check later.
>> Wanted to remove this check - but simple code scan revealed this method gets called from engine.addTraverseListener()
>> listener with index = 0. Hence, I have kept this check. Covering this scenario in test seems tough.
>
> Hmm .. re-reading my comment: was assuming and then formulating round a corner, sry. Will try again
> 
> My assumption (from the method implementation before the fix) was that the method expects only valid indices (either -1
> or an index in range) such that
>      assertEquals(focusedMenuIndex, getMenus().indexOf(focusedMenu);
> 
> Which would leave the validity check to the caller.
> 
> With that assumption, the old implementation were just fine. The one location that calls it with an invalid index is
> the one you fixed (not called if empty), the other is the traversalListener (which I silently and incorrectly dropped
> from my mind, because it's never notified anyway - which is nothing but a bold guess ;)  With the change, the
> constraint doesn't hold (as it didn't before if the caller passed in an invalid index) it just doesn't blow. Not sure
> what - if any - bad might happen if we have a focusedMenuIndex >= getMenu().size() (in particular empty menus).    The
> other way round: the method might take the responsibility to protect itself (no precondition and the postcondition to
> guarantee the constraint above).  My preference would be to keep the method as is, and change the callers to check for
> a valid index. Hard to test, one way or other ;)

I differ on this suggestion.
My thinking is - list access in setFocusedMenuIndex() method should have this check. It is not up to the caller to know
the internal details of the method. That's the root cause of Exception. I added another check in
menuBarFocusedPropertyListener because, it accesses the different list - container.getChildren(). In general, I feel,
the validity check near the list usage is logical and readable as well.

-------------

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

From fastegal at openjdk.java.net  Fri May 15 09:31:32 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 15 May 2020 09:31:32 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <c7RHR2S_u8CS604mJEn5AGpKAgMwbrunTEzx5trnvWo=.9bacb1a6-cf59-4ec6-b68f-03def550c527@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
 <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>
 <W_nmBpDF9IAIgCPq2UNsej62tS2pd-XNpNYyj2l0VIc=.26bc8a64-117e-4b69-9d2d-09402d419a7b@github.com>
 <c7RHR2S_u8CS604mJEn5AGpKAgMwbrunTEzx5trnvWo=.9bacb1a6-cf59-4ec6-b68f-03def550c527@github.com>
Message-ID: <uBawAgtWOt6MrrtnMUpFOyzM8B6fAruTt6Kkqld_3Rk=.9be4c639-c896-4b45-a12c-bc40044839ee@github.com>

On Fri, 15 May 2020 09:19:19 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Hmm .. re-reading my comment: was assuming and then formulating round a corner, sry. Will try again
>> 
>> My assumption (from the method implementation before the fix) was that the method expects only valid indices (either -1
>> or an index in range) such that
>>      assertEquals(focusedMenuIndex, getMenus().indexOf(focusedMenu);
>> 
>> Which would leave the validity check to the caller.
>> 
>> With that assumption, the old implementation were just fine. The one location that calls it with an invalid index is
>> the one you fixed (not called if empty), the other is the traversalListener (which I silently and incorrectly dropped
>> from my mind, because it's never notified anyway - which is nothing but a bold guess ;)  With the change, the
>> constraint doesn't hold (as it didn't before if the caller passed in an invalid index) it just doesn't blow. Not sure
>> what - if any - bad might happen if we have a focusedMenuIndex >= getMenu().size() (in particular empty menus).    The
>> other way round: the method might take the responsibility to protect itself (no precondition and the postcondition to
>> guarantee the constraint above).  My preference would be to keep the method as is, and change the callers to check for
>> a valid index. Hard to test, one way or other ;)
>
> I differ on this suggestion.
> My thinking is - list access in setFocusedMenuIndex() method should have this check. It is not up to the caller to know
> the internal details of the method. That's the root cause of Exception. I added another check in
> menuBarFocusedPropertyListener because, it accesses the different list - container.getChildren(). In general, I feel,
> the validity check near the list usage is logical and readable as well.

hmm .. yeah I'm aware of getContainer vs. getMenus - but they should be the same size, shouldn't they?

Anyway, if focusedIndex != getMenus().indexOf all users of focusedIndex have to include a check for validity. That
might be prevented by not allowing it here in the method, in setting its value not unconditionally to the given index
but guard it against being valid:

    focusedMenuIndex = index >= getMenus().size() ? -1 : index

Then focused is either valid or -1.

-------------

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

From fastegal at openjdk.java.net  Fri May 15 09:49:17 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 15 May 2020 09:49:17 GMT
Subject: RFR: 8244824: TableView : Incorrect German translation
In-Reply-To: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>
References: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>
Message-ID: <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com>

On Fri, 15 May 2020 06:49:04 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8244824
> 
> Fix : As simple as it gets !!!

Correct :)

-------------

Marked as reviewed by fastegal (Author).

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

From fastegal at openjdk.java.net  Fri May 15 11:00:31 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 15 May 2020 11:00:31 GMT
Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has
 focus
In-Reply-To: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
Message-ID: <9Lo_Y6wJ7IuZKINGGkRLGaRvqxBtznfG7Z_FhlB8f2g=.510eb3af-df74-4e18-93c4-6b83c044fbf8@github.com>

On Thu, 14 May 2020 19:22:54 GMT, Abhinay Agarwal <github.com+3197675+abhinayagarwal at openjdk.org> wrote:

> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
> should be shown again when the user taps on the TextInputControl.
> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
> both editable and focused.

out off my home-zone here, just fyi and in case it might be relevant to android skins as well: there's an umbrella
issue to cleanup skin implementations [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364) - both the
android text skins look like leaking in the manually registered focus listener (not introduced here) and the
eventHandler added here. Probably should be removed manually in dispose (or in the case of the focusListener,
registered via skin api).

-------------

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

From kcr at openjdk.java.net  Fri May 15 16:11:33 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 May 2020 16:11:33 GMT
Subject: RFR: 8169501: GIF animation is too fast
In-Reply-To: <fOA-gJ-j9Ub8YSPU036f6RvaofKWMHirHmH9NvqPMpE=.114aa588-2478-41da-ab88-7322a23228d8@github.com>
References: <fOA-gJ-j9Ub8YSPU036f6RvaofKWMHirHmH9NvqPMpE=.114aa588-2478-41da-ab88-7322a23228d8@github.com>
Message-ID: <cheWVZHukdFg33dK4DfS-5H6RoIfDk6POSGSVxNz_Fw=.5159869d-58bf-45dc-b30d-6a4d014fe2ae@github.com>

On Fri, 15 May 2020 07:42:40 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

> issue is caused by the threshold value for frame duration used by javaFx before it gets normalized. JavaFx is using
> threshold value 10 while other browser (Safari, Firefox) is using 50 due to which, value between 10 and 50 don't get
> normalized and animation runs at faster speed. To fix the issue change frame duration normalization value to <= 50.
> Safari : https://bugs.webkit.org/show_bug.cgi?id=14413 Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=386269

While it does seem like the fix will make things better, the logic is a bit surprising to me. What it means is that
very small values in the range `[0,50]` (currently `[1,10]` before your fix) will get forced to 100, but moderately
small values, in the range `[51,99]` will be used directly. I wonder what the rationale was for this behavior in Safari
is? I would have thought just a simple clamp (either to 50 or 100) would make more sense, but perhaps matching the
popular browsers is better.

What I would like to see, though, is a comparison of behavior between:

* WebView (both before and after your proposed fix)
* JavaFX Image in an ImageView
* Firefox
* Safari
* Chrome

Can you find two images (the one in the bug report can be one of them) with a frame delay value in the 11-50 range and
also something in the 51-70 range and run the tests?

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Fri May 15 16:41:36 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Fri, 15 May 2020 16:41:36 GMT
Subject: RFR: 8208169: can not print selected pages of web page
Message-ID: <jWsRhnxW7brrPODkakKw-f6PlbmfqE9habjyLiCROhs=.c6993562-79cb-44f1-9ff2-786d307bfe1f@github.com>

Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page,
which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing
pages otherwise print all pages as usual.

-------------

Commit messages:
 - 8208169: can not print selected pages of web page

Changes: https://git.openjdk.java.net/jfx/pull/222/files
 Webrev: https://webrevs.openjdk.java.net/jfx/222/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8208169
  Stats: 19 lines in 1 file changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/222.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/222/head:pull/222

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

From kcr at openjdk.java.net  Fri May 15 17:13:03 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 May 2020 17:13:03 GMT
Subject: RFR: 8208169: can not print selected pages of web page
In-Reply-To: <jWsRhnxW7brrPODkakKw-f6PlbmfqE9habjyLiCROhs=.c6993562-79cb-44f1-9ff2-786d307bfe1f@github.com>
References: <jWsRhnxW7brrPODkakKw-f6PlbmfqE9habjyLiCROhs=.c6993562-79cb-44f1-9ff2-786d307bfe1f@github.com>
Message-ID: <tNJSGXv4kfLWcmrIQQOLWPmyVMIZYgE1BJ-_UuKpFHE=.3289407e-7cc6-4631-97c4-637393480939@github.com>

On Fri, 15 May 2020 16:36:29 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page,
> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing
> pages otherwise print all pages as usual.

@prrace can you also review this?

-------------

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

From kcr at openjdk.java.net  Fri May 15 17:35:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 May 2020 17:35:16 GMT
Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius
 properly
In-Reply-To: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com>
References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com>
Message-ID: <PuJYQqMr2a73CZEBSGsW2j-9ZB2IJsiFd-qAys32miM=.3cb465c0-7755-4b5c-96d1-4a95ea21d6a1@github.com>

On Thu, 14 May 2020 08:15:19 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

> root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four
> corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while
> rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it
> otherwise construct a path from given rounded rect and draw it.

The fix looks correct, but I want to test it. I left one minor comment on the test.

modules/javafx.web/src/test/java/test/javafx/scene/web/CSSTest.java line 34:

> 33:
> 34: import java.awt.*;
> 35: import java.awt.image.BufferedImage;

As a best practice, we avoid Wildcard imports for packages (static imports of fields and methods within a class are
sometimes fine for certain classes).

-------------

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

From kcr at openjdk.java.net  Sat May 16 14:22:18 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 16 May 2020 14:22:18 GMT
Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot
 rendering
In-Reply-To: <uXzTE7XB7IkiQeC6SDT5Et6__0ttVtkz0Bqtl9YDeYQ=.830580c6-bdfc-4ccb-bc7c-9239ac4d9bb2@github.com>
References: <hSZLFZkdZCDK6SvfDoDbflPQ0uQwDMRo--EyPI-x9KA=.9b7ff341-636f-48ec-b1d3-16263be6b3b1@github.com>
 <t_M3Mp0kDXpD1H9CIOem1zKPAepKaOh1RXyatS4adOM=.3daf1852-efe7-4bb9-8174-06568c4d914c@github.com>
 <TgX4954Ekr_lCzK29IkHXF16ix5nzWg53R3tWh01q_E=.e53f33df-35a6-4a2f-9ac2-77cb51cfb64d@github.com>
 <uXzTE7XB7IkiQeC6SDT5Et6__0ttVtkz0Bqtl9YDeYQ=.830580c6-bdfc-4ccb-bc7c-9239ac4d9bb2@github.com>
Message-ID: <7GU_NwPXRJ2nrv98_OZsDFybV0H9p_S16o1KKHAwl0A=.9473c5f2-3056-4344-a4b4-f2f0dd56da67@github.com>

On Thu, 14 May 2020 12:48:30 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1495:
>> 
>>> 1494:                 }
>>> 1495:                 //Copy tile's pixel into the target image
>>> 1496:                 targetImg.image.setPixels(xOffset, yOffset, w, h,
>> 
>> Typo: should be "pixels" (plural)
>
>> 
>> 
>> Overall, this looks quite good. In particular the tiled rendering, as implemented by the `renderTile` method, should be
>> reasonably efficient.
>> My only high-level comment is that I'm somewhat skeptical of `computeOptimumTileSize` to determine the size and
>> direction of tiling. I note that in the case of an image that is tiled in both X and Y, there are at most 4 distinct
>> tile sizes if it doesn't fit evenly. In the case where only one of X or Y is tiled, there are at most 2 distinct tile
>> sizes. Here is an example:  ``` +-----------+-----------+  .  +-------+
>> |           |           |  .  |       |
>> |     M     |     M     |  .  |   R   |
>> |           |           |  .  |       |
>> +-----------+-----------+  .  +-------+
>> |           |           |  .  |       |
>> |     M     |     M     |  .  |   R   |
>> |           |           |  .  |       |
>> +-----------+-----------+  .  +-------+
>>       .           .        .      .
>> +-----------+-----------+  .  +-------+
>> |           |           |  .  |       |
>> |     M     |     M     |  .  |   R   |
>> |           |           |  .  |       |
>> +-----------+-----------+  .  +-------+
>> |     B     |     B     |  .  |   C   |
>> +-----------+-----------+  .  +-------+
>> ```
>> 
>> Where `M` represents the middle set of tiles each with a size of `tileW x tileH`. `R` is the right hand column of
>> tiles, `B` is bottom row, and `C` is corner.
>> Recognizing this, I wonder if it might be better to always use the maximum tile size, but fill all of the middle tiles
>> of that size first, and then pick up the right and/or bottom edges as needed. This will minimize thrashing (no more
>> than 3 changes of tile size), while avoiding the more complicated logic that tries to keep the tiles all the same size
>> at the cost of smaller tiles, and which has to fall back to using uneven tiles anyway. If you do it this way, there is
>> also no need to have code that switches the order of the inner loop. It will naturally handle that.  Either way, I'd
>> like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly (and if you
>> stick with your current approach, X or Y as the inner loop).  I left a couple inline comments as well.
> 
> I'll need to think about this a bit more, but maybe a good approach could be to generally adopt your solution, but
> still attempt to see if any of the snapshot's dimension  can be divided equally by 2 or 3 (while being less than
> maxTextureSize) , and use that a a tile size. As the number of tiles increases, it become less important to have same
> sized tiles as you demonstrated so using maxTextureSize should be fine.  This way we get rid of the inner loop
> direction logic (which I agree is verbose and kind of confusing), and still have a chance to optimize the case where
> tiled snapshots are made up of 4 tiles or less (which I see as being the most frequent use case, in my experience
> anyway).

That sounds like a promising approach.

-------------

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

From kcr at openjdk.java.net  Sat May 16 14:29:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 16 May 2020 14:29:46 GMT
Subject: [Rev 01] RFR: 8237602: TabPane doesn't respect order of
 TabPane.getTabs() list
In-Reply-To: <5m9VY4PZGGkZibnrwUwEJcgTOqu5ev2A9UqudtACvik=.faf778f8-15a2-4e53-b52c-0016d68dd05d@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
 <5m9VY4PZGGkZibnrwUwEJcgTOqu5ev2A9UqudtACvik=.faf778f8-15a2-4e53-b52c-0016d68dd05d@github.com>
Message-ID: <i3lbV2LFzua-2EhgELWrUOwinUiURdZT8RbpNHEHRo0=.c613f09f-5b00-4dc6-b136-b33732fb0fdf@github.com>

On Mon, 11 May 2020 04:12:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Issue:
>> When tabs are permuted as mentioned in the issue description as,
>> 1. TabPane.getTabs().setAll(tab0, tab1)
>> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
>> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
>> 
>> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
>> => but are show in order as  tab2, tab3, tab0, tab1
>> 
>> Cause:
>> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
>> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
>> Fix:
>> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
>> 
>> Verification:
>> No existing tests fail due to this change.
>> Added a system test which fails without and pass with fix.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review-update: change test name

Marked as reviewed by kcr (Lead).

-------------

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

From fastegal at openjdk.java.net  Sun May 17 10:07:18 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sun, 17 May 2020 10:07:18 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <WmZDf0OUvv4fG4FWAgqXytPqMN73TfZ25iRLsvmu384=.4b97c674-04a2-4fc8-9fa7-a4476cc0b913@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <WmZDf0OUvv4fG4FWAgqXytPqMN73TfZ25iRLsvmu384=.4b97c674-04a2-4fc8-9fa7-a4476cc0b913@github.com>
Message-ID: <Gmsktldz4dtAJu_kfYprihVUFjJLTLwUjL_RlmVNL0A=.aef9e035-c516-409c-a546-0aced8d5c156@github.com>

On Tue, 12 May 2020 12:27:11 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Issue :
>> https://bugs.openjdk.java.net/browse/JDK-8244418
>> 
>> Root Cause :
>> Incorrect assumption about menu list size.
>> 
>> Fix :
>> Added check for empty menu list before trying to access it.
>> 
>> Test :
>> Added a unit test that fails before fix and passes after it.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review_fixes

modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuBarTest.java line 134:

> 133:         int focusedIndex = MenuBarSkinShim.getFocusedIndex(skin);
> 134:         assertEquals(focusedIndex, -1);
> 135:     }

the assert should be the other way round, expected value should be the first parameter :)

didn't notice on first read and now only when writing a test case against our argument, c&p'ed the test as-is, replaced
the requestFocus with simulating the notification from traversalListener and was confused about its value being -1

Here's that modified test method (requires test api in MenuBarSkin and shim):

    @Test public void testSimulateTraverseIntoOnEmptyMenubar() {
        menuBar.setFocusTraversable(true);

        AnchorPane root = new AnchorPane();
        root.getChildren().add(menuBar);
        startApp(root);

        MenuBarSkin skin = (MenuBarSkin)menuBar.getSkin();
        assertTrue(skin != null);

        // simulate notification from traversalListener
        MenuBarSkinShim.setFocusedIndex(skin, 0);
        int focusedIndex = MenuBarSkinShim.getFocusedIndex(skin);
        assertEquals(-1, focusedIndex);
    }

-------------

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

From ajoseph at openjdk.java.net  Mon May 18 05:15:18 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Mon, 18 May 2020 05:15:18 GMT
Subject: [Rev 02] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <Spm3_XbWn8yaTelufY0rHr8DOn_JyZDvmsi8DP74CtE=.ecc917e5-6330-4ca5-a92b-101c94b3f61d@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
 <Spm3_XbWn8yaTelufY0rHr8DOn_JyZDvmsi8DP74CtE=.ecc917e5-6330-4ca5-a92b-101c94b3f61d@github.com>
Message-ID: <WgH34Qg2sJioyZJUPj6XzZ-9lcSsAbQBcjMo0PkjhVc=.9a23627c-6bb4-473c-8da2-fd1aa0ce5eed@github.com>

On Sun, 10 May 2020 20:49:07 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

>> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
>> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
>> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
>> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
>> otherwise use usual way of rendering.
>
> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved Printing drawing path to non MaskTextureGraphics interface

modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 560:

> 559:                     } else {
> 560:                         Screen screen = g.getAssociatedScreen();
> 561:                         FilterContext filterContext;

This logic is already present in getFilterContext(). You can call the function instead.

-------------

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

From aghaisas at openjdk.java.net  Mon May 18 05:52:22 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 18 May 2020 05:52:22 GMT
Subject: [Rev 01] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <Gmsktldz4dtAJu_kfYprihVUFjJLTLwUjL_RlmVNL0A=.aef9e035-c516-409c-a546-0aced8d5c156@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <WmZDf0OUvv4fG4FWAgqXytPqMN73TfZ25iRLsvmu384=.4b97c674-04a2-4fc8-9fa7-a4476cc0b913@github.com>
 <Gmsktldz4dtAJu_kfYprihVUFjJLTLwUjL_RlmVNL0A=.aef9e035-c516-409c-a546-0aced8d5c156@github.com>
Message-ID: <yDUIcWtwecy2CiM9fgkxBDa1_LVtNzoSRIHgJ946vnU=.6e925bfb-49cc-4287-9e73-eb0750599f95@github.com>

On Sun, 17 May 2020 10:04:58 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review_fixes
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuBarTest.java line 134:
> 
>> 133:         int focusedIndex = MenuBarSkinShim.getFocusedIndex(skin);
>> 134:         assertEquals(focusedIndex, -1);
>> 135:     }
> 
> the assert should be the other way round, expected value should be the first parameter :)
> 
> didn't notice on first read and now only when writing a test case against our argument, c&p'ed the test as-is, replaced
> the requestFocus with simulating the notification from traversalListener and was confused about its value being -1
> Here's that modified test method (requires test api in MenuBarSkin and shim):
> 
>     @Test public void testSimulateTraverseIntoOnEmptyMenubar() {
>         menuBar.setFocusTraversable(true);
> 
>         AnchorPane root = new AnchorPane();
>         root.getChildren().add(menuBar);
>         startApp(root);
> 
>         MenuBarSkin skin = (MenuBarSkin)menuBar.getSkin();
>         assertTrue(skin != null);
> 
>         // simulate notification from traversalListener
>         MenuBarSkinShim.setFocusedIndex(skin, 0);
>         int focusedIndex = MenuBarSkinShim.getFocusedIndex(skin);
>         assertEquals(-1, focusedIndex);
>     }

Corrected the similar asserts in this file.

Thanks for suggestion on test. Yes. At best, we can simulate this with Shim.
I have added it now.

-------------

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

From aghaisas at openjdk.java.net  Mon May 18 05:52:21 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 18 May 2020 05:52:21 GMT
Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
Message-ID: <vWr49H-PAb_3XSwYiJcMI2tjblA_LYfeagWoRuBIplc=.024bc2fe-f2f2-40e8-af8a-21ee39b0b9b7@github.com>

> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244418
> 
> Root Cause :
> Incorrect assumption about menu list size.
> 
> Fix :
> Added check for empty menu list before trying to access it.
> 
> Test :
> Added a unit test that fails before fix and passes after it.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  review fixes and test addition

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/216/files
  - new: https://git.openjdk.java.net/jfx/pull/216/files/15c4de98..683849c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/216/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/216/webrev.01-02

  Stats: 35 lines in 3 files changed: 25 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/216.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/216/head:pull/216

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

From aghaisas at openjdk.java.net  Mon May 18 05:52:21 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 18 May 2020 05:52:21 GMT
Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <uBawAgtWOt6MrrtnMUpFOyzM8B6fAruTt6Kkqld_3Rk=.9be4c639-c896-4b45-a12c-bc40044839ee@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
 <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>
 <W_nmBpDF9IAIgCPq2UNsej62tS2pd-XNpNYyj2l0VIc=.26bc8a64-117e-4b69-9d2d-09402d419a7b@github.com>
 <c7RHR2S_u8CS604mJEn5AGpKAgMwbrunTEzx5trnvWo=.9bacb1a6-cf59-4ec6-b68f-03def550c527@github.com>
 <uBawAgtWOt6MrrtnMUpFOyzM8B6fAruTt6Kkqld_3Rk=.9be4c639-c896-4b45-a12c-bc40044839ee@github.com>
Message-ID: <S1dY2Kcy8FgOnDzJGzioOOSdzYAtn-kU-hUgz_xTESA=.ac28e59c-a4fc-4c29-b306-a342fb1b573d@github.com>

On Fri, 15 May 2020 09:29:27 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> I differ on this suggestion.
>> My thinking is - list access in setFocusedMenuIndex() method should have this check. It is not up to the caller to know
>> the internal details of the method. That's the root cause of Exception. I added another check in
>> menuBarFocusedPropertyListener because, it accesses the different list - container.getChildren(). In general, I feel,
>> the validity check near the list usage is logical and readable as well.
>
> hmm .. yeah I'm aware of getContainer vs. getMenus - but they should be the same size, shouldn't they?
> 
> Anyway, if focusedIndex != getMenus().indexOf all users of focusedIndex have to include a check for validity. That
> might be prevented by not allowing it here in the method, in setting its value not unconditionally to the given index
> but guard it against being valid:
>     focusedMenuIndex = index >= getMenus().size() ? -1 : index
> 
> Then focused is either valid or -1.

Good suggestion on not setting the foucusedMenuIndex unconditionally.
Also, we need to check for index < -1 : just to tighten up this method.
I have added this check.

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Mon May 18 07:06:02 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Mon, 18 May 2020 07:06:02 GMT
Subject: [Rev 01] RFR: 8181775: JavaFX WebView does not calculate
 border-radius properly
In-Reply-To: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com>
References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com>
Message-ID: <vz_71Ks7Y_iLjwevU4N1vO4VtfypI53LmkjdM1dq64U=.a6aae4ad-705c-46f5-8434-57ee4c561c24@github.com>

> root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four
> corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while
> rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it
> otherwise construct a path from given rounded rect and draw it.

Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:

  Removed wildcard import statement

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/218/files
  - new: https://git.openjdk.java.net/jfx/pull/218/files/a742ba43..e7cb98fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/218/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/218/webrev.00-01

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

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Mon May 18 08:00:38 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Mon, 18 May 2020 08:00:38 GMT
Subject: [Rev 03] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
Message-ID: <WoE5XJ3o8dheyRhV754boaN-h1N1kpWsO5SvIKg4Tgg=.9aeab587-5a48-4f68-8d20-e648771ce15a@github.com>

> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
> otherwise use usual way of rendering.

Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring, Utilize getFilterContext() function

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/213/files
  - new: https://git.openjdk.java.net/jfx/pull/213/files/5b85b47d..a55f9f23

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/213/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.02-03

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

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

From fastegal at openjdk.java.net  Mon May 18 09:54:05 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 18 May 2020 09:54:05 GMT
Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <vWr49H-PAb_3XSwYiJcMI2tjblA_LYfeagWoRuBIplc=.024bc2fe-f2f2-40e8-af8a-21ee39b0b9b7@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <vWr49H-PAb_3XSwYiJcMI2tjblA_LYfeagWoRuBIplc=.024bc2fe-f2f2-40e8-af8a-21ee39b0b9b7@github.com>
Message-ID: <iHqB4hK09J2Pxu6gLaUxgiqOfojDdVj7-jgT3kHG35M=.57c55022-2c50-4529-a803-89a28cbf3130@github.com>

On Mon, 18 May 2020 05:52:21 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Issue :
>> https://bugs.openjdk.java.net/browse/JDK-8244418
>> 
>> Root Cause :
>> Incorrect assumption about menu list size.
>> 
>> Fix :
>> Added check for empty menu list before trying to access it.
>> 
>> Test :
>> Added a unit test that fails before fix and passes after it.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fixes and test addition

looks fine :)

-------------

Marked as reviewed by fastegal (Author).

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

From fastegal at openjdk.java.net  Mon May 18 09:54:05 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 18 May 2020 09:54:05 GMT
Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on
 empty bar
In-Reply-To: <S1dY2Kcy8FgOnDzJGzioOOSdzYAtn-kU-hUgz_xTESA=.ac28e59c-a4fc-4c29-b306-a342fb1b573d@github.com>
References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com>
 <BKMErbU3VL0yZ5FYpTyHImksYGH-DpETieBemB_DV4E=.690d37c7-7d47-4fb7-babf-4f44f6958861@github.com>
 <VXu-k2Dg_ert50ebkXbHWyOnadoXlS5LgYGmVKwSqiU=.5067188d-5dfb-40f2-9639-0cfdc51bafac@github.com>
 <W_nmBpDF9IAIgCPq2UNsej62tS2pd-XNpNYyj2l0VIc=.26bc8a64-117e-4b69-9d2d-09402d419a7b@github.com>
 <c7RHR2S_u8CS604mJEn5AGpKAgMwbrunTEzx5trnvWo=.9bacb1a6-cf59-4ec6-b68f-03def550c527@github.com>
 <uBawAgtWOt6MrrtnMUpFOyzM8B6fAruTt6Kkqld_3Rk=.9be4c639-c896-4b45-a12c-bc40044839ee@github.com>
 <S1dY2Kcy8FgOnDzJGzioOOSdzYAtn-kU-hUgz_xTESA=.ac28e59c-a4fc-4c29-b306-a342fb1b573d@github.com>
Message-ID: <KGUE6STjYp2FHgs34xBt501LIgmCK7UmLWfW_1F7gl4=.674b9571-9e88-4508-ac57-dbb640499174@github.com>

On Mon, 18 May 2020 05:42:17 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> hmm .. yeah I'm aware of getContainer vs. getMenus - but they should be the same size, shouldn't they?
>> 
>> Anyway, if focusedIndex != getMenus().indexOf all users of focusedIndex have to include a check for validity. That
>> might be prevented by not allowing it here in the method, in setting its value not unconditionally to the given index
>> but guard it against being valid:
>>     focusedMenuIndex = index >= getMenus().size() ? -1 : index
>> 
>> Then focused is either valid or -1.
>
> Good suggestion on not setting the foucusedMenuIndex unconditionally.
> Also, we need to check for index < -1 : just to tighten up this method.
> I have added this check.

glad we came to an agreement at last :)

-------------

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

From fastegal at openjdk.java.net  Mon May 18 09:56:02 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 18 May 2020 09:56:02 GMT
Subject: [Rev 01] RFR: 8237602: TabPane doesn't respect order of
 TabPane.getTabs() list
In-Reply-To: <5m9VY4PZGGkZibnrwUwEJcgTOqu5ev2A9UqudtACvik=.faf778f8-15a2-4e53-b52c-0016d68dd05d@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
 <5m9VY4PZGGkZibnrwUwEJcgTOqu5ev2A9UqudtACvik=.faf778f8-15a2-4e53-b52c-0016d68dd05d@github.com>
Message-ID: <JBITTY5QqCDyUupfauzbYFcFeJ0Ke9Fg8tzsighoZnI=.b6cf8ff6-19f8-48a8-a2dc-6ced8761c0cd@github.com>

On Mon, 11 May 2020 04:12:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Issue:
>> When tabs are permuted as mentioned in the issue description as,
>> 1. TabPane.getTabs().setAll(tab0, tab1)
>> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
>> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
>> 
>> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
>> => but are show in order as  tab2, tab3, tab0, tab1
>> 
>> Cause:
>> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
>> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
>> Fix:
>> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
>> 
>> Verification:
>> No existing tests fail due to this change.
>> Added a system test which fails without and pass with fix.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review-update: change test name

tests are passing, what else can we achieve with a fix :) Looks good!

-------------

Marked as reviewed by fastegal (Author).

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

From arapte at openjdk.java.net  Mon May 18 10:27:31 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 18 May 2020 10:27:31 GMT
Subject: [Integrated] RFR: 8237602: TabPane doesn't respect order of
 TabPane.getTabs() list
In-Reply-To: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
References: <d1CpKaVl8oKiuk80xWYOue_89foHzSPIDtYYxmAZrjM=.127fdc7c-dc9d-4fe2-8a09-ae7ffbef1b83@github.com>
Message-ID: <YTXojNDZNUWmwNbHaqUDNHs1RmR1EhWq9fNRbSLmWIQ=.40be7ef5-6003-4a07-83ca-7006c0ca2ff1@github.com>

On Wed, 29 Apr 2020 04:40:59 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> When tabs are permuted as mentioned in the issue description as,
> 1. TabPane.getTabs().setAll(tab0, tab1)
> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
> 
> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
> => but are show in order as  tab2, tab3, tab0, tab1
> 
> Cause:
> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
> Fix:
> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
> 
> Verification:
> No existing tests fail due to this change.
> Added a system test which fails without and pass with fix.

This pull request has now been integrated.

Changeset: 6e039302
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/6e039302
Stats:     71 lines in 2 files changed: 2 ins; 65 del; 4 mod

8237602: TabPane doesn't respect order of TabPane.getTabs() list

Reviewed-by: kcr, fastegal

-------------

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

From fastegal at openjdk.java.net  Mon May 18 12:12:54 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 18 May 2020 12:12:54 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues with
 controls et al
Message-ID: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>

It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)

Basically, there's a utility class
- to access lists of all control/classes,
- to access/create all behaviors
- has alternative skins classes for all controls and utility to install/replace skins

POC:
- has test examples (not run in normal testing due to not following naming conventions) for using
- changed SkinDisposeContractTest to use

-------------

Commit messages:
 - 8244531: Tests: add support to identify recurring issues with controls

Changes: https://git.openjdk.java.net/jfx/pull/223/files
 Webrev: https://webrevs.openjdk.java.net/jfx/223/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244531
  Stats: 1243 lines in 6 files changed: 1141 ins; 97 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/223.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/223/head:pull/223

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

From aghaisas at openjdk.java.net  Mon May 18 12:31:19 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 18 May 2020 12:31:19 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
Message-ID: <02YQmaXQbHw9HdHnLF-zddlIzJ2EZMQtOd1F8Mdoe0I=.f5c39f9e-0612-4677-9826-40baa561145a@github.com>

On Mon, 18 May 2020 12:07:30 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
> 
> Basically, there's a utility class
> - to access lists of all control/classes,
> - to access/create all behaviors
> - has alternative skins classes for all controls and utility to install/replace skins
> 
> POC:
> - has test examples (not run in normal testing due to not following naming conventions) for using
> - changed SkinDisposeContractTest to use

I have not reviewed this PR yet, but a quick comment - Can we enable  and fix currently Ignored ControlSkinTest with
this?

-------------

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

From fastegal at openjdk.java.net  Mon May 18 13:30:01 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 18 May 2020 13:30:01 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <02YQmaXQbHw9HdHnLF-zddlIzJ2EZMQtOd1F8Mdoe0I=.f5c39f9e-0612-4677-9826-40baa561145a@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <02YQmaXQbHw9HdHnLF-zddlIzJ2EZMQtOd1F8Mdoe0I=.f5c39f9e-0612-4677-9826-40baa561145a@github.com>
Message-ID: <knm6QjUAag3ncUOc1eExt7YHjT4hbF_8ttJu5KdQfWM=.c2094d04-fa61-4f4c-b2cc-0c3de9c8b621@github.com>

On Mon, 18 May 2020 12:29:05 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>  Can we enable and fix currently Ignored ControlSkinTest with this?

will check, always ignored that test :)

-------------

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

From fastegal at openjdk.java.net  Mon May 18 13:41:32 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 18 May 2020 13:41:32 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <knm6QjUAag3ncUOc1eExt7YHjT4hbF_8ttJu5KdQfWM=.c2094d04-fa61-4f4c-b2cc-0c3de9c8b621@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <02YQmaXQbHw9HdHnLF-zddlIzJ2EZMQtOd1F8Mdoe0I=.f5c39f9e-0612-4677-9826-40baa561145a@github.com>
 <knm6QjUAag3ncUOc1eExt7YHjT4hbF_8ttJu5KdQfWM=.c2094d04-fa61-4f4c-b2cc-0c3de9c8b621@github.com>
Message-ID: <Ksi5VRQ4Oj3Liay4NwkHnKtcr9mJeQTXcr9wmJKn_eU=.69951ece-071c-47db-96ed-c93d07115fa4@github.com>

On Mon, 18 May 2020 13:27:52 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> I have not reviewed this PR yet, but a quick comment - Can we enable  and fix currently Ignored ControlSkinTest with
>> this?
>
>>  Can we enable and fix currently Ignored ControlSkinTest with this?
> 
> will check, always ignored that test :)

direct re-enable probably is not possible, but I think we can re-write most of it (not sure about the css stuff) - that
would be a follow-up issue.

-------------

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

From ajoseph at openjdk.java.net  Mon May 18 16:38:47 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Mon, 18 May 2020 16:38:47 GMT
Subject: [Rev 03] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <WoE5XJ3o8dheyRhV754boaN-h1N1kpWsO5SvIKg4Tgg=.9aeab587-5a48-4f68-8d20-e648771ce15a@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
 <WoE5XJ3o8dheyRhV754boaN-h1N1kpWsO5SvIKg4Tgg=.9aeab587-5a48-4f68-8d20-e648771ce15a@github.com>
Message-ID: <gMYlkdB_SHPuJr52YlMqDJRz_VigLDw_6zx_gg7uagE=.d063886b-fa4f-4b8a-8672-cc25757aac72@github.com>

On Mon, 18 May 2020 08:00:38 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

>> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
>> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
>> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
>> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
>> otherwise use usual way of rendering.
>
> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring, Utilize getFilterContext() function

modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 536:

> 535:                     RTTexture paintRtTexture = g.getResourceFactory().createRTTexture(
> 536:                             (int) Math.ceil(transformedRect.width),
> 537:                             (int) Math.ceil(transformedRect.height),

transformedRect's height and width are already of type int

-------------

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

From github.com+3197675+abhinayagarwal at openjdk.java.net  Tue May 19 08:10:40 2020
From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal)
Date: Tue, 19 May 2020 08:10:40 GMT
Subject: [Rev 01] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
Message-ID: <1mHJgWoN1yMbw2bx_8AFnNU7dZ_GFmBNXL1pya_REhE=.5af5f306-0743-455a-8603-1d68a7e59ab6@github.com>

> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
> should be shown again when the user taps on the TextInputControl.
> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
> both editable and focused.

Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:

  Remove listeners in dispose method

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/219/files
  - new: https://git.openjdk.java.net/jfx/pull/219/files/6f56d48d..9b7d54f4

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/219/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/219/webrev.00-01

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

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

From github.com+3197675+abhinayagarwal at openjdk.java.net  Tue May 19 08:10:48 2020
From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal)
Date: Tue, 19 May 2020 08:10:48 GMT
Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has
 focus
In-Reply-To: <9Lo_Y6wJ7IuZKINGGkRLGaRvqxBtznfG7Z_FhlB8f2g=.510eb3af-df74-4e18-93c4-6b83c044fbf8@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <9Lo_Y6wJ7IuZKINGGkRLGaRvqxBtznfG7Z_FhlB8f2g=.510eb3af-df74-4e18-93c4-6b83c044fbf8@github.com>
Message-ID: <mawoL8rf57duexV6tcDEzxtFBkuhdEpRupopsBw0QOM=.3a4d9ede-0056-4d40-99ee-53db555a7053@github.com>

On Fri, 15 May 2020 10:58:14 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
>> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
>> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
>> should be shown again when the user taps on the TextInputControl.
>> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
>> both editable and focused.
>
> out off my home-zone here, just fyi and in case it might be relevant to android skins as well: there's an umbrella
> issue to cleanup skin implementations [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364) - both the
> android text skins look like leaking in the manually registered focus listener (not introduced here) and the
> eventHandler added here. Probably should be removed manually in dispose (or in the case of the focusListener,
> registered via skin api).

@kleopatra Done!

-------------

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

From fastegal at openjdk.java.net  Tue May 19 09:22:03 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 19 May 2020 09:22:03 GMT
Subject: [Rev 01] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <1mHJgWoN1yMbw2bx_8AFnNU7dZ_GFmBNXL1pya_REhE=.5af5f306-0743-455a-8603-1d68a7e59ab6@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <1mHJgWoN1yMbw2bx_8AFnNU7dZ_GFmBNXL1pya_REhE=.5af5f306-0743-455a-8603-1d68a7e59ab6@github.com>
Message-ID: <KTBIo0lo4KxAFYgc8ImxkdgEbC-7ohGWB1U4Cqb453g=.46701990-1aa1-4448-9f66-4719fbff5c00@github.com>

On Tue, 19 May 2020 08:10:40 GMT, Abhinay Agarwal <github.com+3197675+abhinayagarwal at openjdk.org> wrote:

>> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
>> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
>> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
>> should be shown again when the user taps on the TextInputControl.
>> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
>> both editable and focused.
>
> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove listeners in dispose method

modules/javafx.controls/src/android/java/javafx/scene/control/skin/TextAreaSkinAndroid.java line 81:

> 80:         getSkinnable().focusedProperty().removeListener(weakFocusChangeListener);
> 81:         super.dispose();
> 82:     }

good :) Next step is to implement dispose according to contract (see JDK-8244112). Currently the pattern in dispose is
something like:

    if (getSkinnable() == null) return;
    ... do cleanup for this skin
    super.dispose();

-------------

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

From fastegal at openjdk.java.net  Tue May 19 09:25:46 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 19 May 2020 09:25:46 GMT
Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has
 focus
In-Reply-To: <mawoL8rf57duexV6tcDEzxtFBkuhdEpRupopsBw0QOM=.3a4d9ede-0056-4d40-99ee-53db555a7053@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <9Lo_Y6wJ7IuZKINGGkRLGaRvqxBtznfG7Z_FhlB8f2g=.510eb3af-df74-4e18-93c4-6b83c044fbf8@github.com>
 <mawoL8rf57duexV6tcDEzxtFBkuhdEpRupopsBw0QOM=.3a4d9ede-0056-4d40-99ee-53db555a7053@github.com>
Message-ID: <p_s8bkK2_x16A5fSb4zDpMfCHrH5FnHJ0I3ovmDDZ2E=.454d32f9-eded-43db-a3f5-87f2a42cee40@github.com>

On Tue, 19 May 2020 08:08:44 GMT, Abhinay Agarwal <github.com+3197675+abhinayagarwal at openjdk.org> wrote:

>> out off my home-zone here, just fyi and in case it might be relevant to android skins as well: there's an umbrella
>> issue to cleanup skin implementations [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364) - both the
>> android text skins look like leaking in the manually registered focus listener (not introduced here) and the
>> eventHandler added here. Probably should be removed manually in dispose (or in the case of the focusListener,
>> registered via skin api).
>
> @kleopatra Done!

wondering if there is any way to include android specific skins in unit testing? For all (nearly, htmlEditor excluded
;) others we have a test to guard against contract violations (and will soon have tests for memory leaks).

-------------

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

From github.com+4208131+bhaweshkc at openjdk.java.net  Tue May 19 10:13:44 2020
From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary)
Date: Tue, 19 May 2020 10:13:44 GMT
Subject: [Rev 04] RFR: 8218973: SVG with masking is not rendering image
 with mask effect
In-Reply-To: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
References: <MOlG60irIHGam0w-637jQ7xPyrtN8godqm9ptA1sQrY=.e3df43fc-424a-45ca-ad56-0bd354b5c22f@github.com>
Message-ID: <ixvZDZW13LsmqOwQ7XQY7AZ9dp4oWH5eQQ8qzi_Leks=.9e093c8c-e6fd-4f45-ac8c-c854f1af18b0@github.com>

> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java  While rendering in
> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface
> otherwise use usual way of rendering.

Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessery Ceil Functions

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/213/files
  - new: https://git.openjdk.java.net/jfx/pull/213/files/a55f9f23..f0c217ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/213/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.03-04

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

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

From github.com+3197675+abhinayagarwal at openjdk.java.net  Tue May 19 10:19:42 2020
From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal)
Date: Tue, 19 May 2020 10:19:42 GMT
Subject: [Rev 02] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
Message-ID: <Qt9IsXZMTyupI_CxZUpwAHZRvN_z-HlhT4PBMaQ43uU=.0edb8bb7-4dc0-45bb-a78a-189bcfdc8794@github.com>

> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
> should be shown again when the user taps on the TextInputControl.
> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
> both editable and focused.

Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:

  Skin implementation must maintain the contract of dispose

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/219/files
  - new: https://git.openjdk.java.net/jfx/pull/219/files/9b7d54f4..0b22747f

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/219/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/219/webrev.01-02

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

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

From aghaisas at openjdk.java.net  Tue May 19 10:31:12 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 19 May 2020 10:31:12 GMT
Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren
 logs an exception
In-Reply-To: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>
References: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>
Message-ID: <baP6rDp4Nb4-miqO_53bwZdfqZTuZeBVgW7VuGlTkys=.d68f6603-a5bb-478c-a12a-bde1f3c62c4a@github.com>

On Tue, 19 May 2020 10:25:24 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245181
> 
> Root cause : The exception just gets logged and does not result in test failure.
> 
> Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this
> mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I
> have removed System.out.printlns that were causing log pollution.

I completed the work with an incorrect branch name. I will continue using this branch only for this fix.

-------------

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

From aghaisas at openjdk.java.net  Tue May 19 10:31:04 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 19 May 2020 10:31:04 GMT
Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren logs
 an exception
Message-ID: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>

Issue : https://bugs.openjdk.java.net/browse/JDK-8245181

Root cause : The exception just gets logged and does not result in test failure.

Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this
mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I
have removed System.out.printlns that were causing log pollution.

-------------

Commit messages:
 - fix_8245181

Changes: https://git.openjdk.java.net/jfx/pull/224/files
 Webrev: https://webrevs.openjdk.java.net/jfx/224/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245181
  Stats: 32 lines in 2 files changed: 24 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/224.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/224/head:pull/224

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

From kcr at openjdk.java.net  Tue May 19 11:41:13 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 19 May 2020 11:41:13 GMT
Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren
 logs an exception
In-Reply-To: <baP6rDp4Nb4-miqO_53bwZdfqZTuZeBVgW7VuGlTkys=.d68f6603-a5bb-478c-a12a-bde1f3c62c4a@github.com>
References: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>
 <baP6rDp4Nb4-miqO_53bwZdfqZTuZeBVgW7VuGlTkys=.d68f6603-a5bb-478c-a12a-bde1f3c62c4a@github.com>
Message-ID: <vAxyeSEK_1rKhrjXMDR3rMWZSqwQl08Vl0PimrjKqek=.51e32c8d-6db7-4a7c-8035-600ad14eba79@github.com>

On Tue, 19 May 2020 10:29:12 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Issue : https://bugs.openjdk.java.net/browse/JDK-8245181
>> 
>> Root cause : The exception just gets logged and does not result in test failure.
>> 
>> Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this
>> mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I
>> have removed System.out.printlns that were causing log pollution.
>
> I completed the work with an incorrect branch name. I will continue using this branch only for this fix.

So the exception was pointing out an actual bug in the implementation, but it wasn't causing a test failure. Even
though this isn't a test-only bug, it looks simple enough that a single reviewer should suffice.

-------------

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

From github.com+3197675+abhinayagarwal at openjdk.java.net  Tue May 19 14:00:05 2020
From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal)
Date: Tue, 19 May 2020 14:00:05 GMT
Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has
 focus
In-Reply-To: <p_s8bkK2_x16A5fSb4zDpMfCHrH5FnHJ0I3ovmDDZ2E=.454d32f9-eded-43db-a3f5-87f2a42cee40@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <9Lo_Y6wJ7IuZKINGGkRLGaRvqxBtznfG7Z_FhlB8f2g=.510eb3af-df74-4e18-93c4-6b83c044fbf8@github.com>
 <mawoL8rf57duexV6tcDEzxtFBkuhdEpRupopsBw0QOM=.3a4d9ede-0056-4d40-99ee-53db555a7053@github.com>
 <p_s8bkK2_x16A5fSb4zDpMfCHrH5FnHJ0I3ovmDDZ2E=.454d32f9-eded-43db-a3f5-87f2a42cee40@github.com>
Message-ID: <BnopeB9pBoJpzrT-JbkLI6SpGLX1QFYZToVgy_CTdfY=.254ed0b7-f39f-4458-a8e8-f4b6f8c18b15@github.com>

On Tue, 19 May 2020 09:23:38 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> @kleopatra Done!
>
> wondering if there is any way to include android specific skins in unit testing? For all (nearly, htmlEditor excluded
> ;) others we have a test to guard against contract violations (and will soon have tests for memory leaks).

Indeed. It would be good if we could add a few Android specific tests which are automatically activated when
`-PCOMPILE_TARGETS=android` is passed to Gradle.

-------------

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

From aghaisas at openjdk.java.net  Tue May 19 14:29:54 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 19 May 2020 14:29:54 GMT
Subject: RFR: 8244824: TableView : Incorrect German translation
In-Reply-To: <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com>
References: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>
 <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com>
Message-ID: <m0wUncaqwnK1OPSkv4x-M9PNyoTOYoq5w4Sm5-XO4L8=.c46e7b78-159d-4552-bc6d-71605fd02047@github.com>

On Fri, 15 May 2020 09:47:09 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Issue : https://bugs.openjdk.java.net/browse/JDK-8244824
>> 
>> Fix : As simple as it gets !!!
>
> Correct :)

@kevinrushforth brought to my notice that there is a PR (https://github.com/openjdk/jfx/pull/210) opened for the same
issue by [schelldorfer](https://github.com/schelldorfer). I was not aware of this PR as it did not have 'rfr' label -
which I look for. I picked up this issue from JBS and submitted the solution mentioned in JBS.

I would *NOT* like to step on a new contributor's contribution.

Now, I see that the original PR has been closed. Once his signed OCA has been recorded, we have two options :
1. I will integrate with this PR with due attribution given to  [schelldorfer](https://github.com/schelldorfer)
OR
2. I will withdraw my PR without integrating and [schelldorfer](https://github.com/schelldorfer) can reopen and submit
his PR.

-------------

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

From kcr at openjdk.java.net  Tue May 19 14:40:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 19 May 2020 14:40:06 GMT
Subject: RFR: 8244824: TableView : Incorrect German translation
In-Reply-To: <m0wUncaqwnK1OPSkv4x-M9PNyoTOYoq5w4Sm5-XO4L8=.c46e7b78-159d-4552-bc6d-71605fd02047@github.com>
References: <KTENJNJeAceOnqgiHPJDwwl9VUWRw9xvhMbyuKCpf5s=.c46d147d-5588-4084-9d28-6bb86bc57371@github.com>
 <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com>
 <m0wUncaqwnK1OPSkv4x-M9PNyoTOYoq5w4Sm5-XO4L8=.c46e7b78-159d-4552-bc6d-71605fd02047@github.com>
Message-ID: <Gi75jmJN2s5GTTJNLL74TDzY_JC0Db-hSYE8MuzP_Ec=.de998af4-e7dd-4d8b-b0ad-f9699a1df492@github.com>

On Tue, 19 May 2020 14:27:40 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Correct :)
>
> @kevinrushforth brought to my notice that there is a PR (https://github.com/openjdk/jfx/pull/210) opened for the same
> issue by [schelldorfer](https://github.com/schelldorfer). I was not aware of this PR as it did not have 'rfr' label -
> which I look for. I picked up this issue from JBS and submitted the solution mentioned in JBS.
> I would *NOT* like to step on a new contributor's contribution.
> 
> Now, I see that the original PR has been closed. Once his signed OCA has been recorded, we have two options :
> 1. I will integrate with this PR with due attribution given to  [schelldorfer](https://github.com/schelldorfer)
> OR
> 2. I will withdraw my PR without integrating and [schelldorfer](https://github.com/schelldorfer) can reopen and submit
> his PR.

@aghaisas that sounds fine to me. In order to attribute the fix, you will need to wait for the OCA to be recorded.

@schelldorfer once your OCA is recorded, which would you prefer to do? Create a new PR yourself or have @aghaisas list
you as the contributor.

-------------

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

From aghaisas at openjdk.java.net  Wed May 20 06:29:52 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 20 May 2020 06:29:52 GMT
Subject: RFR: 8245183: Two fxml unit tests log warnings about deprecated
 escape sequences
Message-ID: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>

Issue : https://bugs.openjdk.java.net/browse/JDK-8245183
Fix : Added a message to the test saying these are expected warnings. Refer JBS comments for more details.

-------------

Commit messages:
 - Add expected warning message

Changes: https://git.openjdk.java.net/jfx/pull/225/files
 Webrev: https://webrevs.openjdk.java.net/jfx/225/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245183
  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/225.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/225/head:pull/225

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

From fastegal at openjdk.java.net  Wed May 20 11:21:16 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 20 May 2020 11:21:16 GMT
Subject: RFR: 8245282: ButtonBehavior: memory leak on dispose
Message-ID: <eJ0Oi1aFh_7v38NGYfBYzrzm-OhJNK_uhN4PBnBHTzI=.4f745c55-3a19-45db-801d-f0769c98abb8@github.com>

Reason for the memory leak is a listener on control's focusProperty that is not correctly removed on dispose. For
details please see the report.

Added a test method to ButtonSkinTest that failed before and passes after the fix.

-------------

Commit messages:
 - 8245282: ButtonBehavior: memory leak on dispose

Changes: https://git.openjdk.java.net/jfx/pull/226/files
 Webrev: https://webrevs.openjdk.java.net/jfx/226/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245282
  Stats: 22 lines in 2 files changed: 17 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/226.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/226/head:pull/226

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

From aghaisas at openjdk.java.net  Wed May 20 11:51:01 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 20 May 2020 11:51:01 GMT
Subject: RFR: 8245457: [TestBug] Enable and fix ignored tests in
 ButtonBaseTest & ButtonTest
Message-ID: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>

Issue : https://bugs.openjdk.java.net/browse/JDK-8245457

Fix : It is a simple test fix. I have enabled the ignored tests from ButtonBaseTest & ButtonTest test classes & fixed
them. Also removed a print to std.out.

-------------

Commit messages:
 - enable ignored unit tests

Changes: https://git.openjdk.java.net/jfx/pull/227/files
 Webrev: https://webrevs.openjdk.java.net/jfx/227/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245457
  Stats: 36 lines in 2 files changed: 25 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/227.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/227/head:pull/227

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

From jpereda at openjdk.java.net  Wed May 20 11:52:50 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Wed, 20 May 2020 11:52:50 GMT
Subject: RFR: 8245456: MacPasteboard throws ClassCastException on static builds
Message-ID: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>

Trying to paste on a JavaFX app statically built on Mac OS throws:

Exception in thread "JavaFX Application Thread" java.lang.ClassCastException
        at         at com.sun.glass.ui.mac.MacPasteboard._getUTFs(MacPasteboard.java)
 

Checking the native method signature a `String[][]` type is expected. However the native method implementation uses:
jobjectArray utfs = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/Object"), NULL);
for (items) {
     jobjectArray array = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/String"), NULL);
}

This PR fixes the issue by applying the correct array type signature according to [JNI
specs](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#findclass).

It has been tested on Mac OS, both with and without static build.

-------------

Commit messages:
 - Use correct array type signature

Changes: https://git.openjdk.java.net/jfx/pull/228/files
 Webrev: https://webrevs.openjdk.java.net/jfx/228/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245456
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/228.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/228/head:pull/228

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

From kcr at openjdk.java.net  Wed May 20 12:20:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 May 2020 12:20:02 GMT
Subject: RFR: 8245456: MacPasteboard throws ClassCastException on static
 builds
In-Reply-To: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>
References: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>
Message-ID: <TIykC6fjp5tbIQnTljVrFSNDJrDYj5nVbbckusT-OhA=.e9d40d82-9b9b-4da4-abac-4cba15265ef9@github.com>

On Wed, 20 May 2020 11:47:29 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Trying to paste on a JavaFX app statically built on Mac OS throws:
> 
> Exception in thread "JavaFX Application Thread" java.lang.ClassCastException
>         at         at com.sun.glass.ui.mac.MacPasteboard._getUTFs(MacPasteboard.java)
>  
> 
> Checking the native method signature a `String[][]` type is expected. However the native method implementation uses:
> jobjectArray utfs = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/Object"), NULL);
> for (items) {
>      jobjectArray array = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/String"), NULL);
> }
> 
> This PR fixes the issue by applying the correct array type signature according to [JNI
> specs](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#findclass).
> It has been tested on Mac OS, both with and without static build.

So this is a case where native image exposed a latent bug in FX. Would this have been caught by `-Xcheck:jni`? (I hope
it would have). We aren't in the habit of regularly running tests with that option, but maybe we should do it more
often.

-------------

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

From kcr at openjdk.java.net  Wed May 20 12:24:32 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 May 2020 12:24:32 GMT
Subject: RFR: 8245456: MacPasteboard throws ClassCastException on static
 builds
In-Reply-To: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>
References: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>
Message-ID: <r0g_3uncQQX8IF2znTltTfKX14Ts71Jr0z8-5s5rYvU=.d23cd047-7e04-4622-90b6-d117e0254cf1@github.com>

On Wed, 20 May 2020 11:47:29 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Trying to paste on a JavaFX app statically built on Mac OS throws:
> 
> Exception in thread "JavaFX Application Thread" java.lang.ClassCastException
>         at         at com.sun.glass.ui.mac.MacPasteboard._getUTFs(MacPasteboard.java)
>  
> 
> Checking the native method signature a `String[][]` type is expected. However the native method implementation uses:
> jobjectArray utfs = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/Object"), NULL);
> for (items) {
>      jobjectArray array = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/String"), NULL);
> }
> 
> This PR fixes the issue by applying the correct array type signature according to [JNI
> specs](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#findclass).
> It has been tested on Mac OS, both with and without static build.

Marked as reviewed by kcr (Lead).

-------------

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

From jpereda at openjdk.java.net  Wed May 20 13:24:02 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Wed, 20 May 2020 13:24:02 GMT
Subject: [Integrated] RFR: 8245456: MacPasteboard throws
 ClassCastException on static builds
In-Reply-To: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>
References: <F_aeh-LRXgyDbEO_lVQH0Fp6B-fsq7yMMLqwO_AL1RU=.a0a60be7-17a6-42f5-8ae4-c2baaf811382@github.com>
Message-ID: <Nfery1Lus0-hX8QoWNuqL13OgxMNA4es8qjFrQcDalA=.ba444009-5e89-4949-b1ad-f0a53ebe3288@github.com>

On Wed, 20 May 2020 11:47:29 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Trying to paste on a JavaFX app statically built on Mac OS throws:
> 
> Exception in thread "JavaFX Application Thread" java.lang.ClassCastException
>         at         at com.sun.glass.ui.mac.MacPasteboard._getUTFs(MacPasteboard.java)
>  
> 
> Checking the native method signature a `String[][]` type is expected. However the native method implementation uses:
> jobjectArray utfs = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/Object"), NULL);
> for (items) {
>      jobjectArray array = (*env)->NewObjectArray(env, size, (*env)->FindClass(env, "java/lang/String"), NULL);
> }
> 
> This PR fixes the issue by applying the correct array type signature according to [JNI
> specs](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#findclass).
> It has been tested on Mac OS, both with and without static build.

This pull request has now been integrated.

Changeset: 37b5edc7
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/37b5edc7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8245456: MacPasteboard throws ClassCastException on static builds

Reviewed-by: kcr

-------------

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

From fastegal at openjdk.java.net  Wed May 20 13:49:35 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 20 May 2020 13:49:35 GMT
Subject: RFR: WIP: 8245282: ButtonBehavior: memory leak on dispose
In-Reply-To: <eJ0Oi1aFh_7v38NGYfBYzrzm-OhJNK_uhN4PBnBHTzI=.4f745c55-3a19-45db-801d-f0769c98abb8@github.com>
References: <eJ0Oi1aFh_7v38NGYfBYzrzm-OhJNK_uhN4PBnBHTzI=.4f745c55-3a19-45db-801d-f0769c98abb8@github.com>
Message-ID: <S3UtEd9rtD8ExZrOZt2hljZ2FOGVeXFJYLvmXM2Io-Y=.90bfbf06-6b33-4877-80df-7ceba6653a32@github.com>

On Wed, 20 May 2020 11:15:34 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> Reason for the memory leak is a listener on control's focusProperty that is not correctly removed on dispose. For
> details please see the report.
> Added a test method to ButtonSkinTest that failed before and passes after the fix.

changed to WIP: just noticed that all ComboXXBehaviors have exactly the same issue with exactly the same fix. So will
widen the bug report to include these as well and wait with fixing this until JDK-8244531 is integrated (which can then
be used here for cross-behavior tests)

-------------

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

From Rony.Flatscher at wu.ac.at  Wed May 20 14:13:52 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Wed, 20 May 2020 16:13:52 +0200
Subject: Questions ad JavaScript in JavaFX' WebEngine
In-Reply-To: <CANEZrP1fFUyWFrn68_py68Qeamc+fWhEshsiAqZb-_5NOb=BLw@mail.gmail.com>
References: <ddb1f55d-e9fa-eaea-a3dc-d73a72732a76@wu.ac.at>
 <0b0d08fd-992b-6dc9-09c5-9589c7a9b805@oracle.com>
 <0233cb09-a33e-fd54-4399-436165747200@wu.ac.at>
 <CANEZrP1fFUyWFrn68_py68Qeamc+fWhEshsiAqZb-_5NOb=BLw@mail.gmail.com>
Message-ID: <3c573b78-832d-da17-41cd-1da239c53df6@wu.ac.at>

Hi Mike,

thank you for your pointers!

On 14.05.2020 14:21, Mike Hearn wrote:
> The WebKit binding code is some of the more complex code in JavaFX. Rather than try to extend the
> script tag you could instead look at the code for the <object> tag and the old support for
> Netscape-style plugins.?
>
> https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebCore/plugins
>
> I've looked at this in the past to investigate embedding of arbitrary JavaFX nodes into a web
> page. It doesn't look particularly unfeasible as there's still a lot of old code lying around that
> used to do exactly that, it's just not used much anymore. However wiring it up to the Java level
> would require a fairly adventurous programmer with good knowledge of C++, rendering engines and
> JavaFX internals.

In the meantime I had some time to peek around that location which is quite interesting!

What I would be interested in is a possibility to get callbacks into Java while the DOM tree gets
built, such that one could run scripts and define script callbacks for plain HTML text.

The idea would be to think about possibilities to enable all of the Java script languages to become
usable as script languages for HTML, i.e. for WebView applications.

As it stands now it should be possible with the help of WebEngine to process the DOM tree after
loading concluded and process and set up event attribute scripts, if necessary. (Again, this is a
very coarse idea at the moment.)

---rony


>
> On Mon, May 11, 2020 at 14:17:07, Rony G. Flatscher <Rony.Flatscher at wu.ac.at
> <mailto:Rony.Flatscher at wu.ac.at>> wrote:
>
>     On 09.05.2020 17:23, Kevin Rushforth wrote:
>
>         WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The sources are in the
>         jfx repo, along with the JavaFX-specific classes that implement the two-way Java <-->
>         JavaScript bridge. Other than the public API docs for WebEngine, which you referred to in
>         your message, there isn't any documentation of the interface.
>
>     OK, thank you very much, this is reassuring! :)
>
>         What sort of information are you looking for?
>
>     Well, as event handlers and script tags in HTML have a type attribute that allows to denote
>     script languages other than JavaScript, I am interested in evaluating what WebEngine/WebView
>     allows for to support this with any of the Java script engines.
>
>     ---rony
>
>         On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
>
>             Wondering which JavaScript engine gets referred to in WebEngine [1].
>
>             In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn gets
>             removed from the next [3] version? In case it is WebKit's JavaScriptCore [4] where can
>             one study the interface from WebEngine to it?
>
>             ---rony
>
>             [1] WebEngine:
>             <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html
>             <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html>>
>             [2] Nashorn: <https://openjdk.java.net/projects/nashorn/
>             <https://openjdk.java.net/projects/nashorn/>>
>             [3] Nashorn removal from JDK 15: <https://openjdk.java.net/jeps/372
>             <https://openjdk.java.net/jeps/372>>
>             [4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore
>             <https://trac.webkit.org/wiki/JavaScriptCore>>
>
>

From ajoseph at openjdk.java.net  Wed May 20 14:35:49 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Wed, 20 May 2020 14:35:49 GMT
Subject: RFR: 8244579: Windows "User Objects" leakage with WebView
Message-ID: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>

Cause: The Window Class `RunLoopMessageWindow` is never registered (this happens because
registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx uses MainThreadJava.cpp) and this
causes every setTimer() to create a new user object instead of reusing the same object over again.

Fix: Call registerRunLoopMessageWindowClass() from MainThreadJava.cpp

Test: To verify open any webpage using WebView on WIndows, with and without the fix and compare the number of user
objects created using Windows Task Manager.

-------------

Commit messages:
 - 8244579: Windows "User Objects" leakage with WebView

Changes: https://git.openjdk.java.net/jfx/pull/229/files
 Webrev: https://webrevs.openjdk.java.net/jfx/229/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244579
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/229.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/229/head:pull/229

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

From kcr at openjdk.java.net  Wed May 20 15:18:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 May 2020 15:18:16 GMT
Subject: RFR: 8244579: Windows "User Objects" leakage with WebView
In-Reply-To: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
References: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
Message-ID: <yLpn8qvAuC9M48GZEGgPcvmMf3eIxS0i_SoMDpuwXX4=.60b17b11-917f-48c8-a290-2f0751a11939@github.com>

On Wed, 20 May 2020 14:30:11 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Cause: The Window Class `RunLoopMessageWindow` is never registered (this happens because
> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx uses MainThreadJava.cpp) and this
> causes every SetTimer() call in
> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
> to create a new user object instead of reusing the same object over again.  Fix: Call
> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify open any webpage using WebView on WIndows,
> with and without the fix and compare the number of user objects created using Windows Task Manager.

Is there a way to create a test?

-------------

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

From ajoseph at openjdk.java.net  Wed May 20 19:20:17 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Wed, 20 May 2020 19:20:17 GMT
Subject: RFR: 8244579: Windows "User Objects" leakage with WebView
In-Reply-To: <yLpn8qvAuC9M48GZEGgPcvmMf3eIxS0i_SoMDpuwXX4=.60b17b11-917f-48c8-a290-2f0751a11939@github.com>
References: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
 <yLpn8qvAuC9M48GZEGgPcvmMf3eIxS0i_SoMDpuwXX4=.60b17b11-917f-48c8-a290-2f0751a11939@github.com>
Message-ID: <_-Qm5c3zOzrZ0dYhak2BZglMGY9pOc5k8S__Piskxl4=.dfef67cc-b629-4fa3-80ac-625eadc4a67b@github.com>

On Wed, 20 May 2020 15:16:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Cause: The Window Class `RunLoopMessageWindow` is never registered (this happens because
>> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx uses MainThreadJava.cpp) and this
>> causes every SetTimer() call in
>> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
>> to create a new user object instead of reusing the same object over again.  Fix: Call
>> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify open any webpage using WebView on WIndows,
>> with and without the fix and compare the number of user objects created using Windows Task Manager.
>
> Is there a way to create a test?

I think it will be difficult to write a test for this. While debugging, RunLoop was mostly used by threads managing
heap. It can't be directly accessed via JavaScript. Also, this issue only affects Windows. The best way would be to
monitor the user objects created.

-------------

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

From jvos at openjdk.java.net  Wed May 20 19:20:17 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 20 May 2020 19:20:17 GMT
Subject: RFR: 8244579: Windows "User Objects" leakage with WebView
In-Reply-To: <_-Qm5c3zOzrZ0dYhak2BZglMGY9pOc5k8S__Piskxl4=.dfef67cc-b629-4fa3-80ac-625eadc4a67b@github.com>
References: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
 <yLpn8qvAuC9M48GZEGgPcvmMf3eIxS0i_SoMDpuwXX4=.60b17b11-917f-48c8-a290-2f0751a11939@github.com>
 <_-Qm5c3zOzrZ0dYhak2BZglMGY9pOc5k8S__Piskxl4=.dfef67cc-b629-4fa3-80ac-625eadc4a67b@github.com>
Message-ID: <EbyG4gUHg-v6RrsFEedpP4-AUBfe3MR5Lq27ygnLnDs=.0ecad4a9-d593-4ecd-915b-aef233b08500@github.com>

On Wed, 20 May 2020 19:17:28 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

>> Is there a way to create a test?
>
> I think it will be difficult to write a test for this. While debugging, RunLoop was mostly used by threads managing
> heap. It can't be directly accessed via JavaScript. Also, this issue only affects Windows. The best way would be to
> monitor the user objects created.

https://bugs.openjdk.java.net/browse/JDK-8244579 refers to a manual test, but it's probably very hard to automate this.

-------------

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

From ghb at openjdk.java.net  Thu May 21 07:29:03 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Thu, 21 May 2020 07:29:03 GMT
Subject: RFR: 8244579: Windows "User Objects" leakage with WebView
In-Reply-To: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
References: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
Message-ID: <eqSlncilAQqOMEuarMKISrnJd6vsW9FWsx6Nj-lWoxY=.94c746f9-ee50-436e-be79-47bf1bcd83a8@github.com>

On Wed, 20 May 2020 14:30:11 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Cause: The Window Class `RunLoopMessageWindow` is never registered (this happens because
> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx uses MainThreadJava.cpp) and this
> causes every SetTimer() call in
> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
> to create a new user object instead of reusing the same object over again.  Fix: Call
> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify open any webpage using WebView on WIndows,
> with and without the fix and compare the number of user objects created using Windows Task Manager.

Looks good to me
Tested with your fix and ran Test case provided in JBS (WebViewUserObjectLeakage) didn't exceeds more than 50 user
objects (Which is same as in 14-GA build).

-------------

Marked as reviewed by ghb (Reviewer).

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

From arapte at openjdk.java.net  Thu May 21 08:02:26 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 21 May 2020 08:02:26 GMT
Subject: RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
Message-ID: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>

As discussed [here](https://github.com/openjdk/jfx/pull/201#issuecomment-621772586) during #201 , This PR converts the
system tests in TabPanePermuteGetTabsTest.java to unit test.

Thanks @kleopatra , for providing the test. I have added few more tests and found few failures.
[JDK-8245528](https://bugs.openjdk.java.net/browse/JDK-8245528) is created to fix these failures, the failing tests are
currently ignored using this bug.

Please take a look.

-------------

Commit messages:
 - 8244195: [TEST_BUG] Convert the system tests TabPanePermuteGetTabsTest to unit test

Changes: https://git.openjdk.java.net/jfx/pull/230/files
 Webrev: https://webrevs.openjdk.java.net/jfx/230/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244195
  Stats: 660 lines in 4 files changed: 307 ins; 352 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/230.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/230/head:pull/230

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

From aghaisas at openjdk.java.net  Thu May 21 10:14:05 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 21 May 2020 10:14:05 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
Message-ID: <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>

On Mon, 18 May 2020 12:07:30 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
> 
> Basically, there's a utility class
> - to access lists of all control/classes,
> - to access/create all behaviors
> - has alternative skins classes for all controls and utility to install/replace skins
> 
> POC:
> - has test examples (not run in normal testing due to not following naming conventions) for using
> - changed SkinDisposeContractTest to use

I am ok with separating ControlsSkinTest from this fix.

modules/javafx.controls/src/shims/java/javafx/scene/control/skin/ControlSkinShim.java line 35:

> 34: /**
> 35:  *
> 36:  */

Don't leave the class description blank. If not needed, remove the comment.

modules/javafx.controls/src/shims/java/javafx/scene/control/skin/ControlSkinShim.java line 44:

> 43:      * @return the value of the skin's behavior field
> 44:      * @throws RuntimeException with the exception thrown by the reflective access
> 45:      */

Remove word 'with'

modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlSkinFactory.java line 212:

> 211:      * @return the default behavior for the control
> 212:      * @throws RuntimeException with the exception thrown when instantiating the behavior
> 213:      *

Remove word 'with'

modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlSkinFactoryTest.java line
91:

> 90:             Control control = createControl(controlClass);
> 91:             Skin<?> old = replaceSkin(control);
> 92:         }

An assertion can be added about old skin and new skin objects being different.

modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlBehaviorTestExample.java
line 52:

> 51: @RunWith(Parameterized.class)
> 52: public class ControlBehaviorTestExample {
> 53:

This test does not execute when run as part of :controls:test. We need to rename this class (and file) name to end with
'Test'. I tried doing it and lot of failures are seen.

-------------

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

From fastegal at openjdk.java.net  Thu May 21 10:24:32 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:24:32 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
Message-ID: <qiFVK1aUKzeYn27Xkt5tMm982rZ9Q4jIbxMgVpbp9iE=.1a542107-4de0-4013-92e7-87c2b8cf7ecb@github.com>

On Thu, 21 May 2020 10:05:25 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
>> 
>> Basically, there's a utility class
>> - to access lists of all control/classes,
>> - to access/create all behaviors
>> - has alternative skins classes for all controls and utility to install/replace skins
>> 
>> POC:
>> - has test examples (not run in normal testing due to not following naming conventions) for using
>> - changed SkinDisposeContractTest to use
>
> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlBehaviorTestExample.java
> line 52:
>> 51: @RunWith(Parameterized.class)
>> 52: public class ControlBehaviorTestExample {
>> 53:
> 
> This test does not execute when run as part of :controls:test. We need to rename this class (and file) name to end with
> 'Test'. I tried doing it and lot of failures are seen.

that's the point - they are examples of how-to use it and see our tasks :)

Will address your other comments in a minute - and add two real tests (on skin/behavior memory leaks with the
misbehaving classes removed: then we'll have both the passing classes and informal ignores on what's going wrong.

-------------

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

From fastegal at openjdk.java.net  Thu May 21 10:35:47 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:35:47 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
Message-ID: <fyf-rurz03M8-cBtFDtpys5p3W44IjWP5QlCxbMsrNg=.66ec52fd-3e4d-437a-b541-d48228ae9a80@github.com>

On Thu, 21 May 2020 07:16:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
>> 
>> Basically, there's a utility class
>> - to access lists of all control/classes,
>> - to access/create all behaviors
>> - has alternative skins classes for all controls and utility to install/replace skins
>> 
>> POC:
>> - has test examples (not run in normal testing due to not following naming conventions) for using
>> - changed SkinDisposeContractTest to use
>
> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlSkinFactoryTest.java line
> 91:
>> 90:             Control control = createControl(controlClass);
>> 91:             Skin<?> old = replaceSkin(control);
>> 92:         }
> 
> An assertion can be added about old skin and new skin objects being different.

oops ... forgot, will do

-------------

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

From fastegal at openjdk.java.net  Thu May 21 10:38:17 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:38:17 GMT
Subject: RFR: 8244531: Tests: add support to identify recurring issues
 with controls et al
In-Reply-To: <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
Message-ID: <xkB8EE18mZ-lXtVJ_8t6f5cEs3Fb13IHiqc_xry6v7g=.4489ced2-51cc-45bf-893e-dcf01170a5d5@github.com>

On Thu, 21 May 2020 06:56:12 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
>> 
>> Basically, there's a utility class
>> - to access lists of all control/classes,
>> - to access/create all behaviors
>> - has alternative skins classes for all controls and utility to install/replace skins
>> 
>> POC:
>> - has test examples (not run in normal testing due to not following naming conventions) for using
>> - changed SkinDisposeContractTest to use
>
> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlSkinFactory.java line 212:
> 
>> 211:      * @return the default behavior for the control
>> 212:      * @throws RuntimeException with the exception thrown when instantiating the behavior
>> 213:      *
> 
> Remove word 'with'

hmm .. the runtime is wrapping the checked exceptions, now tried to clarify by "RuntimeException wrapped around"

-------------

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

From fastegal at openjdk.java.net  Thu May 21 10:45:09 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:45:09 GMT
Subject: [Rev 01] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
Message-ID: <uzP8TaArjRyBIv3BQrdn-fV0d6GL8fS56Cg45yf-_gQ=.57952a2c-bdb6-472f-b730-fe5867c14e67@github.com>

> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
> 
> Basically, there's a utility class
> - to access lists of all control/classes,
> - to access/create all behaviors
> - has alternative skins classes for all controls and utility to install/replace skins
> 
> POC:
> - has test examples (not run in normal testing due to not following naming conventions) for using
> - changed SkinDisposeContractTest to use

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  code/doc changes as requested in review
  
  added Skin/BehaviorMemoryLeakTest

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/223/files
  - new: https://git.openjdk.java.net/jfx/pull/223/files/e1a1a459..d11d304b

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/223/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/223/webrev.00-01

  Stats: 336 lines in 4 files changed: 332 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/223.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/223/head:pull/223

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

From fastegal at openjdk.java.net  Thu May 21 10:46:17 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:46:17 GMT
Subject: [Rev 01] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <fyf-rurz03M8-cBtFDtpys5p3W44IjWP5QlCxbMsrNg=.66ec52fd-3e4d-437a-b541-d48228ae9a80@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
 <fyf-rurz03M8-cBtFDtpys5p3W44IjWP5QlCxbMsrNg=.66ec52fd-3e4d-437a-b541-d48228ae9a80@github.com>
Message-ID: <17s8BWBJtm50rvzj7UE3khteMEPYZM_pPpGpr8n0Uws=.f93c131d-d27d-419d-b19e-934ba8573ed8@github.com>

On Thu, 21 May 2020 10:33:27 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlSkinFactoryTest.java line
>> 91:
>>> 90:             Control control = createControl(controlClass);
>>> 91:             Skin<?> old = replaceSkin(control);
>>> 92:         }
>> 
>> An assertion can be added about old skin and new skin objects being different.
>
> oops ... forgot, will do

done

-------------

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

From fastegal at openjdk.java.net  Thu May 21 10:46:17 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:46:17 GMT
Subject: [Rev 01] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
Message-ID: <QstZ07Nittgmt8I4c4FFKXgWp9PdEvDAa07QAfWweuE=.b94d5233-0ff1-4096-a2c6-99d14a1bfa63@github.com>

On Thu, 21 May 2020 06:47:09 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code/doc changes as requested in review
>>   
>>   added Skin/BehaviorMemoryLeakTest
>
> modules/javafx.controls/src/shims/java/javafx/scene/control/skin/ControlSkinShim.java line 35:
> 
>> 34: /**
>> 35:  *
>> 36:  */
> 
> Don't leave the class description blank. If not needed, remove the comment.

removed

-------------

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

From fastegal at openjdk.java.net  Thu May 21 10:50:01 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 10:50:01 GMT
Subject: [Rev 01] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <qiFVK1aUKzeYn27Xkt5tMm982rZ9Q4jIbxMgVpbp9iE=.1a542107-4de0-4013-92e7-87c2b8cf7ecb@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
 <qiFVK1aUKzeYn27Xkt5tMm982rZ9Q4jIbxMgVpbp9iE=.1a542107-4de0-4013-92e7-87c2b8cf7ecb@github.com>
Message-ID: <BlQe17zCFutiUWUSZzEZhq7FHyVRg4wibu3i2RD-nXA=.9e434234-2553-4cb4-aab7-31fca9b2d7a0@github.com>

On Thu, 21 May 2020 10:22:18 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlBehaviorTestExample.java
>> line 52:
>>> 51: @RunWith(Parameterized.class)
>>> 52: public class ControlBehaviorTestExample {
>>> 53:
>> 
>> This test does not execute when run as part of :controls:test. We need to rename this class (and file) name to end with
>> 'Test'. I tried doing it and lot of failures are seen.
>
> that's the point - they are examples of how-to use it and see our tasks :)
> 
> Will address your other comments in a minute - and add two real tests (on skin/behavior memory leaks with the
> misbehaving classes removed: then we'll have both the passing classes and informal ignores on what's going wrong.

added SkinMemoryLeakTest/BehaviorMemoryLeakTest as (more or less ;) outlined in the bug report: in the parameter list
we start with all controls/classes and then remove the failing explicitly. Future fixes of the leaking classes will
have to remove the fixed from the excluded.

Hmm ..  now probably should remove the xxTestExamples (there existence doesn't seem to have been clear enough anyway ;)

-------------

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

From aghaisas at openjdk.java.net  Thu May 21 12:34:19 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 21 May 2020 12:34:19 GMT
Subject: [Rev 01] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <BlQe17zCFutiUWUSZzEZhq7FHyVRg4wibu3i2RD-nXA=.9e434234-2553-4cb4-aab7-31fca9b2d7a0@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <fjudEablDLryA7PYIKWep5Gswfe31P8oTTxb5HGVbcM=.f9dca920-f5be-4974-90dd-8e373483fee7@github.com>
 <qiFVK1aUKzeYn27Xkt5tMm982rZ9Q4jIbxMgVpbp9iE=.1a542107-4de0-4013-92e7-87c2b8cf7ecb@github.com>
 <BlQe17zCFutiUWUSZzEZhq7FHyVRg4wibu3i2RD-nXA=.9e434234-2553-4cb4-aab7-31fca9b2d7a0@github.com>
Message-ID: <PIADCSrdsKbwcAC6JR7AkLgGVGwjrhbQ0f1P_td4-6g=.85d020d9-041f-4ac5-826c-f870aa015f7c@github.com>

On Thu, 21 May 2020 10:47:52 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> that's the point - they are examples of how-to use it and see our tasks :)
>> 
>> Will address your other comments in a minute - and add two real tests (on skin/behavior memory leaks with the
>> misbehaving classes removed: then we'll have both the passing classes and informal ignores on what's going wrong.
>
> added SkinMemoryLeakTest/BehaviorMemoryLeakTest as (more or less ;) outlined in the bug report: in the parameter list
> we start with all controls/classes and then remove the failing explicitly. Future fixes of the leaking classes will
> have to remove the fixed from the excluded.   Hmm ..  now probably should remove the xxTestExamples (there existence
> doesn't seem to have been clear enough anyway ;)

Yes. It is better to remove this xxTestExamples file.

-------------

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

From aghaisas at openjdk.java.net  Thu May 21 12:34:18 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 21 May 2020 12:34:18 GMT
Subject: [Rev 01] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <uzP8TaArjRyBIv3BQrdn-fV0d6GL8fS56Cg45yf-_gQ=.57952a2c-bdb6-472f-b730-fe5867c14e67@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <uzP8TaArjRyBIv3BQrdn-fV0d6GL8fS56Cg45yf-_gQ=.57952a2c-bdb6-472f-b730-fe5867c14e67@github.com>
Message-ID: <8z09Zx7fr59kmeezmbV-4tzIUZSWncjRZXEqXqh_g3g=.705b6c79-ac0d-4ff3-a789-e0b42b3b2533@github.com>

On Thu, 21 May 2020 10:45:09 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
>> 
>> Basically, there's a utility class
>> - to access lists of all control/classes,
>> - to access/create all behaviors
>> - has alternative skins classes for all controls and utility to install/replace skins
>> 
>> POC:
>> - has test examples (not run in normal testing due to not following naming conventions) for using
>> - changed SkinDisposeContractTest to use
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code/doc changes as requested in review
>   
>   added Skin/BehaviorMemoryLeakTest

Update the PR description once you remove the xxTestExamples file.

Rest all changes look OK.

-------------

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

From fastegal at openjdk.java.net  Thu May 21 13:21:39 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 13:21:39 GMT
Subject: [Rev 02] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <8z09Zx7fr59kmeezmbV-4tzIUZSWncjRZXEqXqh_g3g=.705b6c79-ac0d-4ff3-a789-e0b42b3b2533@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <uzP8TaArjRyBIv3BQrdn-fV0d6GL8fS56Cg45yf-_gQ=.57952a2c-bdb6-472f-b730-fe5867c14e67@github.com>
 <8z09Zx7fr59kmeezmbV-4tzIUZSWncjRZXEqXqh_g3g=.705b6c79-ac0d-4ff3-a789-e0b42b3b2533@github.com>
Message-ID: <lWh0aMB1I1UORcb22hcHFf7-NRIunBIIGtF-lPaID60=.d29b70c0-a4d4-4c81-8891-ac0fc59c49f3@github.com>

On Thu, 21 May 2020 12:31:59 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed xxTestExample
>
> Update the PR description once you remove the xxTestExamples file.
> 
> Rest all changes look OK.

done - both removed the example and updated the PR comment

-------------

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

From fastegal at openjdk.java.net  Thu May 21 13:21:39 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 21 May 2020 13:21:39 GMT
Subject: [Rev 02] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
Message-ID: <nQum17aD60abHMrSQMh3UdtzkW35FWakjyJbUcL4ZA4=.b72ad87a-2a3c-4409-ad95-07f17a89e114@github.com>

> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
> 
> Basically, there's a utility class
> - to access lists of all control/classes,
> - to access/create all behaviors
> - has alternative skins classes for all controls and utility to install/replace skins
> 
> POC:
> - added tests Skin/BehaviorMemoryTest as examples for using
> - changed SkinDisposeContractTest to use

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  removed xxTestExample

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/223/files
  - new: https://git.openjdk.java.net/jfx/pull/223/files/d11d304b..e9cffa43

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/223/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/223/webrev.01-02

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

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

From kcr at openjdk.java.net  Thu May 21 15:20:21 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 15:20:21 GMT
Subject: RFR: 8244579: Windows "User Objects" leakage with WebView
In-Reply-To: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
References: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
Message-ID: <ndwx93WKl2YNSXtT2_LLj-DRG-Axjmy3Fz918sg7Zg0=.f8ecbee2-3a34-466c-9ccb-a177ff39bfd9@github.com>

On Wed, 20 May 2020 14:30:11 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Cause: The Window Class `RunLoopMessageWindow` is never registered (this happens because
> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx uses MainThreadJava.cpp) and this
> causes every SetTimer() call in
> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
> to create a new user object instead of reusing the same object over again.  Fix: Call
> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify open any webpage using WebView on WIndows,
> with and without the fix and compare the number of user objects created using Windows Task Manager.

Marked as reviewed by kcr (Lead).

-------------

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

From ajoseph at openjdk.java.net  Thu May 21 15:44:35 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Thu, 21 May 2020 15:44:35 GMT
Subject: [Integrated] RFR: 8244579: Windows "User Objects" leakage with
 WebView
In-Reply-To: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
References: <NhCUJ7DELttl406CKGuQVZWp8MA3w69yx0y-fVW7Ces=.5c35e106-83aa-48c0-8798-091fb978d1bb@github.com>
Message-ID: <V16uPUVrx5b6ZoZa3gA5z9slGPe_RPvBdvvEZi0i5-I=.a71f91d8-eb64-4141-b3a4-a2d1e7835315@github.com>

On Wed, 20 May 2020 14:30:11 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Cause: The Window Class `RunLoopMessageWindow` is never registered (this happens because
> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx uses MainThreadJava.cpp) and this
> causes every SetTimer() call in
> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
> to create a new user object instead of reusing the same object over again.  Fix: Call
> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify open any webpage using WebView on WIndows,
> with and without the fix and compare the number of user objects created using Windows Task Manager.

This pull request has now been integrated.

Changeset: a13a642d
Author:    Arun Joseph <ajoseph at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/a13a642d
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8244579: Windows "User Objects" leakage with WebView

Reviewed-by: ghb, kcr

-------------

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

From kcr at openjdk.java.net  Thu May 21 15:50:49 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 15:50:49 GMT
Subject: RFR: 8245183: Two fxml unit tests log warnings about deprecated
 escape sequences
In-Reply-To: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
References: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
Message-ID: <aH6RvHqWzxlaTx6Jboca1C0WVmcswGf-3IjPsb4dNB4=.56b74b84-dd17-4e7e-8072-df46258a6884@github.com>

On Wed, 20 May 2020 06:24:32 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245183
> Fix : Added a message to the test saying these are expected warnings. Refer JBS comments for more details.

Marked as reviewed by kcr (Lead).

-------------

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

From kcr at openjdk.java.net  Thu May 21 16:37:18 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 16:37:18 GMT
Subject: RFR: 8245183: Two fxml unit tests log warnings about deprecated
 escape sequences
In-Reply-To: <aH6RvHqWzxlaTx6Jboca1C0WVmcswGf-3IjPsb4dNB4=.56b74b84-dd17-4e7e-8072-df46258a6884@github.com>
References: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
 <aH6RvHqWzxlaTx6Jboca1C0WVmcswGf-3IjPsb4dNB4=.56b74b84-dd17-4e7e-8072-df46258a6884@github.com>
Message-ID: <qwJq2_AGcy02ZfrKhI83PBcfThuhvPi0VD4Mx0bW_K4=.384ff6dc-2c71-4d16-b52d-77af14372c1f@github.com>

On Thu, 21 May 2020 15:48:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue : https://bugs.openjdk.java.net/browse/JDK-8245183
>> Fix : Added a message to the test saying these are expected warnings. Refer JBS comments for more details.
>
> Marked as reviewed by kcr (Lead).

While running the FXML tests, I see two more test warnings due to the fact that Nashorn has been deprecated (for quite
some time now). Now that Nashorn has been removed in JDK 15, we will need to address this by replacing the tests with
something that doesn't use Nashorn. I filed [JDK-8245568](https://bugs.openjdk.java.net/browse/JDK-8245568) as a
follow-up issue to track this.

-------------

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

From kcr at openjdk.java.net  Thu May 21 16:44:49 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 16:44:49 GMT
Subject: RFR: 8245457: [TestBug] Enable and fix ignored tests in
 ButtonBaseTest & ButtonTest
In-Reply-To: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>
References: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>
Message-ID: <t_VQqICV3XoZIhw1HihHHIgTBVBbUS2Dh_ShLfZ7Mtk=.cb6ba1b3-a795-49d6-999d-7db919b3afdd@github.com>

On Wed, 20 May 2020 11:45:59 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245457
> 
> Fix : It is a simple test fix. I have enabled the ignored tests from ButtonBaseTest & ButtonTest test classes & fixed
> them. Also removed a print to std.out.

Marked as reviewed by kcr (Lead).

-------------

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

From kcr at openjdk.java.net  Thu May 21 16:56:03 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 16:56:03 GMT
Subject: RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
Message-ID: <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>

On Thu, 21 May 2020 07:55:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> As discussed [here](https://github.com/openjdk/jfx/pull/201#issuecomment-621772586) during #201 , This PR converts the
> system tests in TabPanePermuteGetTabsTest.java to unit test.
> Thanks @kleopatra , for providing the test. I have added few more tests and found few failures.
> [JDK-8245528](https://bugs.openjdk.java.net/browse/JDK-8245528) is created to fix these failures, the failing tests are
> currently ignored using this bug.
> Please take a look.

I'll do a more careful review + test later. I left a few inline comments below.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 2293:

> 2292:
> 2293:     void test_disableAnimations() {
> 2294:         closeTabAnimation.set(TabAnimation.NONE);

Might be better to change this to `test_setAnimations(TabAnimation mode)` so the test can restore it in the cleanup
method.

modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TabPaneSkinShim.java line 41:

> 40:
> 41:     public static void disableAnimations(TabPaneSkin tpSkin) {
> 42:         tpSkin.test_disableAnimations();

See comment in `TabPaneSkin.java`

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TabPaneSkinHeaderOrderTest.java line 25:

> 24:  */
> 25: package test.javafx.scene.control.skin;
> 26:

Minor: add blank line between the copyright header and package.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TabPaneSkinHeaderOrderTest.java line 52:

> 51:  * updating the tab headers.
> 52:  *
> 53:  */

Minor: this blank comment line can be removed.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TabPaneSkinHeaderOrderTest.java line 274:

> 273:     public void cleanup() {
> 274:         stage.hide();
> 275:     }

I recommend to restore animation here.

-------------

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

From kcr at openjdk.java.net  Thu May 21 17:00:34 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 17:00:34 GMT
Subject: RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
 <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>
Message-ID: <5Ax2sJgG47artoStWZ14iYE4yDj9EOKKUNjUISCqgG4=.314eeffb-d57a-4f89-a006-120c598dadbb@github.com>

On Thu, 21 May 2020 16:47:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> As discussed [here](https://github.com/openjdk/jfx/pull/201#issuecomment-621772586) during #201 , This PR converts the
>> system tests in TabPanePermuteGetTabsTest.java to unit test.
>> Thanks @kleopatra , for providing the test. I have added few more tests and found few failures.
>> [JDK-8245528](https://bugs.openjdk.java.net/browse/JDK-8245528) is created to fix these failures, the failing tests are
>> currently ignored using this bug.
>> Please take a look.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 2293:
> 
>> 2292:
>> 2293:     void test_disableAnimations() {
>> 2294:         closeTabAnimation.set(TabAnimation.NONE);
> 
> Might be better to change this to `test_setAnimations(TabAnimation mode)` so the test can restore it in the cleanup
> method.

Never mind. I see that the test constructs a new TabPane instance for each test, so there is no need to restore it.

> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TabPaneSkinHeaderOrderTest.java line 274:
> 
>> 273:     public void cleanup() {
>> 274:         stage.hide();
>> 275:     }
> 
> I recommend to restore animation here.

Never mind. This is not needed since the test constructs a new TabPane instance for each test in the `@Before` method.

-------------

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

From arapte at openjdk.java.net  Thu May 21 17:11:02 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 21 May 2020 17:11:02 GMT
Subject: RFR: 8245183: Two fxml unit tests log warnings about deprecated
 escape sequences
In-Reply-To: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
References: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
Message-ID: <lheyHNHmNbk45jOsgXxRdBVgai6h4O36Xi8HBFj-Rm0=.722283c9-a8ff-4dbe-94b6-e8296a1ce302@github.com>

On Wed, 20 May 2020 06:24:32 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245183
> Fix : Added a message to the test saying these are expected warnings. Refer JBS comments for more details.

Marked as reviewed by arapte (Reviewer).

-------------

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

From arapte at openjdk.java.net  Thu May 21 17:18:37 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 21 May 2020 17:18:37 GMT
Subject: RFR: 8245457: [TestBug] Enable and fix ignored tests in
 ButtonBaseTest & ButtonTest
In-Reply-To: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>
References: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>
Message-ID: <Fa6dt9D4eU5Gb24aq6FVzmSKXWg1uEOx5RdH5ixXSjE=.02b18313-8ef3-4f54-ab7d-6dc5d37eda75@github.com>

On Wed, 20 May 2020 11:45:59 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245457
> 
> Fix : It is a simple test fix. I have enabled the ignored tests from ButtonBaseTest & ButtonTest test classes & fixed
> them. Also removed a print to std.out.

These are negative test for the properties that are not supported. Will it be a good idea to remove the tests? Guessing
that, these css property were supported earlier and were removed later, and these tests were added at the time of
removing them. I think in that case, the test should continue to remain. Approving.

-------------

Marked as reviewed by arapte (Reviewer).

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

From arapte at openjdk.java.net  Thu May 21 17:23:53 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 21 May 2020 17:23:53 GMT
Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren
 logs an exception
In-Reply-To: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>
References: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>
Message-ID: <1QwVOR5GQsKKO1LsqLzBP2iUhN6htlgQBkkqwO4lKHc=.92ea3401-1934-4162-bc57-e21efa03a3bc@github.com>

On Tue, 19 May 2020 10:25:24 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245181
> 
> Root cause : The exception just gets logged and does not result in test failure.
> 
> Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this
> mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I
> have removed System.out.printlns that were causing log pollution.

modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 2563:

> 2562:                                 pMap.put(i, e.getChange().getPermutation(i));
> 2563:                             }
> 2564:                         }

Hi Ajit, I am working on fix for [JDK-8193800](https://bugs.openjdk.java.net/browse/JDK-8193800),  This code of
handling permutation of table rows is not correct, and as part of the changes for this fix, this code would be changed
such that `pMap` will be removed. Could you please hold this change until
[JDK-8193800](https://bugs.openjdk.java.net/browse/JDK-8193800) is fixed.?

-------------

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

From kcr at openjdk.java.net  Thu May 21 17:28:51 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 17:28:51 GMT
Subject: RFR: 8208169: can not print selected pages of web page
In-Reply-To: <tNJSGXv4kfLWcmrIQQOLWPmyVMIZYgE1BJ-_UuKpFHE=.3289407e-7cc6-4631-97c4-637393480939@github.com>
References: <jWsRhnxW7brrPODkakKw-f6PlbmfqE9habjyLiCROhs=.c6993562-79cb-44f1-9ff2-786d307bfe1f@github.com>
 <tNJSGXv4kfLWcmrIQQOLWPmyVMIZYgE1BJ-_UuKpFHE=.3289407e-7cc6-4631-97c4-637393480939@github.com>
Message-ID: <JRxwtUkdwoFfC_K7cPGvlPpqE3y2gF5uOJ6KujPFP2Q=.5eaabf36-e6f1-46bc-ae95-3ff8a717e4d2@github.com>

On Fri, 15 May 2020 17:10:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page,
>> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing
>> pages otherwise print all pages as usual.
>
> @prrace can you also review this?

Can you add a test for this? It may need to be a manual test, in which case it can go into `tests/manual/printing/`.

-------------

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

From prr at openjdk.java.net  Thu May 21 17:44:05 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 May 2020 17:44:05 GMT
Subject: RFR: 8208169: can not print selected pages of web page
In-Reply-To: <jWsRhnxW7brrPODkakKw-f6PlbmfqE9habjyLiCROhs=.c6993562-79cb-44f1-9ff2-786d307bfe1f@github.com>
References: <jWsRhnxW7brrPODkakKw-f6PlbmfqE9habjyLiCROhs=.c6993562-79cb-44f1-9ff2-786d307bfe1f@github.com>
Message-ID: <MqHX1l4dNgVipAp1mjRaQSTr4l1sdb5o_-CNXTPqOFI=.e67853ae-2583-4c17-916b-90d5f24ea3c9@github.com>

On Fri, 15 May 2020 16:36:29 GMT, Bhawesh Choudhary <github.com+4208131+bhaweshkc at openjdk.org> wrote:

> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page,
> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing
> pages otherwise print all pages as usual.

looks ok. Approval waiting on a test.

-------------

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

From jpereda at openjdk.java.net  Thu May 21 17:46:12 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Thu, 21 May 2020 17:46:12 GMT
Subject: RFR: 8245499: Text input controls should show handles on iOS
Message-ID: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>

After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
device. However, selection handles are not enabled and currently text selection is not possible at all.

This PR enables handles on iOS as in the rest of the platforms with touch support.

It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
are a little bit bigger, and there is no caret handle.

-------------

Commit messages:
 - Use circular shape for selection handles on iOS
 - Don?t show caretHandle on iOS
 - Enable Show_Handles on iOS

Changes: https://git.openjdk.java.net/jfx/pull/231/files
 Webrev: https://webrevs.openjdk.java.net/jfx/231/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245499
  Stats: 35 lines in 4 files changed: 18 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jfx/pull/231.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/231/head:pull/231

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

From kcr at openjdk.java.net  Thu May 21 18:14:18 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 21 May 2020 18:14:18 GMT
Subject: RFR: 8245499: Text input controls should show handles on iOS
In-Reply-To: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
Message-ID: <WXRqb2fsnHrONTu8CkfCWB7gghA7lQibOvDv32117Xw=.52f5275b-5f69-4c5b-9d89-2db46f6b7f28@github.com>

On Thu, 21 May 2020 17:41:02 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
> device. However, selection handles are not enabled and currently text selection is not possible at all.
> This PR enables handles on iOS as in the rest of the platforms with touch support.
> 
> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
> are a little bit bigger, and there is no caret handle.

Since this touches shared code, I'd like @aghaisas to look at this.

-------------

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

From aghaisas at openjdk.java.net  Fri May 22 05:08:48 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 22 May 2020 05:08:48 GMT
Subject: [Integrated] RFR: 8245183: Two fxml unit tests log warnings about
 deprecated escape sequences
In-Reply-To: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
References: <V8fn2vI4uvjKlwN2xpPZbrc4h0yp4DqalGvC6knqpCg=.b4e43806-d0dd-4b8f-b8bc-34a7cd5fa8f3@github.com>
Message-ID: <cb3RJKgDONlFB9jBBFaMhrt9AfrHSSh6kvOFM-6gJ5Q=.1d0eef63-fff6-45c7-901c-c2268db355da@github.com>

On Wed, 20 May 2020 06:24:32 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245183
> Fix : Added a message to the test saying these are expected warnings. Refer JBS comments for more details.

This pull request has now been integrated.

Changeset: 6e0b45a3
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/6e0b45a3
Stats:     5 lines in 2 files changed: 0 ins; 3 del; 2 mod

8245183: Two fxml unit tests log warnings about deprecated escape sequences

Reviewed-by: kcr, arapte

-------------

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

From aghaisas at openjdk.java.net  Fri May 22 05:35:33 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 22 May 2020 05:35:33 GMT
Subject: [Rev 02] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <lWh0aMB1I1UORcb22hcHFf7-NRIunBIIGtF-lPaID60=.d29b70c0-a4d4-4c81-8891-ac0fc59c49f3@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <uzP8TaArjRyBIv3BQrdn-fV0d6GL8fS56Cg45yf-_gQ=.57952a2c-bdb6-472f-b730-fe5867c14e67@github.com>
 <8z09Zx7fr59kmeezmbV-4tzIUZSWncjRZXEqXqh_g3g=.705b6c79-ac0d-4ff3-a789-e0b42b3b2533@github.com>
 <lWh0aMB1I1UORcb22hcHFf7-NRIunBIIGtF-lPaID60=.d29b70c0-a4d4-4c81-8891-ac0fc59c49f3@github.com>
Message-ID: <o8otWFCmus3bQCchHdoHmBxoDsuZWf085R7bCliYLUo=.b7790fb2-e7cd-4070-9981-2583ac5ba6e9@github.com>

On Thu, 21 May 2020 13:15:12 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Update the PR description once you remove the xxTestExamples file.
>> 
>> Rest all changes look OK.
>
> done - both removed the example and updated the PR comment

PR looks fine to me.
Thanks for coming up with this general test for Skins and Behaviors. Good contribution!!

-------------

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

From aghaisas at openjdk.java.net  Fri May 22 05:35:33 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 22 May 2020 05:35:33 GMT
Subject: [Rev 02] RFR: 8244531: Tests: add support to identify recurring
 issues with controls et al
In-Reply-To: <nQum17aD60abHMrSQMh3UdtzkW35FWakjyJbUcL4ZA4=.b72ad87a-2a3c-4409-ad95-07f17a89e114@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
 <nQum17aD60abHMrSQMh3UdtzkW35FWakjyJbUcL4ZA4=.b72ad87a-2a3c-4409-ad95-07f17a89e114@github.com>
Message-ID: <diyhqlZ4nEMmH5aVfk73QcKRYvCsguwiIBuA3s4gYE0=.70422860-83d8-4588-abd3-f9dcfe2f2caf@github.com>

On Thu, 21 May 2020 13:21:39 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
>> 
>> Basically, there's a utility class
>> - to access lists of all control/classes,
>> - to access/create all behaviors
>> - has alternative skins classes for all controls and utility to install/replace skins
>> 
>> POC:
>> - added tests Skin/BehaviorMemoryTest as examples for using
>> - changed SkinDisposeContractTest to use
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed xxTestExample

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From aghaisas at openjdk.java.net  Fri May 22 06:20:20 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 22 May 2020 06:20:20 GMT
Subject: [Integrated] RFR: 8245457: [TestBug] Enable and fix ignored tests
 in ButtonBaseTest & ButtonTest
In-Reply-To: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>
References: <fauZPQDqYLYYrO_hOwo3UwW4P-wlBL2cjj6g1iu2be0=.2a0bb074-2a7f-4587-8ef8-06e2634aed69@github.com>
Message-ID: <ybsQIPo2HGXXao3ajg5urUrdMY-sxbzyBlvQn72bVDE=.e581c004-16ce-4fe9-88b1-36025e4c8933@github.com>

On Wed, 20 May 2020 11:45:59 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Issue : https://bugs.openjdk.java.net/browse/JDK-8245457
> 
> Fix : It is a simple test fix. I have enabled the ignored tests from ButtonBaseTest & ButtonTest test classes & fixed
> them. Also removed a print to std.out.

This pull request has now been integrated.

Changeset: 1971c701
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/1971c701
Stats:     36 lines in 2 files changed: 6 ins; 25 del; 5 mod

8245457: TestBug] Enable and fix ignored tests in ButtonBaseTest & ButtonTest

Reviewed-by: kcr, arapte

-------------

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

From aghaisas at openjdk.java.net  Fri May 22 10:51:03 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 22 May 2020 10:51:03 GMT
Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren
 logs an exception
In-Reply-To: <1QwVOR5GQsKKO1LsqLzBP2iUhN6htlgQBkkqwO4lKHc=.92ea3401-1934-4162-bc57-e21efa03a3bc@github.com>
References: <ZQCz-PFcKDgNzpqkt8VwCNOsx7eJs8iCvva2KF_YIW0=.75cd0639-fc90-4a86-aa74-3b57c267f7e1@github.com>
 <1QwVOR5GQsKKO1LsqLzBP2iUhN6htlgQBkkqwO4lKHc=.92ea3401-1934-4162-bc57-e21efa03a3bc@github.com>
Message-ID: <vagvwq6odeT_6a2BaLWDHCNJ4zlUhPaQGvLDOc4YaB0=.79b6b2cb-5b93-4308-a2b9-dcaa216f2687@github.com>

On Thu, 21 May 2020 17:21:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Issue : https://bugs.openjdk.java.net/browse/JDK-8245181
>> 
>> Root cause : The exception just gets logged and does not result in test failure.
>> 
>> Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this
>> mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I
>> have removed System.out.printlns that were causing log pollution.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 2563:
> 
>> 2562:                                 pMap.put(i, e.getChange().getPermutation(i));
>> 2563:                             }
>> 2564:                         }
> 
> Hi Ajit, I am working on fix for [JDK-8193800](https://bugs.openjdk.java.net/browse/JDK-8193800),  This code of
> handling permutation of table rows is not correct, and as part of the changes for this fix, this code would be changed
> such that `pMap` will be removed. Could you please hold this change until
> [JDK-8193800](https://bugs.openjdk.java.net/browse/JDK-8193800) is fixed.?

OK. I will make it a draft PR.
Once you fix JDK-8193800, If no test issue is seen, I will just close this PR.
You may still want to add the UncaughtExceptionHandler in TreeTableViewTest as part of your fix to uncover any similar
issue.

-------------

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

From jpereda at openjdk.java.net  Fri May 22 11:51:37 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 22 May 2020 11:51:37 GMT
Subject: RFR: 8245575: Show the ContextMenu of input controls with long press
 gesture on iOS
Message-ID: <TT6KPPT07YcIx75VAbX1Ego9zRrj2LMZWnP6OG2khFs=.ed9b322e-48d7-4bae-9ac0-ac7fcc9e674f@github.com>

This PR uses iOS long press gesture to generate a menu event that will trigger a `ContextMenuEvent`.

Based on this event, input controls will show the ContextMenu (once JDK-8245499 is fixed), and if required, a developer
could add an event handler based on `ContextMenuEvent.CONTEXT_MENU_REQUESTED` for custom processing of such event.

-------------

Commit messages:
 - Use iOS long press gesture to generate a menu event

Changes: https://git.openjdk.java.net/jfx/pull/232/files
 Webrev: https://webrevs.openjdk.java.net/jfx/232/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245575
  Stats: 32 lines in 3 files changed: 32 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/232.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/232/head:pull/232

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

From arapte at openjdk.java.net  Fri May 22 12:15:04 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 22 May 2020 12:15:04 GMT
Subject: [Rev 01] RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
 <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>
Message-ID: <Z950N2BjUx8HI8wuCNYLOGMRry5yi7odfuj8X5BDwmY=.8999d53c-863d-44c4-9ef7-efeca3c1853c@github.com>

On Thu, 21 May 2020 16:49:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TabPaneSkinHeaderOrderTest.java line 25:
> 
>> 24:  */
>> 25: package test.javafx.scene.control.skin;
>> 26:
> 
> Minor: add blank line between the copyright header and package.

corrected

-------------

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

From arapte at openjdk.java.net  Fri May 22 12:15:04 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 22 May 2020 12:15:04 GMT
Subject: [Rev 01] RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
Message-ID: <_hgk49qaNDlNcwO1COkYFexM4v_JOsjgqipUwpk7S0I=.2dd3142f-181e-49c3-9e56-5be44b41899a@github.com>

> As discussed [here](https://github.com/openjdk/jfx/pull/201#issuecomment-621772586) during #201 , This PR converts the
> system tests in TabPanePermuteGetTabsTest.java to unit test.
> Thanks @kleopatra , for providing the test. I have added few more tests and found few failures.
> [JDK-8245528](https://bugs.openjdk.java.net/browse/JDK-8245528) is created to fix these failures, the failing tests are
> currently ignored using this bug.
> Please take a look.

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/230/files
  - new: https://git.openjdk.java.net/jfx/pull/230/files/9e12c606..687083b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/230/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/230/webrev.00-01

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

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

From jpereda at openjdk.java.net  Fri May 22 13:06:17 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 22 May 2020 13:06:17 GMT
Subject: RFR: 8245635: GlassPasteboard::getUTFs fails on iOS
Message-ID: <_rKgQYpD6f8Wmwr9ao0Nedgd3BqWNp_dTdGfFWKotlw=.314168d5-4fa1-4c48-bd6b-1e79daa837f6@github.com>

As a follow-up of JDK-8245456, IosPasteboard throws a ClassCastException when trying to paste clipboard content on iOS
devices. Same fix apply, using the correct signature.

When retrieving the UTF formats, the native method fails to create the correct String array, as the total number of
keys is not taken into account. Using a for loop fixes the issue.

Relates to JDK-8245499 and JDK-8245575

-------------

Commit messages:
 - Fill keys array with for loop
 - Use correct array type signature

Changes: https://git.openjdk.java.net/jfx/pull/233/files
 Webrev: https://webrevs.openjdk.java.net/jfx/233/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245635
  Stats: 11 lines in 1 file changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/233.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/233/head:pull/233

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

From arapte at openjdk.java.net  Fri May 22 13:27:43 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 22 May 2020 13:27:43 GMT
Subject: RFR: 8245601: [TESTBUG] Disable TabPaneDragPolicyTest on Mac until
 JDK-8213136 is fixed and fix ISE
Message-ID: <MU7MRmH_Eea8wiPu0mHMhInb8aUvyr7gDcOVWIg-UrE=.ad277abe-8886-43fc-bafc-980e8feca6c4@github.com>

The reordering tests in TabPaneDragPolicyTest fail only fails on Mac. It may be a a product issue which is tracked by
[JDK-8213136](https://bugs.openjdk.java.net/browse/JDK-8213136). This PR disables the 4 reordering test on Mac
platform. And fixes an Exception, Please check the JBS for exception.

-------------

Commit messages:
 - 8245601: [TESTBUG] Disable TabPaneDragPolicyTest on Mac until JDK-8213136 is fixed and fix ISE

Changes: https://git.openjdk.java.net/jfx/pull/234/files
 Webrev: https://webrevs.openjdk.java.net/jfx/234/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245601
  Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/234.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/234/head:pull/234

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

From johan.vos at gluonhq.com  Fri May 22 14:24:27 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 22 May 2020 16:24:27 +0200
Subject: backport request for JavaFX 11: JDK-8244579
Message-ID: <CABxFH2Efy3m_WfTef_gpFqW0BbA4hLqreajShFvY5naqzan_3w@mail.gmail.com>

Hi Kevin,

I request permission to backport JDK-8244579 to JavaFX 11. (11.0.8)

- Johan

From johan.vos at gluonhq.com  Fri May 22 14:25:04 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 22 May 2020 16:25:04 +0200
Subject: backport request for JavaFX 14: JDK-8244579
Message-ID: <CABxFH2FhuS8+a3V9cB=b=bie+-cR_9W1UaGjPDUJLSU8QoRmTQ@mail.gmail.com>

Hi Kevin,

I request permission to backport JDK-8244579 to JavaFX 14 (14.0.2).

- Johan

From jvos at openjdk.java.net  Fri May 22 14:27:20 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 22 May 2020 14:27:20 GMT
Subject: [jfx14] RFR: 8245644: Change JavaFX release version in jfx14 branch
 to 14.0.2
Message-ID: <fCTqkoiBZ0y1vR1IpS1jFrj7u5rATFCBlbxAM5wSah0=.22e60ed2-b97b-4fa1-970b-6f9a3e3951cd@github.com>

Increase security number for the 14.0.2 release
Fix for JDK-8245644

-------------

Commit messages:
 - Increase security number for the 14.0.2 release

Changes: https://git.openjdk.java.net/jfx/pull/235/files
 Webrev: https://webrevs.openjdk.java.net/jfx/235/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245644
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/235.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/235/head:pull/235

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

From kcr at openjdk.java.net  Fri May 22 14:37:33 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 May 2020 14:37:33 GMT
Subject: [jfx14] RFR: 8245644: Change JavaFX release version in jfx14
 branch to 14.0.2
In-Reply-To: <fCTqkoiBZ0y1vR1IpS1jFrj7u5rATFCBlbxAM5wSah0=.22e60ed2-b97b-4fa1-970b-6f9a3e3951cd@github.com>
References: <fCTqkoiBZ0y1vR1IpS1jFrj7u5rATFCBlbxAM5wSah0=.22e60ed2-b97b-4fa1-970b-6f9a3e3951cd@github.com>
Message-ID: <0yA6CJy921sDtR3N2mFtVDx8dZvmNxrn2FdOT51IMgo=.6cfc569f-6a02-4cdd-b724-7e1030a7561a@github.com>

On Fri, 22 May 2020 14:21:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase security number for the 14.0.2 release
> Fix for JDK-8245644

Marked as reviewed by kcr (Lead).

-------------

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

From jvos at openjdk.java.net  Fri May 22 14:45:49 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 22 May 2020 14:45:49 GMT
Subject: [Integrated] [jfx14] RFR: 8245644: Change JavaFX release version
 in jfx14 branch to 14.0.2
In-Reply-To: <fCTqkoiBZ0y1vR1IpS1jFrj7u5rATFCBlbxAM5wSah0=.22e60ed2-b97b-4fa1-970b-6f9a3e3951cd@github.com>
References: <fCTqkoiBZ0y1vR1IpS1jFrj7u5rATFCBlbxAM5wSah0=.22e60ed2-b97b-4fa1-970b-6f9a3e3951cd@github.com>
Message-ID: <wTOiyCxwEMlU8-K6ksU4zxa7EWdjwMkQS6efy_GcqDs=.0a3637fe-f2f1-4a89-b872-78eb2b16f407@github.com>

On Fri, 22 May 2020 14:21:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase security number for the 14.0.2 release
> Fix for JDK-8245644

This pull request has now been integrated.

Changeset: 5f9ba882
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/5f9ba882
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8245644: Change JavaFX release version in jfx14 branch to 14.0.2

Reviewed-by: kcr

-------------

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

From kevin.rushforth at oracle.com  Fri May 22 14:58:43 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 22 May 2020 07:58:43 -0700
Subject: backport request for JavaFX 14: JDK-8244579
In-Reply-To: <CABxFH2FhuS8+a3V9cB=b=bie+-cR_9W1UaGjPDUJLSU8QoRmTQ@mail.gmail.com>
References: <CABxFH2FhuS8+a3V9cB=b=bie+-cR_9W1UaGjPDUJLSU8QoRmTQ@mail.gmail.com>
Message-ID: <13420ce4-f662-ed22-0c1e-a2483988fa64@oracle.com>

I approved the PR.

On 5/22/2020 7:25 AM, Johan Vos wrote:
> Hi Kevin,
>
> I request permission to backport JDK-8244579 to JavaFX 14 (14.0.2).
>
> - Johan


From kevin.rushforth at oracle.com  Fri May 22 18:57:25 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 22 May 2020 11:57:25 -0700
Subject: backport request for JavaFX 14: JDK-8244579
In-Reply-To: <13420ce4-f662-ed22-0c1e-a2483988fa64@oracle.com>
References: <CABxFH2FhuS8+a3V9cB=b=bie+-cR_9W1UaGjPDUJLSU8QoRmTQ@mail.gmail.com>
 <13420ce4-f662-ed22-0c1e-a2483988fa64@oracle.com>
Message-ID: <6e41e110-d318-1226-f3b8-3e209456d111@oracle.com>

I misread the bug ID. Sorry about that. In any case, yes, this is a good 
bug fix to backport.

+1

-- Kevin


On 5/22/2020 7:58 AM, Kevin Rushforth wrote:
> I approved the PR.
>
> On 5/22/2020 7:25 AM, Johan Vos wrote:
>> Hi Kevin,
>>
>> I request permission to backport JDK-8244579 to JavaFX 14 (14.0.2).
>>
>> - Johan
>


From kevin.rushforth at oracle.com  Fri May 22 18:58:20 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 22 May 2020 11:58:20 -0700
Subject: backport request for JavaFX 14: JDK-8244579
In-Reply-To: <6e41e110-d318-1226-f3b8-3e209456d111@oracle.com>
References: <CABxFH2FhuS8+a3V9cB=b=bie+-cR_9W1UaGjPDUJLSU8QoRmTQ@mail.gmail.com>
 <13420ce4-f662-ed22-0c1e-a2483988fa64@oracle.com>
 <6e41e110-d318-1226-f3b8-3e209456d111@oracle.com>
Message-ID: <5f734452-00cb-691c-3698-b75f9b2f7418@oracle.com>

And this is good for 11.0.8, too.

-- Kevin


On 5/22/2020 11:57 AM, Kevin Rushforth wrote:
> I misread the bug ID. Sorry about that. In any case, yes, this is a 
> good bug fix to backport.
>
> +1
>
> -- Kevin
>
>
> On 5/22/2020 7:58 AM, Kevin Rushforth wrote:
>> I approved the PR.
>>
>> On 5/22/2020 7:25 AM, Johan Vos wrote:
>>> Hi Kevin,
>>>
>>> I request permission to backport JDK-8244579 to JavaFX 14 (14.0.2).
>>>
>>> - Johan
>>
>


From kcr at openjdk.java.net  Sat May 23 14:29:03 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 23 May 2020 14:29:03 GMT
Subject: RFR: 8245601: [TESTBUG] Disable TabPaneDragPolicyTest on Mac
 until JDK-8213136 is fixed and fix ISE
In-Reply-To: <MU7MRmH_Eea8wiPu0mHMhInb8aUvyr7gDcOVWIg-UrE=.ad277abe-8886-43fc-bafc-980e8feca6c4@github.com>
References: <MU7MRmH_Eea8wiPu0mHMhInb8aUvyr7gDcOVWIg-UrE=.ad277abe-8886-43fc-bafc-980e8feca6c4@github.com>
Message-ID: <L2I58QDh2vY71vEeoSjnP4uJW5aGTVYHpLDmVEj2rHA=.f1e843ed-1c88-47ca-8478-1a9bd1bb4abf@github.com>

On Fri, 22 May 2020 13:21:45 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The reordering tests in TabPaneDragPolicyTest fail only fails on Mac. It may be a a product issue which is tracked by
> [JDK-8213136](https://bugs.openjdk.java.net/browse/JDK-8213136). This PR disables the 4 reordering test on Mac
> platform. And fixes an Exception, Please check the JBS for exception.

Marked as reviewed by kcr (Lead).

-------------

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

From rony.flatscher at wu.ac.at  Sat May 23 18:30:05 2020
From: rony.flatscher at wu.ac.at (Rony G Flatscher)
Date: Sat, 23 May 2020 20:30:05 +0200
Subject: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP
 (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for
 review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script
 engines implement javax.script.Compilabel compile scripts"
In-Reply-To: <77bc0cae-bee1-c569-ca0b-abc4d7ca9be6@wu.ac.at>
References: <77bc0cae-bee1-c569-ca0b-abc4d7ca9be6@wu.ac.at>
Message-ID: <D45D8007-1AEA-4A09-B91D-FEDF12EA0F37@wu.ac.at>

Hi Kevin,

is there anything I need to do? What are the next steps I should look for?

?-rony

Rony G. Flatscher (mobil/e)

> Am 12.05.2020 um 19:23 schrieb Rony G. Flatscher <Rony.Flatscher at wu.ac.at>:
> 
> ?Hi Kevin,
> 
> in the meantime I have tried to come up with a formulation for the "Introduction to FXML"
> specification about the new compile processing instruction which is brief and complete. While being
> there I fixed a typo in the document and added a missing language processing instruction to an
> existing script example, hope that was o.k. as I have not filed an explicit bug for it.
> 
> Also closed the PR 129 and 187, removed the WIP from PR 192, and supplied the CSR draft as a comment.
> 
> If there is anything else I should do, please let me know.
> 
> Cheers,
> 
> ---rony
> 
> 
>> On 11.05.2020 14:12, Rony G. Flatscher wrote:
>> Hi Kevin,
>> 
>>> On 09.05.2020 17:16, Kevin Rushforth wrote:
>>> I'm finally getting back to this. I took a look at https://github.com/openjdk/jfx/pull/192 and I
>>> like that as the direction for this enhancement.
>>> 
>>> The initial CSR you have is a good start.
>> Thank you!
>> 
>>> Next steps are:
>>> 
>>> 1. Update the "Introduction to FXML" specification (see my comment in the PR)
>>> 2. Update PR 192 with the draft CSR as a comment, modifying it to include the above additions to
>>> "Introduction to FXML"
>>> 3. Remove WIP from the title
>>> 
>>> You can then close the other two PRs (129 and 187).
>> will do (may take a little bit).
>> 
>> Cheers
>> 
>> ---rony
>> 
>> 
>>> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>>> Hi Kevin,
>>>> 
>>>> what should be the next steps?
>>>> 
>>>> Should I remove "WIP" from the title in <https://github.com/openjdk/jfx/pull/192> and add the CSR
>>>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby requesting it to be added
>>>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>>> 
>>>> Please advise.
>>>> 
>>>> TIA,
>>>> 
>>>> ---rony
>>>> 
>>>> P.S.: This is the RFE:
>>>> 
>>>>  * RFE (2020-01-24): <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>> 
>>>> These are the three versions (all with appropriate unit tests) that I came up with
>>>> chronologically to implement the RFE, would prefer the latest version (PR # 192):
>>>> 
>>>>  * Compile if Compilable implemented (2020-02-28): <https://github.com/openjdk/jfx/pull/129>
>>>>  * Compile if compile PI and Compilable is implemented (2020-04-11):
>>>>    <https://github.com/openjdk/jfx/pull/187>
>>>>  * Compile with fallback, if Compilable is implemented, compile PI for fine-grained control
>>>>    (2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>>> 
>>>> 
>>>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>>>> Hi Kevin,
>>>>> 
>>>>> as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes:
>>>>> 
>>>>>    Summary
>>>>>    =======
>>>>>    Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
>>>>>    implements the javax.script.Compilable interface to speed up execution. In case compilation
>>>>>    throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
>>>>>    control of script compilation with a "compile" PI for FXML files.
>>>>> 
>>>>>    Problem
>>>>>    =======
>>>>>    javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>>>>>    (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
>>>>> 
>>>>>    If a script engine implements the javax.script.Compilable interface, then such scripts could be
>>>>>    compiled and the resulting javax.script.CompiledScript could be executed instead using its
>>>>>    eval() methods.
>>>>> 
>>>>>    Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
>>>>>    invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>    onMouseMove) which may be repetitively invoked and evaluated.
>>>>> 
>>>>>    Solution 
>>>>>    ========
>>>>>    Before evaluating the script code test whether the javax.script.ScriptEngine implements
>>>>>    javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
>>>>>    and then use its eval() method to evaluate the script, otherwise continue to use the
>>>>>    javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
>>>>>    (unexpectedly) a javax.script.ScriptException then fall back to using the
>>>>>    javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
>>>>>    the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
>>>>>    files.
>>>>> 
>>>>>    Specification
>>>>>    =============
>>>>>    If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
>>>>>    compile() method to compile the script to a javax.script.CompiledScript object and use its
>>>>>    eval() method to run the script. In the case that the compilation throws (unexpectedly) a
>>>>>    javax.script.ScriptException log a warning and fall back to using the
>>>>>    javax.script.ScriptEngine's eval() method instead.
>>>>>    To allow setting this feature off and on while processing the FXML file a "compile" process
>>>>>    instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
>>>>>    compilation off and on throughout a FXML file.
>>>>> 
>>>>> Having never seen a real CSR I hope that this matches what is expected and is helpful for
>>>>> assessment. If not please advise (got the name of these fields from [1]).
>>>>> 
>>>>> ---
>>>>> 
>>>>> Also added brief information about the respective test units (what they test and yield) in the WIP  [2].
>>>>> 
>>>>> ---rony
>>>>> 
>>>>> [1] "CSR-FAQ": <https://wiki.openjdk.java.net/display/csr/CSR+FAQs>
>>>>> 
>>>>> [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement
>>>>> javax.script.Compilable compile scripts #192":  <https://github.com/openjdk/jfx/pull/192>
>>>>> 
>>>>> 
>>>>> On 20.04.2020 14:58, Rony G. Flatscher wrote:
>>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:
>>>>>> 
>>>>>>    This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a
>>>>>>    warning gets issued about this fact and evaluation of the script will be done without
>>>>>>    compilation. Because of the fallback scripts get compiled with this version by default. It
>>>>>>    extends PR 187 #187.
>>>>>> 
>>>>>>    To further ease spotting scripts that cause a ScriptException a message in the form of
>>>>>>    "filename: caused ScriptException" gets added to the exception handling in either of the three
>>>>>>    locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three
>>>>>>    different kinds of reporting ScriptExceptions may be questioned, however none of these tear down
>>>>>>    the FXML GUI).
>>>>>> 
>>>>>> This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged
>>>>>> whenever a script cannot be compiled and the fallback gets used.
>>>>>> 
>>>>>> It is suggested to use this WIP as it includes the compilation by default with a safe fallback to
>>>>>> evaluate the uncompiled script, if compilation (unexpectedly) fails.
>>>>>> 
>>>>>> Again, any feedback, discussion welcome!
>>>>>> 
>>>>>> ---rony
>>>>>> 
>>>>>> P.S.: In the log history there is a commit message "Make message more pregnant.", it should have
>>>>>> read "Make messages more terse." instead|.||
>>>>>> |
>>>>>> 
>>>>>> 
>>>>>> On 17.04.2020 19:37, Rony G. Flatscher wrote:
>>>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a compile PI (process
>>>>>>> instruction) for turning on and off script compilation if the script engine implements the
>>>>>>> Compilable interface.
>>>>>>> 
>>>>>>> By default compilation is off (no compilation), such that one needs to add a compile PI
>>>>>>> ("<?compile?>") at the top to activate this feature. Supplying "true" (default) or "false" as the PI
>>>>>>> data turns this feature on and off.
>>>>>>> 
>>>>>>> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off",
>>>>>>> alternating using "compile on and off", and alternating using "compile off and on". This will test
>>>>>>> all variants of applying the compile PI for all categories of scripts.
>>>>>>> 
>>>>>>> Any feedback appreciated!
>>>>>>> 
>>>>>>> ---rony
>>>>>>> 
>>>>>>> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get
>>>>>>> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes.
>>>>>>> 
>>>>>>> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a
>>>>>>> fallback solution in case a compilation is (unexpectedly) not successful, reverting to
>>>>>>> (interpretative) evaluation/execution of the script. In that version it is planned to have
>>>>>>> compilation on by default as in the case of a compilation failure there will be a safe backup solution.
>>>>>>> 
>>>>>>> 
>>>>>>> On 14.04.2020 19:52, Kevin Rushforth wrote:
>>>>>>>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to
>>>>>>>> create the CSR until the review is far enough along to know which direction we intend to go.
>>>>>>>> 
>>>>>>>> Unless there is a real concern about possible regressions if scripts are compiled by default, I
>>>>>>>> think "enabled by default" is the way to go. Your argument that such script engines are broken
>>>>>>>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable
>>>>>>>> in the first place. We still might want to add way to turn compilation off for individual scripts.
>>>>>>>> One other thing to consider is that if compilation fails, it might make sense to log a warning and
>>>>>>>> fall back to the existing interpreted mode.
>>>>>>>> 
>>>>>>>> Does anyone else have any concerns with this?
>>>>>>>> 
>>>>>>>> -- Kevin
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>>>>>>>> Hi there,
>>>>>>>>> 
>>>>>>>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days
>>>>>>>>> with the PR as per Kevin's suggestion.
>>>>>>>>> 
>>>>>>>>> (For the case that this feature should not be active by default, the CSR will suggest to define a
>>>>>>>>> new "compile" PI in the form <?compile [true|false] ?> (default, if no PI data given: true), which
>>>>>>>>> is independent of the existence of a language PI (this way it becomes also possible to allow
>>>>>>>>> compilation of external scripts denoted with the script-element, which do not need a page language
>>>>>>>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for
>>>>>>>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI
>>>>>>>>> <?compile?> or <?compile true?>  to FXML files (and <?compile false?> to turn off), which seems to
>>>>>>>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation
>>>>>>>>> of scripts on and off throughout an FXML file.)
>>>>>>>>> 
>>>>>>>>> ---rony
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>>>>>>>> 
>>>>>>>>>> Hi Kevin,
>>>>>>>>>> 
>>>>>>>>>> On 03.04.2020 01:21, Kevin Rushforth wrote:
>>>>>>>>>>> I see that you updated the PR and sent it for review.
>>>>>>>>>>> 
>>>>>>>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful
>>>>>>>>>>> feature, and if so, what form this feature should take.
>>>>>>>>>>> 
>>>>>>>>>>>  From my point of view, this does seem like a useful feature. Would other users of FXML benefit
>>>>>>>>>>> from it?
>>>>>>>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code
>>>>>>>>>> may
>>>>>>>>>> benefit.
>>>>>>>>>> 
>>>>>>>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the
>>>>>>>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit
>>>>>>>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause
>>>>>>>>>> the reparsing of that script's source and interpreting it on each invocation, which may be
>>>>>>>>>> expensive
>>>>>>>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the
>>>>>>>>>> compiled
>>>>>>>>>> script by the script engine.
>>>>>>>>>> 
>>>>>>>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in
>>>>>>>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons?
>>>>>>>>>> In principle there are three possibilities:
>>>>>>>>>> 
>>>>>>>>>>      1) If a script engine implements javax.script.Compilable, compile the script and execute the
>>>>>>>>>>      compiled version. In the case of event handlers compile and buffer the compiled script and
>>>>>>>>>>      execute the compiled script each time its registered event fires.
>>>>>>>>>> 
>>>>>>>>>>        o Pro: immediately benefits all existing FXML pages that host scripts
>>>>>>>>>>        o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail
>>>>>>>>>>          compiling but have been employed successfully in interpreted mode
>>>>>>>>>> 
>>>>>>>>>>      2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML
>>>>>>>>>>      language PI that switches on compilation of scripts hosted in FXML definitions if the script
>>>>>>>>>>      engine implements the javax.script.Compilable interface. If missing it would default to
>>>>>>>>>> "false".
>>>>>>>>>>      (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the
>>>>>>>>>>      script engine supports it. It would be an error if the "compile" PI was present, but the
>>>>>>>>>>      "language" PI was not.)
>>>>>>>>>> 
>>>>>>>>>>        o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the
>>>>>>>>>> language
>>>>>>>>>>          PI gets changed
>>>>>>>>>>        o Con: benefit not made available automatically to existing FXML pages that host scripts
>>>>>>>>>> 
>>>>>>>>>>      3) Another possibility would be to define a boolean attribute/property "compile" for script
>>>>>>>>>> and
>>>>>>>>>>      node elements and only compile the scripts, if the property is set to true
>>>>>>>>>> 
>>>>>>>>>>        o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed
>>>>>>>>>>          accordingly
>>>>>>>>>>        o Con: potential benefit not made available automatically to existing FXML pages that
>>>>>>>>>> host scripts
>>>>>>>>>> 
>>>>>>>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be
>>>>>>>>>> overruled individually by 3.
>>>>>>>>>> 
>>>>>>>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that
>>>>>>>>>> compilation
>>>>>>>>>> of scripts by the script engines would find the same errors as while interpreting the very same
>>>>>>>>>> scripts (if not, the script engine is badly broken and it could be argued that then the
>>>>>>>>>> interpretation part of the script engine might be expected to be broken as well which would be
>>>>>>>>>> quite
>>>>>>>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the
>>>>>>>>>> compiled script would behave differently to interpreting the very same script by the same script
>>>>>>>>>> engine).
>>>>>>>>>> 
>>>>>>>>>> The current WIP implements 1 above and includes an appropriate test unit.
>>>>>>>>>> 
>>>>>>>>>>> What do others think?
>>>>>>>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the
>>>>>>>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine,
>>>>>>>>>>> but we would need to ensure that.
>>>>>>>>>> The compilation of scripts needs to be done by the Java script engines (implementing both,
>>>>>>>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled
>>>>>>>>>> scripts ([javax.script.CompiledScript]
>>>>>>>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ---rony
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>> After merging master, applying some fixes and changing the title to reflect the change from
>>>>>>>>>>>> WIP to a
>>>>>>>>>>>> pull request I would kindly request a review of this pull request!
>>>>>>>>>>>> 
>>>>>>>>>>>> Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: "8238080:
>>>>>>>>>>>> FXMLLoader: if
>>>>>>>>>>>> script engines implement javax.script.Compilable compile scripts".
>>>>>>>>>>>> 
>>>>>>>>>>>> ---rony
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote:
>>>>>>>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in
>>>>>>>>>>>>> review, and
>>>>>>>>>>>>> has an appropriate test unit going with it as well, please review.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There should be no compatibility issue with this implementation.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new
>>>>>>>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML
>>>>>>>>>>>>> files.
>>>>>>>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts
>>>>>>>>>>>>> if the
>>>>>>>>>>>>> language process instruction (e.g. <?language rexx?>) contains an appropriate attribute with a
>>>>>>>>>>>>> value
>>>>>>>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML
>>>>>>>>>>>>> with
>>>>>>>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up
>>>>>>>>>>>>> with a
>>>>>>>>>>>>> respective solution as well.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ---rony
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] "Implementation and test unit": <https://github.com/openjdk/jfx/pull/129>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile
>>>>>>>>>>>>> scripts":
>>>>>>>>>>>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
>>>>>>>>>>>>> <https://github.com/openjdk/jfx/pull/122/commits>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this
>>>>>>>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to
>>>>>>>>>>>>>> illustrate
>>>>>>>>>>>>>> the concept).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility
>>>>>>>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -- Kevin
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>>>>> Just filed a RFE with the following information:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>      * Component:
>>>>>>>>>>>>>>>          o JavaFX
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>      * Subcomponent:
>>>>>>>>>>>>>>>          o fxml: JavaFX FXML
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>      * Synopsis:
>>>>>>>>>>>>>>>          o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>      * Descriptions:
>>>>>>>>>>>>>>>          o "FXMLLoader is able to execute scripts in Java script languages
>>>>>>>>>>>>>>> (javax.script.ScriptEngine
>>>>>>>>>>>>>>>            implementations) if such a Java script language gets defined as the controller
>>>>>>>>>>>>>>> language in
>>>>>>>>>>>>>>>            the FXML file.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>            If a script engine implements the javax.script.Compilable interface, then such
>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>            be compiled and the resulting javax.script.CompiledScript could be executed instead
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>            its eval() methods.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>            Evaluating the CompiledScript objects may help speed up the execution of script
>>>>>>>>>>>>>>> invocations,
>>>>>>>>>>>>>>>            especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>>>>>>>>>>> onMouseMove)
>>>>>>>>>>>>>>>            which may be repetitevly invoked and evaluated."
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>      * System /OS/Java Runtime Information:
>>>>>>>>>>>>>>>          o "All systems."
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Received the internal review ID: "9063426"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ---rony
> 


From rob.nikander at gmail.com  Sun May 24 19:28:36 2020
From: rob.nikander at gmail.com (Rob Nikander)
Date: Sun, 24 May 2020 14:28:36 -0500
Subject: Font rendering issue on macOS - cut off characters
Message-ID: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>

Hello all,

I just started experimenting with JavaFX and I notice a font rendering problem on macOS Catalina 10.15.4, an older (2012) MacBook Pro that does not have a ?retina? display. As an example, if I create a `Label` with the default font and the text ?aod?, then the ?o? character looks like a ?c?. The right side of the character is shaved off. Anyone know what is causing this and how to fix it?

Rob

From philip.race at oracle.com  Sun May 24 21:47:21 2020
From: philip.race at oracle.com (Philip Race)
Date: Sun, 24 May 2020 14:47:21 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
Message-ID: <5ECAEB69.3080303@oracle.com>

Should I understand 10.15.4 is the only version of macOS you've tried ?
Not some earlier version of Catalina for example ?

Folks *mostly* use retina so it is possible that if it is somewhat 
recently introduced it is specific to non-retina.

As to the cause ? I can only speculate. Rounding error in the bitmap size ?
Being over-written by the next glyph (d) - possibly due to some rounding 
issue again ?

If you display just "ao" does it all render ?
That might point to being over-written.

-phil.

On 5/24/20, 12:28 PM, Rob Nikander wrote:
> Hello all,
>
> I just started experimenting with JavaFX and I notice a font rendering problem on macOS Catalina 10.15.4, an older (2012) MacBook Pro that does not have a ?retina? display. As an example, if I create a `Label` with the default font and the text ?aod?, then the ?o? character looks like a ?c?. The right side of the character is shaved off. Anyone know what is causing this and how to fix it?
>
> Rob

From rob.nikander at gmail.com  Sun May 24 22:25:13 2020
From: rob.nikander at gmail.com (Rob Nikander)
Date: Sun, 24 May 2020 17:25:13 -0500
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <5ECAEB69.3080303@oracle.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
Message-ID: <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>



> On May 24, 2020, at 4:47 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> Should I understand 10.15.4 is the only version of macOS you've tried ?
> Not some earlier version of Catalina for example ?

Yes, it?s all I?ve tried. 

> As to the cause ? I can only speculate. Rounding error in the bitmap size ?
> Being over-written by the next glyph (d) - possibly due to some rounding issue again ?
> 
> If you display just "ao" does it all render ?
> That might point to being over-written.

Yes, the ?d? appears to be overwriting it. I put the following in a Label: "o od o od o od, o od o od o od?. The isolated ?o?s are fine, but 4 of 6 of the ?o?s next to the ?d?s are shaved off. 

Does JavaFX have its own text rendering engine? It?s not deferring to CoreText on macOS? 

The text render seems to have other problems compared to native apps. There is a barely-visible color in anti-aliased pixels. It?s so faint I can barely see it, but it gives me an unpleasant feeling, like my eyes are having trouble focusing. The macOS has a utility program called Digital Color Meter, which lets you see zoomed pixels of the screen. Using that, I can see clearly see that while native black on white text is black with anti-aliased pixels appearing some shade of gray, as you?d expect; the JavaFX black-on-white text has non gray colors in the anti-aliased pixels. 

I thought high res screens still used anti-aliasing for text. (?) I wonder if this is a fainter problem on retina screens as well. I have no way of checking at the moment.

Rob


From philip.race at oracle.com  Sun May 24 22:46:53 2020
From: philip.race at oracle.com (Philip Race)
Date: Sun, 24 May 2020 15:46:53 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
Message-ID: <5ECAF95D.9070105@oracle.com>



On 5/24/20, 3:25 PM, Rob Nikander wrote:
>
>> On May 24, 2020, at 4:47 PM, Philip Race<philip.race at oracle.com>  wrote:
>>
>> Should I understand 10.15.4 is the only version of macOS you've tried ?
>> Not some earlier version of Catalina for example ?
> Yes, it?s all I?ve tried.
>
>> As to the cause ? I can only speculate. Rounding error in the bitmap size ?
>> Being over-written by the next glyph (d) - possibly due to some rounding issue again ?
>>
>> If you display just "ao" does it all render ?
>> That might point to being over-written.
> Yes, the ?d? appears to be overwriting it. I put the following in a Label: "o od o od o od, o od o od o od?. The isolated ?o?s are fine, but 4 of 6 of the ?o?s next to the ?d?s are shaved off.
>
> Does JavaFX have its own text rendering engine? It?s not deferring to CoreText on macOS?

core text generates all glyph image and all information about it.
But FX uses its own OpenGL code to render the provided glyphs.

>
> The text render seems to have other problems compared to native apps. There is a barely-visible color in anti-aliased pixels. It?s so faint I can barely see it, but it gives me an unpleasant feeling,

That's likely LCD sub-pixel text. Its normal to see it if you squint. 
Not new.
macOS has been moving away from it but people with non-retina displays 
have lamented its passing.

https://osxdaily.com/2018/09/26/fix-blurry-thin-fonts-text-macos-mojave/

FX still requests LCD tho'. Although it is not clear how long macOS will 
continue to provide it.

-phil.

>   like my eyes are having trouble focusing. The macOS has a utility program called Digital Color Meter, which lets you see zoomed pixels of the screen. Using that, I can see clearly see that while native black on white text is black with anti-aliased pixels appearing some shade of gray, as you?d expect; the JavaFX black-on-white text has non gray colors in the anti-aliased pixels.
>
> I thought high res screens still used anti-aliasing for text. (?) I wonder if this is a fainter problem on retina screens as well. I have no way of checking at the moment.
>
> Rob
>

From rob.nikander at gmail.com  Sun May 24 23:27:00 2020
From: rob.nikander at gmail.com (Rob Nikander)
Date: Sun, 24 May 2020 18:27:00 -0500
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <5ECAF95D.9070105@oracle.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
Message-ID: <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>



> On May 24, 2020, at 5:46 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> That's likely LCD sub-pixel text. Its normal to see it if you squint. Not new.

I?m doubting that this is normal, but let me try to share a few screenshots so we can be sure. (All pasted into one PNG for easy comparison):

https://drive.google.com/file/d/1pHtehqm8AP0H_dkV3NdczRdqNSA5gq2o/view?usp=sharing <https://drive.google.com/file/d/1pHtehqm8AP0H_dkV3NdczRdqNSA5gq2o/view?usp=sharing>

(I hope that if you view those on a retina display, you will still see the blockier appearance of my non-retina laptop screen. )

You can see the shaved ?o? characters there, but I?m just talking about the colors now. Is that normal? To me the JavaFX text looks significantly worse than the native app text [1]. In the native app, I don?t see any color, even looking real close. The JavaFX seems like it went overboard on something. 

Rob

[1] It?s a screenshot from Pages, but they all look the same.

> macOS has been moving away from it but people with non-retina displays have lamented its passing.
> 
> https://osxdaily.com/2018/09/26/fix-blurry-thin-fonts-text-macos-mojave/ <https://osxdaily.com/2018/09/26/fix-blurry-thin-fonts-text-macos-mojave/>
> 
> FX still requests LCD tho'. Although it is not clear how long macOS will continue to provide it.


From philip.race at oracle.com  Mon May 25 00:16:52 2020
From: philip.race at oracle.com (Phil Race)
Date: Sun, 24 May 2020 17:16:52 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
 <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
Message-ID: <4987FA9B-0C29-4469-B0C8-2BBAFE18A611@oracle.com>

That looks normal.

-Phil.

> On May 24, 2020, at 4:27 PM, Rob Nikander <rob.nikander at gmail.com> wrote:
> 
> 
> 
>> On May 24, 2020, at 5:46 PM, Philip Race <philip.race at oracle.com> wrote:
>> 
>> That's likely LCD sub-pixel text. Its normal to see it if you squint. Not new.
> 
> I?m doubting that this is normal, but let me try to share a few screenshots so we can be sure. (All pasted into one PNG for easy comparison):
> 
> https://drive.google.com/file/d/1pHtehqm8AP0H_dkV3NdczRdqNSA5gq2o/view?usp=sharing
> 
> (I hope that if you view those on a retina display, you will still see the blockier appearance of my non-retina laptop screen. )
> 
> You can see the shaved ?o? characters there, but I?m just talking about the colors now. Is that normal? To me the JavaFX text looks significantly worse than the native app text [1]. In the native app, I don?t see any color, even looking real close. The JavaFX seems like it went overboard on something. 
> 
> Rob
> 
> [1] It?s a screenshot from Pages, but they all look the same.
> 
>> macOS has been moving away from it but people with non-retina displays have lamented its passing.
>> 
>> https://osxdaily.com/2018/09/26/fix-blurry-thin-fonts-text-macos-mojave/
>> 
>> FX still requests LCD tho'. Although it is not clear how long macOS will continue to provide it.
> 

From philip.race at oracle.com  Mon May 25 01:14:29 2020
From: philip.race at oracle.com (Phil Race)
Date: Sun, 24 May 2020 18:14:29 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <4987FA9B-0C29-4469-B0C8-2BBAFE18A611@oracle.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
 <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
 <4987FA9B-0C29-4469-B0C8-2BBAFE18A611@oracle.com>
Message-ID: <68125745-1B0C-439B-8571-14D8536C1EDC@oracle.com>

PS the spacing is very uneven. That does not look right.

-Phil.

> On May 24, 2020, at 5:16 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> That looks normal.
> 
> -Phil.
> 
>> On May 24, 2020, at 4:27 PM, Rob Nikander <rob.nikander at gmail.com> wrote:
>> 
>> 
>> 
>>> On May 24, 2020, at 5:46 PM, Philip Race <philip.race at oracle.com> wrote:
>>> 
>>> That's likely LCD sub-pixel text. Its normal to see it if you squint. Not new.
>> 
>> I?m doubting that this is normal, but let me try to share a few screenshots so we can be sure. (All pasted into one PNG for easy comparison):
>> 
>> https://drive.google.com/file/d/1pHtehqm8AP0H_dkV3NdczRdqNSA5gq2o/view?usp=sharing
>> 
>> (I hope that if you view those on a retina display, you will still see the blockier appearance of my non-retina laptop screen. )
>> 
>> You can see the shaved ?o? characters there, but I?m just talking about the colors now. Is that normal? To me the JavaFX text looks significantly worse than the native app text [1]. In the native app, I don?t see any color, even looking real close. The JavaFX seems like it went overboard on something. 
>> 
>> Rob
>> 
>> [1] It?s a screenshot from Pages, but they all look the same.
>> 
>>> macOS has been moving away from it but people with non-retina displays have lamented its passing.
>>> 
>>> https://osxdaily.com/2018/09/26/fix-blurry-thin-fonts-text-macos-mojave/
>>> 
>>> FX still requests LCD tho'. Although it is not clear how long macOS will continue to provide it.
>> 

From john at status6.com  Mon May 25 16:44:25 2020
From: john at status6.com (John Neffenger)
Date: Mon, 25 May 2020 09:44:25 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
 <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
Message-ID: <22e1bc9b-907e-c27f-9b21-c33305706985@status6.com>

On 5/24/20 4:27 PM, Rob Nikander wrote:
> You can see the shaved ?o? characters there, but I?m just talking about the colors now. Is that normal?

No. I think it's a bug.

See my comment dated May 20, 2020, on the old GitHub issue that reported 
the same bug on Linux in 2018 and was fixed for JavaFX 12.

Yes, it does look as if macOS now has the same problem ...
https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333

Dirk Lemmermann opened a new bug report, but I don't know the JDK Bug 
System number yet. I would like see whether I can come up with a fix, 
but I can't say when I'll get to it.

John

From rob.nikander at gmail.com  Mon May 25 16:56:00 2020
From: rob.nikander at gmail.com (Rob Nikander)
Date: Mon, 25 May 2020 11:56:00 -0500
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <22e1bc9b-907e-c27f-9b21-c33305706985@status6.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
 <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
 <22e1bc9b-907e-c27f-9b21-c33305706985@status6.com>
Message-ID: <FB0D02E7-7735-4A77-A1EC-60F2CD8E3732@gmail.com>

Thanks. Maybe I should I file another bug report for the shaved off ?o? characters?

Rob

> On May 25, 2020, at 11:44 AM, John Neffenger <john at status6.com> wrote:
> 
> On 5/24/20 4:27 PM, Rob Nikander wrote:
>> You can see the shaved ?o? characters there, but I?m just talking about the colors now. Is that normal?
> 
> No. I think it's a bug.
> 
> See my comment dated May 20, 2020, on the old GitHub issue that reported the same bug on Linux in 2018 and was fixed for JavaFX 12.
> 
> Yes, it does look as if macOS now has the same problem ...
> https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333
> 
> Dirk Lemmermann opened a new bug report, but I don't know the JDK Bug System number yet. I would like see whether I can come up with a fix, but I can't say when I'll get to it.
> 
> John


From philip.race at oracle.com  Mon May 25 18:47:54 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 25 May 2020 11:47:54 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <22e1bc9b-907e-c27f-9b21-c33305706985@status6.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
 <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
 <22e1bc9b-907e-c27f-9b21-c33305706985@status6.com>
Message-ID: <5ECC12DA.5000507@oracle.com>

Mmm .. it can't be the same bug even if the effect is similar.
We don't use freetype on macOS, that's for Linux.

Can you check your display's settings ?

https://spin.atomicobject.com/2018/08/24/macbook-pro-external-monitor-display-problem/

I have a Dell U2412M and it has a menu similar to what he sees and macOS 
for me defaults to RGB,
and selecting YPbYr results in a LOT more problems than text because I 
don't think macOS is
changing the signal when I do - I am connected via displayport too FWIW 
but have an old mac (2015)
and an old OS (10.13.6),

BTW I found the incident (bug report) and I see it is submitted as an FX 
regression
in 14.0.1 when I haven't seen any reason to suggest this is the case.
Isn't everyone seeing it just when they move to catalina ?

Can anyone say if they definitely see it on a built-in retina display too ?

You might also want to check what color profile is set in System 
settings -> Display -> Color.

-phil.


On 5/25/20, 9:44 AM, John Neffenger wrote:
> On 5/24/20 4:27 PM, Rob Nikander wrote:
>> You can see the shaved ?o? characters there, but I?m just talking 
>> about the colors now. Is that normal?
>
> No. I think it's a bug.
>
> See my comment dated May 20, 2020, on the old GitHub issue that 
> reported the same bug on Linux in 2018 and was fixed for JavaFX 12.
>
> Yes, it does look as if macOS now has the same problem ...
> https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333 
>
>
> Dirk Lemmermann opened a new bug report, but I don't know the JDK Bug 
> System number yet. I would like see whether I can come up with a fix, 
> but I can't say when I'll get to it.
>
> John

From projects at saring.de  Mon May 25 19:31:48 2020
From: projects at saring.de (projects at saring.de)
Date: Mon, 25 May 2020 21:31:48 +0200
Subject: Font rendering issue on macOS - cut off characters
Message-ID: <6DD963AA-0292-4F5C-9294-3920C20A302B@saring.de>

Sounds like the same bug I've already reported to the OpenJFX project: https://bugs.openjdk.java.net/browse/JDK-8236689 <https://bugs.openjdk.java.net/browse/JDK-8236689>
It occurred for me the first time after updating to macOS 10.15 / Catalina and only on non-retina displays.

Unfortunately there was no progress on this bug yet.

Bye, Stefan

From philip.race at oracle.com  Mon May 25 20:34:38 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 25 May 2020 13:34:38 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <6DD963AA-0292-4F5C-9294-3920C20A302B@saring.de>
References: <6DD963AA-0292-4F5C-9294-3920C20A302B@saring.de>
Message-ID: <5ECC2BDE.7040100@oracle.com>

I completely forgot we had that report.
I think it describes all the same things discussed here.

So it is a catalina issue, not a regression, and it
is retina & non-retina, but the various consequences
are more apparent on non-retina, and only on non-retina
are we seeing the cut-off glyphs.

Hmm. Some of the glyphs are grey scale. I wonder
if all of the glyphs are grey scale but in LCD format and something
unintended is happening during rendering with sub-pixel
positioning ? I think we could inadvertently introduce what
is being seen here if we shifted a greyscale 3x oversampled image.
Or maybe something changed in the way macOS is providing subpixel 
positions, which varies according to font size.
We actually cache glyphs rendered at sub-pixel positions so the
final rendering step likely isn't where the (main) problem is
introduced.

-phil.

On 5/25/20, 12:31 PM, projects at saring.de wrote:
> Sounds like the same bug I've already reported to the OpenJFX project: https://bugs.openjdk.java.net/browse/JDK-8236689<https://bugs.openjdk.java.net/browse/JDK-8236689>
> It occurred for me the first time after updating to macOS 10.15 / Catalina and only on non-retina displays.
>
> Unfortunately there was no progress on this bug yet.
>
> Bye, Stefan

From john at status6.com  Mon May 25 21:33:19 2020
From: john at status6.com (John Neffenger)
Date: Mon, 25 May 2020 14:33:19 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <5ECC2BDE.7040100@oracle.com>
References: <6DD963AA-0292-4F5C-9294-3920C20A302B@saring.de>
 <5ECC2BDE.7040100@oracle.com>
Message-ID: <239dbcb8-7c3e-8465-cac1-c07ec66771f0@status6.com>

On 5/25/20 1:34 PM, Philip Race wrote:
> Hmm. Some of the glyphs are grey scale.

I see that, too. Notice the first "A" in "Animation" is anti-aliased in 
grayscale, yet the other letters use subpixel rendering and result in 
severe color fringes:

https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333

Also note that the letters seem too close together on macOS compared to 
Windows and Linux.

Unfortunately, I have only macOS 10.15 Catalina now, so I can't see how 
this renders on 10.13 High Sierra before Apple removed subpixel 
rendering for 10.14 Mojave.

John

From arapte at openjdk.java.net  Tue May 26 04:13:06 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 26 May 2020 04:13:06 GMT
Subject: [Rev 01] RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
 <qSxp3799EDTVenr3TCG-rKLSyV4c76MmPaGO4FEHYFE=.4f0cd2a9-1183-47d9-8704-9f4550b3778a@github.com>
Message-ID: <oheQXPF2GPNEGZRJkRZ3uRjZl1wO0Qm0kTAIZzCPoUw=.abf07eb5-0b03-4421-be87-24d3da80bc6f@github.com>

On Thu, 21 May 2020 16:50:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TabPaneSkinHeaderOrderTest.java line 52:
> 
>> 51:  * updating the tab headers.
>> 52:  *
>> 53:  */
> 
> Minor: this blank comment line can be removed.

removed the blank line.

-------------

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

From fastegal at openjdk.java.net  Tue May 26 04:43:32 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 26 May 2020 04:43:32 GMT
Subject: [Integrated] RFR: 8244531: Tests: add support to identify
 recurring issues with controls et al
In-Reply-To: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
References: <FPtV-tao9ECfcOe6vWfnpkVNIPvyWhFYT0TR_z9dHAs=.75a01868-510b-4c9b-b96c-9dbb926d7c3c@github.com>
Message-ID: <u0nzer1R1jA4V4LnUHmMkyWFdkRZ3SotovAdpRZTbsg=.aa5cf3ca-025e-4bd8-baa9-c73b453a7c47@github.com>

On Mon, 18 May 2020 12:07:30 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> It's a task to support cross-control/skin testing for recurring issues (like memory leaks on switching skins)
> 
> Basically, there's a utility class
> - to access lists of all control/classes,
> - to access/create all behaviors
> - has alternative skins classes for all controls and utility to install/replace skins
> 
> POC:
> - added tests Skin/BehaviorMemoryTest as examples for using
> - changed SkinDisposeContractTest to use

This pull request has now been integrated.

Changeset: f3190db7
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/f3190db7
Stats:     1357 lines in 6 files changed: 97 ins; 1255 del; 5 mod

8244531: Tests: add support to identify recurring issues with controls et al

Reviewed-by: aghaisas

-------------

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

From swpalmer at gmail.com  Tue May 26 04:53:05 2020
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 26 May 2020 00:53:05 -0400
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <5ECC12DA.5000507@oracle.com>
References: <5ECC12DA.5000507@oracle.com>
Message-ID: <CFA44EBB-5F3D-42A5-B96A-A0500D3AA305@gmail.com>

> Can anyone say if they definitely see it on a built-in retina display too ?

Yes. It is present on the built-in Retina display on my mid-2015 MacBook Pro running Catalina 10.15.5 beta. 

I looked quickly using Java 8.

Scott


> On May 25, 2020, at 2:48 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> ?Mmm .. it can't be the same bug even if the effect is similar.
> We don't use freetype on macOS, that's for Linux.
> 
> Can you check your display's settings ?
> 
> https://spin.atomicobject.com/2018/08/24/macbook-pro-external-monitor-display-problem/
> 
> I have a Dell U2412M and it has a menu similar to what he sees and macOS for me defaults to RGB,
> and selecting YPbYr results in a LOT more problems than text because I don't think macOS is
> changing the signal when I do - I am connected via displayport too FWIW but have an old mac (2015)
> and an old OS (10.13.6),
> 
> BTW I found the incident (bug report) and I see it is submitted as an FX regression
> in 14.0.1 when I haven't seen any reason to suggest this is the case.
> Isn't everyone seeing it just when they move to catalina ?
> 
> Can anyone say if they definitely see it on a built-in retina display too ?
> 
> You might also want to check what color profile is set in System settings -> Display -> Color.
> 
> -phil.
> 
> 
>> On 5/25/20, 9:44 AM, John Neffenger wrote:
>>> On 5/24/20 4:27 PM, Rob Nikander wrote:
>>> You can see the shaved ?o? characters there, but I?m just talking about the colors now. Is that normal?
>> 
>> No. I think it's a bug.
>> 
>> See my comment dated May 20, 2020, on the old GitHub issue that reported the same bug on Linux in 2018 and was fixed for JavaFX 12.
>> 
>> Yes, it does look as if macOS now has the same problem ...
>> https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333 
>> 
>> Dirk Lemmermann opened a new bug report, but I don't know the JDK Bug System number yet. I would like see whether I can come up with a fix, but I can't say when I'll get to it.
>> 
>> John

From arapte at openjdk.java.net  Tue May 26 04:56:02 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 26 May 2020 04:56:02 GMT
Subject: [Integrated] RFR: 8245601: [TESTBUG] Disable
 TabPaneDragPolicyTest on Mac until JDK-8213136 is fixed and fix ISE
In-Reply-To: <MU7MRmH_Eea8wiPu0mHMhInb8aUvyr7gDcOVWIg-UrE=.ad277abe-8886-43fc-bafc-980e8feca6c4@github.com>
References: <MU7MRmH_Eea8wiPu0mHMhInb8aUvyr7gDcOVWIg-UrE=.ad277abe-8886-43fc-bafc-980e8feca6c4@github.com>
Message-ID: <oKTSQQWaKYfR17eCYgZDKpQnvxfWysmzW3zIZ7-H36Y=.453f69c6-a63f-4761-8c05-767840264c7c@github.com>

On Fri, 22 May 2020 13:21:45 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The reordering tests in TabPaneDragPolicyTest fail only fails on Mac. It may be a a product issue which is tracked by
> [JDK-8213136](https://bugs.openjdk.java.net/browse/JDK-8213136). This PR disables the 4 reordering test on Mac
> platform. And fixes an Exception, Please check the JBS for exception.

This pull request has now been integrated.

Changeset: 2d98fe6c
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/2d98fe6c
Stats:     13 lines in 1 file changed: 0 ins; 11 del; 2 mod

8245601: TESTBUG] Disable TabPaneDragPolicyTest on Mac until JDK-8213136 is fixed and fix ISE

Reviewed-by: kcr

-------------

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

From ajoseph at openjdk.java.net  Tue May 26 10:53:17 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Tue, 26 May 2020 10:53:17 GMT
Subject: RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails
 intermittently
Message-ID: <o5zSKMRDX63o9Z06L5RHir_zlnqkEHDerMrPzAVZdhw=.1329037f-c406-48fc-a3e2-248b603868c5@github.com>

Cause: The test assumes that WebView/WebPage will be GCed right after `System.gc()`

Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

-------------

Commit messages:
 - Update copyright year
 - Remove unwanted line
 - 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

Changes: https://git.openjdk.java.net/jfx/pull/236/files
 Webrev: https://webrevs.openjdk.java.net/jfx/236/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234540
  Stats: 33 lines in 1 file changed: 7 ins; 15 del; 11 mod
  Patch: https://git.openjdk.java.net/jfx/pull/236.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/236/head:pull/236

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

From arapte at openjdk.java.net  Tue May 26 11:18:37 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 26 May 2020 11:18:37 GMT
Subject: RFR: 8234876: Unit test classes should not extend Application
Message-ID: <K1R8uWLbBcy6Wg6wyh2bOcIMFyCVeSDJijj7Mo8DPjg=.0a6c732d-eaba-4885-ad6c-5bafafe6fd9f@github.com>

Copied from JBS:
As a best practice, unit test classes that are run by Junit should not extend javafx.application.Application.
JUnit constructs an instance of a test class for each test method that it runs. This will be different from the
instance of the object that is constructed when Application.launch method is called, and this can lead to unexpected
behavior. Most of our tests use helper classes or nested (static) sub classes of Application, but the following two
test classes do not:

tests/system/src/test/java/test/com/sun/javafx/image/impl/ImageRaceTest.java
tests/system/src/test/java/test/javafx/scene/control/AccordionTitlePaneLeakTest.java

----
Changes in the tests are:
ImageRaceTest.java->  Does not require a sub class of Application.
AccordionTitlePaneLeakTest.java->  Required minor changes to create a static sub class.

-------------

Commit messages:
 - 8234876: Unit test classes should not extend Application

Changes: https://git.openjdk.java.net/jfx/pull/237/files
 Webrev: https://webrevs.openjdk.java.net/jfx/237/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234876
  Stats: 51 lines in 2 files changed: 4 ins; 25 del; 22 mod
  Patch: https://git.openjdk.java.net/jfx/pull/237.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/237/head:pull/237

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

From nlisker at openjdk.java.net  Tue May 26 11:33:01 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 26 May 2020 11:33:01 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <G1rAVCJCqUU20uweJcarnv755R41OsKeh1XKUK71C2M=.f94cff54-0ea1-49bd-b990-a264eadcae36@github.com>
Message-ID: <7ZslgtCTCatCCthZ-eZmVbpRGunyfbL9MaqZOsJvy4U=.df2b120f-1d5e-4d77-b813-86283288756b@github.com>

On Mon, 11 May 2020 04:44:27 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> Overall looks good to me, Added few minor comments.

@kevinrushforth Do you have any other comments?

-------------

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

From aghaisas at openjdk.java.net  Tue May 26 11:51:12 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 May 2020 11:51:12 GMT
Subject: RFR: 8245499: Text input controls should show handles on iOS
In-Reply-To: <WXRqb2fsnHrONTu8CkfCWB7gghA7lQibOvDv32117Xw=.52f5275b-5f69-4c5b-9d89-2db46f6b7f28@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
 <WXRqb2fsnHrONTu8CkfCWB7gghA7lQibOvDv32117Xw=.52f5275b-5f69-4c5b-9d89-2db46f6b7f28@github.com>
Message-ID: <jNyDxIMoFpSktR5iodZq3ZLk91nSJvesWDVu7jrPFFg=.5898bd89-db7a-4cc8-b55b-98538bfd2979@github.com>

On Thu, 21 May 2020 18:11:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
>> device. However, selection handles are not enabled and currently text selection is not possible at all.
>> This PR enables handles on iOS as in the rest of the platforms with touch support.
>> 
>> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
>> are a little bit bigger, and there is no caret handle.
>
> Since this touches shared code, I'd like @aghaisas to look at this.

Code changes look OK.
I think, we need a note in PR description about what testing you have done with this fix.

-------------

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

From aghaisas at openjdk.java.net  Tue May 26 11:51:14 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 May 2020 11:51:14 GMT
Subject: RFR: 8245499: Text input controls should show handles on iOS
In-Reply-To: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
Message-ID: <P4GuxeqCe5VasM7O68z6d33tCBIuc_9nV5LE4QbQxnM=.49b3e2ef-30cb-4b86-a63f-a4ace0965ada@github.com>

On Thu, 21 May 2020 17:41:02 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
> device. However, selection handles are not enabled and currently text selection is not possible at all.
> This PR enables handles on iOS as in the rest of the platforms with touch support.
> 
> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
> are a little bit bigger, and there is no caret handle.

modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/caspian/ios.css line 58:

> 57:     -fx-pref-height: 12;
> 58: }

No newline at end of file.

modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/modena/ios.css line 58:

> 57:     -fx-pref-height: 12;
> 58: }

No newline at end of file.

-------------

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

From fastegal at openjdk.java.net  Tue May 26 13:47:26 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 26 May 2020 13:47:26 GMT
Subject: RFR: 8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin
Message-ID: <DzckbpguK2-T4rkhY6R12BQ_zgpkpHs3nxhRxGbkD6Y=.0ffedc7c-58ba-4f7f-913f-24da2a90ec40@github.com>

Both skins have similar misbehavior when switching skins

- memory leak due to a manually added but not removed change listener
- NPE when modifying items after skin switch due to a not removed listener to the control's items

Fixed in both (for details see the issue). Added SkinCleanupTest for simple testing of per-control side-effects,
removed both skins from memory test exclusion list: failing before and passing after fix.

-------------

Commit messages:
 - 8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin

Changes: https://git.openjdk.java.net/jfx/pull/238/files
 Webrev: https://webrevs.openjdk.java.net/jfx/238/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244657
  Stats: 158 lines in 4 files changed: 150 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/238.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/238/head:pull/238

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

From john at status6.com  Tue May 26 15:27:25 2020
From: john at status6.com (John Neffenger)
Date: Tue, 26 May 2020 08:27:25 -0700
Subject: Font rendering issue on macOS - cut off characters
In-Reply-To: <5ECC12DA.5000507@oracle.com>
References: <06FBD238-6772-43F3-974C-7AFD0B07C045@gmail.com>
 <5ECAEB69.3080303@oracle.com>
 <1B059816-2E81-495B-A095-2C8977C491C4@gmail.com>
 <5ECAF95D.9070105@oracle.com>
 <C06C0A6A-D341-4F12-B3D2-544EC37A6E10@gmail.com>
 <22e1bc9b-907e-c27f-9b21-c33305706985@status6.com>
 <5ECC12DA.5000507@oracle.com>
Message-ID: <9ca00bee-93a9-828b-8648-77625645b0fa@status6.com>

On 5/25/20 11:47 AM, Philip Race wrote:
> Mmm .. it can't be the same bug even if the effect is similar.
> We don't use freetype on macOS, that's for Linux.

Right. I meant the same visible bug (severe color fringes).

> Can you check your display's settings ?

I'm using a Dell UltraSharp U2715H 27-inch monitor (2560 ? 1440 px at 
109 ppi) on a Mac mini. The monitor's on-screen display shows "Input 
Color Format: RGB".

In any case, so far I've seen these color fringes only in JavaFX 
applications on my Mac.

> Isn't everyone seeing it just when they move to catalina ?

The color fringes may have shown up when macOS switched to grayscale 
anti-aliasing in macOS 10.14 Mojave. [1]

Does anyone have two Macs available for testing on both 10.13 High 
Sierra (with subpixel rendering) and 10.15 Catalina (without)?

> You might also want to check what color profile is set in System 
> settings -> Display -> Color.

That shows DELL U2715H as my active display profile.

John

[1] See the short section on "Font antialiasing refinements" at 28:03 in 
this video from Apple WWDC 2018:
https://developer.apple.com/videos/play/wwdc2018/209/?time=1683

From jpereda at openjdk.java.net  Tue May 26 17:33:20 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Tue, 26 May 2020 17:33:20 GMT
Subject: [Rev 01] RFR: 8245499: Text input controls should show handles on
 iOS
In-Reply-To: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
Message-ID: <qhIHiwl1eIRVT47yDLNTIJwSsht9PZhcc3nbKxbuOG8=.d0868bd4-3391-4b56-851d-07f50613ac76@github.com>

> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
> device. However, selection handles are not enabled and currently text selection is not possible at all.
> This PR enables handles on iOS as in the rest of the platforms with touch support.
> 
> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
> are a little bit bigger, and there is no caret handle.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Add new line at the end of the file

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/231/files
  - new: https://git.openjdk.java.net/jfx/pull/231/files/4933c7d4..fc681a1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/231/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/231/webrev.00-01

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

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

From jpereda at openjdk.java.net  Tue May 26 17:35:56 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Tue, 26 May 2020 17:35:56 GMT
Subject: RFR: 8245499: Text input controls should show handles on iOS
In-Reply-To: <jNyDxIMoFpSktR5iodZq3ZLk91nSJvesWDVu7jrPFFg=.5898bd89-db7a-4cc8-b55b-98538bfd2979@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
 <WXRqb2fsnHrONTu8CkfCWB7gghA7lQibOvDv32117Xw=.52f5275b-5f69-4c5b-9d89-2db46f6b7f28@github.com>
 <jNyDxIMoFpSktR5iodZq3ZLk91nSJvesWDVu7jrPFFg=.5898bd89-db7a-4cc8-b55b-98538bfd2979@github.com>
Message-ID: <FQ-S_XB1nDkl9VFY8P6GsDzFsJGYFwQJX6ZOBLYMCK4=.0d74fe8f-8834-4452-9966-5580191b10e4@github.com>

On Tue, 26 May 2020 11:46:54 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Since this touches shared code, I'd like @aghaisas to look at this.
>
> Code changes look OK.
> I think, we need a note in PR description about what testing you have done with this fix.

I've edited the PR description with details of the tests I've done.

-------------

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

From jpereda at openjdk.java.net  Tue May 26 17:35:57 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Tue, 26 May 2020 17:35:57 GMT
Subject: [Rev 01] RFR: 8245499: Text input controls should show handles on
 iOS
In-Reply-To: <P4GuxeqCe5VasM7O68z6d33tCBIuc_9nV5LE4QbQxnM=.49b3e2ef-30cb-4b86-a63f-a4ace0965ada@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
 <P4GuxeqCe5VasM7O68z6d33tCBIuc_9nV5LE4QbQxnM=.49b3e2ef-30cb-4b86-a63f-a4ace0965ada@github.com>
Message-ID: <u4XZigL-EAVNDfP1u3XZ8qYs_JdFAd1crKta2l5i53s=.be5b8a9e-5b15-44dc-8cae-b6fccaabf727@github.com>

On Tue, 26 May 2020 11:42:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add new line at the end of the file
>
> modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/caspian/ios.css line 58:
> 
>> 57:     -fx-pref-height: 12;
>> 58: }
> 
> No newline at end of file.

Fixed

> modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/modena/ios.css line 58:
> 
>> 57:     -fx-pref-height: 12;
>> 58: }
> 
> No newline at end of file.

Fixed

-------------

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

From kcr at openjdk.java.net  Tue May 26 20:19:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 May 2020 20:19:55 GMT
Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL
 context changes
In-Reply-To: <PxQulAMSgKPbxHAaeqVaZ1RNizQRBICtUPnqiOl_KfU=.896e4345-3dd8-44b5-8dd6-b0f50b149212@github.com>
References: <or67mzmuvlaOT4sysxt6Snb7QtcbArNZDug84t0_N34=.e7e280b9-222b-47b3-8f1b-eaa6c504f9f8@github.com>
 <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com>
 <AJ36gFtvSrx0d7WObMbYh-pca9Vm_q42fEDHFuNqiiY=.8c01e3f1-c72d-45ab-9429-53c8f8874599@github.com>
 <PxQulAMSgKPbxHAaeqVaZ1RNizQRBICtUPnqiOl_KfU=.896e4345-3dd8-44b5-8dd6-b0f50b149212@github.com>
Message-ID: <0lJ9LsO0Tm6LfRtohHck4R3AoPQPv4r02MKPLL-aODQ=.c7cc7e49-cada-4859-a8c7-d0b9cc0f2c1a@github.com>

On Mon, 13 Apr 2020 18:56:36 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> The root cause for this issue is not the unnecessary logging, but the fact that the Quantum Renderer keeps running when
>> the app is not in the foreground (causing a long list of debug lines). I'll create a separate issue for that.
>
> It would be nice to show this debug info when javafx.pulseLogger is true, and hide it when that property is false. It
> shows interesting information about the rendering phase, so when that info is requested (by enabling pulseLogger), it
> is useful.

@jperedadnr I think this is pending an answer to @johanvos comment. Also, he should review it, so I set the number of
reviewers to 2.

-------------

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

From kevin.rushforth at oracle.com  Tue May 26 20:43:50 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 26 May 2020 13:43:50 -0700
Subject: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP
 (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for
 review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script
 engines implement javax.script.Compilabel compile scripts"
In-Reply-To: <D45D8007-1AEA-4A09-B91D-FEDF12EA0F37@wu.ac.at>
References: <77bc0cae-bee1-c569-ca0b-abc4d7ca9be6@wu.ac.at>
 <D45D8007-1AEA-4A09-B91D-FEDF12EA0F37@wu.ac.at>
Message-ID: <d0767be3-1b9e-75e0-a65c-9dd4ce51c38f@oracle.com>

This is waiting on me. I need to review the updated API docs and CSR 
test, and then create a draft CSR issue.

-- Kevin


On 5/23/2020 11:30 AM, Rony G Flatscher wrote:
> Hi Kevin,
>
> is there anything I need to do? What are the next steps I should look for?
>
> ?-rony
>
> Rony G. Flatscher (mobil/e)
>
>> Am 12.05.2020 um 19:23 schrieb Rony G. Flatscher <Rony.Flatscher at wu.ac.at>:
>>
>> ?Hi Kevin,
>>
>> in the meantime I have tried to come up with a formulation for the "Introduction to FXML"
>> specification about the new compile processing instruction which is brief and complete. While being
>> there I fixed a typo in the document and added a missing language processing instruction to an
>> existing script example, hope that was o.k. as I have not filed an explicit bug for it.
>>
>> Also closed the PR 129 and 187, removed the WIP from PR 192, and supplied the CSR draft as a comment.
>>
>> If there is anything else I should do, please let me know.
>>
>> Cheers,
>>
>> ---rony
>>
>>
>>> On 11.05.2020 14:12, Rony G. Flatscher wrote:
>>> Hi Kevin,
>>>
>>>> On 09.05.2020 17:16, Kevin Rushforth wrote:
>>>> I'm finally getting back to this. I took a look at https://github.com/openjdk/jfx/pull/192 and I
>>>> like that as the direction for this enhancement.
>>>>
>>>> The initial CSR you have is a good start.
>>> Thank you!
>>>
>>>> Next steps are:
>>>>
>>>> 1. Update the "Introduction to FXML" specification (see my comment in the PR)
>>>> 2. Update PR 192 with the draft CSR as a comment, modifying it to include the above additions to
>>>> "Introduction to FXML"
>>>> 3. Remove WIP from the title
>>>>
>>>> You can then close the other two PRs (129 and 187).
>>> will do (may take a little bit).
>>>
>>> Cheers
>>>
>>> ---rony
>>>
>>>
>>>> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>>>> Hi Kevin,
>>>>>
>>>>> what should be the next steps?
>>>>>
>>>>> Should I remove "WIP" from the title in <https://github.com/openjdk/jfx/pull/192> and add the CSR
>>>>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby requesting it to be added
>>>>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>>>>
>>>>> Please advise.
>>>>>
>>>>> TIA,
>>>>>
>>>>> ---rony
>>>>>
>>>>> P.S.: This is the RFE:
>>>>>
>>>>>   * RFE (2020-01-24): <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>>>
>>>>> These are the three versions (all with appropriate unit tests) that I came up with
>>>>> chronologically to implement the RFE, would prefer the latest version (PR # 192):
>>>>>
>>>>>   * Compile if Compilable implemented (2020-02-28): <https://github.com/openjdk/jfx/pull/129>
>>>>>   * Compile if compile PI and Compilable is implemented (2020-04-11):
>>>>>     <https://github.com/openjdk/jfx/pull/187>
>>>>>   * Compile with fallback, if Compilable is implemented, compile PI for fine-grained control
>>>>>     (2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>>>>
>>>>>
>>>>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>>>>> Hi Kevin,
>>>>>>
>>>>>> as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes:
>>>>>>
>>>>>>     Summary
>>>>>>     =======
>>>>>>     Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine
>>>>>>     implements the javax.script.Compilable interface to speed up execution. In case compilation
>>>>>>     throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow
>>>>>>     control of script compilation with a "compile" PI for FXML files.
>>>>>>
>>>>>>     Problem
>>>>>>     =======
>>>>>>     javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>>>>>>     (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file.
>>>>>>
>>>>>>     If a script engine implements the javax.script.Compilable interface, then such scripts could be
>>>>>>     compiled and the resulting javax.script.CompiledScript could be executed instead using its
>>>>>>     eval() methods.
>>>>>>
>>>>>>     Evaluating the javax.script.CompiledScript objects may help speed up the execution of script
>>>>>>     invocations, especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>>     onMouseMove) which may be repetitively invoked and evaluated.
>>>>>>
>>>>>>     Solution
>>>>>>     ========
>>>>>>     Before evaluating the script code test whether the javax.script.ScriptEngine implements
>>>>>>     javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first
>>>>>>     and then use its eval() method to evaluate the script, otherwise continue to use the
>>>>>>     javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield
>>>>>>     (unexpectedly) a javax.script.ScriptException then fall back to using the
>>>>>>     javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of
>>>>>>     the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML
>>>>>>     files.
>>>>>>
>>>>>>     Specification
>>>>>>     =============
>>>>>>     If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its
>>>>>>     compile() method to compile the script to a javax.script.CompiledScript object and use its
>>>>>>     eval() method to run the script. In the case that the compilation throws (unexpectedly) a
>>>>>>     javax.script.ScriptException log a warning and fall back to using the
>>>>>>     javax.script.ScriptEngine's eval() method instead.
>>>>>>     To allow setting this feature off and on while processing the FXML file a "compile" process
>>>>>>     instruction ("<?compile false?>" or "<?compile true?>") gets defined that allows to turn
>>>>>>     compilation off and on throughout a FXML file.
>>>>>>
>>>>>> Having never seen a real CSR I hope that this matches what is expected and is helpful for
>>>>>> assessment. If not please advise (got the name of these fields from [1]).
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Also added brief information about the respective test units (what they test and yield) in the WIP  [2].
>>>>>>
>>>>>> ---rony
>>>>>>
>>>>>> [1] "CSR-FAQ": <https://wiki.openjdk.java.net/display/csr/CSR+FAQs>
>>>>>>
>>>>>> [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement
>>>>>> javax.script.Compilable compile scripts #192":  <https://github.com/openjdk/jfx/pull/192>
>>>>>>
>>>>>>
>>>>>> On 20.04.2020 14:58, Rony G. Flatscher wrote:
>>>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:
>>>>>>>
>>>>>>>     This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a
>>>>>>>     warning gets issued about this fact and evaluation of the script will be done without
>>>>>>>     compilation. Because of the fallback scripts get compiled with this version by default. It
>>>>>>>     extends PR 187 #187.
>>>>>>>
>>>>>>>     To further ease spotting scripts that cause a ScriptException a message in the form of
>>>>>>>     "filename: caused ScriptException" gets added to the exception handling in either of the three
>>>>>>>     locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three
>>>>>>>     different kinds of reporting ScriptExceptions may be questioned, however none of these tear down
>>>>>>>     the FXML GUI).
>>>>>>>
>>>>>>> This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged
>>>>>>> whenever a script cannot be compiled and the fallback gets used.
>>>>>>>
>>>>>>> It is suggested to use this WIP as it includes the compilation by default with a safe fallback to
>>>>>>> evaluate the uncompiled script, if compilation (unexpectedly) fails.
>>>>>>>
>>>>>>> Again, any feedback, discussion welcome!
>>>>>>>
>>>>>>> ---rony
>>>>>>>
>>>>>>> P.S.: In the log history there is a commit message "Make message more pregnant.", it should have
>>>>>>> read "Make messages more terse." instead|.||
>>>>>>> |
>>>>>>>
>>>>>>>
>>>>>>> On 17.04.2020 19:37, Rony G. Flatscher wrote:
>>>>>>>> There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a compile PI (process
>>>>>>>> instruction) for turning on and off script compilation if the script engine implements the
>>>>>>>> Compilable interface.
>>>>>>>>
>>>>>>>> By default compilation is off (no compilation), such that one needs to add a compile PI
>>>>>>>> ("<?compile?>") at the top to activate this feature. Supplying "true" (default) or "false" as the PI
>>>>>>>> data turns this feature on and off.
>>>>>>>>
>>>>>>>> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off",
>>>>>>>> alternating using "compile on and off", and alternating using "compile off and on". This will test
>>>>>>>> all variants of applying the compile PI for all categories of scripts.
>>>>>>>>
>>>>>>>> Any feedback appreciated!
>>>>>>>>
>>>>>>>> ---rony
>>>>>>>>
>>>>>>>> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get
>>>>>>>> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes.
>>>>>>>>
>>>>>>>> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a
>>>>>>>> fallback solution in case a compilation is (unexpectedly) not successful, reverting to
>>>>>>>> (interpretative) evaluation/execution of the script. In that version it is planned to have
>>>>>>>> compilation on by default as in the case of a compilation failure there will be a safe backup solution.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14.04.2020 19:52, Kevin Rushforth wrote:
>>>>>>>>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to
>>>>>>>>> create the CSR until the review is far enough along to know which direction we intend to go.
>>>>>>>>>
>>>>>>>>> Unless there is a real concern about possible regressions if scripts are compiled by default, I
>>>>>>>>> think "enabled by default" is the way to go. Your argument that such script engines are broken
>>>>>>>>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable
>>>>>>>>> in the first place. We still might want to add way to turn compilation off for individual scripts.
>>>>>>>>> One other thing to consider is that if compilation fails, it might make sense to log a warning and
>>>>>>>>> fall back to the existing interpreted mode.
>>>>>>>>>
>>>>>>>>> Does anyone else have any concerns with this?
>>>>>>>>>
>>>>>>>>> -- Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>>>>>>>>> Hi there,
>>>>>>>>>>
>>>>>>>>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days
>>>>>>>>>> with the PR as per Kevin's suggestion.
>>>>>>>>>>
>>>>>>>>>> (For the case that this feature should not be active by default, the CSR will suggest to define a
>>>>>>>>>> new "compile" PI in the form <?compile [true|false] ?> (default, if no PI data given: true), which
>>>>>>>>>> is independent of the existence of a language PI (this way it becomes also possible to allow
>>>>>>>>>> compilation of external scripts denoted with the script-element, which do not need a page language
>>>>>>>>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for
>>>>>>>>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI
>>>>>>>>>> <?compile?> or <?compile true?>  to FXML files (and <?compile false?> to turn off), which seems to
>>>>>>>>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation
>>>>>>>>>> of scripts on and off throughout an FXML file.)
>>>>>>>>>>
>>>>>>>>>> ---rony
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Kevin,
>>>>>>>>>>>
>>>>>>>>>>> On 03.04.2020 01:21, Kevin Rushforth wrote:
>>>>>>>>>>>> I see that you updated the PR and sent it for review.
>>>>>>>>>>>>
>>>>>>>>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful
>>>>>>>>>>>> feature, and if so, what form this feature should take.
>>>>>>>>>>>>
>>>>>>>>>>>>   From my point of view, this does seem like a useful feature. Would other users of FXML benefit
>>>>>>>>>>>> from it?
>>>>>>>>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code
>>>>>>>>>>> may
>>>>>>>>>>> benefit.
>>>>>>>>>>>
>>>>>>>>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the
>>>>>>>>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit
>>>>>>>>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause
>>>>>>>>>>> the reparsing of that script's source and interpreting it on each invocation, which may be
>>>>>>>>>>> expensive
>>>>>>>>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the
>>>>>>>>>>> compiled
>>>>>>>>>>> script by the script engine.
>>>>>>>>>>>
>>>>>>>>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in
>>>>>>>>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons?
>>>>>>>>>>> In principle there are three possibilities:
>>>>>>>>>>>
>>>>>>>>>>>       1) If a script engine implements javax.script.Compilable, compile the script and execute the
>>>>>>>>>>>       compiled version. In the case of event handlers compile and buffer the compiled script and
>>>>>>>>>>>       execute the compiled script each time its registered event fires.
>>>>>>>>>>>
>>>>>>>>>>>         o Pro: immediately benefits all existing FXML pages that host scripts
>>>>>>>>>>>         o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail
>>>>>>>>>>>           compiling but have been employed successfully in interpreted mode
>>>>>>>>>>>
>>>>>>>>>>>       2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML
>>>>>>>>>>>       language PI that switches on compilation of scripts hosted in FXML definitions if the script
>>>>>>>>>>>       engine implements the javax.script.Compilable interface. If missing it would default to
>>>>>>>>>>> "false".
>>>>>>>>>>>       (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the
>>>>>>>>>>>       script engine supports it. It would be an error if the "compile" PI was present, but the
>>>>>>>>>>>       "language" PI was not.)
>>>>>>>>>>>
>>>>>>>>>>>         o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the
>>>>>>>>>>> language
>>>>>>>>>>>           PI gets changed
>>>>>>>>>>>         o Con: benefit not made available automatically to existing FXML pages that host scripts
>>>>>>>>>>>
>>>>>>>>>>>       3) Another possibility would be to define a boolean attribute/property "compile" for script
>>>>>>>>>>> and
>>>>>>>>>>>       node elements and only compile the scripts, if the property is set to true
>>>>>>>>>>>
>>>>>>>>>>>         o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed
>>>>>>>>>>>           accordingly
>>>>>>>>>>>         o Con: potential benefit not made available automatically to existing FXML pages that
>>>>>>>>>>> host scripts
>>>>>>>>>>>
>>>>>>>>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be
>>>>>>>>>>> overruled individually by 3.
>>>>>>>>>>>
>>>>>>>>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that
>>>>>>>>>>> compilation
>>>>>>>>>>> of scripts by the script engines would find the same errors as while interpreting the very same
>>>>>>>>>>> scripts (if not, the script engine is badly broken and it could be argued that then the
>>>>>>>>>>> interpretation part of the script engine might be expected to be broken as well which would be
>>>>>>>>>>> quite
>>>>>>>>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the
>>>>>>>>>>> compiled script would behave differently to interpreting the very same script by the same script
>>>>>>>>>>> engine).
>>>>>>>>>>>
>>>>>>>>>>> The current WIP implements 1 above and includes an appropriate test unit.
>>>>>>>>>>>
>>>>>>>>>>>> What do others think?
>>>>>>>>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the
>>>>>>>>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine,
>>>>>>>>>>>> but we would need to ensure that.
>>>>>>>>>>> The compilation of scripts needs to be done by the Java script engines (implementing both,
>>>>>>>>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled
>>>>>>>>>>> scripts ([javax.script.CompiledScript]
>>>>>>>>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---rony
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>>> After merging master, applying some fixes and changing the title to reflect the change from
>>>>>>>>>>>>> WIP to a
>>>>>>>>>>>>> pull request I would kindly request a review of this pull request!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: "8238080:
>>>>>>>>>>>>> FXMLLoader: if
>>>>>>>>>>>>> script engines implement javax.script.Compilable compile scripts".
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---rony
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote:
>>>>>>>>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in
>>>>>>>>>>>>>> review, and
>>>>>>>>>>>>>> has an appropriate test unit going with it as well, please review.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There should be no compatibility issue with this implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new
>>>>>>>>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML
>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts
>>>>>>>>>>>>>> if the
>>>>>>>>>>>>>> language process instruction (e.g. <?language rexx?>) contains an appropriate attribute with a
>>>>>>>>>>>>>> value
>>>>>>>>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up
>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>> respective solution as well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---rony
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] "Implementation and test unit": <https://github.com/openjdk/jfx/pull/129>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile
>>>>>>>>>>>>>> scripts":
>>>>>>>>>>>>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
>>>>>>>>>>>>>> <https://github.com/openjdk/jfx/pull/122/commits>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this
>>>>>>>>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to
>>>>>>>>>>>>>>> illustrate
>>>>>>>>>>>>>>> the concept).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility
>>>>>>>>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- Kevin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>>>>>>>>>>>>>>>> Just filed a RFE with the following information:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       * Component:
>>>>>>>>>>>>>>>>           o JavaFX
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       * Subcomponent:
>>>>>>>>>>>>>>>>           o fxml: JavaFX FXML
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       * Synopsis:
>>>>>>>>>>>>>>>>           o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       * Descriptions:
>>>>>>>>>>>>>>>>           o "FXMLLoader is able to execute scripts in Java script languages
>>>>>>>>>>>>>>>> (javax.script.ScriptEngine
>>>>>>>>>>>>>>>>             implementations) if such a Java script language gets defined as the controller
>>>>>>>>>>>>>>>> language in
>>>>>>>>>>>>>>>>             the FXML file.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             If a script engine implements the javax.script.Compilable interface, then such
>>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>             be compiled and the resulting javax.script.CompiledScript could be executed instead
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>             its eval() methods.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             Evaluating the CompiledScript objects may help speed up the execution of script
>>>>>>>>>>>>>>>> invocations,
>>>>>>>>>>>>>>>>             especially for scripts defined for event attributes in FXML elements (e.g. like
>>>>>>>>>>>>>>>> onMouseMove)
>>>>>>>>>>>>>>>>             which may be repetitevly invoked and evaluated."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       * System /OS/Java Runtime Information:
>>>>>>>>>>>>>>>>           o "All systems."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Received the internal review ID: "9063426"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---rony


From kcr at openjdk.java.net  Tue May 26 22:28:56 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 May 2020 22:28:56 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
Message-ID: <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>

On Fri, 24 Apr 2020 00:58:30 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
> of methods. Summery of changes:
> ### Animation
> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
> * Added `runHandler` method to deal with running the handler.
> * Moved methods to be grouped closer to where they are used rather than by visibility.
> * Removed the static import for `TickCalculation`.
> * Various small subjective readability changes.
> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>   initializing the `cuePoints` map.
> 
> ### Clip Envelopes
> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
> * Rearranged methods order to be consistent.
> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
> * Renamed `pos` to `cyclePos`.
> * Extracted common methods: `changedDirection` and `ticksRateChange`
> * Added internal documentation.
> 
> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.

The code changes look fine except for one thing I noticed (see below), which might lead to an unintended side effect.
Also, I had one suggestion for a javadoc comment block.

modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 332:

> 331:                     }
> 332:                     if (isNearZero(newRate)) {
> 333:                         if (isRunning()) {

The code from here to the end of the method used to be in an `else` block of the `if (isRunningEmbedded())` test. It
will now be run even if that test is true. Was this intended, and if so, why?

modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 402:

> 401:      */
> 402:     private void doSetCurrentRate(double value) {
> 403:         if (currentRate != null || !areNearEqual(value, DEFAULT_CURRENT_RATE)) {

The above javadoc comment block appears after the javadoc comments for the private `currentRate` property variable and
before the public get/property methods for `currentRate`. This seems fragile (although the API docs pick up the right
one), so I recommend making this an ordinary block comment (i.e., `/*` rather than `/**`). Either that or move it below
the get/property methods (and add `@param value`).

-------------

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

From kcr at openjdk.java.net  Tue May 26 23:29:28 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 May 2020 23:29:28 GMT
Subject: [Rev 01] RFR: 8238080: FXMLLoader: if script engines implement
 javax.script.Compilable compile scripts
In-Reply-To: <5nK7rqiVIiR0-3z26cwaWJFfVGmUwuaz5OeYXnicOBU=.ff2d9fb7-6008-4cb0-a56c-9883b54f29b9@github.com>
References: <x2qfTHQi6iWKoHzqJNglXGIrln_rvVV9JWsJKxYXbn8=.55bc5cc1-52f5-4572-b57c-6dc3379e3422@github.com>
 <5nK7rqiVIiR0-3z26cwaWJFfVGmUwuaz5OeYXnicOBU=.ff2d9fb7-6008-4cb0-a56c-9883b54f29b9@github.com>
Message-ID: <cJ1WpZwtLPP7OR2Xz6joD--Cvb9tXvYtg7EtqaZ06GM=.e48799cb-3270-401e-b49e-84d29685482b@github.com>

On Wed, 13 May 2020 08:46:11 GMT, Rony G. Flatscher <github.com+60214806+ronyfla at openjdk.org> wrote:

>> This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued
>> about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get
>> compiled with this version by default. It extends PR 187 <https://github.com/openjdk/jfx/pull/187>.  To further ease
>> spotting scripts that cause a ScriptException a message in the form of "filename: caused ScriptException" gets added to
>> the exception handling in either of the three locations: an error message, a stack trace or a wrap-up into a
>> RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned, however none of these
>> tear down the FXML GUI).
>
> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword the compile processing instructions (replace 'Hint' with 'Note:', adjust text to context), remove spurious empty
>   line in script example code.

Here are a couple overall comments.

1. Please update the Description of this PR now that this is no longer WIP. Also, can you copy any relevant information
from PR #187 so that this PR is standalone (reviewers shouldn't have to go to the earlier PRs for any information)?

2. The text you provided for the CSR is a good start, so I created a Draft CSR,
[JDK-8245873](https://bugs.openjdk.java.net/browse/JDK-8245873), based on what you have. I'll have additional comments
later, but one thing I noticed that needs to be added is that the "Specification" section needs to list the diffs for
the public API docs in FXMLLoader and for the FXML intro.

I also left some inline comments below. I haven't done a code review yet because I want to get the API documentation
and CSR in shape first.

modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html line 723:

> 722: <span class="code">ObservableList</span>, <span class="code">ObservableMap</span> or <span
> class="code">ObservableSet</span> 723:  uses a special <span class="code">onChange</span> attribute that points to a
> handler method with a <span class="code">ListChangeListener.Change</span>, <span
> class="code">MapChangeListener.Change</span> or <span class="code">SetChangeListener.Change</span> parameter
> respectively. 724: </p>

Please revert this change since it is unrelated. Especially in this case where it is public API docs that will be noted
in the CSR, this will seem out of place. I filed JDK-nnnnn to track and accumulate these sort of typos.

modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1924:

> 1923:      */
> 1924:     public static final String COMPILE_PROCESSING_INSTRUCTION = "compile";
> 1925:

You need to add an `@since 15` javadoc tag for this new public field.

modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html line 775:

> 774:
> 775: <p>Note: to turn off automatic compilation of script code place the processing instruction <span
> class="code">&lt;?compile false?&gt;</span> before the script element. To turn on compilation of script code again use
> the processing instruction <span class="code">&lt;?compile true?&gt;</span> (or short: <span
> class="code">&lt;?compile?&gt;</span>). The compile processing instruction can be used repeatedly to turn compilation
> of script code off and on.</p> 776:

I would start by saying that scripts are compiled by default if the script engine implements `javax.script.Compilable`.
Maybe add a sentence something like this:

Scripts are compiled by default, when they are first loaded, if the `ScriptEngine` implements the
`javax.script.Compilable` interface. If compilation fails, the `FXMLLoader` will fall back to interpreted mode.

-------------

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

From kcr at openjdk.java.net  Tue May 26 23:53:25 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 May 2020 23:53:25 GMT
Subject: RFR: 8234876: Unit test classes should not extend Application
In-Reply-To: <K1R8uWLbBcy6Wg6wyh2bOcIMFyCVeSDJijj7Mo8DPjg=.0a6c732d-eaba-4885-ad6c-5bafafe6fd9f@github.com>
References: <K1R8uWLbBcy6Wg6wyh2bOcIMFyCVeSDJijj7Mo8DPjg=.0a6c732d-eaba-4885-ad6c-5bafafe6fd9f@github.com>
Message-ID: <Y-M9Nz10foLXXGu0L0cmktyFKJTE8O19XKC-PwaSRtk=.968fa3d0-0a63-49bd-bc3f-248cc0d8385e@github.com>

On Tue, 26 May 2020 11:12:25 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Copied from JBS:
> As a best practice, unit test classes that are run by Junit should not extend javafx.application.Application.
> JUnit constructs an instance of a test class for each test method that it runs. This will be different from the
> instance of the object that is constructed when Application.launch method is called, and this can lead to unexpected
> behavior. Most of our tests use helper classes or nested (static) sub classes of Application, but the following two
> test classes do not:  tests/system/src/test/java/test/com/sun/javafx/image/impl/ImageRaceTest.java
> tests/system/src/test/java/test/javafx/scene/control/AccordionTitlePaneLeakTest.java
> 
> ----
> Changes in the tests are:
> ImageRaceTest.java->  Does not require a sub class of Application.
> AccordionTitlePaneLeakTest.java->  Required minor changes to create a static sub class.

Marked as reviewed by kcr (Lead).

-------------

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

From kcr at openjdk.java.net  Wed May 27 00:01:10 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 27 May 2020 00:01:10 GMT
Subject: RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails
 intermittently
In-Reply-To: <o5zSKMRDX63o9Z06L5RHir_zlnqkEHDerMrPzAVZdhw=.1329037f-c406-48fc-a3e2-248b603868c5@github.com>
References: <o5zSKMRDX63o9Z06L5RHir_zlnqkEHDerMrPzAVZdhw=.1329037f-c406-48fc-a3e2-248b603868c5@github.com>
Message-ID: <bnCqhypBjuaY7PCbs7bCEdpFVBwXj0-MDdWzIWSBLhw=.d115661d-9f80-44f9-b941-d463edd30856@github.com>

On Tue, 26 May 2020 09:27:52 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Cause: The test assumes that WebView/WebPage will be GCed right after `System.gc()`
> 
> Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

Marked as reviewed by kcr (Lead).

-------------

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

From arapte at openjdk.java.net  Wed May 27 01:31:26 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 27 May 2020 01:31:26 GMT
Subject: [Integrated] RFR: 8234876: Unit test classes should not extend
 Application
In-Reply-To: <K1R8uWLbBcy6Wg6wyh2bOcIMFyCVeSDJijj7Mo8DPjg=.0a6c732d-eaba-4885-ad6c-5bafafe6fd9f@github.com>
References: <K1R8uWLbBcy6Wg6wyh2bOcIMFyCVeSDJijj7Mo8DPjg=.0a6c732d-eaba-4885-ad6c-5bafafe6fd9f@github.com>
Message-ID: <gmdVJp3MkGEGWKR0Z2NJlvqC4p9apBrBukZaQ6luJb8=.0ecc5529-1999-4480-a6fa-ace672e9b4f0@github.com>

On Tue, 26 May 2020 11:12:25 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Copied from JBS:
> As a best practice, unit test classes that are run by Junit should not extend javafx.application.Application.
> JUnit constructs an instance of a test class for each test method that it runs. This will be different from the
> instance of the object that is constructed when Application.launch method is called, and this can lead to unexpected
> behavior. Most of our tests use helper classes or nested (static) sub classes of Application, but the following two
> test classes do not:  tests/system/src/test/java/test/com/sun/javafx/image/impl/ImageRaceTest.java
> tests/system/src/test/java/test/javafx/scene/control/AccordionTitlePaneLeakTest.java
> 
> ----
> Changes in the tests are:
> ImageRaceTest.java->  Does not require a sub class of Application.
> AccordionTitlePaneLeakTest.java->  Required minor changes to create a static sub class.

This pull request has now been integrated.

Changeset: 16f446a0
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/16f446a0
Stats:     51 lines in 2 files changed: 25 ins; 4 del; 22 mod

8234876: Unit test classes should not extend Application

Reviewed-by: kcr

-------------

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

From aghaisas at openjdk.java.net  Wed May 27 05:22:40 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 27 May 2020 05:22:40 GMT
Subject: [Rev 01] RFR: 8245499: Text input controls should show handles on
 iOS
In-Reply-To: <qhIHiwl1eIRVT47yDLNTIJwSsht9PZhcc3nbKxbuOG8=.d0868bd4-3391-4b56-851d-07f50613ac76@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
 <qhIHiwl1eIRVT47yDLNTIJwSsht9PZhcc3nbKxbuOG8=.d0868bd4-3391-4b56-851d-07f50613ac76@github.com>
Message-ID: <MamhqsL8xJSg4d1SU1MdZBWYk7-LCM4ZOZffxOo-Bu4=.eb1d9e69-6271-4e17-9b44-aa038f02fc0b@github.com>

On Tue, 26 May 2020 17:33:20 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
>> device. However, selection handles are not enabled and currently text selection is not possible at all.
>> This PR enables handles on iOS as in the rest of the platforms with touch support.
>> 
>> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
>> are a little bit bigger, and there is no caret handle.
>> I've tested it on iPhone, running a small
>> [HelloFX](https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX) sample, with a TextField control.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new line at the end of the file

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From ajoseph at openjdk.java.net  Wed May 27 06:19:56 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Wed, 27 May 2020 06:19:56 GMT
Subject: [Integrated] RFR: 8234540: javafx.web
 LeakTest.testGarbageCollectability fails intermittently
In-Reply-To: <o5zSKMRDX63o9Z06L5RHir_zlnqkEHDerMrPzAVZdhw=.1329037f-c406-48fc-a3e2-248b603868c5@github.com>
References: <o5zSKMRDX63o9Z06L5RHir_zlnqkEHDerMrPzAVZdhw=.1329037f-c406-48fc-a3e2-248b603868c5@github.com>
Message-ID: <SZVy6Fd-CVurDADLow3ZCiBXeAFtxNTtjEXtr_kX_Y8=.9a11a2a6-103b-4f34-95cb-b42809eb42ee@github.com>

On Tue, 26 May 2020 09:27:52 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Cause: The test assumes that WebView/WebPage will be GCed right after `System.gc()`
> 
> Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

This pull request has now been integrated.

Changeset: 8914bd2a
Author:    Arun Joseph <ajoseph at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/8914bd2a
Stats:     33 lines in 1 file changed: 15 ins; 7 del; 11 mod

8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

Reviewed-by: kcr

-------------

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

From aghaisas at openjdk.java.net  Wed May 27 06:57:07 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 27 May 2020 06:57:07 GMT
Subject: RFR: 8245634: [TestBug] Enable and fix tests ignored with message
 "impl_cssSet API removed"
Message-ID: <hOkH8tsaam7-TNvEvBVifen21Kn_AetQz7Iy9Rou3YE=.3d2d13d3-d7df-417f-88a0-e83de5ffd166@github.com>

This is a simple test fix.

Issue : https://bugs.openjdk.java.net/browse/JDK-8245634

After fixing [JDK-8245457,](https://bugs.openjdk.java.net/browse/JDK-8245457) I found that there are more ignored tests
of similar nature that can be enabled and fixed. A search for ignored tests with message "impl_cssSet API removed" -
revealed a total 6 occurrences in 4 files - 1) CellTest
2) CheckBoxTest
3) ChoiceBoxTest
4) DateCellTest

This PR enables and fixes these tests.

-------------

Commit messages:
 - enable ignored unit tests

Changes: https://git.openjdk.java.net/jfx/pull/239/files
 Webrev: https://webrevs.openjdk.java.net/jfx/239/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245634
  Stats: 65 lines in 4 files changed: 48 ins; 7 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/239.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/239/head:pull/239

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

From rlichten at openjdk.java.net  Wed May 27 07:43:56 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 27 May 2020 07:43:56 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
 <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
 <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>
Message-ID: <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com>

On Mon, 11 May 2020 04:54:31 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> @effad I just closed PR #73 due to inactivity. If you are interested interested in pursuing this, go ahead and reopen
>> this (although you would need to address the feedback that clamping is insufficient).
>
> We're in the process of finishing our products' release. If I find time
> I will try and give this (rather nasty) Problem another shot.
> 
> On 2020-05-08 20:51, Kevin Rushforth wrote:
>>
>> @effad <https://github.com/effad> I just closed PR #73
>> <https://github.com/openjdk/jfx/pull/73> due to inactivity. If you are
>> interested interested in pursuing this, go ahead and reopen this
>> (although you would need to address the feedback that clamping is
>> insufficient).
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/openjdk/jfx/pull/138#issuecomment-625963496>, or
>> unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ABCKAQ6JRLHJSGPI3U2YTNLRQRIB7ANCNFSM4LCNBSIA>.
>>

Reopening the pull request, since PR #73 has been closed.

-------------

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

From rlichten at openjdk.java.net  Wed May 27 07:43:55 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 27 May 2020 07:43:55 GMT
Subject: [Rev 01] RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
Message-ID: <tTXeVtWli-xsWqp9yAfC318G7lQKLJQUkS9MCyAi1cA=.f189c11a-b9b6-4e22-9cfe-de614e27bfac@github.com>

> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text.

Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision:

  8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException
  
  This fix will prevent the StringOutOfBoundsException by clearing the selection temporarily.

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/138/files
  - new: https://git.openjdk.java.net/jfx/pull/138/files/e78e8793..f5209e05

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/138/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.00-01

  Stats: 46 lines in 3 files changed: 40 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138

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

From jvos at openjdk.java.net  Wed May 27 07:47:14 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 27 May 2020 07:47:14 GMT
Subject: [Rev 01] RFR: 8245499: Text input controls should show handles on
 iOS
In-Reply-To: <qhIHiwl1eIRVT47yDLNTIJwSsht9PZhcc3nbKxbuOG8=.d0868bd4-3391-4b56-851d-07f50613ac76@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
 <qhIHiwl1eIRVT47yDLNTIJwSsht9PZhcc3nbKxbuOG8=.d0868bd4-3391-4b56-851d-07f50613ac76@github.com>
Message-ID: <ozy65kzBOlcePPdV6IyeAlFRzGPiTY3JVEXwB5CZrkE=.a7d528df-7a60-4d3b-9eda-60153116c9c2@github.com>

On Tue, 26 May 2020 17:33:20 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
>> device. However, selection handles are not enabled and currently text selection is not possible at all.
>> This PR enables handles on iOS as in the rest of the platforms with touch support.
>> 
>> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
>> are a little bit bigger, and there is no caret handle.
>> I've tested it on iPhone, running a small
>> [HelloFX](https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX) sample, with a TextField control.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new line at the end of the file

Marked as reviewed by jvos (Reviewer).

-------------

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

From falcon.sheep at gmail.com  Wed May 27 07:50:12 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Wed, 27 May 2020 11:50:12 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
Message-ID: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>

Hi,

i have started testing my app using Javafx on MacOS 10.15.3 and arabic
letters are not displayed correctly. only title bar is correct. the
rest are just random characters (not arabic). please have a look at
the snapshot:
https://ibb.co/Yk6m3Pj

im using jfx 15-ea-5 on MacOS 10.15.3

normal swing application is working fine without issues

From rlichten at openjdk.java.net  Wed May 27 07:52:13 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 27 May 2020 07:52:13 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
 <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
 <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>
 <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com>
Message-ID: <pVwNpVFmEB4qEVKKwQbvuQVegaUdTN6CkuccLkZnHnk=.da8c0f96-ce56-40cc-a72c-5809a5e4462b@github.com>

On Wed, 27 May 2020 07:37:13 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> We're in the process of finishing our products' release. If I find time
>> I will try and give this (rather nasty) Problem another shot.
>> 
>> On 2020-05-08 20:51, Kevin Rushforth wrote:
>>>
>>> @effad <https://github.com/effad> I just closed PR #73
>>> <https://github.com/openjdk/jfx/pull/73> due to inactivity. If you are
>>> interested interested in pursuing this, go ahead and reopen this
>>> (although you would need to address the feedback that clamping is
>>> insufficient).
>>>
>>> ?
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/openjdk/jfx/pull/138#issuecomment-625963496>, or
>>> unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/ABCKAQ6JRLHJSGPI3U2YTNLRQRIB7ANCNFSM4LCNBSIA>.
>>>
>
> Reopening the pull request, since PR #73 has been closed.

Clearing the selection temporarily works fine to prevent the StringOutOfBoundsException but will also change
selectionProperty to reflect the selection being 0/0 for a short time.

-------------

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

From jpereda at openjdk.java.net  Wed May 27 09:35:29 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Wed, 27 May 2020 09:35:29 GMT
Subject: [Integrated] RFR: 8245499: Text input controls should show
 handles on iOS
In-Reply-To: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
References: <Tjb35_bJcrA8uXm4v7BmCuT_pfaxFST7f7YaXjbiOQg=.741ad97b-8d65-488c-8407-aa613eba231e@github.com>
Message-ID: <V9SrdJ_hNCjUVvz8zZRE18GIfOrJeqM25j6V0Ut_MXw=.6b4299b2-789d-4b61-b2be-59a847d9f759@github.com>

On Thu, 21 May 2020 17:41:02 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> After JDK-8242167, a JavaFX control is used for text input on iOS instead of the native control, on a touch enabled
> device. However, selection handles are not enabled and currently text selection is not possible at all.
> This PR enables handles on iOS as in the rest of the platforms with touch support.
> 
> It also tries to accommodate its style to the native style for handles, where selection handles have a circle shape and
> are a little bit bigger, and there is no caret handle.
> I've tested it on iPhone, running a small
> [HelloFX](https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX) sample, with a TextField control.

This pull request has now been integrated.

Changeset: 3ceee699
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/3ceee699
Stats:     35 lines in 4 files changed: 2 ins; 18 del; 15 mod

8245499: Text input controls should show handles on iOS

Reviewed-by: aghaisas, jvos

-------------

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

From rlichten at openjdk.java.net  Wed May 27 10:20:57 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 27 May 2020 10:20:57 GMT
Subject: [Rev 02] RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
Message-ID: <Cf2-y3eBintKMyyWPOvV8s60lRhVVHH6CifK-lNcltg=.3be68332-fc78-4446-afc5-b8ad41f089f9@github.com>

> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text.

Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision:

  8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException
  
  This fix will execute the selection change before the insertion of new text.
  Only if adjustmentAmount is not 0 a second selection change will be made.

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/138/files
  - new: https://git.openjdk.java.net/jfx/pull/138/files/f5209e05..54eacb41

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/138/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.01-02

  Stats: 20 lines in 3 files changed: 10 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jfx/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138

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

From fastegal at openjdk.java.net  Wed May 27 10:20:58 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 27 May 2020 10:20:58 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <pVwNpVFmEB4qEVKKwQbvuQVegaUdTN6CkuccLkZnHnk=.da8c0f96-ce56-40cc-a72c-5809a5e4462b@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
 <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
 <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>
 <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com>
 <pVwNpVFmEB4qEVKKwQbvuQVegaUdTN6CkuccLkZnHnk=.da8c0f96-ce56-40cc-a72c-5809a5e4462b@github.com>
Message-ID: <cLHAdw9DmioPMPC8_IUFQDUOgLGglja17ZHpo5B_WC0=.c5550d1d-8f55-44df-993a-301f90d804dd@github.com>

On Wed, 27 May 2020 07:50:00 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Reopening the pull request, since PR #73 has been closed.
>
> Clearing the selection temporarily works fine to prevent the StringOutOfBoundsException but will also change
> selectionProperty to reflect the selection being 0/0 for a short time.

you are hacking around ;)

doSelect _must not_ be called somewhere "in-between" changing the text: the api doc clearly states that the
caret/anchor coordinates are the _new_ coordinates, that is after all changes have been applied. When re-calculating
them on-the-fly might have unexpected side-effects, f.i. if a TextFormatter had something special in mind (no failing
test handy though).

-------------

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

From fastegal at openjdk.java.net  Wed May 27 10:26:25 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 27 May 2020 10:26:25 GMT
Subject: [Rev 01] RFR: 8245282: Button/Combo Behavior: memory leak on
 dispose
In-Reply-To: <eJ0Oi1aFh_7v38NGYfBYzrzm-OhJNK_uhN4PBnBHTzI=.4f745c55-3a19-45db-801d-f0769c98abb8@github.com>
References: <eJ0Oi1aFh_7v38NGYfBYzrzm-OhJNK_uhN4PBnBHTzI=.4f745c55-3a19-45db-801d-f0769c98abb8@github.com>
Message-ID: <ZRZZ83PQxxT_rWxNOTWzIKenM0I4ysa-_AG-JEl5Jos=.5dadfd50-d13a-4e37-8537-c0575282021c@github.com>

> Reason for the memory leak is a listener on control's focusProperty that is not correctly removed on dispose. For
> details please see the report.
> Added a test method to ButtonSkinTest that failed before and passes after the fix.

Jeanette Winzenburg has updated the pull request with a new target base due to a merge or a rebase. The pull request
now contains one commit:

  8245282: Button/Combo Behavior: memory leak on dispose

-------------

Changes: https://git.openjdk.java.net/jfx/pull/226/files
 Webrev: https://webrevs.openjdk.java.net/jfx/226/webrev.01
  Stats: 45 lines in 3 files changed: 8 ins; 33 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/226.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/226/head:pull/226

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

From rlichten at openjdk.java.net  Wed May 27 12:14:06 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 27 May 2020 12:14:06 GMT
Subject: RFR: WIP: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <cLHAdw9DmioPMPC8_IUFQDUOgLGglja17ZHpo5B_WC0=.c5550d1d-8f55-44df-993a-301f90d804dd@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
 <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
 <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>
 <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com>
 <pVwNpVFmEB4qEVKKwQbvuQVegaUdTN6CkuccLkZnHnk=.da8c0f96-ce56-40cc-a72c-5809a5e4462b@github.com>
 <cLHAdw9DmioPMPC8_IUFQDUOgLGglja17ZHpo5B_WC0=.c5550d1d-8f55-44df-993a-301f90d804dd@github.com>
Message-ID: <KaDj7IibI5Ud7YHq0g2y7H6BgUMz-1uEZexcwGmzFYU=.5d3f2ca5-7af9-4674-8f7d-8d613df0d18e@github.com>

On Wed, 27 May 2020 10:09:52 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Clearing the selection temporarily works fine to prevent the StringOutOfBoundsException but will also change
>> selectionProperty to reflect the selection being 0/0 for a short time.
>
> you are hacking around ;)
> 
> doSelect _must not_ be called somewhere "in-between" changing the text: the api doc clearly states that the
> caret/anchor coordinates are the _new_ coordinates, that is after all changes have been applied. When re-calculating
> them on-the-fly might have unexpected side-effects, f.i. if a TextFormatter had something special in mind (no failing
> test handy though).

Most of the time, value in javafx.scene.control.TextInputControl.replaceText(int, int, String, int, int) will already
be filtered (e.g. linebreaks in TextField) In that case, adjustmentAmount will be zero and one could just do the
selection before actually inserting the text.

But a case can be constructed with a TextFormatter that will produce characters that will be filtered by the TextField
itself:
    
    @Test public void replaceSelectionWithFilteredCharacters() {
        txtField.setText("x xxxyyy");
        txtField.selectRange(2, 5);
        txtField.setTextFormatter(new TextFormatter<>(this::noDigits));
        txtField.replaceSelection("a1234a");
        assertEquals("x aayyy", txtField.getText());
        assertEquals(4, txtField.getSelection().getStart());
        assertEquals(4, txtField.getSelection().getStart());
    }

    private Change noDigits(Change change) {
        Change filtered = change.clone();
        filtered.setText(change.getText().replaceAll("[0-9]","\n"));
        return filtered;
    }

-------------

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

From rlichten at openjdk.java.net  Wed May 27 13:33:35 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 27 May 2020 13:33:35 GMT
Subject: [Rev 03] RFR: WIP: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
Message-ID: <V4BhDxlyKcFuaEHdJuu8j66xy7SEXCqSGVB41mSYPsI=.48db7a04-6c14-4190-86e5-219c84d6c2e4@github.com>

> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text.

Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision:

  8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException
  
  This fix changes the selectedText property from a direct binding to a property
  that can be updated manually after text AND selection change have been processed.

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/138/files
  - new: https://git.openjdk.java.net/jfx/pull/138/files/54eacb41..6f10355d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/138/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.02-03

  Stats: 70 lines in 2 files changed: 42 ins; 15 del; 13 mod
  Patch: https://git.openjdk.java.net/jfx/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138

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

From philip.race at oracle.com  Wed May 27 15:53:17 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 27 May 2020 08:53:17 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
Message-ID: <5ECE8CED.8060106@oracle.com>

Is Latin displaying correctly for you ?
I can't see anything at all in that screen shot that looks likely to be 
correct,
but I also don't know if it is supposed to be entirely Arabic or a 
mixture of scripts,
although clearly it is all laid out RTL.

In an arm-wavy sort of way, it looks like there's a mismatch between
the selected font and the glyph ids.  whether its the font that's wrong
or the id is impossible to say ..

-phil.

On 5/27/20, 12:50 AM, Abu Abdullah wrote:
> Hi,
>
> i have started testing my app using Javafx on MacOS 10.15.3 and arabic
> letters are not displayed correctly. only title bar is correct. the
> rest are just random characters (not arabic). please have a look at
> the snapshot:
> https://ibb.co/Yk6m3Pj
>
> im using jfx 15-ea-5 on MacOS 10.15.3
>
> normal swing application is working fine without issues

From falcon.sheep at gmail.com  Wed May 27 16:00:51 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Wed, 27 May 2020 20:00:51 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <5ECE8CED.8060106@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
Message-ID: <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>

On Wed, May 27, 2020 at 7:53 PM Philip Race <philip.race at oracle.com> wrote:
>
> Is Latin displaying correctly for you ?
yes, the GUI contains just few words in English which seems to be OK

> I can't see anything at all in that screen shot that looks likely to be
> correct,
> but I also don't know if it is supposed to be entirely Arabic or a
> mixture of scripts,
> although clearly it is all laid out RTL.
entirely in Arabic. please find snap shot on how it should be (taken in Windows)
https://ibb.co/bv74qnK

> In an arm-wavy sort of way, it looks like there's a mismatch between
> the selected font and the glyph ids.  whether its the font that's wrong
> or the id is impossible to say ..

I tried that as well. nothing changes if i changed the font using the tinkertool

From philip.race at oracle.com  Wed May 27 18:32:45 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 27 May 2020 11:32:45 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
Message-ID: <5ECEB24D.4000901@oracle.com>

 >  I tried that as well. nothing changes if i changed the font using 
the tinkertool

Not sure what you did but it is probably more complex than that.
Arabic is likely supported by one of the cascading fallback fonts macOS 
reports,
although it could be via a primary if locale is Arabic.

-phil.

On 5/27/20, 9:00 AM, Abu Abdullah wrote:
> On Wed, May 27, 2020 at 7:53 PM Philip Race<philip.race at oracle.com>  wrote:
>> Is Latin displaying correctly for you ?
> yes, the GUI contains just few words in English which seems to be OK
>
>> I can't see anything at all in that screen shot that looks likely to be
>> correct,
>> but I also don't know if it is supposed to be entirely Arabic or a
>> mixture of scripts,
>> although clearly it is all laid out RTL.
> entirely in Arabic. please find snap shot on how it should be (taken in Windows)
> https://ibb.co/bv74qnK
>
>> In an arm-wavy sort of way, it looks like there's a mismatch between
>> the selected font and the glyph ids.  whether its the font that's wrong
>> or the id is impossible to say ..
> I tried that as well. nothing changes if i changed the font using the tinkertool

From rlichten at openjdk.java.net  Thu May 28 06:53:08 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Thu, 28 May 2020 06:53:08 GMT
Subject: RFR: 8176270: Adding ChangeListener to
 TextField.selectedTextProperty causes StringOutOfBoundsException
In-Reply-To: <KaDj7IibI5Ud7YHq0g2y7H6BgUMz-1uEZexcwGmzFYU=.5d3f2ca5-7af9-4674-8f7d-8d613df0d18e@github.com>
References: <W8KJF19Vxq6EGhTW4W3jn0TDdb5Uhlsn_4GfrtY8bhw=.e15093d7-8fbd-4004-b427-4d77b24e86a9@github.com>
 <gnAVq73SvUaDXpDiutIVBvxlLI9LY7dG7eytFV5Sd4k=.d1f7c94b-93b0-4919-ad3e-9f4109affab8@github.com>
 <UTYedFKGrOhLd2MqcVifVxOoRPcblPfvYRgoBm3XQdo=.4288d66d-91ca-4092-ae2d-a66fdbcc29c2@github.com>
 <NM9sJ5ObLlX1Lxgl_Ja-dMwMLXrYPSjzQ_O7gTH7IUA=.d485fa20-a4ac-4af5-b01e-c68777fccd45@github.com>
 <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com>
 <DpMLL2CvyrTrww6Jc8xv7H7aQYuKpGPUr-SU3aFOktg=.29b591c4-9a58-4c59-9674-1f74d2f70c62@github.com>
 <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com>
 <pVwNpVFmEB4qEVKKwQbvuQVegaUdTN6CkuccLkZnHnk=.da8c0f96-ce56-40cc-a72c-5809a5e4462b@github.com>
 <cLHAdw9DmioPMPC8_IUFQDUOgLGglja17ZHpo5B_WC0=.c5550d1d-8f55-44df-993a-301f90d804dd@github.com>
 <KaDj7IibI5Ud7YHq0g2y7H6BgUMz-1uEZexcwGmzFYU=.5d3f2ca5-7af9-4674-8f7d-8d613df0d18e@github.com>
Message-ID: <6WhyH_3NIHMKxVw-xsTv6jAsSb2njDPkaaNVz64y60E=.352fb913-33e4-40ee-a28b-9da54e7095c8@github.com>

On Wed, 27 May 2020 12:11:48 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> you are hacking around ;)
>> 
>> doSelect _must not_ be called somewhere "in-between" changing the text: the api doc clearly states that the
>> caret/anchor coordinates are the _new_ coordinates, that is after all changes have been applied. When re-calculating
>> them on-the-fly might have unexpected side-effects, f.i. if a TextFormatter had something special in mind (no failing
>> test handy though).
>
> Most of the time, value in javafx.scene.control.TextInputControl.replaceText(int, int, String, int, int) will already
> be filtered (e.g. linebreaks in TextField) In that case, adjustmentAmount will be zero and one could just do the
> selection before actually inserting the text.
> But a case can be constructed with a TextFormatter that will produce characters that will be filtered by the TextField
> itself:
>     
>     @Test public void replaceSelectionWithFilteredCharacters() {
>         txtField.setText("x xxxyyy");
>         txtField.selectRange(2, 5);
>         txtField.setTextFormatter(new TextFormatter<>(this::noDigits));
>         txtField.replaceSelection("a1234a");
>         assertEquals("x aayyy", txtField.getText());
>         assertEquals(4, txtField.getSelection().getStart());
>         assertEquals(4, txtField.getSelection().getStart());
>     }
> 
>     private Change noDigits(Change change) {
>         Change filtered = change.clone();
>         filtered.setText(change.getText().replaceAll("[0-9]","\n"));
>         return filtered;
>     }

The last commit on this branch seems like the "best" way to fix this problem. It prevents in-between changes in
selectedText and does not introduce (to the best of my knowledge) any new corner cases. It eliminiates the "root cause"
of the problem by postponing selectedText update to the end of whole replace-operation. So, this is RFR now (I hope).

-------------

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

From ajoseph at openjdk.java.net  Thu May 28 08:52:12 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Thu, 28 May 2020 08:52:12 GMT
Subject: RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently
Message-ID: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>

Issue: Snapshot taken before webpage is rendered

Fix: Use stateProperty and sleep to wait for the page to finish rendering

-------------

Commit messages:
 - Add sleep
 - 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

Changes: https://git.openjdk.java.net/jfx/pull/240/files
 Webrev: https://webrevs.openjdk.java.net/jfx/240/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243110
  Stats: 18 lines in 1 file changed: 15 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/240.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/240/head:pull/240

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

From kcr at openjdk.java.net  Thu May 28 14:46:37 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 May 2020 14:46:37 GMT
Subject: RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails
 intermittently
In-Reply-To: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
References: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
Message-ID: <6hyq0xJ2cJ1AMqrzlxYRumpdP1XJIo3JMc72DCneuuU=.d3196ace-bda9-4fed-a434-2894dcbba1a1@github.com>

On Thu, 28 May 2020 08:45:36 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Issue: Snapshot taken before webpage is rendered
> 
> Fix: Use stateProperty and sleep to wait for the page to finish rendering

I tested it on my machine and it is running reliably for me now. I have a couple suggestions below.

tests/system/src/test/java/test/javafx/scene/web/SVGTest.java line 116:

> 115:         Util.runAndWait(() -> {
> 116:             webView.getEngine().getLoadWorker().stateProperty().
> 117:                 addListener((observable, oldValue, newValue) -> {

This should go after the `assertNotNull`

tests/system/src/test/java/test/javafx/scene/web/SVGTest.java line 126:

> 125:
> 126:             webView.focusedProperty().
> 127:                 addListener((observable, oldValue, newValue) -> {

The listener should probably be installed before the content is loaded.

-------------

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

From nlisker at openjdk.java.net  Thu May 28 15:18:13 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 28 May 2020 15:18:13 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
Message-ID: <oochr8gpN03mFz3bq6sigNkdwhoclCOfNcw8zft14qM=.4083de05-897c-48c1-80b1-109a746c1468@github.com>

On Tue, 26 May 2020 21:12:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 332:
> 
>> 331:                     }
>> 332:                     if (isNearZero(newRate)) {
>> 333:                         if (isRunning()) {
> 
> The code from here to the end of the method used to be in an `else` block of the `if (isRunningEmbedded())` test. It
> will now be run even if that test is true. Was this intended, and if so, why?

If the test for `isRunningEmbedded()` passes, the method will throw an exception.

-------------

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

From nlisker at openjdk.java.net  Thu May 28 15:26:04 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 28 May 2020 15:26:04 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
Message-ID: <yhw_vqoJI-2Hp6wx0edGLCrkrm_CUdPnEXl0qWZKQLc=.aa6ef70f-55a3-4883-a989-18509aee6379@github.com>

On Tue, 26 May 2020 21:53:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 402:
> 
>> 401:      */
>> 402:     private void doSetCurrentRate(double value) {
>> 403:         if (currentRate != null || !areNearEqual(value, DEFAULT_CURRENT_RATE)) {
> 
> The above javadoc comment block appears after the javadoc comments for the private `currentRate` property variable and
> before the public get/property methods for `currentRate`. This seems fragile (although the API docs pick up the right
> one), so I recommend making this an ordinary block comment (i.e., `/*` rather than `/**`). Either that or move it below
> the get/property methods (and add `@param value`).

Doesn't the autogenerated JavaDoc for the `getX`, `setX` and `xProperty` methods work by matching the method name to
the property name regardless of they location in the class? `doSetCurrentRate` shouldn't ever be able to interfere with
that. I can add a `@param` anyway.

-------------

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

From kcr at openjdk.java.net  Thu May 28 15:37:33 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 May 2020 15:37:33 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <oochr8gpN03mFz3bq6sigNkdwhoclCOfNcw8zft14qM=.4083de05-897c-48c1-80b1-109a746c1468@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
 <oochr8gpN03mFz3bq6sigNkdwhoclCOfNcw8zft14qM=.4083de05-897c-48c1-80b1-109a746c1468@github.com>
Message-ID: <IaZxxjoMj0XQhX4Btkf_5nGc6TwDBi_YWkr2_eMiH8g=.d7dfd4d1-1d1d-49e1-94e6-33c6ba533e04@github.com>

On Thu, 28 May 2020 15:16:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 332:
>> 
>>> 331:                     }
>>> 332:                     if (isNearZero(newRate)) {
>>> 333:                         if (isRunning()) {
>> 
>> The code from here to the end of the method used to be in an `else` block of the `if (isRunningEmbedded())` test. It
>> will now be run even if that test is true. Was this intended, and if so, why?
>
> If the test for `isRunningEmbedded()` passes, the method will throw an exception.

Ah, of course.

-------------

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

From kcr at openjdk.java.net  Thu May 28 15:53:37 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 May 2020 15:53:37 GMT
Subject: RFR: 8242523: Update the animation and clip envelope classes
In-Reply-To: <yhw_vqoJI-2Hp6wx0edGLCrkrm_CUdPnEXl0qWZKQLc=.aa6ef70f-55a3-4883-a989-18509aee6379@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
 <yhw_vqoJI-2Hp6wx0edGLCrkrm_CUdPnEXl0qWZKQLc=.aa6ef70f-55a3-4883-a989-18509aee6379@github.com>
Message-ID: <JPoZNYmBLupZnZh85AoKhfIvlFQZWPHhAOFHOVGNeuE=.f207d81d-6484-415f-9113-a66a41b61565@github.com>

On Thu, 28 May 2020 15:23:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 402:
>> 
>>> 401:      */
>>> 402:     private void doSetCurrentRate(double value) {
>>> 403:         if (currentRate != null || !areNearEqual(value, DEFAULT_CURRENT_RATE)) {
>> 
>> The above javadoc comment block appears after the javadoc comments for the private `currentRate` property variable and
>> before the public get/property methods for `currentRate`. This seems fragile (although the API docs pick up the right
>> one), so I recommend making this an ordinary block comment (i.e., `/*` rather than `/**`). Either that or move it below
>> the get/property methods (and add `@param value`).
>
> Doesn't the autogenerated JavaDoc for the `getX`, `setX` and `xProperty` methods work by matching the method name to
> the property name regardless of they location in the class? `doSetCurrentRate` shouldn't ever be able to interfere with
> that. I can add a `@param` anyway.

So it would seem. It still seems a bit fragile, but as long as it works, I won't push the point (we are very
inconsistent on this).

-------------

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

From nlisker at openjdk.java.net  Thu May 28 16:44:33 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 28 May 2020 16:44:33 GMT
Subject: [Rev 01] RFR: 8242523: Update the animation and clip envelope
 classes
In-Reply-To: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
Message-ID: <cEgYgt-beIl09izfUuzj96Y2DAr9D87hZo_DTLoadIw=.b482b095-2ee5-42ff-831f-99bf9ab922a6@github.com>

> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
> of methods. Summery of changes:
> ### Animation
> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
> * Added `runHandler` method to deal with running the handler.
> * Moved methods to be grouped closer to where they are used rather than by visibility.
> * Removed the static import for `TickCalculation`.
> * Various small subjective readability changes.
> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>   initializing the `cuePoints` map.
> 
> ### Clip Envelopes
> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
> * Rearranged methods order to be consistent.
> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
> * Renamed `pos` to `cyclePos`.
> * Extracted common methods: `changedDirection` and `ticksRateChange`
> * Added internal documentation.
> 
> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.

Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 10 commits:

 - Merge branch 'master' into 8242523_Update_the_Animation_and_ClipEnvelope_classes
 - Synch whitespace fix
 - Addressed review comments
 - Removing cycleNumber for now
 - Fix typo in TicksCalculation & add an explanation for an animation test
 - Initial push of 8242523
 - Comment out erroneous test
 - Fix IndefiniteCycleDuration test
 - Fixed single loop test
 - Initial commit

-------------

Changes: https://git.openjdk.java.net/jfx/pull/196/files
 Webrev: https://webrevs.openjdk.java.net/jfx/196/webrev.01
  Stats: 660 lines in 9 files changed: 344 ins; 180 del; 136 mod
  Patch: https://git.openjdk.java.net/jfx/pull/196.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/196/head:pull/196

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

From nlisker at openjdk.java.net  Thu May 28 16:44:42 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 28 May 2020 16:44:42 GMT
Subject: [Rev 01] RFR: 8242523: Update the animation and clip envelope
 classes
In-Reply-To: <JPoZNYmBLupZnZh85AoKhfIvlFQZWPHhAOFHOVGNeuE=.f207d81d-6484-415f-9113-a66a41b61565@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <mpLaAHAVA3Af-GwjfE2xJcmwMzN6QpjRMADRWR9WWi0=.0ae68f1d-1149-4df2-922f-8d4eb0f002a5@github.com>
 <yhw_vqoJI-2Hp6wx0edGLCrkrm_CUdPnEXl0qWZKQLc=.aa6ef70f-55a3-4883-a989-18509aee6379@github.com>
 <JPoZNYmBLupZnZh85AoKhfIvlFQZWPHhAOFHOVGNeuE=.f207d81d-6484-415f-9113-a66a41b61565@github.com>
Message-ID: <yQJu0iM6yD_kyO7LcAGX-4F4rqy2tBRGh7NMo2Kv7sI=.2ce8d071-e8dc-40ef-85d4-3b2527645b73@github.com>

On Thu, 28 May 2020 15:51:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Doesn't the autogenerated JavaDoc for the `getX`, `setX` and `xProperty` methods work by matching the method name to
>> the property name regardless of they location in the class? `doSetCurrentRate` shouldn't ever be able to interfere with
>> that. I can add a `@param` anyway.
>
> So it would seem. It still seems a bit fragile, but as long as it works, I won't push the point (we are very
> inconsistent on this).

I moved the method down anyway so it will be separated from the public API.

-------------

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

From kcr at openjdk.java.net  Thu May 28 17:05:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 May 2020 17:05:16 GMT
Subject: [Rev 01] RFR: 8242523: Update the animation and clip envelope
 classes
In-Reply-To: <cEgYgt-beIl09izfUuzj96Y2DAr9D87hZo_DTLoadIw=.b482b095-2ee5-42ff-831f-99bf9ab922a6@github.com>
References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com>
 <cEgYgt-beIl09izfUuzj96Y2DAr9D87hZo_DTLoadIw=.b482b095-2ee5-42ff-831f-99bf9ab922a6@github.com>
Message-ID: <GFVrCoYcL127j7WxAK0P9f-kfuvF9g7fP7Bc5iHN4Ew=.1486b633-bab7-46af-8982-539f6b1ebffa@github.com>

On Thu, 28 May 2020 16:44:33 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test.
>
> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains 10 commits:
>  - Merge branch 'master' into 8242523_Update_the_Animation_and_ClipEnvelope_classes
>  - Synch whitespace fix
>  - Addressed review comments
>  - Removing cycleNumber for now
>  - Fix typo in TicksCalculation & add an explanation for an animation test
>  - Initial push of 8242523
>  - Comment out erroneous test
>  - Fix IndefiniteCycleDuration test
>  - Fixed single loop test
>  - Initial commit

Marked as reviewed by kcr (Lead).

-------------

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

From kcr at openjdk.java.net  Thu May 28 21:09:17 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 May 2020 21:09:17 GMT
Subject: RFR: 8246099: Intermittent test failures in SandboxAppTest
Message-ID: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>

This is a fix for an intermittent test failure, due to a timeout, in `SandboxAppTest` that we are starting to see on
some of our test machines.

The failure is happening because of a 10 second timeout in the launched application. This doesn't seem to be enough to
run the test to completion in all cases. I note that the similar launched apps, such as those launched by
`MainLauncherTest`, `ModuleLauncherTest`, and `JarLauncherTest` don't have a timeout (they just rely on the timeout
value of the launching test itself).

The app timeout was just added to prevent the test suite from hanging if the application were to get stuck, so there is
no need for it to be such a small value (nor to have it be less than the test timeout).

The proposed solution is to increase the app timeout to 30 seconds (up from 10) and the test timeout to 25 (up from 15).

-------------

Commit messages:
 - 8246099: Intermittent test failures in SandboxAppTest

Changes: https://git.openjdk.java.net/jfx/pull/241/files
 Webrev: https://webrevs.openjdk.java.net/jfx/241/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246099
  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/241.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/241/head:pull/241

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

From philip.race at oracle.com  Thu May 28 21:23:15 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 28 May 2020 14:23:15 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
Message-ID: <5ED02BC3.1080007@oracle.com>

Looks like this is not a Catalina problem. It is a regression in openjfx 
14 on macOS.
And it is caused by https://bugs.openjdk.java.net/browse/JDK-8234916

We have filed a new bug : https://bugs.openjdk.java.net/browse/JDK-8246104

-phil.

On 5/27/20, 9:00 AM, Abu Abdullah wrote:
> On Wed, May 27, 2020 at 7:53 PM Philip Race<philip.race at oracle.com>  wrote:
>> Is Latin displaying correctly for you ?
> yes, the GUI contains just few words in English which seems to be OK
>
>> I can't see anything at all in that screen shot that looks likely to be
>> correct,
>> but I also don't know if it is supposed to be entirely Arabic or a
>> mixture of scripts,
>> although clearly it is all laid out RTL.
> entirely in Arabic. please find snap shot on how it should be (taken in Windows)
> https://ibb.co/bv74qnK
>
>> In an arm-wavy sort of way, it looks like there's a mismatch between
>> the selected font and the glyph ids.  whether its the font that's wrong
>> or the id is impossible to say ..
> I tried that as well. nothing changes if i changed the font using the tinkertool

From falcon.sheep at gmail.com  Fri May 29 00:50:52 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Fri, 29 May 2020 04:50:52 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <5ED02BC3.1080007@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
Message-ID: <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>

On Fri, May 29, 2020 at 1:21 AM Philip Race <philip.race at oracle.com> wrote:
>
> Looks like this is not a Catalina problem. It is a regression in openjfx 14 on macOS.
> And it is caused by https://bugs.openjdk.java.net/browse/JDK-8234916

I can see in the console this message:
CoreText note: Client requested name ".ArabicUIText-Regular", it will
get Times-Roman rather than the intended font. All system UI font
access should be through proper APIs such as
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].

> We have filed a new bug : https://bugs.openjdk.java.net/browse/JDK-8246104

Thank you

i can see a comment about the differences between Windows and mac. To
me, the difference is about the font type. in Windows it is Tahoma, in
Mac it seems Times-Roman

From aghaisas at openjdk.java.net  Fri May 29 05:37:21 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 May 2020 05:37:21 GMT
Subject: RFR: 8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin
In-Reply-To: <DzckbpguK2-T4rkhY6R12BQ_zgpkpHs3nxhRxGbkD6Y=.0ffedc7c-58ba-4f7f-913f-24da2a90ec40@github.com>
References: <DzckbpguK2-T4rkhY6R12BQ_zgpkpHs3nxhRxGbkD6Y=.0ffedc7c-58ba-4f7f-913f-24da2a90ec40@github.com>
Message-ID: <EL43uiq-QNT936EYVJRpj7o18_b7IxZih8u3iMG9sz8=.131b9383-2af3-44a0-97d4-47ab4327a9f2@github.com>

On Tue, 26 May 2020 13:41:15 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> Both skins have similar misbehavior when switching skins
> 
> - memory leak due to a manually added but not removed change listener
> - NPE when modifying items after skin switch due to a not removed listener to the control's items
> 
> Fixed in both (for details see the issue). Added SkinCleanupTest for simple testing of per-control side-effects,
> removed both skins from memory test exclusion list: failing before and passing after fix.

Marked as reviewed by aghaisas (Reviewer).

-------------

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

From philip.race at oracle.com  Fri May 29 05:48:17 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 28 May 2020 22:48:17 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
Message-ID: <5ED0A221.2030602@oracle.com>

Ok. you said in the first post :

im using jfx 15-ea-5 on MacOS 10.15.3

Where did you get that build ?

-phil

On 5/28/20, 5:50 PM, Abu Abdullah wrote:
> On Fri, May 29, 2020 at 1:21 AM Philip Race<philip.race at oracle.com>  wrote:
>> Looks like this is not a Catalina problem. It is a regression in openjfx 14 on macOS.
>> And it is caused by https://bugs.openjdk.java.net/browse/JDK-8234916
> I can see in the console this message:
> CoreText note: Client requested name ".ArabicUIText-Regular", it will
> get Times-Roman rather than the intended font. All system UI font
> access should be through proper APIs such as
> CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
>
>> We have filed a new bug : https://bugs.openjdk.java.net/browse/JDK-8246104
> Thank you
>
> i can see a comment about the differences between Windows and mac. To
> me, the difference is about the font type. in Windows it is Tahoma, in
> Mac it seems Times-Roman

From arapte at openjdk.java.net  Fri May 29 05:59:08 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 29 May 2020 05:59:08 GMT
Subject: RFR: 8245634: [TestBug] Enable and fix tests ignored with message
 "impl_cssSet API removed"
In-Reply-To: <hOkH8tsaam7-TNvEvBVifen21Kn_AetQz7Iy9Rou3YE=.3d2d13d3-d7df-417f-88a0-e83de5ffd166@github.com>
References: <hOkH8tsaam7-TNvEvBVifen21Kn_AetQz7Iy9Rou3YE=.3d2d13d3-d7df-417f-88a0-e83de5ffd166@github.com>
Message-ID: <PF9l29oIYD485KMx8jWPvAbBIcSkjMMreDMIeI02_oQ=.d6dc742f-82f1-4193-9e66-937c32745ecf@github.com>

On Wed, 27 May 2020 06:51:41 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This is a simple test fix.
> 
> Issue : https://bugs.openjdk.java.net/browse/JDK-8245634
> 
> After fixing [JDK-8245457,](https://bugs.openjdk.java.net/browse/JDK-8245457) I found that there are more ignored tests
> of similar nature that can be enabled and fixed. A search for ignored tests with message "impl_cssSet API removed" -
> revealed a total 6 occurrences in 4 files - 1) CellTest
> 2) CheckBoxTest
> 3) ChoiceBoxTest
> 4) DateCellTest
> 
> This PR enables and fixes these tests.

looks good to me.

-------------

Marked as reviewed by arapte (Reviewer).

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

From falcon.sheep at gmail.com  Fri May 29 06:09:47 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Fri, 29 May 2020 10:09:47 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <5ED0A221.2030602@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <5ED0A221.2030602@oracle.com>
Message-ID: <CAD678-Ciraedd8Uy5DcPf8Ymwzw5c8+SxY5Y3w=OUXHsugwEmw@mail.gmail.com>

On Fri, May 29, 2020 at 9:46 AM Philip Race <philip.race at oracle.com> wrote:
>
> Ok. you said in the first post :
>
> im using jfx 15-ea-5 on MacOS 10.15.3
>
> Where did you get that build ?

from maven

<dependency>
   <groupId>org.openjfx</groupId>
   <artifactId>javafx-controls</artifactId>
   <version>15-ea+5</version>
   <classifier>mac</classifier>
</dependency>

From aghaisas at openjdk.java.net  Fri May 29 06:16:49 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 May 2020 06:16:49 GMT
Subject: [Integrated] RFR: 8245634: [TestBug] Enable and fix tests ignored
 with message "impl_cssSet API removed"
In-Reply-To: <hOkH8tsaam7-TNvEvBVifen21Kn_AetQz7Iy9Rou3YE=.3d2d13d3-d7df-417f-88a0-e83de5ffd166@github.com>
References: <hOkH8tsaam7-TNvEvBVifen21Kn_AetQz7Iy9Rou3YE=.3d2d13d3-d7df-417f-88a0-e83de5ffd166@github.com>
Message-ID: <S-ISz7ygKSNLbEQ5yLldX1t8zgDG8wGVUxuFkttZpME=.258a0260-3617-4bfc-8b60-710938a48c58@github.com>

On Wed, 27 May 2020 06:51:41 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This is a simple test fix.
> 
> Issue : https://bugs.openjdk.java.net/browse/JDK-8245634
> 
> After fixing [JDK-8245457,](https://bugs.openjdk.java.net/browse/JDK-8245457) I found that there are more ignored tests
> of similar nature that can be enabled and fixed. A search for ignored tests with message "impl_cssSet API removed" -
> revealed a total 6 occurrences in 4 files - 1) CellTest
> 2) CheckBoxTest
> 3) ChoiceBoxTest
> 4) DateCellTest
> 
> This PR enables and fixes these tests.

This pull request has now been integrated.

Changeset: c41777e3
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/c41777e3
Stats:     65 lines in 4 files changed: 7 ins; 48 del; 10 mod

8245634: [TestBug] Enable and fix tests ignored with message "impl_cssSet API removed"

Reviewed-by: arapte

-------------

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

From ajoseph at openjdk.java.net  Fri May 29 07:58:21 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Fri, 29 May 2020 07:58:21 GMT
Subject: [Rev 01] RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails
 intermittently
In-Reply-To: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
References: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
Message-ID: <lWLKPFmhM_xdcMLI8zVrmcBrQDnmu4sr1SV-In-8SA4=.ecd27d52-8720-4647-bc7e-fe5b362f75c6@github.com>

> Issue: Snapshot taken before webpage is rendered
> 
> Fix: Use stateProperty and sleep to wait for the page to finish rendering

Arun Joseph has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/240/files
  - new: https://git.openjdk.java.net/jfx/pull/240/files/211a1f65..4195f0fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/240/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/240/webrev.00-01

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

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

From arapte at openjdk.java.net  Fri May 29 08:15:38 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 29 May 2020 08:15:38 GMT
Subject: RFR: 8246099: Intermittent test failures in SandboxAppTest
In-Reply-To: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>
References: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>
Message-ID: <gH1Qreq_ogzjkZWu0nnMzeTacw73JzwKSUyyVKqMMZ8=.b39d849d-be55-4f2d-99b9-3a8e10ac2c58@github.com>

On Thu, 28 May 2020 21:02:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a fix for an intermittent test failure, due to a timeout, in `SandboxAppTest` that we are starting to see on
> some of our test machines.
> The failure is happening because of a 10 second timeout in the launched application. This doesn't seem to be enough to
> run the test to completion in all cases. I note that the similar launched apps, such as those launched by
> `MainLauncherTest`, `ModuleLauncherTest`, and `JarLauncherTest` don't have a timeout (they just rely on the timeout
> value of the launching test itself).  The app timeout was just added to prevent the test suite from hanging if the
> application were to get stuck, so there is no need for it to be such a small value (nor to have it be less than the
> test timeout).  The proposed solution is to increase the app timeout to 30 seconds (up from 10) and the test timeout to
> 25 (up from 15).

Marked as reviewed by arapte (Reviewer).

-------------

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

From kevin.rushforth at oracle.com  Fri May 29 12:38:39 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 29 May 2020 05:38:39 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
Message-ID: <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>



On 5/28/2020 5:50 PM, Abu Abdullah wrote:
> On Fri, May 29, 2020 at 1:21 AM Philip Race <philip.race at oracle.com> wrote:
>> Looks like this is not a Catalina problem. It is a regression in openjfx 14 on macOS.
>> And it is caused by https://bugs.openjdk.java.net/browse/JDK-8234916
> I can see in the console this message:
> CoreText note: Client requested name ".ArabicUIText-Regular", it will
> get Times-Roman rather than the intended font. All system UI font
> access should be through proper APIs such as
> CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].

What JDK are you running? This looks like it is caused by 
https://bugs.openjdk.java.net/browse/JDK-8244621 which affects JDKs 
built with Xcode 11 / MacOSX SDK 10.15.

>> We have filed a new bug : https://bugs.openjdk.java.net/browse/JDK-8246104
> Thank you
>
> i can see a comment about the differences between Windows and mac. To
> me, the difference is about the font type. in Windows it is Tahoma, in
> Mac it seems Times-Roman

I attached annotated versions of the images from Mac 10.15 and Win 10 to 
the above bug in JBS:

ComplexText-mac-10-15-two.png
ComplexText-win-10-two.png

with a couple of the differences highlighted. Since I don't read Arabic, 
I can't comment on whether it is a problem or not, just that it looks 
different.

-- Kevin


From philip.race at oracle.com  Fri May 29 12:44:25 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 29 May 2020 05:44:25 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-Ciraedd8Uy5DcPf8Ymwzw5c8+SxY5Y3w=OUXHsugwEmw@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <5ED0A221.2030602@oracle.com>
 <CAD678-Ciraedd8Uy5DcPf8Ymwzw5c8+SxY5Y3w=OUXHsugwEmw@mail.gmail.com>
Message-ID: <5ED103A9.5070105@oracle.com>

The interesting thing about you seeing :

I can see in the console this message:
CoreText note: Client requested name ".ArabicUIText-Regular", it will
get Times-Roman rather than the intended font. All system UI font
access should be through proper APIs such as
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].


Is that this message should be *prevented* by the very fix that I see as 
introducing the problem.
So I don't understand that at all.

So I think there are a few variables here.

1. The version of macOS

2. The version of Xcode / SDK used to create the build.
     I am not sure what the version on Maven used but I'm sure its not 
the same
     version I am using.

3. The system locale as set by preferred language + region.
    What is this for you ?

-phil.

On 5/28/20, 11:09 PM, Abu Abdullah wrote:
> On Fri, May 29, 2020 at 9:46 AM Philip Race<philip.race at oracle.com>  wrote:
>> Ok. you said in the first post :
>>
>> im using jfx 15-ea-5 on MacOS 10.15.3
>>
>> Where did you get that build ?
> from maven
>
> <dependency>
>     <groupId>org.openjfx</groupId>
>     <artifactId>javafx-controls</artifactId>
>     <version>15-ea+5</version>
>     <classifier>mac</classifier>
> </dependency>

From philip.race at oracle.com  Fri May 29 12:48:58 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 29 May 2020 05:48:58 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
Message-ID: <5ED104BA.1050007@oracle.com>



On 5/29/20, 5:38 AM, Kevin Rushforth wrote:
>
>> CoreText note: Client requested name ".ArabicUIText-Regular", it will
>> get Times-Roman rather than the intended font. All system UI font
>> access should be through proper APIs such as
>> CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
> I can see in the console this message:
>
> What JDK are you running? This looks like it is caused by 
> https://bugs.openjdk.java.net/browse/JDK-8244621 which affects JDKs 
> built with Xcode 11 / MacOSX SDK 10.15.

That message would only appear from the JDK side if you do something to 
execute
some Java 2D code *and* - as Kevin said have a JDK from somewhere that 
is also using
that newest Xcode.

But I haven't heard anything from Abu that says his app uses Swing 
Interop for example ...

Abu: does it ? And where did you get JDK ?

BTW I should add that because this message says .ArabicUIText-Regular" I 
am expecting
that you'll be reporting you are running with Arabic as the preferred 
system language ..

-phil.


From jvos at openjdk.java.net  Fri May 29 12:50:35 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 29 May 2020 12:50:35 GMT
Subject: [Rev 02] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <Qt9IsXZMTyupI_CxZUpwAHZRvN_z-HlhT4PBMaQ43uU=.0edb8bb7-4dc0-45bb-a78a-189bcfdc8794@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <Qt9IsXZMTyupI_CxZUpwAHZRvN_z-HlhT4PBMaQ43uU=.0edb8bb7-4dc0-45bb-a78a-189bcfdc8794@github.com>
Message-ID: <Zzzh8-V0tYr0m0IL2RQ6dwpU3tloQg38TKmLvZQUwnw=.5d6a7889-03f4-4f9f-80d5-69f798cdf6b3@github.com>

On Tue, 19 May 2020 10:19:42 GMT, Abhinay Agarwal <github.com+3197675+abhinayagarwal at openjdk.org> wrote:

>> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
>> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
>> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
>> should be shown again when the user taps on the TextInputControl.
>> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
>> both editable and focused.
>
> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skin implementation must maintain the contract of dispose

Looks good.
A test strategy for Android is a good idea for a follow-up issue.

-------------

Marked as reviewed by jvos (Reviewer).

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

From falcon.sheep at gmail.com  Fri May 29 12:53:38 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Fri, 29 May 2020 16:53:38 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
Message-ID: <CAD678-ALGLuKUbwTWj_rPERO7rJF65zcJMDSDgqLCDjPqcWTxg@mail.gmail.com>

> What JDK are you running? This looks like it is caused by
> https://bugs.openjdk.java.net/browse/JDK-8244621 which affects JDKs
> built with Xcode 11 / MacOSX SDK 10.15.

openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+24-1168)
OpenJDK 64-Bit Server VM (build 15-ea+24-1168, mixed mode, sharing)

> I attached annotated versions of the images from Mac 10.15 and Win 10 to
> the above bug in JBS:
>
> ComplexText-mac-10-15-two.png
> ComplexText-win-10-two.png
>
> with a couple of the differences highlighted. Since I don't read Arabic,
> I can't comment on whether it is a problem or not, just that it looks
> different.
i got your point, this is totally fine. it is different way of
presenting the characters depending on the font that you use. thank
you for the efforts.

From philip.race at oracle.com  Fri May 29 13:00:05 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 29 May 2020 06:00:05 -0700
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <CAD678-ALGLuKUbwTWj_rPERO7rJF65zcJMDSDgqLCDjPqcWTxg@mail.gmail.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
 <CAD678-ALGLuKUbwTWj_rPERO7rJF65zcJMDSDgqLCDjPqcWTxg@mail.gmail.com>
Message-ID: <5ED10755.9090708@oracle.com>

 From https://jdk.java.net/15/ ?

-phil.

On 5/29/20, 5:53 AM, Abu Abdullah wrote:
> openjdk version "15-ea" 2020-09-15
> OpenJDK Runtime Environment (build 15-ea+24-1168)
> OpenJDK 64-Bit Server VM (build 15-ea+24-1168, mixed mode, sharing)
>

From falcon.sheep at gmail.com  Fri May 29 13:00:59 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Fri, 29 May 2020 17:00:59 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <5ED103A9.5070105@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <5ED0A221.2030602@oracle.com>
 <CAD678-Ciraedd8Uy5DcPf8Ymwzw5c8+SxY5Y3w=OUXHsugwEmw@mail.gmail.com>
 <5ED103A9.5070105@oracle.com>
Message-ID: <CAD678-BwO_fGqRipWBUFjBXsTiy8N0c+S24i4TiKgpgOHuSpLQ@mail.gmail.com>

On Fri, May 29, 2020 at 4:42 PM Philip Race <philip.race at oracle.com> wrote:
>
> The interesting thing about you seeing :
>
> I can see in the console this message:
> CoreText note: Client requested name ".ArabicUIText-Regular", it will
> get Times-Roman rather than the intended font. All system UI font
> access should be through proper APIs such as
> CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
>
>
> Is that this message should be *prevented* by the very fix that I see as
> introducing the problem.
> So I don't understand that at all.
>
> So I think there are a few variables here.
>
> 1. The version of macOS
MacOS Catalina 10.15.3
[oracle at oracles-Mac bin % uname -a
Darwin oracles-Mac.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan
9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64

> 2. The version of Xcode / SDK used to create the build.
>      I am not sure what the version on Maven used but I'm sure its not
> the same
>      version I am using.

No clue how to support here

> 3. The system locale as set by preferred language + region.
>     What is this for you ?
language: English
Region: AE (UAE)

oracle at oracles-Mac bin % defaults read -g AppleLocale
en_AE

From falcon.sheep at gmail.com  Fri May 29 13:02:01 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Fri, 29 May 2020 17:02:01 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <5ED10755.9090708@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
 <CAD678-ALGLuKUbwTWj_rPERO7rJF65zcJMDSDgqLCDjPqcWTxg@mail.gmail.com>
 <5ED10755.9090708@oracle.com>
Message-ID: <CAD678-AMq+TZLV33nqv6QQ9=i3ZyN+W+ry6fCSWB43tvQK2G-Q@mail.gmail.com>

On Fri, May 29, 2020 at 5:00 PM Philip Race <philip.race at oracle.com> wrote:
>
>  From https://jdk.java.net/15/ ?

Yes

From falcon.sheep at gmail.com  Fri May 29 13:10:10 2020
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Fri, 29 May 2020 17:10:10 +0400
Subject: Arabic letters are not displayed correctly in MacOS 10.15.3
In-Reply-To: <5ED104BA.1050007@oracle.com>
References: <CAD678-BFHyd-8Ox31hgVPtYsq19z_x3vZuLu6m71O2qkqKFg2A@mail.gmail.com>
 <5ECE8CED.8060106@oracle.com>
 <CAD678-Dvbj_KYpb74yiJrwm1Pm+b1PFt6iXGPCanPh-r2nkrpA@mail.gmail.com>
 <5ED02BC3.1080007@oracle.com>
 <CAD678-CGSKagU6rJCvk_bVdqdoyC7jT_imfFdT3f8nS8_-pFoA@mail.gmail.com>
 <f6de4d3f-acd4-34d8-f863-71961bdfda36@oracle.com>
 <5ED104BA.1050007@oracle.com>
Message-ID: <CAD678-DzTbw61b+uNOFso4SRO3C9eJuhZwiDHex-o-uVf6BvXQ@mail.gmail.com>

On Fri, May 29, 2020 at 4:47 PM Philip Race <philip.race at oracle.com> wrote:
>
>
>
> On 5/29/20, 5:38 AM, Kevin Rushforth wrote:
> >
> >> CoreText note: Client requested name ".ArabicUIText-Regular", it will
> >> get Times-Roman rather than the intended font. All system UI font
> >> access should be through proper APIs such as
> >> CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
> > I can see in the console this message:
> >
> > What JDK are you running? This looks like it is caused by
> > https://bugs.openjdk.java.net/browse/JDK-8244621 which affects JDKs
> > built with Xcode 11 / MacOSX SDK 10.15.
>
> That message would only appear from the JDK side if you do something to
> execute
> some Java 2D code *and* - as Kevin said have a JDK from somewhere that
> is also using
> that newest Xcode.
>
> But I haven't heard anything from Abu that says his app uses Swing
> Interop for example ...
No im not using swing in this app at all, pure Javafx. but i have
another app that is swing based and it is running just fine in the
latest MacOS 10.15 so i was expecting it from Javafx side not from the
JDK.

>
> Abu: does it ? And where did you get JDK ?
yes as you predict. http://jdk.java.net/15/

>
> BTW I should add that because this message says .ArabicUIText-Regular" I
> am expecting
> that you'll be reporting you are running with Arabic as the preferred
> system language ..

I'm having arabic keyboard as an input as well + the region as you
asked is en_AE which is arabic region. not sure how the OS interpret
this

From mpaus at openjdk.java.net  Fri May 29 13:10:31 2020
From: mpaus at openjdk.java.net (Michael Paus)
Date: Fri, 29 May 2020 13:10:31 GMT
Subject: [Rev 02] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <Zzzh8-V0tYr0m0IL2RQ6dwpU3tloQg38TKmLvZQUwnw=.5d6a7889-03f4-4f9f-80d5-69f798cdf6b3@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <Qt9IsXZMTyupI_CxZUpwAHZRvN_z-HlhT4PBMaQ43uU=.0edb8bb7-4dc0-45bb-a78a-189bcfdc8794@github.com>
 <Zzzh8-V0tYr0m0IL2RQ6dwpU3tloQg38TKmLvZQUwnw=.5d6a7889-03f4-4f9f-80d5-69f798cdf6b3@github.com>
Message-ID: <N7ALHuv-4dzpq3t1GnyXTMyhWCsaIRqCy3eCucLfMUw=.f3d006ee-3e6a-4831-8952-bfd57265fd97@github.com>

On Fri, 29 May 2020 12:48:29 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skin implementation must maintain the contract of dispose
>
> Looks good.
> A test strategy for Android is a good idea for a follow-up issue.

Have you considered the case where a TextField is focused by default when its view is shown? As soon as the view is
shown the keybord will pop up, even if the user does not plan to edit anything. I just experienced this when I
exchanged the Label in the HelloGluon example against a TextField. A lot of strange things then happen. The keyboard
pops up, it hides the Gluon nag screen, if you close the keyboard and the nag screen you still see these edit markers
and all this just because this text field was focused by default. To my opinion the keyboard and the edit markers
should only be shown when the user actually clicks into the text field and thus indicates that he really wants to edit
something. I also noticed that after the keyboard was shown I could not normally close the application anymore. (This
was on Android with a Galaxy Tab 4)

-------------

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

From github.com+3197675+abhinayagarwal at openjdk.java.net  Fri May 29 15:09:30 2020
From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal)
Date: Fri, 29 May 2020 15:09:30 GMT
Subject: [Rev 03] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
Message-ID: <wRUWhcySyxW5bI9FV84MIJoKu7SEUl8-Ej8dFTNCy5M=.c7ff6d59-b112-4bda-8751-65e37f3b239d@github.com>

> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
> should be shown again when the user taps on the TextInputControl.
> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
> both editable and focused.

Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo: dispose should remove event handler

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/219/files
  - new: https://git.openjdk.java.net/jfx/pull/219/files/0b22747f..3024ddcb

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/219/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/219/webrev.02-03

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

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

From jvos at openjdk.java.net  Fri May 29 16:50:36 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 29 May 2020 16:50:36 GMT
Subject: [Rev 03] RFR: 8245053: Keyboard doesn't show when
 TextInputControl has focus
In-Reply-To: <wRUWhcySyxW5bI9FV84MIJoKu7SEUl8-Ej8dFTNCy5M=.c7ff6d59-b112-4bda-8751-65e37f3b239d@github.com>
References: <OTtmF3MegV-zLv00i9OAtKrQFb896hZCrN3UkmprIaY=.407d69de-8dae-4904-b2bb-06856367e682@github.com>
 <wRUWhcySyxW5bI9FV84MIJoKu7SEUl8-Ej8dFTNCy5M=.c7ff6d59-b112-4bda-8751-65e37f3b239d@github.com>
Message-ID: <MQKGurCSo7xmjF6Qszxb6ZbT4z1WvfMIB1eS_q94hEc=.e44431cd-09b4-4090-a52f-ea66dcae372b@github.com>

On Fri, 29 May 2020 15:09:30 GMT, Abhinay Agarwal <github.com+3197675+abhinayagarwal at openjdk.org> wrote:

>> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard.
>> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This
>> condition fails in cases where the control already has focus but the keyboard is not visible.  Ideally, the keyboard
>> should be shown again when the user taps on the TextInputControl.
>> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard  if the TextInput control is
>> both editable and focused.
>
> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo: dispose should remove event handler

worth discussing the case were a TextInput is the only control.

-------------

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

From jvos at openjdk.java.net  Fri May 29 17:48:30 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 29 May 2020 17:48:30 GMT
Subject: RFR: 8246099: Intermittent test failures in SandboxAppTest
In-Reply-To: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>
References: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>
Message-ID: <gi4vpk44hbvpkKUxYot_re6kx8tciE2TkewhWoc6TbA=.17c3d1ad-6af1-4c30-af27-b06c66ca2f83@github.com>

On Thu, 28 May 2020 21:02:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a fix for an intermittent test failure, due to a timeout, in `SandboxAppTest` that we are starting to see on
> some of our test machines.
> The failure is happening because of a 10 second timeout in the launched application. This doesn't seem to be enough to
> run the test to completion in all cases. I note that the similar launched apps, such as those launched by
> `MainLauncherTest`, `ModuleLauncherTest`, and `JarLauncherTest` don't have a timeout (they just rely on the timeout
> value of the launching test itself).  The app timeout was just added to prevent the test suite from hanging if the
> application were to get stuck, so there is no need for it to be such a small value (nor to have it be less than the
> test timeout).  The proposed solution is to increase the app timeout to 30 seconds (up from 10) and the test timeout to
> 25 (up from 15).

looks good

-------------

Marked as reviewed by jvos (Reviewer).

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

From kcr at openjdk.java.net  Fri May 29 18:27:20 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 May 2020 18:27:20 GMT
Subject: [Rev 01] RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <_hgk49qaNDlNcwO1COkYFexM4v_JOsjgqipUwpk7S0I=.2dd3142f-181e-49c3-9e56-5be44b41899a@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
 <_hgk49qaNDlNcwO1COkYFexM4v_JOsjgqipUwpk7S0I=.2dd3142f-181e-49c3-9e56-5be44b41899a@github.com>
Message-ID: <lqCXdp4Fa7LN0_0Q66Lw9iEhayJpeA5DCzI0g4ttUc0=.77226c49-3d09-4844-969b-b0b9c41807c5@github.com>

On Fri, 22 May 2020 12:15:04 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> As discussed [here](https://github.com/openjdk/jfx/pull/201#issuecomment-621772586) during #201 , This PR converts the
>> system tests in TabPanePermuteGetTabsTest.java to unit test.
>> Thanks @kleopatra , for providing the test. I have added few more tests and found few failures.
>> [JDK-8245528](https://bugs.openjdk.java.net/browse/JDK-8245528) is created to fix these failures, the failing tests are
>> currently ignored using this bug.
>> Please take a look.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

Looks good.

-------------

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Fri May 29 18:33:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 May 2020 18:33:15 GMT
Subject: [Rev 01] RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails
 intermittently
In-Reply-To: <lWLKPFmhM_xdcMLI8zVrmcBrQDnmu4sr1SV-In-8SA4=.ecd27d52-8720-4647-bc7e-fe5b362f75c6@github.com>
References: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
 <lWLKPFmhM_xdcMLI8zVrmcBrQDnmu4sr1SV-In-8SA4=.ecd27d52-8720-4647-bc7e-fe5b362f75c6@github.com>
Message-ID: <4rgab5Cs-xgirFWRcSMHDkcgCDzQ9pmXMxU9kc4-xJU=.bcc239be-17ca-497e-a804-40fff9c356ed@github.com>

On Fri, 29 May 2020 07:58:21 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

>> Issue: Snapshot taken before webpage is rendered
>> 
>> Fix: Use stateProperty and sleep to wait for the page to finish rendering
>
> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by kcr (Lead).

-------------

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

From kcr at openjdk.java.net  Fri May 29 18:34:42 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 May 2020 18:34:42 GMT
Subject: [Integrated] RFR: 8246099: Intermittent test failures in
 SandboxAppTest
In-Reply-To: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>
References: <-EEORCTAtLFFzEmyKzyvHt0FNnz16Um58sgO70f-jXc=.41bf9f05-a595-4728-8914-6f73572c7d48@github.com>
Message-ID: <j8tm43-Z3yLhtcFHJgUDhH1-oZkdc6GzA7VDRW_phP0=.e4dbe5b3-bfdc-46af-90a1-7eefb48d0c32@github.com>

On Thu, 28 May 2020 21:02:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a fix for an intermittent test failure, due to a timeout, in `SandboxAppTest` that we are starting to see on
> some of our test machines.
> The failure is happening because of a 10 second timeout in the launched application. This doesn't seem to be enough to
> run the test to completion in all cases. I note that the similar launched apps, such as those launched by
> `MainLauncherTest`, `ModuleLauncherTest`, and `JarLauncherTest` don't have a timeout (they just rely on the timeout
> value of the launching test itself).  The app timeout was just added to prevent the test suite from hanging if the
> application were to get stuck, so there is no need for it to be such a small value (nor to have it be less than the
> test timeout).  The proposed solution is to increase the app timeout to 30 seconds (up from 10) and the test timeout to
> 25 (up from 15).

This pull request has now been integrated.

Changeset: 168b7f79
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/168b7f79
Stats:     7 lines in 2 files changed: 0 ins; 0 del; 7 mod

8246099: Intermittent test failures in SandboxAppTest

Reviewed-by: arapte, jvos

-------------

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

From ajoseph at openjdk.java.net  Fri May 29 19:12:03 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Fri, 29 May 2020 19:12:03 GMT
Subject: [Integrated] RFR: 8243110: SVGTest.testSVGRenderingWithPattern
 fails intermittently
In-Reply-To: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
References: <PXio6Qam1ZbMm1OFyPvpz93KR8XwleV86f2qdikuvzU=.39fd0e86-48c1-4824-b7dd-e5e22c7e172e@github.com>
Message-ID: <wCVHDmPtNGHwBsXWGEtncVr3iB7HjGZ6OXtEE_a3rak=.24bc61c5-3b69-4c0c-9884-7174e269bc43@github.com>

On Thu, 28 May 2020 08:45:36 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Issue: Snapshot taken before webpage is rendered
> 
> Fix: Use stateProperty and sleep to wait for the page to finish rendering

This pull request has now been integrated.

Changeset: 9edba9cc
Author:    Arun Joseph <ajoseph at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/9edba9cc
Stats:     19 lines in 1 file changed: 3 ins; 16 del; 0 mod

8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

Reviewed-by: kcr

-------------

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

From almatvee at openjdk.java.net  Fri May 29 22:31:05 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 29 May 2020 22:31:05 GMT
Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version
Message-ID: <YNh69ewcDyB9VbmjL54vltKi-CSTeyAQzxavcQETF8w=.3f4d9540-0745-40e6-821d-5137f4fc7ea0@github.com>

- Updated libffi to 3.3.

-------------

Commit messages:
 - 8239095: Fixed jcheck
 - 8239095: Upgrade libFFI to the latest 3.3 version

Changes: https://git.openjdk.java.net/jfx/pull/242/files
 Webrev: https://webrevs.openjdk.java.net/jfx/242/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8239095
  Stats: 10110 lines in 37 files changed: 5391 ins; 4060 del; 659 mod
  Patch: https://git.openjdk.java.net/jfx/pull/242.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/242/head:pull/242

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

From kcr at openjdk.java.net  Fri May 29 22:43:42 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 May 2020 22:43:42 GMT
Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version
In-Reply-To: <YNh69ewcDyB9VbmjL54vltKi-CSTeyAQzxavcQETF8w=.3f4d9540-0745-40e6-821d-5137f4fc7ea0@github.com>
References: <YNh69ewcDyB9VbmjL54vltKi-CSTeyAQzxavcQETF8w=.3f4d9540-0745-40e6-821d-5137f4fc7ea0@github.com>
Message-ID: <nlJ6PoiCrIVEmU2eTm2Nv0SLacIfe8pUMQscS-bFo50=.78aa7d62-3250-4f70-b0b4-958f09e54510@github.com>

On Fri, 29 May 2020 01:24:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Updated libffi to 3.3.

@arapte Can you review as well?

-------------

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

From kcr at openjdk.java.net  Fri May 29 23:07:11 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 May 2020 23:07:11 GMT
Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version
In-Reply-To: <nlJ6PoiCrIVEmU2eTm2Nv0SLacIfe8pUMQscS-bFo50=.78aa7d62-3250-4f70-b0b4-958f09e54510@github.com>
References: <YNh69ewcDyB9VbmjL54vltKi-CSTeyAQzxavcQETF8w=.3f4d9540-0745-40e6-821d-5137f4fc7ea0@github.com>
 <nlJ6PoiCrIVEmU2eTm2Nv0SLacIfe8pUMQscS-bFo50=.78aa7d62-3250-4f70-b0b4-958f09e54510@github.com>
Message-ID: <rfqLNwyaNRXojm409hrt8KXPwscdc1JKNhpuftiYLdE=.d7d78bfb-0e9b-4dda-9262-52dc355f5008@github.com>

On Fri, 29 May 2020 22:41:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> - Updated libffi to 3.3.
>
> @arapte Can you review as well?

Initial testing looks good. I'll finish my testing & review on Monday.

-------------

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

From arapte at openjdk.java.net  Sat May 30 00:17:17 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Sat, 30 May 2020 00:17:17 GMT
Subject: [Integrated] RFR: 8244195: [TEST_BUG] Convert the system tests
 TabPanePermuteGetTabsTest to unit test
In-Reply-To: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
References: <WxpxzaN2KPCHKQ9QYBfFATLGqvQbZXxxSwPMugUdVLY=.e3f95388-c584-4855-9f03-d45f6f33e065@github.com>
Message-ID: <GTE_iV26kk8Zcqvy7ckhAoloGhzuC-dTqnj1LEXRX-U=.ebcb3b35-dfe0-460b-8cdb-6b328539541d@github.com>

On Thu, 21 May 2020 07:55:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> As discussed [here](https://github.com/openjdk/jfx/pull/201#issuecomment-621772586) during #201 , This PR converts the
> system tests in TabPanePermuteGetTabsTest.java to unit test.
> Thanks @kleopatra , for providing the test. I have added few more tests and found few failures.
> [JDK-8245528](https://bugs.openjdk.java.net/browse/JDK-8245528) is created to fix these failures, the failing tests are
> currently ignored using this bug.
> Please take a look.

This pull request has now been integrated.

Changeset: 804ccced
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/804ccced
Stats:     660 lines in 4 files changed: 352 ins; 307 del; 1 mod

8244195: [TEST_BUG] Convert the system tests TabPanePermuteGetTabsTest to unit test

Reviewed-by: kcr

-------------

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

From fastegal at openjdk.java.net  Sat May 30 09:16:11 2020
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sat, 30 May 2020 09:16:11 GMT
Subject: [Integrated] RFR: 8244657: ChoiceBox/ToolBarSkin: misbehavior on
 switching skin
In-Reply-To: <DzckbpguK2-T4rkhY6R12BQ_zgpkpHs3nxhRxGbkD6Y=.0ffedc7c-58ba-4f7f-913f-24da2a90ec40@github.com>
References: <DzckbpguK2-T4rkhY6R12BQ_zgpkpHs3nxhRxGbkD6Y=.0ffedc7c-58ba-4f7f-913f-24da2a90ec40@github.com>
Message-ID: <yJzTKIyv1anbPajXXFBpUlA1pgQVr4TyxoDiTfdluLk=.c908e581-eea9-44c7-a1e6-802e17d38e85@github.com>

On Tue, 26 May 2020 13:41:15 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> Both skins have similar misbehavior when switching skins
> 
> - memory leak due to a manually added but not removed change listener
> - NPE when modifying items after skin switch due to a not removed listener to the control's items
> 
> Fixed in both (for details see the issue). Added SkinCleanupTest for simple testing of per-control side-effects,
> removed both skins from memory test exclusion list: failing before and passing after fix.

This pull request has now been integrated.

Changeset: 1ab653cb
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/1ab653cb
Stats:     158 lines in 4 files changed: 3 ins; 150 del; 5 mod

8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin

Reviewed-by: aghaisas

-------------

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