From jvos at openjdk.java.net  Wed Jan  1 19:16:45 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 1 Jan 2020 19:16:45 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
 <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
Message-ID: <CA37tnaZSQpugCKNGIX6OhKGlo3lMMeDyABbg0um79o=.e14617b6-754a-4bb8-bd6f-04aaf8e69e92@github.com>

On Fri, 20 Dec 2019 22:19:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232589
>> 
>> - Removed CoreAudio Utility classes.
>> - Spectrum which was depended on CoreAudio Utility classes for doing computations will now run GStreamer spectrum element to do spectrum. Element will be run without pipeline and will be used as utility library to do spectrum calculation. I added extra APIs to bypass proper element initialization.
>> - Equalizer and audio unit (volume and balance) where modified, so we can run then directly without CoreAudio pipeline.
> 
> modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/spectrum/gstspectrum.c line 915:
> 
>> 914:   bpf = GST_AUDIO_FILTER_BPF (spectrum);
>> 915: #ifdef OSX
>> 916:   if (spectrum->bps_user != 0 && spectrum->bpf_user != 0) {
> 
> Should this also be qualified with `GSTREAMER_LITE` since it represents changes specific to our port?

It doesn't look required to me, but it would make more sense and bring it at the same level as line 738

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

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

From nlisker at gmail.com  Wed Jan  1 21:04:54 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 1 Jan 2020 23:04:54 +0200
Subject: Rate of embedded animations
Message-ID: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>

Hi,

As part of my work in the animations package I've come across an undefined
spec. Is the rate of an animation that is embedded in a Parallel/Sequential
transition inherited and overridden by its parent?

If I have an animations with a rate of 1 and a parent with a rate of 2, and
I add the animation to the parent, does the rate property change from 1 to
2 (generating a change/invalidation event etc.)? Then, should any
subsequent changes to the parent's rate trigger a change in the child's
rate?

The implementation is a bit messy in this regard. The rate and currentRate
values exist in both Animation and its ClipEnvelope, which is the source
for a couple of bugs. For example, changing the rate of a
ParallelTransition changes the child's ClipEnvelope's rate and currentRate,
but only the animation's currentRate (and not rate). Is it supposed to be
this way?

What is clear is that it's not possible to change the rate of the embedded
animation directly.

The docs do not talk about the rate of an embedded animation (they do talk
about the node property though).

- Nir

From github.com+6153953+pankaj-bansal at openjdk.java.net  Thu Jan  2 06:08:25 2020
From: github.com+6153953+pankaj-bansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 2 Jan 2020 06:08:25 GMT
Subject: [Rev 04] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <eyXaSGR06zfVnqLGw2qCC253QVU-dnB6wTydHdsMGfg=.a6265dae-c240-4dca-af00-2a993f2ca8d2@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <eyXaSGR06zfVnqLGw2qCC253QVU-dnB6wTydHdsMGfg=.a6265dae-c240-4dca-af00-2a993f2ca8d2@github.com>
Message-ID: <nd-I5a2bj7CmAV5afks2tHVaFpb2zIy83AmGrOloZEA=.42504fc2-1ec9-4973-acb1-9f7d9744a5db@github.com>

On Thu, 2 Jan 2020 06:08:25 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8225571
>> 
>> To run tests (on the root of the source tree):
>> ./gradlew apps
>> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
>> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
>> 
>> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
>> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
> 
> The pull request has been updated with 1 additional commit.

Sorry for late review. I have reviewed the code and have run few tests for DND on Ubuntu 18.04, Ubuntu 19.04 and OL 7.5. All works fine for me. Approved.

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

Marked as reviewed by pankaj-bansal at github.com (no known OpenJDK username).

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

From thiago.sayao at clamed.com.br  Thu Jan  2 11:18:49 2020
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Thu, 2 Jan 2020 11:18:49 +0000
Subject: Linux Glass - WindowContextChild and WindowContextPlug
In-Reply-To: <CP2P15201MB222861932AFEAE636E35F464DE260@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
References: <CP2P15201MB222861932AFEAE636E35F464DE260@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
Message-ID: <CP2P15201MB2228942C58B316340C58FE1BDE200@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

Ran all the robot test suite and those two classes are not touched.

I suspect they are used for web-start.

Are there any guides for running Ensemble on web-start? I guess I must use an old linux distro, that has old browser tech.

Happy new year.
________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Thiago Milczarek Sayao <thiago.sayao at clamed.com.br>
Enviado: ter?a-feira, 31 de dezembro de 2019 16:50
Para: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Assunto: Linux Glass - WindowContextChild and WindowContextPlug


Does anyone knows the context of use of WindowContextChild and WindowContextPlug on the linux glass implementation?

File: glass_window.cpp

They seem to be never called.

Thanks.



From kcr at openjdk.java.net  Thu Jan  2 16:35:56 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 2 Jan 2020 16:35:56 GMT
Subject: [Rev 03] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <6A7EJnUHKCuLh4m2zY5YoOTHsAfNpJfTss1K8_JBELE=.34aca62b-f58f-49c4-ba11-14dbec1e1b86@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <Tbq2LkhQdqOAxjklFu3gRF3-HAdCOHSOvfRwWRTzDmo=.965a915c-310f-4c25-855a-4fbdc34f41e1@github.com>
 <6A7EJnUHKCuLh4m2zY5YoOTHsAfNpJfTss1K8_JBELE=.34aca62b-f58f-49c4-ba11-14dbec1e1b86@github.com>
Message-ID: <2unCYsYHhSg68GSBHU5ZF5C5095MGm5KYS2sfl5Eve8=.e4deb6a8-ccbc-4f10-9b74-b7822c9d7104@github.com>

On Fri, 20 Dec 2019 13:53:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 2 additional commits.
> 
> Looks good.
> 
> I can sponsor this fix.

@tsayao this is ready for you to integrate.

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

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

From kcr at openjdk.java.net  Thu Jan  2 16:39:36 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 2 Jan 2020 16:39:36 GMT
Subject: [Rev 04] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <nd-I5a2bj7CmAV5afks2tHVaFpb2zIy83AmGrOloZEA=.42504fc2-1ec9-4973-acb1-9f7d9744a5db@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <eyXaSGR06zfVnqLGw2qCC253QVU-dnB6wTydHdsMGfg=.a6265dae-c240-4dca-af00-2a993f2ca8d2@github.com>
 <nd-I5a2bj7CmAV5afks2tHVaFpb2zIy83AmGrOloZEA=.42504fc2-1ec9-4973-acb1-9f7d9744a5db@github.com>
Message-ID: <1BMcfFHcS0Iw_Os4vn3ZbNpycbrsNpECPv_e8FuU-L0=.567d5aaa-e494-4519-92a1-f2e1bf3629bc@github.com>

On Thu, 2 Jan 2020 06:08:09 GMT, Pankaj Bansal <github.com+6153953+pankaj-bansal at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Sorry for late review. I have reviewed the code and have run few tests for DND on Ubuntu 18.04, Ubuntu 19.04 and OL 7.5. All works fine for me. Approved.

@tsayao this is ready for you to integrate. I note that it will only show one reviewer in the commit message; Pankaj did review it, but still needs to associate his GitHub ID with his OpenJDK ID before it will show up (so it will miss being recorded in the commit for this fix).

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

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

From kevin.rushforth at oracle.com  Thu Jan  2 17:12:39 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 2 Jan 2020 09:12:39 -0800
Subject: Pending Skara notifications, JBS updates for recent fixes
Message-ID: <118d678c-14eb-f35c-87f4-7f04539857e7@oracle.com>

The Skara commit notifications and JBS issue updates for the following 
recently-integrated bugs are still pending:

https://bugs.openjdk.java.net/browse/JDK-8130738
https://bugs.openjdk.java.net/browse/JDK-8236484
https://bugs.openjdk.java.net/browse/JDK-8232811
https://bugs.openjdk.java.net/browse/JDK-8225571

The reason for the delay is a problem accessing JBS from the Skara bot. 
It should be sorted out soon. In the mean time, I've added a label and a 
comment to each bug so we can track them, but I left them open to see 
whether the Skara bot will catch back up once access is restored (it 
should do). I'll do the same to any other bugs that are resolved prior 
to fixing the issue.

-- Kevin


From kcr at openjdk.java.net  Thu Jan  2 17:18:26 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 2 Jan 2020 17:18:26 GMT
Subject: [Rev 01] RFR: 8087980: Add property to disable Monocle cursor
In-Reply-To: <0IRAm4s9xg7Mt5cJ8kOtx-zyHJsvGW01Y5Qxi2WgdAo=.2cd54920-d581-470b-a4c7-1df5fd2a9c18@github.com>
References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com>
 <q8SnX5X_3xnnD3H-V5wqxgaTbyHmuORA4vxNlw8a3io=.1ae2b80c-c82e-4288-a334-9029a98cf44a@github.com>
 <0IRAm4s9xg7Mt5cJ8kOtx-zyHJsvGW01Y5Qxi2WgdAo=.2cd54920-d581-470b-a4c7-1df5fd2a9c18@github.com>
Message-ID: <CD1RqUHIuXCKB0qv-_K6BrhAtFCAE8m14QOkiTaOvwY=.f20d5c33-4264-44d9-9559-3d6ffc945e7a@github.com>

On Wed, 18 Dec 2019 12:52:04 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> LGTM

@dellgreen this is ready for you to integrate. It will need a sponsor, so perhaps @johanvos would be willing?

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

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

From nlisker at openjdk.java.net  Thu Jan  2 18:18:35 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 2 Jan 2020 18:18:35 GMT
Subject: RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <DpuJJPsI7LyNn9X5jsgwEoVmhPPCAGMWXmtiY4af4HU=.aefb6cdb-28b8-4d2c-9ca6-d8ca2ae5c518@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <deq05FjcDNT3m6beVoiK7XX9x_E6X_0NJAX-SqNQlpo=.93bb488a-f5dc-43b4-8a74-689c6f16aed5@github.com>
 <8rYgugRQG-zrAZsJc8I2KCABvRgf6yJ7F-AOMgUvKV8=.267cc5a7-c8b5-4b6e-87ed-3cbdab895020@github.com>
 <DpuJJPsI7LyNn9X5jsgwEoVmhPPCAGMWXmtiY4af4HU=.aefb6cdb-28b8-4d2c-9ca6-d8ca2ae5c518@github.com>
Message-ID: <_3FajXoBUGI2oS7eCJLrCiNCeUBhUpPvNzi6hbS6LXY=.92f12e93-1885-4d09-916a-90daa1fe1cbd@github.com>

On Fri, 20 Dec 2019 21:56:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The bug I mentioned above is not a bug actually. There are large changes over a small distance that make it looks like a jump in the lighting values, but when working with a finer scale the lighting dynamics seem correct.
> 
> I think this is on the right track. The API looks like it is in good shape.
> 
> This will need a fair bit of testing to ensure that there are no regressions either in functionality or (especially) performance, in addition to tests for the new functionality. On the performance aspect, the inner loop of the lighting calculation now has an additional if test for the max range and additional arithmetic calculations for the attenuation. What we will need is a test program that we can run on Mac and Windows to measure the performance of rendering in a fill-rate-limited case. Ideally, we would not pay much of a performance hit in the default case where `ca == 1, la == 0, qa == 0`, but we first need to be able to measure the drop in performance before we can say whether it is acceptable.
> 
> Speaking of testing, I took the current patch for a test drive on Mac and Windows. I get the following system test failures on Mac, and also the same failure using fx83dfeatures/LightMotion in toys.
> 
> 
> Shader compile log: ERROR: 0:308: Use of undeclared identifier 'range'
> ERROR: 0:316: Regular non-array variable 'dist' may not be redeclared
> 
> test.robot.test3d.MeshCompareTest > testSnapshot3D[3] STANDARD_ERROR
>     java.lang.RuntimeException: Error creating fragment shader
>     	at javafx.graphics/com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:141)
>     	at javafx.graphics/com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177)
>         ...
> test.robot.test3d.MeshCompareTest > testSnapshot3D[3] FAILED
>     java.lang.IllegalArgumentException: Unrecognized image loader: null
>         at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278)
>         at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53)
>         at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1340)
>         at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1372)
>         at javafx.graphics/javafx.scene.Scene.snapshot(Scene.java:1462)
>         at test.robot.test3d.MeshCompareTest.lambda$testSnapshot3D$0(MeshCompareTest.java:315)
> 
> 
> test.robot.test3d.Snapshot3DTest > testSnapshot3D[3] FAILED
> (same failure as above)
> 
> 
> test.robot.test3d.Snapshot3DTest > testSnapshot3D[7] FAILED
> (same failure as above)

> I get the following system test failures on Mac
> ```
> Shader compile log: ERROR: 0:308: Use of undeclared identifier 'range'
> ERROR: 0:316: Regular non-array variable 'dist' may not be redeclared
> ```

I don't have a Mac to test on, but on Ubuntu system tests pass (I ran the `test` command for systemTests). Does the sample app I attached also fail on Mac? They both use the same shaders, so I wonder where the issue could be.
Moreover, the error messages are strange. `dist` is not redeclared and `range` is not undeclared in the shader. The error message seems to originate from the native function `Java_com_sun_prism_es2_GLContext_nCompileShader` in `GLContext.c`, not managing to compile the shader, but I can't tell why.

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

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

From kcr at openjdk.java.net  Fri Jan  3 00:31:38 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 00:31:38 GMT
Subject: RFR: 8236626: Update copyright header for files modified in 2019
Message-ID: <AHAEhmsgnn_vIteJp_wGLp2yNc13RkoGPfbLV8m46m8=.3bcf0bd6-55e8-4685-a9a5-12c5e3cce8a3@github.com>

Simple fix to update the copyright year in the one file that was changed in 2019 after the last update of the year.

@arapte can you please review?

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

Commits:
 - c1d9b8ef: 8236626: Update copyright header for files modified in 2019

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

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

From kcr at openjdk.java.net  Fri Jan  3 00:49:05 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 00:49:05 GMT
Subject: RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <_3FajXoBUGI2oS7eCJLrCiNCeUBhUpPvNzi6hbS6LXY=.92f12e93-1885-4d09-916a-90daa1fe1cbd@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <deq05FjcDNT3m6beVoiK7XX9x_E6X_0NJAX-SqNQlpo=.93bb488a-f5dc-43b4-8a74-689c6f16aed5@github.com>
 <8rYgugRQG-zrAZsJc8I2KCABvRgf6yJ7F-AOMgUvKV8=.267cc5a7-c8b5-4b6e-87ed-3cbdab895020@github.com>
 <DpuJJPsI7LyNn9X5jsgwEoVmhPPCAGMWXmtiY4af4HU=.aefb6cdb-28b8-4d2c-9ca6-d8ca2ae5c518@github.com>
 <_3FajXoBUGI2oS7eCJLrCiNCeUBhUpPvNzi6hbS6LXY=.92f12e93-1885-4d09-916a-90daa1fe1cbd@github.com>
Message-ID: <2LXTsp6kQNFIuGEKjzqp8W8O5-VkFKHFPbpaWHddPlA=.4a6f9043-875e-4914-918a-b9365abf9e24@github.com>

On Thu, 2 Jan 2020 18:18:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> I think this is on the right track. The API looks like it is in good shape.
>> 
>> This will need a fair bit of testing to ensure that there are no regressions either in functionality or (especially) performance, in addition to tests for the new functionality. On the performance aspect, the inner loop of the lighting calculation now has an additional if test for the max range and additional arithmetic calculations for the attenuation. What we will need is a test program that we can run on Mac and Windows to measure the performance of rendering in a fill-rate-limited case. Ideally, we would not pay much of a performance hit in the default case where `ca == 1, la == 0, qa == 0`, but we first need to be able to measure the drop in performance before we can say whether it is acceptable.
>> 
>> Speaking of testing, I took the current patch for a test drive on Mac and Windows. I get the following system test failures on Mac, and also the same failure using fx83dfeatures/LightMotion in toys.
>> 
>> 
>> Shader compile log: ERROR: 0:308: Use of undeclared identifier 'range'
>> ERROR: 0:316: Regular non-array variable 'dist' may not be redeclared
>> 
>> test.robot.test3d.MeshCompareTest > testSnapshot3D[3] STANDARD_ERROR
>>     java.lang.RuntimeException: Error creating fragment shader
>>     	at javafx.graphics/com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:141)
>>     	at javafx.graphics/com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177)
>>         ...
>> test.robot.test3d.MeshCompareTest > testSnapshot3D[3] FAILED
>>     java.lang.IllegalArgumentException: Unrecognized image loader: null
>>         at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278)
>>         at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53)
>>         at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1340)
>>         at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1372)
>>         at javafx.graphics/javafx.scene.Scene.snapshot(Scene.java:1462)
>>         at test.robot.test3d.MeshCompareTest.lambda$testSnapshot3D$0(MeshCompareTest.java:315)
>> 
>> 
>> test.robot.test3d.Snapshot3DTest > testSnapshot3D[3] FAILED
>> (same failure as above)
>> 
>> 
>> test.robot.test3d.Snapshot3DTest > testSnapshot3D[7] FAILED
>> (same failure as above)
> 
>> I get the following system test failures on Mac
>> ```
>> Shader compile log: ERROR: 0:308: Use of undeclared identifier 'range'
>> ERROR: 0:316: Regular non-array variable 'dist' may not be redeclared
>> ```
> 
> I don't have a Mac to test on, but on Ubuntu system tests pass (I ran the `test` command for systemTests). Does the sample app I attached also fail on Mac? They both use the same shaders, so I wonder where the issue could be.
> Moreover, the error messages are strange. `dist` is not redeclared and `range` is not undeclared in the shader. The error message seems to originate from the native function `Java_com_sun_prism_es2_GLContext_nCompileShader` in `GLContext.c`, not managing to compile the shader, but I can't tell why.

I get the same error on Ubuntu 16.04 as on Mac. Did you run the system tests with `-PFULL_TEST=true -PUSE_ROBOT=true`? Also, you can try running the `fx83dfeatures/LightMotion` toy and you should see the same error.

I still need to test your sample app on Mac.

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

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

From arapte at openjdk.java.net  Fri Jan  3 04:41:55 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 3 Jan 2020 04:41:55 GMT
Subject: RFR: 8236626: Update copyright header for files modified in 2019
In-Reply-To: <AHAEhmsgnn_vIteJp_wGLp2yNc13RkoGPfbLV8m46m8=.3bcf0bd6-55e8-4685-a9a5-12c5e3cce8a3@github.com>
References: <AHAEhmsgnn_vIteJp_wGLp2yNc13RkoGPfbLV8m46m8=.3bcf0bd6-55e8-4685-a9a5-12c5e3cce8a3@github.com>
Message-ID: <Cx7gkDQwMyKSx_Pf2vr485umhhrT_Cg8MnhrHQgcGz4=.d686b35a-ffcb-4fd2-bc3d-14018b823527@github.com>

On Fri, 3 Jan 2020 00:29:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Simple fix to update the copyright year in the one file that was changed in 2019 after the last update of the year.
> 
> @arapte can you please review?

looks good to me.

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

Marked as reviewed by arapte (Reviewer).

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

From arapte at openjdk.java.net  Fri Jan  3 09:26:58 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 3 Jan 2020 09:26:58 GMT
Subject: 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: <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>

On Sun, 17 Nov 2019 04:15:34 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

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

I have added few comments, but have not run tests and sample yet.

modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 71:

> 70:     public void setCa(double ca) {
> 71:         this.ca = ca;
> 72:         visualsChanged();

`if (this.ca != ca)`  check can be added here. Similar for `la`, `qa` and `maxRange`

modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DContext.java line 556:

> 555:     void setPointLight(long nativeMeshView, int index, float x, float y, float z,
> 556:             float r, float g, float b, float w, float ca, float la, float qa,  float maxRange) {
> 557:         nSetPointLight(pContext, nativeMeshView, index, x, y, z, r, g, b, w, ca, la, qa, maxRange);

There is an extra space before `float maxRange`

modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 97:

> 96:      * The maximum range of this {@code PointLight}. For a pixel to be affected by this light, its distance to
> 97:      * the light source must be less than or equal to the light's maximum range. Any negative value will treated
> 98:      * as 0.

=> will `be` treated as 0.

modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 43:

> 42:     private static final double DEFAULT_MAX_RANGE = Double.POSITIVE_INFINITY;
> 43: 
> 44:     public NGPointLight() {

Will it be a good idea to move these constants to `PointLight` class?
However they look good here too.

modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 41:

> 40:  * unless it belongs to a {@code Shape3D} outside of its {@code scope}.
> 41:  * <p>
> 42:  * The light's intensity can be set to decrease over distance by attenuating it. The attenuation formula

Can the behavior be explained in terms of `Shape `or `Node `instead of `Pixel`.
May be something like this,

`Any node within the range of the light will be illuminated by this light, except the nodes that are added to the exclusion scope of this light.`

modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 103:

> 102:      * {@code maxRange} value by finding the where the attenuation is close enough to 0.
> 103:      * <p>
> 104:      * Nodes that are inside the light's range can still be excluded from the light's effect

{@code maxRange} value by finding the `distance` where the attenuation is close enough to 0.

modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 64:

> 63: 
> 64:     private double ca = DEFAULT_CA;
> 65: 

The coefficients are not directly used in any arithmetic on java side. They are converted to `float` and passed to GL or D3D pipeline. Should these be `float `instead of `double` ?

modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 175:

> 174:         lightsAttenuation[a++] = lights[i].attenuation[2];
> 175:         lightsAttenuation[a++] = 0;
> 176: 

In the initial commit this filed was used for `maxRange`. I think that was good idea. Was there any issue with that approach ?

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

Changes requested by arapte (Reviewer).

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

From kcr at openjdk.java.net  Fri Jan  3 15:55:47 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 15:55:47 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
Message-ID: <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>

> This PR is a fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474), a crash in the code that shows a file open or save dialog.
> 
> In order to provide additional support for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V), the Glass implementation for displaying a file open or save dialog subclasses NSSavePanel or NSOpenPanel to add this support. When the application is running in sandboxed mode, the dialogs are shown out-of-process by the "powerbox". In this mode, attempting to use our subclass results in a security exception. Previously, we added code to detect whether we were running in a sandbox as a fix for [JDK-8092977](https://bugs.openjdk.java.net/browse/JDK-8092977); we now use NSSavePanel or NSOpenPanel directly when in sandboxed mode.
> 
> Starting with macOS 10.15 (Catalina) Apple always displays file dialogs out-of-process via powerbox, so our use of a subclass is ineffective. Further, we have reports of some cases where we crash even though our sandbox detection code doesn't indicate that we are running in a sandbox.
> 
> Since there is no point in trying to use our subclasses on macOS 10.15 or later, I propose to fix this bug by changing the logic so that we use NSSavePanel or NSOpenPanel directly in either of the following conditions:
> 
> 1) the app is running in sandbox mode
> OR
> 2) The platform is macOS 10.15 or later

The pull request has been updated with 1 additional commit.

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

Added commits:
 - b13da6f7: Update copyright year to 2020

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/70/files
  - new: https://git.openjdk.java.net/jfx/pull/70/files/dca394e6..b13da6f7

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

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

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

From nlisker at openjdk.java.net  Fri Jan  3 19:19:06 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 19:19:06 GMT
Subject: [Rev 01] 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: <JC-crkdebBn_GNY0HY9b7BVn_F6AJ3OC6rcaAU4CRko=.0a6f581b-d9b5-4b15-868b-a7f24aef3765@github.com>

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

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f66e8cf4: Addressing review comments

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/43/files
  - new: https://git.openjdk.java.net/jfx/pull/43/files/a388fb92..f66e8cf4

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

  Stats: 25 lines in 3 files changed: 8 ins; 2 del; 15 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 nlisker at openjdk.java.net  Fri Jan  3 19:22:55 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 19:22:55 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
Message-ID: <SXcT2y61_ySgzTXrfoBiTPkbrLG5MSDPSp6urBz30Ec=.22544c1a-a331-4a97-af78-bfa2cb3ce420@github.com>

On Fri, 3 Jan 2020 05:08:33 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 43:
> 
>> 42:     private static final double DEFAULT_MAX_RANGE = Double.POSITIVE_INFINITY;
>> 43: 
>> 44:     public NGPointLight() {
> 
> Will it be a good idea to move these constants to `PointLight` class?
> However they look good here too.

If they are in `PointLight` it will be difficult for the peer to access them (will need to do through the accessor). Also, the parent `NGLightBase` holds the defaults for `color` and `lightOn`.

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

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

From nlisker at openjdk.java.net  Fri Jan  3 19:32:35 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 19:32:35 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
Message-ID: <VwPeDOOli1pbRVmsImVjH-6Rf7Drpfsk0VnXLXh_Ee4=.94c5fd52-2f05-4c4d-945a-01da7933e64f@github.com>

On Fri, 3 Jan 2020 05:17:26 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 41:
> 
>> 40:  * unless it belongs to a {@code Shape3D} outside of its {@code scope}.
>> 41:  * <p>
>> 42:  * The light's intensity can be set to decrease over distance by attenuating it. The attenuation formula
> 
> Can the behavior be explained in terms of `Shape `or `Node `instead of `Pixel`.
> May be something like this,
> 
> `Any node within the range of the light will be illuminated by this light, except the nodes that are added to the exclusion scope of this light.`

The issue is that range and attenuation work on the pixel scale, not on the node/shape scale. A node can be partially illuminated if only part of it is within the range of the light. See the image in the comment above.

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

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

From nlisker at openjdk.java.net  Fri Jan  3 19:36:45 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 19:36:45 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
Message-ID: <vX2q1QRX8RvHQoUuInfvlo63kS5gBvoS4JkWA14S6q0=.c3b22cd4-9941-4908-b817-d1337a22a4ba@github.com>

On Fri, 3 Jan 2020 09:21:32 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 64:
> 
>> 63: 
>> 64:     private double ca = DEFAULT_CA;
>> 65: 
> 
> The coefficients are not directly used in any arithmetic on java side. They are converted to `float` and passed to GL or D3D pipeline. Should these be `float `instead of `double` ?

I was wondering about it myself, but all the other values are `double`s that are cast to `float`s. Wouldn't it also be odd to have the API properties `DoubleProperty` and the peer to use `float`s? Isn't it just a matter of where the cast happens?

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

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

From nlisker at openjdk.java.net  Fri Jan  3 19:41:15 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 19:41:15 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
Message-ID: <fdRveloL4LWK_zmRBJk-x8wicEwVIN-WYT5J8uIx0iE=.773974aa-d649-4c1e-ba05-6ce623e1da79@github.com>

On Fri, 3 Jan 2020 09:25:21 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 175:
> 
>> 174:         lightsAttenuation[a++] = lights[i].attenuation[2];
>> 175:         lightsAttenuation[a++] = 0;
>> 176: 
> 
> In the initial commit this filed was used for `maxRange`. I think that was good idea. Was there any issue with that approach ?

`maxRange` has its own array to reserve space for `minRange` if we ever do that (see [this discussion](https://github.com/javafxports/openjdk-jfx/issues/256#issuecomment-469970201)), so I future-proofed it.

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

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

From kcr at openjdk.java.net  Fri Jan  3 22:21:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 22:21:16 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <VwPeDOOli1pbRVmsImVjH-6Rf7Drpfsk0VnXLXh_Ee4=.94c5fd52-2f05-4c4d-945a-01da7933e64f@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <VwPeDOOli1pbRVmsImVjH-6Rf7Drpfsk0VnXLXh_Ee4=.94c5fd52-2f05-4c4d-945a-01da7933e64f@github.com>
Message-ID: <5wmco96mDV2o6049nG257Ac_7cUWQzkRXClNSDHdTYY=.c046919f-25fb-4437-894a-2c5ed5ebc936@github.com>

On Fri, 3 Jan 2020 19:32:23 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 41:
>> 
>>> 40:  * unless it belongs to a {@code Shape3D} outside of its {@code scope}.
>>> 41:  * <p>
>>> 42:  * The light's intensity can be set to decrease over distance by attenuating it. The attenuation formula
>> 
>> Can the behavior be explained in terms of `Shape `or `Node `instead of `Pixel`.
>> May be something like this,
>> 
>> `Any node within the range of the light will be illuminated by this light, except the nodes that are added to the exclusion scope of this light.`
> 
> The issue is that range and attenuation work on the pixel scale, not on the node/shape scale. A node can be partially illuminated if only part of it is within the range of the light. See the image in the comment above.

Right. This needs to talk about pixels. Perhaps there is a way to make it more clear that we are talking about pixels that are part of a rendered Shape3D, but I don't have a good suggestion right now.

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

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

From kcr at openjdk.java.net  Fri Jan  3 22:23:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 22:23:46 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <vX2q1QRX8RvHQoUuInfvlo63kS5gBvoS4JkWA14S6q0=.c3b22cd4-9941-4908-b817-d1337a22a4ba@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <vX2q1QRX8RvHQoUuInfvlo63kS5gBvoS4JkWA14S6q0=.c3b22cd4-9941-4908-b817-d1337a22a4ba@github.com>
Message-ID: <AFo8s1hRqeWCqYxNEbTfoKCkAtsekB-mzURfSNCo0cA=.2eb2dab3-42c2-404e-b402-a47fd6faa56f@github.com>

On Fri, 3 Jan 2020 19:36:35 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 64:
>> 
>>> 63: 
>>> 64:     private double ca = DEFAULT_CA;
>>> 65: 
>> 
>> The coefficients are not directly used in any arithmetic on java side. They are converted to `float` and passed to GL or D3D pipeline. Should these be `float `instead of `double` ?
> 
> I was wondering about it myself, but all the other values are `double`s that are cast to `float`s. Wouldn't it also be odd to have the API properties `DoubleProperty` and the peer to use `float`s? Isn't it just a matter of where the cast happens?

Yes, it's just a matter of where the cast happens. While we aren't entirely consistent, I think you'll find more places where the peers hold floats rather than double (one notable exception is transforms where we need the extra precision). In particular, Color and position values for shapes are stored in the peer as floats. Also, PhongMaterial stores the power as a float even though the API is double.

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

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

From kcr at openjdk.java.net  Fri Jan  3 22:37:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 22:37:15 GMT
Subject: [Rev 01] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
Message-ID: <Wuf0jfTK70vHWQmVQSM1WnS3volV0aCGxBJQ2DI1X6k=.18bae9da-83d1-4749-829a-37a08b7c4955@github.com>

On Fri, 3 Jan 2020 09:26:43 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> I have added few comments, but have not run tests and sample yet.

> I still need to test your sample app on Mac.

I get the error with your sample app. It fails on Mac or Linux (Ubuntu 16.04) with the same error as I reported above.

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

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

From nlisker at openjdk.java.net  Fri Jan  3 23:00:55 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 23:00:55 GMT
Subject: [Rev 02] 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: <RZ30NJU0Y4vCTLuOYrZDDabtrTb9c6nB4nDPa1Zqh9I=.00db3b6b-6182-487d-a7fe-840d23c67ecf@github.com>

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

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 464e8b5d: Fixed shader compilation errors for 2 and 3 lights in es2

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/43/files
  - new: https://git.openjdk.java.net/jfx/pull/43/files/f66e8cf4..464e8b5d

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

  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 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 nlisker at openjdk.java.net  Fri Jan  3 23:03:05 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 23:03:05 GMT
Subject: [Rev 02] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <Wuf0jfTK70vHWQmVQSM1WnS3volV0aCGxBJQ2DI1X6k=.18bae9da-83d1-4749-829a-37a08b7c4955@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <Wuf0jfTK70vHWQmVQSM1WnS3volV0aCGxBJQ2DI1X6k=.18bae9da-83d1-4749-829a-37a08b7c4955@github.com>
Message-ID: <zJwg7ZYL4g4Wkkof2-9QMNv7KbM_yvX6yUhJaevIFt4=.c066ee9c-800e-442c-95bb-d733986c5227@github.com>

On Fri, 3 Jan 2020 22:37:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I have added few comments, but have not run tests and sample yet.
> 
>> I still need to test your sample app on Mac.
> 
> I get the error with your sample app. It fails on Mac or Linux (Ubuntu 16.04) with the same error as I reported above.

The error was for the cases of 2 and 3 lights (I was testing 1) and should be fixed now. My fault with copy-paste... that's why we use loops, but I guess this is some optimization for the pipeline. I wonder if it's really woth it over a single shader looping over the number of lights like d3d does.

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

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

From kcr at openjdk.java.net  Fri Jan  3 23:19:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 23:19:16 GMT
Subject: RFR: 8236448: Remove unused and repair broken Android/Dalvik code
In-Reply-To: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
References: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
Message-ID: <S2VDZuMOatDL2314mq_yygvZl6kP_jfXCGKc2DyA0sY=.1da1235a-ca21-4470-9b0a-a64c2f8700ef@github.com>

On Mon, 30 Dec 2019 11:05:55 GMT, Johan Vos <jvos at openjdk.org> wrote:

> This allows to build the JavaFX jars and native libraries for Android devices

I did a test build on Linux since there were changes to the shared Monocle classes. I didn't really look at the `android.gradle` changes or the new `android/nativeBridge.c` file, but I don't have any concerns. I did leave a couple minor formatting comments and one copyright year issue.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/AndroidInputDeviceRegistry.java line 62:

> 61:         }
> 62:         Platform.runLater( () -> instance.gotTouchEvent(touchState));
> 63:     }

Minor: normally we wouldn't put a space between the initial `(` and the `()`

modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java line 229:

> 228:                                    ns.getWidth(), ns.getHeight(),
> 229:                                    1.f,1.f, ns.getScale(), ns.getScale());
> 230:         // Move the cursor to the middle of the screen

Minor: add a space after the first `,`

modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java line 175:

> 174:         Platform.runLater(new Runnable () {
> 175:             @Override
> 176:             public void run() {

Other than removing the one blank line above, this file is unchanged. Perhaps it could be reverted?

modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.h line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

That should be `2012, 2019, Oracle...` so as not to lose the initial year (well actually `2012, 2020, Oracle...`  as of Jan 1, but that will get updated the next time I run my copyright script, which I plan to do right before RDP2, so either 2019 or 2020 for the last-modified year is fine).

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



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

From nlisker at openjdk.java.net  Fri Jan  3 23:22:56 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 23:22:56 GMT
Subject: [Rev 02] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <AFo8s1hRqeWCqYxNEbTfoKCkAtsekB-mzURfSNCo0cA=.2eb2dab3-42c2-404e-b402-a47fd6faa56f@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <vX2q1QRX8RvHQoUuInfvlo63kS5gBvoS4JkWA14S6q0=.c3b22cd4-9941-4908-b817-d1337a22a4ba@github.com>
 <AFo8s1hRqeWCqYxNEbTfoKCkAtsekB-mzURfSNCo0cA=.2eb2dab3-42c2-404e-b402-a47fd6faa56f@github.com>
Message-ID: <CG5i34yFBHXbKu_snrgjQD4M4by6pWxjy46fzKgxZbE=.2c13dab5-e3d9-477a-9a7c-b1c43f7e15d8@github.com>

On Fri, 3 Jan 2020 22:23:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I was wondering about it myself, but all the other values are `double`s that are cast to `float`s. Wouldn't it also be odd to have the API properties `DoubleProperty` and the peer to use `float`s? Isn't it just a matter of where the cast happens?
> 
> Yes, it's just a matter of where the cast happens. While we aren't entirely consistent, I think you'll find more places where the peers hold floats rather than double (one notable exception is transforms where we need the extra precision). In particular, Color and position values for shapes are stored in the peer as floats. Also, PhongMaterial stores the power as a float even though the API is double.

Alright, I don't mind it, I'll cast in the peer level.

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

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

From nlisker at openjdk.java.net  Fri Jan  3 23:42:10 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 3 Jan 2020 23:42:10 GMT
Subject: [Rev 03] 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: <PLNjGcxi_UFFrI4YcW1FaH-4FHa2Nwv71wpGOCdnuII=.cefe3cca-a35f-4a72-8278-530bf7f2a05b@github.com>

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

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 66cdab32: Attenuation and range changed internally to floats from doubles

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/43/files
  - new: https://git.openjdk.java.net/jfx/pull/43/files/464e8b5d..66cdab32

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

  Stats: 32 lines in 3 files changed: 0 ins; 0 del; 32 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 kcr at openjdk.java.net  Fri Jan  3 23:50:44 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 3 Jan 2020 23:50:44 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <yyD8hlcbDx35EajGmbiPkrynBIsHvjC4HX8AbFBmVmA=.cdeac3c5-a77e-4379-bbf1-be10ab4bcbde@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
 <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>
 <dJY6uX8R7fbRyiftmCyh3TuqdUGGy63zll2Qqv3vDnQ=.6dbcd745-a5fd-483c-aa46-16c5b36434b3@github.com>
 <yyD8hlcbDx35EajGmbiPkrynBIsHvjC4HX8AbFBmVmA=.cdeac3c5-a77e-4379-bbf1-be10ab4bcbde@github.com>
Message-ID: <PTQzJ7NSc38A5BInppE5ik8--7HbLWCa_y21VIXbtb4=.274fce44-bb1c-42d7-9f53-9533347581b7@github.com>

On Tue, 24 Dec 2019 06:37:05 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The dispose methods indeed won't set the `mem_Error_Flag` but this flag might have been set by other methods. Isn't there a probability that the flag has been set, and that `readAndClearMemErrorFlag()` is not yet called since the flag has been set?
> 
> Hi Johan, I did miss to verify this angle.
> But have checked the code now and can confirm that, in a given function for all possible calls to `setMemErrorFlag()` there exists a call to `readAndClearMemErrorFlag()` in the same function. So it looks safe to remove the memory checks from `dispose()`

I also looked at the code and don't see any mismatches (including those called from the `ACQUIRE_SURFACE` macro). I suppose you could restore the call, but since we are in a disposer thread throwing an exception doesn't seem like the right thing to do. You could log the error, but if we are sure there can be no pending errors, it might not be worth the effort.

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

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

From nlisker at openjdk.java.net  Sat Jan  4 18:22:45 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 4 Jan 2020 18:22:45 GMT
Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <5wmco96mDV2o6049nG257Ac_7cUWQzkRXClNSDHdTYY=.c046919f-25fb-4437-894a-2c5ed5ebc936@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <VwPeDOOli1pbRVmsImVjH-6Rf7Drpfsk0VnXLXh_Ee4=.94c5fd52-2f05-4c4d-945a-01da7933e64f@github.com>
 <5wmco96mDV2o6049nG257Ac_7cUWQzkRXClNSDHdTYY=.c046919f-25fb-4437-894a-2c5ed5ebc936@github.com>
Message-ID: <S5zMy0iS2Ci2IOfpLz71K6C2PDY6YgXV1M4GYk2Plq0=.7ec6e83d-9ab7-4fa6-8166-cf9e61ac837b@github.com>

On Fri, 3 Jan 2020 22:21:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The issue is that range and attenuation work on the pixel scale, not on the node/shape scale. A node can be partially illuminated if only part of it is within the range of the light. See the image in the comment above.
> 
> Right. This needs to talk about pixels. Perhaps there is a way to make it more clear that we are talking about pixels that are part of a rendered Shape3D, but I don't have a good suggestion right now.

Maybe

A light source that radiates light equally in all directions away from itself. The location of the light
source is a single point in space. The light affects {@code Shape3D}s in its {@code scope}. Any
pixels in the light's {@code range} that belong to a {@code Shape3D} will be illuminated by it according to the
computation specified in {@link PhongMaterial}.
The docs of `PhongMaterial` will need need to be updated too.

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

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

From tsayao at openjdk.java.net  Mon Jan  6 00:29:45 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 6 Jan 2020 00:29:45 GMT
Subject: RFR: 8236651: Simplify and update glass gtk backend
Message-ID: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>

This proposed change does the following:

- Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
- Use gtk signals instead of gdk events (also to reduce code size);
- Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
- Replaces (pointer and focus) grabbing with a gtk approach;
- Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
- Simplified cursor changing;

In general it reduces code size and complexity and hands more work to gtk.

Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.

Please, mark it as WIP. 

![image](https://user-images.githubusercontent.com/30704286/71788555-442ba400-3002-11ea-9d8c-e4265909fe6b.png)

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

Commits:
 - 039daa4a: Cleaning
 - 9f209f1e: JDK-8236651 Simplify and update glass gtk backend

Changes: https://git.openjdk.java.net/jfx/pull/77/files
 Webrev: https://webrevs.openjdk.java.net/jfx/77/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236651
  Stats: 2497 lines in 11 files changed: 600 ins; 1543 del; 354 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From tsayao at openjdk.java.net  Mon Jan  6 00:39:31 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 6 Jan 2020 00:39:31 GMT
Subject: [Rev 01] RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <hU1HRUXyR98BVFd0mzRFeS616vfSnha6kLZMvy1Y7B0=.0f9eba24-497d-4ec1-8d6d-8ff13fc0d208@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> Please, mark it as WIP. 
> 
> ![image](https://user-images.githubusercontent.com/30704286/71788555-442ba400-3002-11ea-9d8c-e4265909fe6b.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 7b48e484: Cleaning + change year to 2020

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/039daa4a..7b48e484

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

  Stats: 45 lines in 5 files changed: 0 ins; 42 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From tsayao at openjdk.java.net  Mon Jan  6 02:08:14 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 6 Jan 2020 02:08:14 GMT
Subject: [Rev 02] RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <PKnnfGeb_q0404qJ-jKxr5oDY9JueSYgMe6alnsr_D0=.766dbff7-ccd4-4ce2-bb74-683142f4c0a8@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> Please, mark it as WIP. 
> 
> ![image](https://user-images.githubusercontent.com/30704286/71788555-442ba400-3002-11ea-9d8c-e4265909fe6b.png)

The pull request has been updated with 4 additional commits.

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

Added commits:
 - 628d5528: Revert idea files
 - 8b0cadfc: Fix crash
 - 1c3df122: Fix crash
 - 4691800a: Fix crash

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/7b48e484..628d5528

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

  Stats: 118 lines in 4 files changed: 25 ins; 47 del; 46 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From ghb at openjdk.java.net  Mon Jan  6 04:32:35 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Mon, 6 Jan 2020 04:32:35 GMT
Subject: [Rev 03] RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <MfLOu2lsbdy9CShftgcn_jN4otCiYlJf2FKSS9oxxIU=.826ae8f4-bac7-4a62-b6c1-9d6bff9d42bc@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
 <MfLOu2lsbdy9CShftgcn_jN4otCiYlJf2FKSS9oxxIU=.826ae8f4-bac7-4a62-b6c1-9d6bff9d42bc@github.com>
Message-ID: <WusRE5JNS1W2cZTvgrLbp-nOyFjTZI8WCcjqUMJIwbY=.b06a58b6-58d5-4c75-a01d-75bd17a794f8@github.com>

On Mon, 6 Jan 2020 04:32:34 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

>> Issue: Native part of WebView throws a DOMException and then, continues executing the rest of the function assuming that value is present. This causes the JVM to crash when retrieving the value.
>> 
>> Fix: Return from the function if exception was raised (code is similar to exception handling in [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp))
>> 
>> This fix also needs to be applied to all function calls in [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM) functions which raises DOMError similar to createAttributeImpl().
> 
> The pull request has been updated with 1 additional commit.

+1, Looks good to me.

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

Marked as reviewed by ghb (Reviewer).

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

From ghb at openjdk.java.net  Mon Jan  6 04:43:04 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Mon, 6 Jan 2020 04:43:04 GMT
Subject: RFR: 8234471: Canvas in webview displayed with wrong scale on
 Windows
In-Reply-To: <jTNfA1sy6_8Jdv8OrgcX1GtLw_lD_8s90_pP5_RTGTw=.73f3f734-3154-447f-8326-02c942807e5a@github.com>
References: <jTNfA1sy6_8Jdv8OrgcX1GtLw_lD_8s90_pP5_RTGTw=.73f3f734-3154-447f-8326-02c942807e5a@github.com>
Message-ID: <fXxs4h0T_9APEzvbTqQsdjUzYu5PtC3pmT6e-E1XsO8=.a5c8e184-a62b-45b9-a990-4dad702074fb@github.com>

On Mon, 9 Dec 2019 13:09:04 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to `pixelScale` values of 1.25, 1.5 and 1.75, respectively.
> 
> Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)`
> 
> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform`

have you tested this on Linux and Mac by changing JVM option -Dglass.win.uiScale=<Scale value>.

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

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

From abhinay_agarwal at live.com  Mon Jan  6 09:43:22 2020
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Mon, 6 Jan 2020 09:43:22 +0000
Subject: Maximized undecorated stage
Message-ID: <PS1PR03MB470070FB7C44A6BEDC65F39AE73C0@PS1PR03MB4700.apcprd03.prod.outlook.com>

Hi,

If maximize property is set to true for an undecorated Stage, the following behaviour is observed on different platforms:

  *   Windows: Undecorated stage is maximized
  *   MacOS: Undecorated stage is not maximized
  *   Linux(Ubuntu): Undecorated stage is not maximized

The following piece of code can be used to reproduce the behaviour:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
import javafx.stage.StageStyle;

public class MaximizedStage extends Application {
    public void start (Stage stage) {
        StackPane sp = new StackPane(new Label("Hello"));
        stage.setScene(new Scene (sp, 500, 500));
        stage.initStyle(StageStyle.UNDECORATED);
        stage.show();
        stage.setMaximized(true);
    }
}

 Is there a reason why the stage gets maximized on Windows but fails on other platforms?

Regards,
Abhinay

From kevin.rushforth at oracle.com  Mon Jan  6 14:05:52 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 6 Jan 2020 06:05:52 -0800
Subject: Linux Glass - WindowContextChild and WindowContextPlug
In-Reply-To: <CP2P15201MB2228942C58B316340C58FE1BDE200@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
References: <CP2P15201MB222861932AFEAE636E35F464DE260@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
 <CP2P15201MB2228942C58B316340C58FE1BDE200@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
Message-ID: <03d329fa-0764-a45a-f30e-e36157ee71c4@oracle.com>

This code was used for running Applets. Support for applets was removed 
in JDK 11, so the code is no longer relevant.

-- Kevin


On 1/2/2020 3:18 AM, Thiago Milczarek Sayao wrote:
> Ran all the robot test suite and those two classes are not touched.
>
> I suspect they are used for web-start.
>
> Are there any guides for running Ensemble on web-start? I guess I must use an old linux distro, that has old browser tech.
>
> Happy new year.
> ________________________________
> De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Thiago Milczarek Sayao <thiago.sayao at clamed.com.br>
> Enviado: ter?a-feira, 31 de dezembro de 2019 16:50
> Para: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
> Assunto: Linux Glass - WindowContextChild and WindowContextPlug
>
>
> Does anyone knows the context of use of WindowContextChild and WindowContextPlug on the linux glass implementation?
>
> File: glass_window.cpp
>
> They seem to be never called.
>
> Thanks.
>
>


From tsayao at openjdk.java.net  Mon Jan  6 14:06:48 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 6 Jan 2020 14:06:48 GMT
Subject: [Rev 03] RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <rL_XAw_c1dR7x5KSxFyFJxvXA8iXA-oX_ykrurRMkV4=.a55fe24c-3dcc-466d-b356-b11f7bcf9c03@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> Please, mark it as WIP. 
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 49426b66: Fix flickering and sizing issues

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/628d5528..49426b66

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

  Stats: 68 lines in 3 files changed: 4 ins; 54 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From tsayao at openjdk.java.net  Mon Jan  6 14:11:04 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 6 Jan 2020 14:11:04 GMT
Subject: RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>

On Mon, 6 Jan 2020 00:28:14 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> Please, mark it as **WIP**. 
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

There are still some sizing issues that I am aware of.

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

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

From kevin.rushforth at oracle.com  Mon Jan  6 14:23:21 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 6 Jan 2020 06:23:21 -0800
Subject: Linux Glass - WindowContextChild and WindowContextPlug
In-Reply-To: <03d329fa-0764-a45a-f30e-e36157ee71c4@oracle.com>
References: <CP2P15201MB222861932AFEAE636E35F464DE260@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
 <CP2P15201MB2228942C58B316340C58FE1BDE200@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
 <03d329fa-0764-a45a-f30e-e36157ee71c4@oracle.com>
Message-ID: <a39cf69b-f180-8f95-5959-2e1104ecaa9b@oracle.com>

Btw, there is already a cleanup issue filed to target the removal of the 
implementation code for applets:

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

-- Kevin


On 1/6/2020 6:05 AM, Kevin Rushforth wrote:
> This code was used for running Applets. Support for applets was 
> removed in JDK 11, so the code is no longer relevant.
>
> -- Kevin
>
>
> On 1/2/2020 3:18 AM, Thiago Milczarek Sayao wrote:
>> Ran all the robot test suite and those two classes are not touched.
>>
>> I suspect they are used for web-start.
>>
>> Are there any guides for running Ensemble on web-start? I guess I 
>> must use an old linux distro, that has old browser tech.
>>
>> Happy new year.
>> ________________________________
>> De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de 
>> Thiago Milczarek Sayao <thiago.sayao at clamed.com.br>
>> Enviado: ter?a-feira, 31 de dezembro de 2019 16:50
>> Para: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
>> Assunto: Linux Glass - WindowContextChild and WindowContextPlug
>>
>>
>> Does anyone knows the context of use of WindowContextChild and 
>> WindowContextPlug on the linux glass implementation?
>>
>> File: glass_window.cpp
>>
>> They seem to be never called.
>>
>> Thanks.
>>
>>
>


From kcr at openjdk.java.net  Mon Jan  6 14:25:35 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 14:25:35 GMT
Subject: RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
Message-ID: <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>

On Mon, 6 Jan 2020 14:10:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This proposed change does the following:
>> 
>> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
>> - Use gtk signals instead of gdk events (also to reduce code size);
>> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
>> - Replaces (pointer and focus) grabbing with a gtk approach;
>> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
>> - Simplified cursor changing;
>> - Reduced the use of gtk/gdk deprecated functions;
>> 
>> 
>> In general it reduces code size and complexity and hands more work to gtk.
>> 
>> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
>> 
>> Please, mark it as **WIP**. 
>> 
>> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)
> 
> There are still some sizing issues that I am aware of.

> Please, mark it as WIP.

You can do this by editing the title and adding `WIP: ` as a prefix.

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

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

From arapte at openjdk.java.net  Mon Jan  6 16:24:43 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 6 Jan 2020 16:24:43 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
Message-ID: <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>

On Mon, 6 Jan 2020 16:24:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR is a fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474), a crash in the code that shows a file open or save dialog.
>> 
>> In order to provide additional support for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V), the Glass implementation for displaying a file open or save dialog subclasses NSSavePanel or NSOpenPanel to add this support. When the application is running in sandboxed mode, the dialogs are shown out-of-process by the "powerbox". In this mode, attempting to use our subclass results in a security exception. Previously, we added code to detect whether we were running in a sandbox as a fix for [JDK-8092977](https://bugs.openjdk.java.net/browse/JDK-8092977); we now use NSSavePanel or NSOpenPanel directly when in sandboxed mode.
>> 
>> Starting with macOS 10.15 (Catalina) Apple always displays file dialogs out-of-process via powerbox, so our use of a subclass is ineffective. Further, we have reports of some cases where we crash even though our sandbox detection code doesn't indicate that we are running in a sandbox.
>> 
>> Since there is no point in trying to use our subclasses on macOS 10.15 or later, I propose to fix this bug by changing the logic so that we use NSSavePanel or NSOpenPanel directly in either of the following conditions:
>> 
>> 1) the app is running in sandbox mode
>> OR
>> 2) The platform is macOS 10.15 or later
> 
> The pull request has been updated with 1 additional commit.

Looks good to me, Verified that all tests pass on Mojave 10.14.6

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

Marked as reviewed by arapte (Reviewer).

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

From prr at openjdk.java.net  Mon Jan  6 17:12:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Jan 2020 17:12:55 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
Message-ID: <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>

On Mon, 6 Jan 2020 16:24:33 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Looks good to me, Verified that all tests pass on Mojave 10.14.6

Based on my reading of https://bugs.openjdk.java.net/browse/JDK-8092977, this means the support for edit operations in these dialogs is on its way out ... now supportable only in non-sandboxed apps on the older macOS releases. Is there a serious practical consequence of this, or was the editing just a convenience ? There must have been some resason we went to the trouble. However based on this being "on its way out" why try to prolong it ? Just drop the subclasses now.

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

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

From kcr at openjdk.java.net  Mon Jan  6 17:35:25 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 17:35:25 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
 <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
Message-ID: <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>

On Mon, 6 Jan 2020 17:12:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> Looks good to me, Verified that all tests pass on Mojave 10.14.6
> 
> Based on my reading of https://bugs.openjdk.java.net/browse/JDK-8092977, this means the support for edit operations in these dialogs is on its way out ... now supportable only in non-sandboxed apps on the older macOS releases. Is there a serious practical consequence of this, or was the editing just a convenience ? There must have been some resason we went to the trouble. However based on this being "on its way out" why try to prolong it ? Just drop the subclasses now.

This was just added as a convenience, so it isn't critical functionality.

Having said that, while we could just drop the subclasses now, it would cause a perceived regression in behavior for users running on macOS 10.14 Mojave. So my preference would be to not remove the subclass at this time, but to just not use them when running on 10.15 or later.

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

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

From prr at openjdk.java.net  Mon Jan  6 17:44:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Jan 2020 17:44:55 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
 <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
 <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>
Message-ID: <2HBoid-2b30X-C8V3MJSNswzRa2fKH0APIFjoxOqWtQ=.59936c8b-920a-4838-aed0-f1d04c5aadf3@github.com>

On Mon, 6 Jan 2020 17:35:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Based on my reading of https://bugs.openjdk.java.net/browse/JDK-8092977, this means the support for edit operations in these dialogs is on its way out ... now supportable only in non-sandboxed apps on the older macOS releases. Is there a serious practical consequence of this, or was the editing just a convenience ? There must have been some resason we went to the trouble. However based on this being "on its way out" why try to prolong it ? Just drop the subclasses now.
> 
> This was just added as a convenience, so it isn't critical functionality.
> 
> Having said that, while we could just drop the subclasses now, it would cause a perceived regression in behavior for users running on macOS 10.14 Mojave. So my preference would be to not remove the subclass at this time, but to just not use them when running on 10.15 or later.

Well then you'll just have to come back to it. If its not critical I'd remove it now so that FX 15 (or is this for 14 ?) behaves consistently

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

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

From kcr at openjdk.java.net  Mon Jan  6 18:11:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 18:11:46 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <2HBoid-2b30X-C8V3MJSNswzRa2fKH0APIFjoxOqWtQ=.59936c8b-920a-4838-aed0-f1d04c5aadf3@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
 <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
 <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>
 <2HBoid-2b30X-C8V3MJSNswzRa2fKH0APIFjoxOqWtQ=.59936c8b-920a-4838-aed0-f1d04c5aadf3@github.com>
Message-ID: <k_ZmFmRjLkS75KCsvRDpitZrLBIo-LApVx90hZrGW2E=.b163bd11-1c05-4287-af66-42c23d35d754@github.com>

On Mon, 6 Jan 2020 17:44:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> This was just added as a convenience, so it isn't critical functionality.
>> 
>> Having said that, while we could just drop the subclasses now, it would cause a perceived regression in behavior for users running on macOS 10.14 Mojave. So my preference would be to not remove the subclass at this time, but to just not use them when running on 10.15 or later.
> 
> Well then you'll just have to come back to it. If its not critical I'd remove it now so that FX 15 (or is this for 14 ?) behaves consistently

This is targeted for JavaFX 14, which is another reason to go with a more targeted (safer) fix, since we are almost at RDP1. For JavaFX 15 it does seem best to just remove the functionality entirely.

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

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

From prr at openjdk.java.net  Mon Jan  6 18:20:05 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Jan 2020 18:20:05 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <k_ZmFmRjLkS75KCsvRDpitZrLBIo-LApVx90hZrGW2E=.b163bd11-1c05-4287-af66-42c23d35d754@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
 <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
 <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>
 <2HBoid-2b30X-C8V3MJSNswzRa2fKH0APIFjoxOqWtQ=.59936c8b-920a-4838-aed0-f1d04c5aadf3@github.com>
 <k_ZmFmRjLkS75KCsvRDpitZrLBIo-LApVx90hZrGW2E=.b163bd11-1c05-4287-af66-42c23d35d754@github.com>
Message-ID: <w0fDnFLShV7AxMkPwNx5qhwXBcWXUSKYo59m0abcirk=.64c5ddba-b333-42d1-846d-0b9efd243e59@github.com>

On Mon, 6 Jan 2020 18:11:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Well then you'll just have to come back to it. If its not critical I'd remove it now so that FX 15 (or is this for 14 ?) behaves consistently
> 
> This is targeted for JavaFX 14, which is another reason to go with a more targeted (safer) fix, since we are almost at RDP1. For JavaFX 15 it does seem best to just remove the functionality entirely.

Ok, fair enough for 14 ...

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

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

From kcr at openjdk.java.net  Mon Jan  6 18:21:25 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 18:21:25 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <w0fDnFLShV7AxMkPwNx5qhwXBcWXUSKYo59m0abcirk=.64c5ddba-b333-42d1-846d-0b9efd243e59@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
 <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
 <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>
 <2HBoid-2b30X-C8V3MJSNswzRa2fKH0APIFjoxOqWtQ=.59936c8b-920a-4838-aed0-f1d04c5aadf3@github.com>
 <k_ZmFmRjLkS75KCsvRDpitZrLBIo-LApVx90hZrGW2E=.b163bd11-1c05-4287-af66-42c23d35d754@github.com>
 <w0fDnFLShV7AxMkPwNx5qhwXBcWXUSKYo59m0abcirk=.64c5ddba-b333-42d1-846d-0b9efd243e59@github.com>
Message-ID: <F_Vk42mFy4ey6AgWk0POQRNsnt7uiCG1FySIVbV5FW0=.cc41ea6d-66d8-4be2-ba1a-8039d7323152@github.com>

On Mon, 6 Jan 2020 18:19:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is targeted for JavaFX 14, which is another reason to go with a more targeted (safer) fix, since we are almost at RDP1. For JavaFX 15 it does seem best to just remove the functionality entirely.
> 
> Ok, fair enough for 14 ...

I'll file a follow-up bug for 15 shortly.

@prrace would you be willing to be the second reviewer on this fix?

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

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

From kcr at openjdk.java.net  Mon Jan  6 18:31:35 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 18:31:35 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <F_Vk42mFy4ey6AgWk0POQRNsnt7uiCG1FySIVbV5FW0=.cc41ea6d-66d8-4be2-ba1a-8039d7323152@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
 <L0j5rIKEXadEG3zjGxcJgp47rx25e2NnVJnmFA5k43A=.cbd98583-6955-4960-9f5b-fed281c3203f@github.com>
 <ttxOTk_ApIDAjUOTksPibX-1pxwy1DQQ1EDnw1Hlxd0=.12fa41a0-3144-42fc-888b-7f4202e4003e@github.com>
 <v7dfeSQdSLHU1Q_rN-CvJ9wSy97H7OuPBO_yfMHzZLE=.fed47e23-8251-4b33-a015-7783f6e3f65d@github.com>
 <2HBoid-2b30X-C8V3MJSNswzRa2fKH0APIFjoxOqWtQ=.59936c8b-920a-4838-aed0-f1d04c5aadf3@github.com>
 <k_ZmFmRjLkS75KCsvRDpitZrLBIo-LApVx90hZrGW2E=.b163bd11-1c05-4287-af66-42c23d35d754@github.com>
 <w0fDnFLShV7AxMkPwNx5qhwXBcWXUSKYo59m0abcirk=.64c5ddba-b333-42d1-846d-0b9efd243e59@github.com>
 <F_Vk42mFy4ey6AgWk0POQRNsnt7uiCG1FySIVbV5FW0=.cc41ea6d-66d8-4be2-ba1a-8039d7323152@github.com>
Message-ID: <n-_M_zoWk0KFxCS_bsis-4X6AF7TggyhDmfaqEEABRU=.c079d3e5-adf2-43c1-844f-f0086b840a78@github.com>

On Mon, 6 Jan 2020 18:21:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ok, fair enough for 14 ...
> 
> I'll file a follow-up bug for 15 shortly.
> 
> @prrace would you be willing to be the second reviewer on this fix?

I filed [JDK-8236685](https://bugs.openjdk.java.net/browse/JDK-8236685) to remove the custom dialogs in JavaFX 15.

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

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

From projects at saring.de  Mon Jan  6 19:28:32 2020
From: projects at saring.de (projects at saring.de)
Date: Mon, 6 Jan 2020 20:28:32 +0100
Subject: Broken text rendering in macOS Catalina
Message-ID: <DF5F1A90-9E47-43D2-82C7-D52DF693B697@saring.de>

Hi,

I've tried to report this JavaFX problem to the OpenJDK project ( https://bugreport.java.com/bugreport/ ), unfortunately I don?t have an account there. And the report of me as a guest wasn?t accepted. That?s why I?m trying to use this mailing list.

Bug description: 

Since updating to macOS Catalina the text rendering is broken in all JavaFX contrals which render text (labels, text areas, buttons, menu items etc.). This behavior is new since macOS 10.15 Catalina, it worked perfectly in macOS 10.14.x and before.
The rendered text is still readable, but looks very blurred. And it looks like vertical pixel lines are completely missing in the displayed text.

This error occurs when using a non-Retina (HiDPI) display, e.g. a MacBook Air with the 1440x900 resolution or an external typical FullHD display (e.g. 24" 1920x1080). Only when using a HiDPI / Retina display, then the rendered text looks fine. Unfortunately many / most people are still using non-Retina external displays.

Test environment:

* OS: macOS 10.15.2
* Java: OpenJDK 11.0.5 (AdaptOpenJDK), OpenJDK 13.0.1 (AdoptOpenJDK), OpenJDK 14 EA Build 28 (2019/12/18)
* JavaFX: OpenJFX 11.0.2, OpenJFX 13.0.1, OpenJFX 14-ea+6
* Display: Dell 24" 1920x1200, MacBook Air (2013) 1440x900

The same problem exists in all combinations.

How to reproduce (example):

* Install and launch SceneBuilder (tested with 11.0.0 from https://gluonhq.com/products/scene-builder/ )
* Open an FXML file or create a new one
* Display Info dialog (Help > About Scene Builder)

Screenshots of the About Dialog:

* NonRetina (broken): https://www.saring.de/openjfx-bugreport/SceneBuilder_About-NonRetina.png <https://www.saring.de/openjfx-bugreport/SceneBuilder_About-NonRetina.png>
  (e.g. in line ?The default configuration") 
* Retina (OK): https://www.saring.de/openjfx-bugreport/SceneBuilder_About-Retina.png <https://www.saring.de/openjfx-bugreport/SceneBuilder_About-Retina.png> 

Best regards,
Stefan

From kcr at openjdk.java.net  Mon Jan  6 19:39:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 19:39:16 GMT
Subject: [Integrated] RFR: 8130738: TextFlow's tab width is static
In-Reply-To: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
Message-ID: <4cc9c958-cec6-4add-8aeb-4fb733837366@openjdk.org>

Changeset: 8367e1a6
Author:    Scott Palmer <swpalmer at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2019-12-31 18:34:33 +0000
URL:       https://git.openjdk.java.net/jfx/commit/8367e1a6

8130738: Add tabSize property to Text and TextFlow

Reviewed-by: prr, kcr

! modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html
! modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java
! modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java
! modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java
! modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
! modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubTextLayout.java
+ modules/javafx.graphics/src/test/java/test/javafx/scene/text/TextFlowTest.java
! modules/javafx.graphics/src/test/java/test/javafx/scene/text/TextTest.java
! modules/javafx.graphics/src/test/java/test/javafx/scene/text/Text_cssMethods_Test.java

From jvos at openjdk.java.net  Mon Jan  6 19:39:18 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Mon, 6 Jan 2020 19:39:18 GMT
Subject: [Integrated] RFR: 8236484: Compile error in monocle dispman
In-Reply-To: <apzKeEAtPEmQqIyv0Whr0wX9VWGsUdFngRvCdhCHnhQ=.e753f03e-9c5a-4a2e-bfe7-28e910b39861@github.com>
References: <apzKeEAtPEmQqIyv0Whr0wX9VWGsUdFngRvCdhCHnhQ=.e753f03e-9c5a-4a2e-bfe7-28e910b39861@github.com>
Message-ID: <aa147a9a-07c9-47a4-bf6e-14e05ebd4cbd@openjdk.org>

Changeset: 4c6ebfb4
Author:    Johan Vos <jvos at openjdk.org>
Date:      2020-01-01 19:15:09 +0000
URL:       https://git.openjdk.java.net/jfx/commit/4c6ebfb4

8236484: Compile error in monocle dispman

Reviewed-by: kcr

! modules/javafx.graphics/src/main/native-glass/monocle/dispman/DispmanScreen.c

From kcr at openjdk.java.net  Mon Jan  6 19:39:24 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 19:39:24 GMT
Subject: [Integrated] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
Message-ID: <513d4f3e-7101-45f1-b30b-144c11d0f5c1@openjdk.org>

Changeset: 1952606a
Author:    Thiago Milczarek Sayao <tsayao at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-02 17:01:13 +0000
URL:       https://git.openjdk.java.net/jfx/commit/1952606a

8232811: Dialog's preferred size no longer accommodates multi-line strings

Reviewed-by: kcr, arapte

! modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp
+ tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java

From kcr at openjdk.java.net  Mon Jan  6 19:39:29 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 19:39:29 GMT
Subject: [Integrated] RFR: 8236626: Update copyright header for files
 modified in 2019
In-Reply-To: <AHAEhmsgnn_vIteJp_wGLp2yNc13RkoGPfbLV8m46m8=.3bcf0bd6-55e8-4685-a9a5-12c5e3cce8a3@github.com>
References: <AHAEhmsgnn_vIteJp_wGLp2yNc13RkoGPfbLV8m46m8=.3bcf0bd6-55e8-4685-a9a5-12c5e3cce8a3@github.com>
Message-ID: <590eb433-5c16-4896-ae34-a0c2c9975b27@openjdk.org>

Changeset: 3c4d68dc
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-03 13:04:04 +0000
URL:       https://git.openjdk.java.net/jfx/commit/3c4d68dc

8236626: Update copyright header for files modified in 2019

Reviewed-by: arapte

! modules/javafx.graphics/src/test/java/test/javafx/scene/text/Text_cssMethods_Test.java

From swpalmer at openjdk.java.net  Mon Jan  6 19:42:55 2020
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Mon, 6 Jan 2020 19:42:55 GMT
Subject: RFR: 8236648: javadoc warning on Text::tabSizeProperty method
Message-ID: <8vO-u43ZDM6ru_aowjZntkXsVafe6BijW2fufIdidqU=.23a4a27f-589e-42fe-8e5e-51e630d9f468@github.com>

Implemented suggested fix to address javadoc warning.

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

Commits:
 - bd81a902: 8236648: javadoc warning on Text::tabSizeProperty method

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

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

From kevin.rushforth at oracle.com  Mon Jan  6 20:05:41 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 6 Jan 2020 12:05:41 -0800
Subject: Broken text rendering in macOS Catalina
In-Reply-To: <DF5F1A90-9E47-43D2-82C7-D52DF693B697@saring.de>
References: <DF5F1A90-9E47-43D2-82C7-D52DF693B697@saring.de>
Message-ID: <96bfa4fe-ba71-e458-0aaa-56dede72b04f@oracle.com>

Your bug report was successfully logged into our system for triaging by 
our incident team. Normally, the bugs are processed quickly and 
transferred into the JDK project within a couple of days. The delay is 
due to the holidays. I have transferred that one manually to the JDK 
project as:

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

I can add the additional pointers to the screenshots you provided below 
to the bug report.

-- Kevin


On 1/6/2020 11:28 AM, projects at saring.de wrote:
> Hi,
>
> I've tried to report this JavaFX problem to the OpenJDK project ( https://bugreport.java.com/bugreport/ ), unfortunately I don?t have an account there. And the report of me as a guest wasn?t accepted. That?s why I?m trying to use this mailing list.
>
> Bug description:
>
> Since updating to macOS Catalina the text rendering is broken in all JavaFX contrals which render text (labels, text areas, buttons, menu items etc.). This behavior is new since macOS 10.15 Catalina, it worked perfectly in macOS 10.14.x and before.
> The rendered text is still readable, but looks very blurred. And it looks like vertical pixel lines are completely missing in the displayed text.
>
> This error occurs when using a non-Retina (HiDPI) display, e.g. a MacBook Air with the 1440x900 resolution or an external typical FullHD display (e.g. 24" 1920x1080). Only when using a HiDPI / Retina display, then the rendered text looks fine. Unfortunately many / most people are still using non-Retina external displays.
>
> Test environment:
>
> * OS: macOS 10.15.2
> * Java: OpenJDK 11.0.5 (AdaptOpenJDK), OpenJDK 13.0.1 (AdoptOpenJDK), OpenJDK 14 EA Build 28 (2019/12/18)
> * JavaFX: OpenJFX 11.0.2, OpenJFX 13.0.1, OpenJFX 14-ea+6
> * Display: Dell 24" 1920x1200, MacBook Air (2013) 1440x900
>
> The same problem exists in all combinations.
>
> How to reproduce (example):
>
> * Install and launch SceneBuilder (tested with 11.0.0 from https://gluonhq.com/products/scene-builder/ )
> * Open an FXML file or create a new one
> * Display Info dialog (Help > About Scene Builder)
>
> Screenshots of the About Dialog:
>
> * NonRetina (broken): https://www.saring.de/openjfx-bugreport/SceneBuilder_About-NonRetina.png <https://www.saring.de/openjfx-bugreport/SceneBuilder_About-NonRetina.png>
>    (e.g. in line ?The default configuration")
> * Retina (OK): https://www.saring.de/openjfx-bugreport/SceneBuilder_About-Retina.png <https://www.saring.de/openjfx-bugreport/SceneBuilder_About-Retina.png>
>
> Best regards,
> Stefan


From kcr at openjdk.java.net  Mon Jan  6 20:59:31 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 20:59:31 GMT
Subject: [Integrated] RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
Message-ID: <db6a33b5-778a-460d-9bc5-d33be7ba3947@openjdk.org>

Changeset: f1108b0a
Author:    Arun Joseph <ajoseph at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-06 20:58:28 +0000
URL:       https://git.openjdk.java.net/jfx/commit/f1108b0a

8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

Reviewed-by: kcr, ghb

! modules/javafx.web/src/main/native/Source/WebCore/bindings/java/JavaDOMUtils.h
! modules/javafx.web/src/test/java/test/javafx/scene/web/DOMTest.java

From prr at openjdk.java.net  Mon Jan  6 21:01:26 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Jan 2020 21:01:26 GMT
Subject: [Rev 01] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
 <IUO2dVsxFr2U8t3OEE0nyOcU8PAW40VMUmVNb8-osKo=.a5e11f82-7c32-4b63-98c9-13e37181bd93@github.com>
Message-ID: <qOLNokoThXIuxv7K7tAfbqXx68lbcQ2f-qqg_gYwg2I=.8cbd6c53-e161-48db-9f0e-4726dc1bb682@github.com>

On Mon, 6 Jan 2020 21:01:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR is a fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474), a crash in the code that shows a file open or save dialog.
>> 
>> In order to provide additional support for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V), the Glass implementation for displaying a file open or save dialog subclasses NSSavePanel or NSOpenPanel to add this support. When the application is running in sandboxed mode, the dialogs are shown out-of-process by the "powerbox". In this mode, attempting to use our subclass results in a security exception. Previously, we added code to detect whether we were running in a sandbox as a fix for [JDK-8092977](https://bugs.openjdk.java.net/browse/JDK-8092977); we now use NSSavePanel or NSOpenPanel directly when in sandboxed mode.
>> 
>> Starting with macOS 10.15 (Catalina) Apple always displays file dialogs out-of-process via powerbox, so our use of a subclass is ineffective. Further, we have reports of some cases where we crash even though our sandbox detection code doesn't indicate that we are running in a sandbox.
>> 
>> Since there is no point in trying to use our subclasses on macOS 10.15 or later, I propose to fix this bug by changing the logic so that we use NSSavePanel or NSOpenPanel directly in either of the following conditions:
>> 
>> 1) the app is running in sandbox mode
>> OR
>> 2) The platform is macOS 10.15 or later
> 
> The pull request has been updated with 1 additional commit.



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

Marked as reviewed by prr (Reviewer).

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

From kcr at openjdk.java.net  Mon Jan  6 21:12:29 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 21:12:29 GMT
Subject: [Integrated] RFR: 8234474: [macos 10.15] Crash in file dialog in
 sandbox mode
In-Reply-To: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
Message-ID: <f3b79518-5539-447c-8cff-3f6ec28453d7@openjdk.org>

Changeset: 587f195c
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-06 21:11:20 +0000
URL:       https://git.openjdk.java.net/jfx/commit/587f195c

8234474: [macos 10.15] Crash in file dialog in sandbox mode

Reviewed-by: arapte, prr

! modules/javafx.graphics/src/main/native-glass/mac/GlassDialogs.m

From kevin.rushforth at oracle.com  Mon Jan  6 21:17:37 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 6 Jan 2020 13:17:37 -0800
Subject: Pending Skara notifications, JBS updates for recent fixes
In-Reply-To: <118d678c-14eb-f35c-87f4-7f04539857e7@oracle.com>
References: <118d678c-14eb-f35c-87f4-7f04539857e7@oracle.com>
Message-ID: <f689ea38-0bca-5e7a-7f38-1d6af3597127@oracle.com>

This is now fixed. The Skara bot successfully processed the backlog and 
resolved all of the issues in question.

-- Kevin


On 1/2/2020 9:12 AM, Kevin Rushforth wrote:
> The Skara commit notifications and JBS issue updates for the following 
> recently-integrated bugs are still pending:
>
> https://bugs.openjdk.java.net/browse/JDK-8130738
> https://bugs.openjdk.java.net/browse/JDK-8236484
> https://bugs.openjdk.java.net/browse/JDK-8232811
> https://bugs.openjdk.java.net/browse/JDK-8225571
>
> The reason for the delay is a problem accessing JBS from the Skara 
> bot. It should be sorted out soon. In the mean time, I've added a 
> label and a comment to each bug so we can track them, but I left them 
> open to see whether the Skara bot will catch back up once access is 
> restored (it should do). I'll do the same to any other bugs that are 
> resolved prior to fixing the issue.
>
> -- Kevin
>


From kcr at openjdk.java.net  Mon Jan  6 21:57:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 21:57:15 GMT
Subject: RFR: 8236648: javadoc warning on Text::tabSizeProperty method
In-Reply-To: <8vO-u43ZDM6ru_aowjZntkXsVafe6BijW2fufIdidqU=.23a4a27f-589e-42fe-8e5e-51e630d9f468@github.com>
References: <8vO-u43ZDM6ru_aowjZntkXsVafe6BijW2fufIdidqU=.23a4a27f-589e-42fe-8e5e-51e630d9f468@github.com>
Message-ID: <RRYzsMGk0yXeBZVJrse9028RndJRavoqA2WAG0yBpOk=.eeceea31-0098-47be-b127-255936edf641@github.com>

On Mon, 6 Jan 2020 19:27:01 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

> Implemented suggested fix to address javadoc warning.

Looks good. This is a low-impact change so one reviewer will suffice.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Mon Jan  6 22:41:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 22:41:15 GMT
Subject: RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
 <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
Message-ID: <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>

On Mon, 6 Jan 2020 14:25:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> There are still some sizing issues that I am aware of.
> 
>> Please, mark it as WIP.
> 
> You can do this by editing the title and adding `WIP: ` as a prefix.

This sort of enhancement needs to be discussed on the openjfx-dev mailing list first. While the WIP PR might be used to illustrate what you have in mind to propose, it is premature to actually review the implementation without first discussing whether and it makes sense to do it, what the high-level goals are, etc.

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

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

From tsayao at openjdk.java.net  Mon Jan  6 22:57:46 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 6 Jan 2020 22:57:46 GMT
Subject: RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
 <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
 <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>
Message-ID: <RTNlL4YgDTkU1J2hxEldvHgLAHAYTBNcAR4OdIGS9vI=.b219fd7a-1f0a-4bcb-9d31-8b2b8b18bc15@github.com>

On Mon, 6 Jan 2020 22:41:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> Please, mark it as WIP.
>> 
>> You can do this by editing the title and adding `WIP: ` as a prefix.
> 
> This sort of enhancement needs to be discussed on the openjfx-dev mailing list first. While the WIP PR might be used to illustrate what you have in mind to propose, it is premature to actually review the implementation without first discussing whether and it makes sense to do it, what the high-level goals are, etc.

I understand. Will do that when everything is 100%.

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

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

From kcr at openjdk.java.net  Mon Jan  6 23:05:26 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 23:05:26 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <xFY1R-O53_xFrJnVfvJdRFvMSTo7e3XxP02zZjGFvvM=.78597514-fb80-454b-a7ce-4e336e7bcc1f@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
 <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
 <iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyO
 Qx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com>
 <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com>
 <xFY1R-O53_xFrJnVfvJdRFvMSTo7e3XxP02zZjGFvvM=.78597514-fb80-454b-a7ce-4e336e7bcc1f@github.com>
Message-ID: <OHR6_mbjOrYOmmJO53Q84ND9MsZvobdX7Di0EDeqS7E=.d86ff800-fe6c-4f50-9409-018620e1ef3c@github.com>

On Fri, 20 Dec 2019 13:26:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I highly doubt that a code analysis tool will find such memoryleaks.
> 
> I agree. Static analysis tools are quite limited in this regard, and are in now way a substitute for regression testing.
> 
> So the question is how best to test fixes for memory leaks at runtime. Our current approach can be best characterized as "ad hoc", and is not all that robust (although works well enough in most cases and is still much better than doing no testing at all). I would welcome discussion of a more robust approach for testing, but it should be decoupled from this bug fix, and discussed as a separate JBS Enhancement request.

The use of static analysis tools to catch certain types of problems is orthogonal to a regression test to validate a bug fix of a specific memory leak.

@FlorianKirmaier as mentioned previously, please file a new JBS Enhancement to propose adding a test utility for memory leak test. You can then start a discussion on the openjfx-dev mailing list.

As for fixing this memory leak, I recommend one of the following two approaches:
1. Modify the PR without relying on any new utilities (meaning you would create yet-another adhoc test for memory leaks).
2. Close this PR, wait for memory leak test utility to be integrated, and then resubmit the PR for this leak using that utility.

Obviously, approach 1 would get the fix in faster. You could then modify the test to use the new utility as part of implementing the utility.

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

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

From almatvee at openjdk.java.net  Mon Jan  6 23:21:45 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 6 Jan 2020 23:21:45 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <CA37tnaZSQpugCKNGIX6OhKGlo3lMMeDyABbg0um79o=.e14617b6-754a-4bb8-bd6f-04aaf8e69e92@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
 <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
 <CA37tnaZSQpugCKNGIX6OhKGlo3lMMeDyABbg0um79o=.e14617b6-754a-4bb8-bd6f-04aaf8e69e92@github.com>
Message-ID: <Iu5nWhqeNBm4msdBktLz7D5Y0-pku0ALA-ObBQfl9kA=.3722f8e6-3bbd-40f6-b48b-da96539825e1@github.com>

On Wed, 1 Jan 2020 19:16:33 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/spectrum/gstspectrum.c line 915:
>> 
>>> 914:   bpf = GST_AUDIO_FILTER_BPF (spectrum);
>>> 915: #ifdef OSX
>>> 916:   if (spectrum->bps_user != 0 && spectrum->bpf_user != 0) {
>> 
>> Should this also be qualified with `GSTREAMER_LITE` since it represents changes specific to our port?
> 
> true, as spectrum->bps_user has #if defined (GSTREAMER_LITE) && defined (OSX) around its definition.
> 
> Even apart from that, it would make more sense and bring it at the same level as line 738

No need for GSTREAMER_LITE, since this code already inside #ifdef GSTREAMER_LITE. See line 885 and 925.

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

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

From kevin.rushforth at oracle.com  Mon Jan  6 23:26:03 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 6 Jan 2020 15:26:03 -0800
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
 <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
 <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
Message-ID: <c438a7f3-14bf-a545-f91f-4e4fbd2d159a@oracle.com>

This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1) 
on January 9, 2020 at 23:59 Pacific time.

Any change integrated to the default 'master' branch after that will be 
for JavaFX 15. I will fork a new 'jfx14' stabilization branch early 
Friday morning (Pacific time). As with previous releases, P1-P3 bug 
fixes, and test or documentation fixes of any priority can still get 
into JavaFX 14 during RDP1. I'll send out more details Friday morning.

-- Kevin


On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
> The announced RDP1 date is the first Monday of the new year. In taking 
> a closer look at the upcoming holiday schedule and accounting for 
> additional days off some will be taking before or after, this doesn't 
> allow enough time for the final stages of the review process to 
> complete, including CSR approval. It is quite possible that an 
> enhancement with a mostly-completed review and a CSR that is Finalized 
> this Thursday or Friday (Dec 19 or 20), won't be approved in time for 
> integration.
>
> To address this, we are delaying RDP1 by three days. The new RDP1 date 
> is:
>
> Thursday, Jan 9, 23:59 PST
>
> The dates for RDP2, code freeze, and GA are unchanged.
>
> Please be aware that this three-day extension isn't an invitation to 
> try to get additional features into 14 at the last minute, but rather 
> an adjustment to better align with the holiday schedule in order to 
> give the already-in-flight features that are nearing completion a 
> little more time to make it. It is still the case that if an 
> enhancement isn't ready (meaning API discussed & approved, code review 
> mostly done, and CSR finalized) by this Friday, it should be 
> retargeted to JavaFX 15.
>
> -- Kevin
>
>
> On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
>> As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59 
>> Pacific time).
>>
>> With the holidays approaching, please allow sufficient time for any 
>> feature that needs a CSR. New features should be far enough along in 
>> the review process so you can finalize the CSR before next Friday, 
>> Dec 20, or it is likely to miss the window for this release, in which 
>> case it can be targeted for JavaFX 15.
>>
>> During rampdown of JavaFX 14, the "master" branch of the jfx repo 
>> will be open for JavaFX 15 fixes.
>>
>> We will follow the same process as previous releases for getting 
>> fixes into JavaFX 14 during rampdown. I'll send a message with 
>> detailed information later, but generally candidates for fixing after 
>> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc 
>> bugs of any priority.
>>
>> -- Kevin
>>
>>
>> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>>> Here is the proposed schedule for JavaFX 14.
>>>
>>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>>> RDP2: Feb 3, 2020
>>> Freeze: Feb 24, 2020
>>> GA: March 10, 2020
>>>
>>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is 
>>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>>
>>> Please let Johan or me know if you have any questions.
>>>
>>> -- Kevin
>>>
>>
>


From kcr at openjdk.java.net  Mon Jan  6 23:28:30 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 23:28:30 GMT
Subject: [Integrated] RFR: 8236648: javadoc warning on
 Text::tabSizeProperty method
In-Reply-To: <8vO-u43ZDM6ru_aowjZntkXsVafe6BijW2fufIdidqU=.23a4a27f-589e-42fe-8e5e-51e630d9f468@github.com>
References: <8vO-u43ZDM6ru_aowjZntkXsVafe6BijW2fufIdidqU=.23a4a27f-589e-42fe-8e5e-51e630d9f468@github.com>
Message-ID: <584444c7-7e54-48ba-8a87-0a37972aad80@openjdk.org>

Changeset: e0b45f8d
Author:    Scott Palmer <swpalmer at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-06 23:27:43 +0000
URL:       https://git.openjdk.java.net/jfx/commit/e0b45f8d

8236648: javadoc warning on Text::tabSizeProperty method

Reviewed-by: kcr

! modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java

From almatvee at openjdk.java.net  Mon Jan  6 23:37:06 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 6 Jan 2020 23:37:06 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
 <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
Message-ID: <alHOm8Hb1yYp5CDjSx7e7xolnfS3DlY0z0SXTXAB3Q0=.2439112f-9f05-49e6-9c61-6865ebadba07@github.com>

On Fri, 20 Dec 2019 22:24:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232589
>> 
>> - Removed CoreAudio Utility classes.
>> - Spectrum which was depended on CoreAudio Utility classes for doing computations will now run GStreamer spectrum element to do spectrum. Element will be run without pipeline and will be used as utility library to do spectrum calculation. I added extra APIs to bypass proper element initialization.
>> - Equalizer and audio unit (volume and balance) where modified, so we can run then directly without CoreAudio pipeline.
> 
> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp line 422:
> 
>> 421:             mEQBufferA = (double*)calloc(mEQBufferSize, sizeof(double));
>> 422:             mEQBufferB = (double*)calloc(mEQBufferSize, sizeof(double));
>> 423:         }
> 
> This is allocating 8 times (i.e., `sizeof(double)`) as much memory as before. I presume this is intentional?

No, it is allocating same amount of memory as before, unless I am missing something.
We used to have CAAutoFree<double> mEQBufferA and
CAAutoFree.alloc(size_t numItems) method allocates (numItems * sizeof(T)) bytes. See deleted CAAutoDisposer.h for CAAutoFree class implementation.

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

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

From kcr at openjdk.java.net  Mon Jan  6 23:50:45 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 23:50:45 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <Iu5nWhqeNBm4msdBktLz7D5Y0-pku0ALA-ObBQfl9kA=.3722f8e6-3bbd-40f6-b48b-da96539825e1@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
 <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
 <CA37tnaZSQpugCKNGIX6OhKGlo3lMMeDyABbg0um79o=.e14617b6-754a-4bb8-bd6f-04aaf8e69e92@github.com>
 <Iu5nWhqeNBm4msdBktLz7D5Y0-pku0ALA-ObBQfl9kA=.3722f8e6-3bbd-40f6-b48b-da96539825e1@github.com>
Message-ID: <B48sQsAEi-PJ7EurcklB8BC7qPSMfgOHKHq7UQS8GIg=.83b74b7e-51eb-4a9b-b63a-03acd7cba315@github.com>

On Mon, 6 Jan 2020 23:21:32 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> true, as spectrum->bps_user has #if defined (GSTREAMER_LITE) && defined (OSX) around its definition.
>> 
>> Even apart from that, it would make more sense and bring it at the same level as line 738
> 
> No need for GSTREAMER_LITE, since this code already inside #ifdef GSTREAMER_LITE. See line 885 and 925.

Yes, I see.

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

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

From kcr at openjdk.java.net  Mon Jan  6 23:50:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 23:50:46 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <alHOm8Hb1yYp5CDjSx7e7xolnfS3DlY0z0SXTXAB3Q0=.2439112f-9f05-49e6-9c61-6865ebadba07@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
 <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>
 <alHOm8Hb1yYp5CDjSx7e7xolnfS3DlY0z0SXTXAB3Q0=.2439112f-9f05-49e6-9c61-6865ebadba07@github.com>
Message-ID: <yB6WSJHEv8ZF2_FKu4ow5AVVMMcihv3oOsNc-tEDS3k=.994e5caa-cab8-489b-a398-04fd1caaf589@github.com>

On Mon, 6 Jan 2020 23:36:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp line 422:
>> 
>>> 421:             mEQBufferA = (double*)calloc(mEQBufferSize, sizeof(double));
>>> 422:             mEQBufferB = (double*)calloc(mEQBufferSize, sizeof(double));
>>> 423:         }
>> 
>> This is allocating 8 times (i.e., `sizeof(double)`) as much memory as before. I presume this is intentional?
> 
> No, it is allocating same amount of memory as before, unless I am missing something.
> We used to have CAAutoFree<double> mEQBufferA and
> CAAutoFree.alloc(size_t numItems) method allocates (numItems * sizeof(T)) bytes. See deleted CAAutoDisposer.h for CAAutoFree class implementation.

Yes, you're right. I missed that the previous `alloc` call was a method call on a CAAutoFree object, which does exactly what you said above. The new code is equivalent.

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

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

From kcr at openjdk.java.net  Mon Jan  6 23:53:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 6 Jan 2020 23:53:55 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
Message-ID: <Z-exT2PBQ8yvzVZI0HifoEIsOFW73J4Vs3upT7YFi1I=.6cd566ab-d193-4860-bc5e-8d874b3c9337@github.com>

On Wed, 18 Dec 2019 01:04:42 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8232589
> 
> - Removed CoreAudio Utility classes.
> - Spectrum which was depended on CoreAudio Utility classes for doing computations will now run GStreamer spectrum element to do spectrum. Element will be run without pipeline and will be used as utility library to do spectrum calculation. I added extra APIs to bypass proper element initialization.
> - Equalizer and audio unit (volume and balance) where modified, so we can run then directly without CoreAudio pipeline.

This looks good to me. As a reminder, it will need a second review from @johanvos .

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

Marked as reviewed by kcr (Lead).

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

From tsayao at openjdk.java.net  Tue Jan  7 00:50:24 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 7 Jan 2020 00:50:24 GMT
Subject: [Rev 04] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <ceagFb9vGo72kon_ZE4-2YdCYn78CNazLntyN5C5Nsk=.7280bed9-be33-4e9f-9b5e-39cce1ba2ddd@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - cc7745b4: Pass more tests

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/49426b66..cc7745b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.03-04

  Stats: 57 lines in 2 files changed: 11 ins; 30 del; 16 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From tsayao at openjdk.java.net  Tue Jan  7 02:01:48 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 7 Jan 2020 02:01:48 GMT
Subject: [Rev 05] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <7t1I8SSqM4GhwdVIzECjTm6SUyG26PtqUeO7S5HaRQE=.21b3a6de-34b7-45e3-9775-f69dca60d2ae@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - e4d2a1d2: Small fixes

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/cc7745b4..e4d2a1d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.05
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.04-05

  Stats: 67 lines in 5 files changed: 31 ins; 8 del; 28 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From jvos at openjdk.java.net  Tue Jan  7 07:55:14 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 7 Jan 2020 07:55:14 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
Message-ID: <nKGyQCoeSayISYLXOEJpt435q3asb09O4skmlccnwdI=.30d83f61-1f34-4970-8c36-184be85ecbb8@github.com>

On Wed, 18 Dec 2019 01:04:42 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8232589
> 
> - Removed CoreAudio Utility classes.
> - Spectrum which was depended on CoreAudio Utility classes for doing computations will now run GStreamer spectrum element to do spectrum. Element will be run without pipeline and will be used as utility library to do spectrum calculation. I added extra APIs to bypass proper element initialization.
> - Equalizer and audio unit (volume and balance) where modified, so we can run then directly without CoreAudio pipeline.

The changes look ok to me, and the build + tests are nominal.
Since there are new calculations being used now, I am slightly concerned about performance regression, but this is very hard to measure, so I suggest we build an EA release once the PR is merged.

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

Marked as reviewed by jvos (Reviewer).

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

From arapte at openjdk.java.net  Tue Jan  7 09:47:16 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 7 Jan 2020 09:47:16 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content causes
 memory leak from weak one
Message-ID: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>

This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).

Issue.
- `Parent.viewOrderChildren` is a list of children sorted according to view order.
- `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.

- Below is the scenario mentioned in this issue,
1. `TabPane` is created with few `tabs`.
2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.

Fix:
Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
`Parent.viewOrderChildren` will be computed on next `pulse`.
This will maintain lazy computation of `Parent.viewOrderChildren`. 

Added a system test, fails without fix and passes with. No failures in existing tests.

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

Commits:
 - cbcc3161: [WIP] 8232824: Removing TabPane with strong referenced content causes memory leak from weak one

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

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

From jvos at openjdk.java.net  Tue Jan  7 12:50:24 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 7 Jan 2020 12:50:24 GMT
Subject: [Rev 01] RFR: 8236448: Remove unused and repair broken
 Android/Dalvik code
In-Reply-To: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
References: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
Message-ID: <NULTWEA7MT1fzS0mMSBMHAtjC4V-Dy8aQHv6AL0-aYY=.c16f0438-aca6-41df-a0d9-838ff7d11224@github.com>

> This allows to build the JavaFX jars and native libraries for Android devices

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f8321fd0: copy (android) resources into directory where they are picked up by the jar task

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/75/files
  - new: https://git.openjdk.java.net/jfx/pull/75/files/504a2440..f8321fd0

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

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

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

From jvos at openjdk.java.net  Tue Jan  7 13:32:54 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 7 Jan 2020 13:32:54 GMT
Subject: [Rev 02] RFR: 8236448: Remove unused and repair broken
 Android/Dalvik code
In-Reply-To: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
References: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
Message-ID: <v1gNlG031Th1mcN8ohplOTh10bXJYlTfevSNuTbsAs4=.e908024d-43e4-4625-886e-df45adf1784a@github.com>

> This allows to build the JavaFX jars and native libraries for Android devices

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 13699670: process reviewer comments

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/75/files
  - new: https://git.openjdk.java.net/jfx/pull/75/files/f8321fd0..13699670

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

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

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

From thevenet.fred at free.fr  Tue Jan  7 13:51:13 2020
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Tue, 7 Jan 2020 14:51:13 +0100 (CET)
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <c438a7f3-14bf-a545-f91f-4e4fbd2d159a@oracle.com>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
 <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
 <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
 <c438a7f3-14bf-a545-f91f-4e4fbd2d159a@oracle.com>
Message-ID: <1791939899.154506977.1578405073214.JavaMail.zimbra@free.fr>

Hi Kevin,

I am wondering about the likelihood for the fix to JDK-8088198 that I 
proposed in PR #68 (https://github.com/openjdk/jfx/pull/68) to make it into 
JavaFX 14.
I think it is unlikely to be integrated into master by Thursday since it 
has yet to be fully reviewed, but since it is marked as a P3 bug, I understand 
that it could still be integrated during RDP1(provided it works as expected,
of course); am I correct?
In the event it doesn't make it on time for 14, would it qualify to be 
backported for inclusion in an intermediate release like 14.0.1, or would
it have to wait for JavaFX 15?

Thanks,
Frederic.

----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Mardi 7 Janvier 2020 00:26:03
Objet: Re: Proposed schedule for JavaFX 14

This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1) 
on January 9, 2020 at 23:59 Pacific time.

Any change integrated to the default 'master' branch after that will be 
for JavaFX 15. I will fork a new 'jfx14' stabilization branch early 
Friday morning (Pacific time). As with previous releases, P1-P3 bug 
fixes, and test or documentation fixes of any priority can still get 
into JavaFX 14 during RDP1. I'll send out more details Friday morning.

-- Kevin


On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
> The announced RDP1 date is the first Monday of the new year. In taking 
> a closer look at the upcoming holiday schedule and accounting for 
> additional days off some will be taking before or after, this doesn't 
> allow enough time for the final stages of the review process to 
> complete, including CSR approval. It is quite possible that an 
> enhancement with a mostly-completed review and a CSR that is Finalized 
> this Thursday or Friday (Dec 19 or 20), won't be approved in time for 
> integration.
>
> To address this, we are delaying RDP1 by three days. The new RDP1 date 
> is:
>
> Thursday, Jan 9, 23:59 PST
>
> The dates for RDP2, code freeze, and GA are unchanged.
>
> Please be aware that this three-day extension isn't an invitation to 
> try to get additional features into 14 at the last minute, but rather 
> an adjustment to better align with the holiday schedule in order to 
> give the already-in-flight features that are nearing completion a 
> little more time to make it. It is still the case that if an 
> enhancement isn't ready (meaning API discussed & approved, code review 
> mostly done, and CSR finalized) by this Friday, it should be 
> retargeted to JavaFX 15.
>
> -- Kevin
>
>
> On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
>> As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59 
>> Pacific time).
>>
>> With the holidays approaching, please allow sufficient time for any 
>> feature that needs a CSR. New features should be far enough along in 
>> the review process so you can finalize the CSR before next Friday, 
>> Dec 20, or it is likely to miss the window for this release, in which 
>> case it can be targeted for JavaFX 15.
>>
>> During rampdown of JavaFX 14, the "master" branch of the jfx repo 
>> will be open for JavaFX 15 fixes.
>>
>> We will follow the same process as previous releases for getting 
>> fixes into JavaFX 14 during rampdown. I'll send a message with 
>> detailed information later, but generally candidates for fixing after 
>> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc 
>> bugs of any priority.
>>
>> -- Kevin
>>
>>
>> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>>> Here is the proposed schedule for JavaFX 14.
>>>
>>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>>> RDP2: Feb 3, 2020
>>> Freeze: Feb 24, 2020
>>> GA: March 10, 2020
>>>
>>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is 
>>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>>
>>> Please let Johan or me know if you have any questions.
>>>
>>> -- Kevin
>>>
>>
>

From thiago.sayao at clamed.com.br  Tue Jan  7 14:18:39 2020
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Tue, 7 Jan 2020 14:18:39 +0000
Subject: How to reproduce a Window with native background?
Message-ID: <CP2P15201MB2228E385EFE57A2FD99C312ADE3F0@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

>From Window.java internal API:


/**
 * Set the background of the window.
 *
 * In most cases the View covers the whole window, so the background color
 * of the window is never seen by the user. However, a window w/o a view
 * does display the background color in its content area.
 *
 * On some platforms setting the background color may produce flickering
 * when painting the content area of the View (even though the View covers
 * the whole window).  Therefore it is recommended to set the background
 * color to windows w/o views only.
 */
public boolean setBackground(final float r, final float g, final float b) {
    Application.checkEventThread();
    checkNotClosed();
    return _setBackground(this.ptr, r, g, b);
}

How to reproduce this scenario? Create a window where this brackground is shown?

Thanks.

From kevin.rushforth at oracle.com  Tue Jan  7 14:54:41 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 7 Jan 2020 06:54:41 -0800
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <1791939899.154506977.1578405073214.JavaMail.zimbra@free.fr>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
 <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
 <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
 <c438a7f3-14bf-a545-f91f-4e4fbd2d159a@oracle.com>
 <1791939899.154506977.1578405073214.JavaMail.zimbra@free.fr>
Message-ID: <e6a947ba-63a5-317a-d8f3-6bd41966fca9@oracle.com>

Hi Frederic,

P3 bug fixes can go in during RDP1 if they are safe enough fixes. The 
RDP2 deadline is Feb 3, so there is still time. Any bug that misses 14 
and is ready for integration into mainline will go into 15. A case can 
be made for pulling in a very limited number of safe fixes from 15 into 
a 14.0.x release, but I wouldn't expect that in this case. If the fix is 
safe enough to get into 14, it will likely make it. If not, then it 
isn't a good candidate for 14.0.1 anyway.

-- Kevin


On 1/7/2020 5:51 AM, thevenet.fred at free.fr wrote:
> Hi Kevin,
>
> I am wondering about the likelihood for the fix to JDK-8088198 that I
> proposed in PR #68 (https://github.com/openjdk/jfx/pull/68) to make it into
> JavaFX 14.
> I think it is unlikely to be integrated into master by Thursday since it
> has yet to be fully reviewed, but since it is marked as a P3 bug, I understand
> that it could still be integrated during RDP1(provided it works as expected,
> of course); am I correct?
> In the event it doesn't make it on time for 14, would it qualify to be
> backported for inclusion in an intermediate release like 14.0.1, or would
> it have to wait for JavaFX 15?
>
> Thanks,
> Frederic.
>
> ----- Mail original -----
> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 7 Janvier 2020 00:26:03
> Objet: Re: Proposed schedule for JavaFX 14
>
> This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1)
> on January 9, 2020 at 23:59 Pacific time.
>
> Any change integrated to the default 'master' branch after that will be
> for JavaFX 15. I will fork a new 'jfx14' stabilization branch early
> Friday morning (Pacific time). As with previous releases, P1-P3 bug
> fixes, and test or documentation fixes of any priority can still get
> into JavaFX 14 during RDP1. I'll send out more details Friday morning.
>
> -- Kevin
>
>
> On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
>> The announced RDP1 date is the first Monday of the new year. In taking
>> a closer look at the upcoming holiday schedule and accounting for
>> additional days off some will be taking before or after, this doesn't
>> allow enough time for the final stages of the review process to
>> complete, including CSR approval. It is quite possible that an
>> enhancement with a mostly-completed review and a CSR that is Finalized
>> this Thursday or Friday (Dec 19 or 20), won't be approved in time for
>> integration.
>>
>> To address this, we are delaying RDP1 by three days. The new RDP1 date
>> is:
>>
>> Thursday, Jan 9, 23:59 PST
>>
>> The dates for RDP2, code freeze, and GA are unchanged.
>>
>> Please be aware that this three-day extension isn't an invitation to
>> try to get additional features into 14 at the last minute, but rather
>> an adjustment to better align with the holiday schedule in order to
>> give the already-in-flight features that are nearing completion a
>> little more time to make it. It is still the case that if an
>> enhancement isn't ready (meaning API discussed & approved, code review
>> mostly done, and CSR finalized) by this Friday, it should be
>> retargeted to JavaFX 15.
>>
>> -- Kevin
>>
>>
>> On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
>>> As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59
>>> Pacific time).
>>>
>>> With the holidays approaching, please allow sufficient time for any
>>> feature that needs a CSR. New features should be far enough along in
>>> the review process so you can finalize the CSR before next Friday,
>>> Dec 20, or it is likely to miss the window for this release, in which
>>> case it can be targeted for JavaFX 15.
>>>
>>> During rampdown of JavaFX 14, the "master" branch of the jfx repo
>>> will be open for JavaFX 15 fixes.
>>>
>>> We will follow the same process as previous releases for getting
>>> fixes into JavaFX 14 during rampdown. I'll send a message with
>>> detailed information later, but generally candidates for fixing after
>>> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc
>>> bugs of any priority.
>>>
>>> -- Kevin
>>>
>>>
>>> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>>>> Here is the proposed schedule for JavaFX 14.
>>>>
>>>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>>>> RDP2: Feb 3, 2020
>>>> Freeze: Feb 24, 2020
>>>> GA: March 10, 2020
>>>>
>>>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is
>>>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>>>
>>>> Please let Johan or me know if you have any questions.
>>>>
>>>> -- Kevin
>>>>


From thevenet.fred at free.fr  Tue Jan  7 15:18:00 2020
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Tue, 7 Jan 2020 16:18:00 +0100 (CET)
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <e6a947ba-63a5-317a-d8f3-6bd41966fca9@oracle.com>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
 <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
 <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
 <c438a7f3-14bf-a545-f91f-4e4fbd2d159a@oracle.com>
 <1791939899.154506977.1578405073214.JavaMail.zimbra@free.fr>
 <e6a947ba-63a5-317a-d8f3-6bd41966fca9@oracle.com>
Message-ID: <831632753.155087784.1578410280380.JavaMail.zimbra@free.fr>

Ok, it is quite clear to me now.
Thanks for the clarifications.

Regards, 
Frederic.

----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
?: "thevenet fred" <thevenet.fred at free.fr>
Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Mardi 7 Janvier 2020 15:54:41
Objet: Re: Proposed schedule for JavaFX 14

Hi Frederic,

P3 bug fixes can go in during RDP1 if they are safe enough fixes. The 
RDP2 deadline is Feb 3, so there is still time. Any bug that misses 14 
and is ready for integration into mainline will go into 15. A case can 
be made for pulling in a very limited number of safe fixes from 15 into 
a 14.0.x release, but I wouldn't expect that in this case. If the fix is 
safe enough to get into 14, it will likely make it. If not, then it 
isn't a good candidate for 14.0.1 anyway.

-- Kevin


On 1/7/2020 5:51 AM, thevenet.fred at free.fr wrote:
> Hi Kevin,
>
> I am wondering about the likelihood for the fix to JDK-8088198 that I
> proposed in PR #68 (https://github.com/openjdk/jfx/pull/68) to make it into
> JavaFX 14.
> I think it is unlikely to be integrated into master by Thursday since it
> has yet to be fully reviewed, but since it is marked as a P3 bug, I understand
> that it could still be integrated during RDP1(provided it works as expected,
> of course); am I correct?
> In the event it doesn't make it on time for 14, would it qualify to be
> backported for inclusion in an intermediate release like 14.0.1, or would
> it have to wait for JavaFX 15?
>
> Thanks,
> Frederic.
>
> ----- Mail original -----
> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 7 Janvier 2020 00:26:03
> Objet: Re: Proposed schedule for JavaFX 14
>
> This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1)
> on January 9, 2020 at 23:59 Pacific time.
>
> Any change integrated to the default 'master' branch after that will be
> for JavaFX 15. I will fork a new 'jfx14' stabilization branch early
> Friday morning (Pacific time). As with previous releases, P1-P3 bug
> fixes, and test or documentation fixes of any priority can still get
> into JavaFX 14 during RDP1. I'll send out more details Friday morning.
>
> -- Kevin
>
>
> On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
>> The announced RDP1 date is the first Monday of the new year. In taking
>> a closer look at the upcoming holiday schedule and accounting for
>> additional days off some will be taking before or after, this doesn't
>> allow enough time for the final stages of the review process to
>> complete, including CSR approval. It is quite possible that an
>> enhancement with a mostly-completed review and a CSR that is Finalized
>> this Thursday or Friday (Dec 19 or 20), won't be approved in time for
>> integration.
>>
>> To address this, we are delaying RDP1 by three days. The new RDP1 date
>> is:
>>
>> Thursday, Jan 9, 23:59 PST
>>
>> The dates for RDP2, code freeze, and GA are unchanged.
>>
>> Please be aware that this three-day extension isn't an invitation to
>> try to get additional features into 14 at the last minute, but rather
>> an adjustment to better align with the holiday schedule in order to
>> give the already-in-flight features that are nearing completion a
>> little more time to make it. It is still the case that if an
>> enhancement isn't ready (meaning API discussed & approved, code review
>> mostly done, and CSR finalized) by this Friday, it should be
>> retargeted to JavaFX 15.
>>
>> -- Kevin
>>
>>
>> On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
>>> As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59
>>> Pacific time).
>>>
>>> With the holidays approaching, please allow sufficient time for any
>>> feature that needs a CSR. New features should be far enough along in
>>> the review process so you can finalize the CSR before next Friday,
>>> Dec 20, or it is likely to miss the window for this release, in which
>>> case it can be targeted for JavaFX 15.
>>>
>>> During rampdown of JavaFX 14, the "master" branch of the jfx repo
>>> will be open for JavaFX 15 fixes.
>>>
>>> We will follow the same process as previous releases for getting
>>> fixes into JavaFX 14 during rampdown. I'll send a message with
>>> detailed information later, but generally candidates for fixing after
>>> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc
>>> bugs of any priority.
>>>
>>> -- Kevin
>>>
>>>
>>> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>>>> Here is the proposed schedule for JavaFX 14.
>>>>
>>>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>>>> RDP2: Feb 3, 2020
>>>> Freeze: Feb 24, 2020
>>>> GA: March 10, 2020
>>>>
>>>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is
>>>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>>>
>>>> Please let Johan or me know if you have any questions.
>>>>
>>>> -- Kevin
>>>>

From kcr at openjdk.java.net  Tue Jan  7 20:38:39 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 7 Jan 2020 20:38:39 GMT
Subject: RFR: 8233798: Ctrl-L character mistakenly removed from gstreamer.md
Message-ID: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>

Fix for [JDK-8233798](https://bugs.openjdk.java.net/browse/JDK-8233798)

Simple fix to restore a Ctrl-L character that was mistakenly deleted as part of the cleanup fix done for [JDK-8222746](https://bugs.openjdk.java.net/browse/JDK-8222746). After the missing ^L is restored the license is once again identical between `gstreamer.md` and `glib.md` (and `webkit.md`) as it should be.

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

Commits:
 - d09255bc: 8233798: Ctrl-L character mistakenly removed from gstreamer.md

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

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

From kcr at openjdk.java.net  Tue Jan  7 20:38:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 7 Jan 2020 20:38:59 GMT
Subject: RFR: 8233798: Ctrl-L character mistakenly removed from
 gstreamer.md
In-Reply-To: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>
References: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>
Message-ID: <HokIlNoLsFhcHGO_ZjAhmWEo1GRbc7qfLSg4tzhvtFw=.580e62ce-d905-48fb-80b1-0d8dd7b2cfb6@github.com>

On Tue, 7 Jan 2020 20:37:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fix for [JDK-8233798](https://bugs.openjdk.java.net/browse/JDK-8233798)
> 
> Simple fix to restore a Ctrl-L character that was mistakenly deleted as part of the cleanup fix done for [JDK-8222746](https://bugs.openjdk.java.net/browse/JDK-8222746). After the missing ^L is restored the license is once again identical between `gstreamer.md` and `glib.md` (and `webkit.md`) as it should be.

@sashamatveev can you review this?

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

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

From almatvee at openjdk.java.net  Tue Jan  7 21:12:25 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 7 Jan 2020 21:12:25 GMT
Subject: RFR: 8233798: Ctrl-L character mistakenly removed from
 gstreamer.md
In-Reply-To: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>
References: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>
Message-ID: <PlSCLpNdBDyVPuB_7XsIICPbJOZzLAfpBfPYzm0K23Q=.81ab1b5d-b0f6-4e7b-95a6-ea1ed8cc0e53@github.com>

On Tue, 7 Jan 2020 20:37:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fix for [JDK-8233798](https://bugs.openjdk.java.net/browse/JDK-8233798)
> 
> Simple fix to restore a Ctrl-L character that was mistakenly deleted as part of the cleanup fix done for [JDK-8222746](https://bugs.openjdk.java.net/browse/JDK-8222746). After the missing ^L is restored the license is once again identical between `gstreamer.md` and `glib.md` (and `webkit.md`) as it should be.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

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

From kcr at openjdk.java.net  Tue Jan  7 21:20:12 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 7 Jan 2020 21:20:12 GMT
Subject: [Integrated] RFR: 8233798: Ctrl-L character mistakenly removed
 from gstreamer.md
In-Reply-To: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>
References: <-4zo1JgA2cPujrabhW7drUAl1XxwcOpamiMIWruyObY=.044324c7-b716-47bf-a9d8-ae60c63aa3c8@github.com>
Message-ID: <623e900f-6f7b-489d-aad7-5478b2e4cb35@openjdk.org>

Changeset: df8b3c50
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-07 21:19:25 +0000
URL:       https://git.openjdk.java.net/jfx/commit/df8b3c50

8233798: Ctrl-L character mistakenly removed from gstreamer.md

Reviewed-by: almatvee

! modules/javafx.media/src/main/legal/gstreamer.md

From almatvee at openjdk.java.net  Tue Jan  7 22:15:13 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 7 Jan 2020 22:15:13 GMT
Subject: [Integrated] RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
Message-ID: <327da043-8014-4199-88d0-3a5c12bb4fac@openjdk.org>

Changeset: c9519b6e
Author:    Alexander Matveev <almatvee at openjdk.org>
Date:      2020-01-07 22:14:22 +0000
URL:       https://git.openjdk.java.net/jfx/commit/c9519b6e

8232589: Remove CoreAudio Utility Classes

Reviewed-by: kcr, jvos

! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/spectrum/gstspectrum.c
! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/spectrum/gstspectrum.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUInputElement.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUInputElement.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUOutputElement.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUOutputElement.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUPlugInDispatch.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUPlugInDispatch.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUScopeElement.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/AUScopeElement.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/ComponentBase.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/AUBase/ComponentBase.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/OtherBases/AUEffectBase.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/OtherBases/AUEffectBase.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/Utility/AUBaseHelper.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/Utility/AUBaseHelper.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/Utility/AUBuffer.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/Utility/AUBuffer.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/AudioUnits/AUPublic/Utility/AUSilentTimeout.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAAtomic.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAAtomicStack.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAAudioChannelLayout.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAAudioChannelLayout.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAAutoDisposer.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CABitOperations.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CADebugMacros.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CADebugMacros.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CADebugPrintf.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CADebugPrintf.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CADebugger.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CADebugger.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAException.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAHostTimeBase.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAHostTimeBase.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CALogMacros.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAMath.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAMutex.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAMutex.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAReferenceCounted.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CASpectralProcessor.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CASpectralProcessor.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAStreamBasicDescription.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAStreamBasicDescription.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAThreadSafeList.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAVectorUnit.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAVectorUnit.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAVectorUnitTypes.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAXException.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/CoreAudio/PublicUtility/CAXException.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/LICENSE.txt
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/CoreAudioUtilityClasses/ReadMe.txt
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.h
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.h
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.mm
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.cpp
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.h
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFKernelProcessor.cpp
- modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFKernelProcessor.h
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFSoundLevelUnit.cpp
! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFSoundLevelUnit.h
! modules/javafx.media/src/main/native/jfxmedia/projects/mac/Makefile

From kcr at openjdk.java.net  Tue Jan  7 22:59:26 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 7 Jan 2020 22:59:26 GMT
Subject: [Rev 02] RFR: 8236448: Remove unused and repair broken
 Android/Dalvik code
In-Reply-To: <v1gNlG031Th1mcN8ohplOTh10bXJYlTfevSNuTbsAs4=.e908024d-43e4-4625-886e-df45adf1784a@github.com>
References: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
 <v1gNlG031Th1mcN8ohplOTh10bXJYlTfevSNuTbsAs4=.e908024d-43e4-4625-886e-df45adf1784a@github.com>
Message-ID: <XK1f08TvcgcRR56dVjJhBXHl0RRRvh851WfvUsGR-ak=.471381b8-ea47-4fc6-b40c-c5749ea46109@github.com>

On Tue, 7 Jan 2020 22:59:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> This allows to build the JavaFX jars and native libraries for Android devices
> 
> The pull request has been updated with 1 additional commit.

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From kevin.rushforth at oracle.com  Tue Jan  7 23:06:34 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 7 Jan 2020 15:06:34 -0800
Subject: Maximized undecorated stage
In-Reply-To: <PS1PR03MB470070FB7C44A6BEDC65F39AE73C0@PS1PR03MB4700.apcprd03.prod.outlook.com>
References: <PS1PR03MB470070FB7C44A6BEDC65F39AE73C0@PS1PR03MB4700.apcprd03.prod.outlook.com>
Message-ID: <81781b6e-63c9-7fed-da3e-690afd0fe97d@oracle.com>

Ideally, we wouldn't have this sort of platform-specific behavior. I can 
see why the underlying platform might not support the concept of 
maximizing an undecorated stage, so we either need to disable it on 
Windows, live with the behavior, or else find some solution on macOS and 
Linux.

-- Kevin


On 1/6/2020 1:43 AM, Abhinay Agarwal wrote:
> Hi,
>
> If maximize property is set to true for an undecorated Stage, the following behaviour is observed on different platforms:
>
>    *   Windows: Undecorated stage is maximized
>    *   MacOS: Undecorated stage is not maximized
>    *   Linux(Ubuntu): Undecorated stage is not maximized
>
> The following piece of code can be used to reproduce the behaviour:
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.Label;
> import javafx.scene.layout.StackPane;
> import javafx.stage.Stage;
> import javafx.stage.StageStyle;
>
> public class MaximizedStage extends Application {
>      public void start (Stage stage) {
>          StackPane sp = new StackPane(new Label("Hello"));
>          stage.setScene(new Scene (sp, 500, 500));
>          stage.initStyle(StageStyle.UNDECORATED);
>          stage.show();
>          stage.setMaximized(true);
>      }
> }
>
>   Is there a reason why the stage gets maximized on Windows but fails on other platforms?
>
> Regards,
> Abhinay


From kevin.rushforth at oracle.com  Tue Jan  7 23:13:32 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 7 Jan 2020 15:13:32 -0800
Subject: Rate of embedded animations
In-Reply-To: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>
References: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>
Message-ID: <e9dee0f6-aba6-b787-849c-6f319049a99f@oracle.com>

A rate in a "parent" transition should probably override the rate in a 
child Animation. There are a couple ways to do it, and it sounds like it 
doesn't really implement it right.

1. The public rate property values of child Animations within a parent 
Transition are ignored, but not updated. As long as the implementation 
is consistent in ignoring the rate property from the child Animation, 
this seems like a fine solution and is consistent with other properties 
where one property overrides another without modifying it.

2. Setting a rate on the parent Transition actually modifies the child 
node. This can work, but has more issues. What happens if you set the 
rate of the parent tansition and then set the rate of a child animation? 
What if you bind to the rate of a child animation?

-- Kevin

On 1/1/2020 1:04 PM, Nir Lisker wrote:
> Hi,
>
> As part of my work in the animations package I've come across an undefined
> spec. Is the rate of an animation that is embedded in a Parallel/Sequential
> transition inherited and overridden by its parent?
>
> If I have an animations with a rate of 1 and a parent with a rate of 2, and
> I add the animation to the parent, does the rate property change from 1 to
> 2 (generating a change/invalidation event etc.)? Then, should any
> subsequent changes to the parent's rate trigger a change in the child's
> rate?
>
> The implementation is a bit messy in this regard. The rate and currentRate
> values exist in both Animation and its ClipEnvelope, which is the source
> for a couple of bugs. For example, changing the rate of a
> ParallelTransition changes the child's ClipEnvelope's rate and currentRate,
> but only the animation's currentRate (and not rate). Is it supposed to be
> this way?
>
> What is clear is that it's not possible to change the rate of the embedded
> animation directly.
>
> The docs do not talk about the rate of an embedded animation (they do talk
> about the node property though).
>
> - Nir


From ebresiedev at gmail.com  Wed Jan  8 06:54:22 2020
From: ebresiedev at gmail.com (Eric Bresie)
Date: Wed, 8 Jan 2020 00:54:22 -0600
Subject: Proposed schedule for JavaFX 14
In-Reply-To: 831632753.155087784.1578410280380.JavaMail.zimbra@free.fr
References: cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com
 536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com
 27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com
 c438a7f3-14bf-a545-f91f-4e4fbd2d159a@oracle.com
 1791939899.154506977.1578405073214.JavaMail.zimbra@free.fr
 e6a947ba-63a5-317a-d8f3-6bd41966fca9@oracle.com
 e6a947ba-63a5-317a-d8f3-6bd41966fca9@oracle.com
Message-ID: <74a479b0-f32f-43ef-a72b-a82f41fa537a@Erics-iPhone-X>

Out of curiosity...are there any labels, milestones, targets or any such type added in github and/or bug systema for changes going in? Or is there a PR of some type with all relevant changes expected?

Eric Bresie
Ebresie at gmail.com
> On January 7, 2020 at 9:18:00 AM CST, thevenet.fred at free.fr wrote:
> Ok, it is quite clear to me now.
> Thanks for the clarifications.
>
> Regards,
> Frederic.
>
> ----- Mail original -----
> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> ?: "thevenet fred" <thevenet.fred at free.fr>
> Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 7 Janvier 2020 15:54:41
> Objet: Re: Proposed schedule for JavaFX 14
>
> Hi Frederic,
>
> P3 bug fixes can go in during RDP1 if they are safe enough fixes. The
> RDP2 deadline is Feb 3, so there is still time. Any bug that misses 14
> and is ready for integration into mainline will go into 15. A case can
> be made for pulling in a very limited number of safe fixes from 15 into
> a 14.0.x release, but I wouldn't expect that in this case. If the fix is
> safe enough to get into 14, it will likely make it. If not, then it
> isn't a good candidate for 14.0.1 anyway.
>
> -- Kevin
>
>
> On 1/7/2020 5:51 AM, thevenet.fred at free.fr wrote:
> > Hi Kevin,
> >
> > I am wondering about the likelihood for the fix to JDK-8088198 that I
> > proposed in PR #68 (https://github.com/openjdk/jfx/pull/68) to make it into
> > JavaFX 14.
> > I think it is unlikely to be integrated into master by Thursday since it
> > has yet to be fully reviewed, but since it is marked as a P3 bug, I understand
> > that it could still be integrated during RDP1(provided it works as expected,
> > of course); am I correct?
> > In the event it doesn't make it on time for 14, would it qualify to be
> > backported for inclusion in an intermediate release like 14.0.1, or would
> > it have to wait for JavaFX 15?
> >
> > Thanks,
> > Frederic.
> >
> > ----- Mail original -----
> > De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> > ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> > Envoy?: Mardi 7 Janvier 2020 00:26:03
> > Objet: Re: Proposed schedule for JavaFX 14
> >
> > This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1)
> > on January 9, 2020 at 23:59 Pacific time.
> >
> > Any change integrated to the default 'master' branch after that will be
> > for JavaFX 15. I will fork a new 'jfx14' stabilization branch early
> > Friday morning (Pacific time). As with previous releases, P1-P3 bug
> > fixes, and test or documentation fixes of any priority can still get
> > into JavaFX 14 during RDP1. I'll send out more details Friday morning.
> >
> > -- Kevin
> >
> >
> > On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
> > > The announced RDP1 date is the first Monday of the new year. In taking
> > > a closer look at the upcoming holiday schedule and accounting for
> > > additional days off some will be taking before or after, this doesn't
> > > allow enough time for the final stages of the review process to
> > > complete, including CSR approval. It is quite possible that an
> > > enhancement with a mostly-completed review and a CSR that is Finalized
> > > this Thursday or Friday (Dec 19 or 20), won't be approved in time for
> > > integration.
> > >
> > > To address this, we are delaying RDP1 by three days. The new RDP1 date
> > > is:
> > >
> > > Thursday, Jan 9, 23:59 PST
> > >
> > > The dates for RDP2, code freeze, and GA are unchanged.
> > >
> > > Please be aware that this three-day extension isn't an invitation to
> > > try to get additional features into 14 at the last minute, but rather
> > > an adjustment to better align with the holiday schedule in order to
> > > give the already-in-flight features that are nearing completion a
> > > little more time to make it. It is still the case that if an
> > > enhancement isn't ready (meaning API discussed & approved, code review
> > > mostly done, and CSR finalized) by this Friday, it should be
> > > retargeted to JavaFX 15.
> > >
> > > -- Kevin
> > >
> > >
> > > On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
> > > > As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59
> > > > Pacific time).
> > > >
> > > > With the holidays approaching, please allow sufficient time for any
> > > > feature that needs a CSR. New features should be far enough along in
> > > > the review process so you can finalize the CSR before next Friday,
> > > > Dec 20, or it is likely to miss the window for this release, in which
> > > > case it can be targeted for JavaFX 15.
> > > >
> > > > During rampdown of JavaFX 14, the "master" branch of the jfx repo
> > > > will be open for JavaFX 15 fixes.
> > > >
> > > > We will follow the same process as previous releases for getting
> > > > fixes into JavaFX 14 during rampdown. I'll send a message with
> > > > detailed information later, but generally candidates for fixing after
> > > > RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc
> > > > bugs of any priority.
> > > >
> > > > -- Kevin
> > > >
> > > >
> > > > On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
> > > > > Here is the proposed schedule for JavaFX 14.
> > > > >
> > > > > RDP1: Jan 6, 2020 (aka ?feature freeze?)
> > > > > RDP2: Feb 3, 2020
> > > > > Freeze: Feb 24, 2020
> > > > > GA: March 10, 2020
> > > > >
> > > > > We plan to fork a jfx14 stabilization branch at RDP1. The GA date is
> > > > > expected to be one week ahead of JDK 14, matching what we did for 13.
> > > > >
> > > > > Please let Johan or me know if you have any questions.
> > > > >
> > > > > -- Kevin
> > > > >

From kevin.rushforth at oracle.com  Wed Jan  8 13:40:45 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 8 Jan 2020 05:40:45 -0800
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <74a479b0-f32f-43ef-a72b-a82f41fa537a@Erics-iPhone-X>
References: <74a479b0-f32f-43ef-a72b-a82f41fa537a@Erics-iPhone-X>
Message-ID: <95817e05-c05b-f92f-98fb-3d46f9a8497e@oracle.com>

Are you asking how to tell whether a PR is targeted for JavaFX 14 or 15 
after the RDP1 fork? I'll send out details on Friday morning after the 
fork, but it's effectively the same as it's been for the last several 
releases. The 'master' branch of jfx is always where the current 
development release is built from. Today that would be JavaFX 14. As of 
Friday morning, it will be JavaFX 15. During rampdown of JavaFX 14, a PR 
can be made against the 'jfx14' branch to get into JavaFX 14 if the 
reviewer(s) agree that it meets the criteria for getting into 14. In 
JBS, a bug that is intended for 14 will have the fixVersion of 
opnejfx14, while a bug intended for 15 will have a fixVersion of 
openjfx15. At RDP1 of 14, most bugs should have their fixVersion updated 
to openjfx15.

-- Kevin


On 1/7/2020 10:54 PM, Eric Bresie wrote:
> Out of curiosity...are there any labels, milestones, targets or any such type added in github and/or bug systema for changes going in? Or is there a PR of some type with all relevant changes expected?
>
> Eric Bresie
> Ebresie at gmail.com
>> On January 7, 2020 at 9:18:00 AM CST, thevenet.fred at free.fr wrote:
>> Ok, it is quite clear to me now.
>> Thanks for the clarifications.
>>
>> Regards,
>> Frederic.
>>
>> ----- Mail original -----
>> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
>> ?: "thevenet fred" <thevenet.fred at free.fr>
>> Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
>> Envoy?: Mardi 7 Janvier 2020 15:54:41
>> Objet: Re: Proposed schedule for JavaFX 14
>>
>> Hi Frederic,
>>
>> P3 bug fixes can go in during RDP1 if they are safe enough fixes. The
>> RDP2 deadline is Feb 3, so there is still time. Any bug that misses 14
>> and is ready for integration into mainline will go into 15. A case can
>> be made for pulling in a very limited number of safe fixes from 15 into
>> a 14.0.x release, but I wouldn't expect that in this case. If the fix is
>> safe enough to get into 14, it will likely make it. If not, then it
>> isn't a good candidate for 14.0.1 anyway.
>>
>> -- Kevin
>>
>>
>> On 1/7/2020 5:51 AM, thevenet.fred at free.fr wrote:
>>> Hi Kevin,
>>>
>>> I am wondering about the likelihood for the fix to JDK-8088198 that I
>>> proposed in PR #68 (https://github.com/openjdk/jfx/pull/68) to make it into
>>> JavaFX 14.
>>> I think it is unlikely to be integrated into master by Thursday since it
>>> has yet to be fully reviewed, but since it is marked as a P3 bug, I understand
>>> that it could still be integrated during RDP1(provided it works as expected,
>>> of course); am I correct?
>>> In the event it doesn't make it on time for 14, would it qualify to be
>>> backported for inclusion in an intermediate release like 14.0.1, or would
>>> it have to wait for JavaFX 15?
>>>
>>> Thanks,
>>> Frederic.
>>>
>>> ----- Mail original -----
>>> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
>>> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
>>> Envoy?: Mardi 7 Janvier 2020 00:26:03
>>> Objet: Re: Proposed schedule for JavaFX 14
>>>
>>> This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1)
>>> on January 9, 2020 at 23:59 Pacific time.
>>>
>>> Any change integrated to the default 'master' branch after that will be
>>> for JavaFX 15. I will fork a new 'jfx14' stabilization branch early
>>> Friday morning (Pacific time). As with previous releases, P1-P3 bug
>>> fixes, and test or documentation fixes of any priority can still get
>>> into JavaFX 14 during RDP1. I'll send out more details Friday morning.
>>>
>>> -- Kevin
>>>
>>>
>>> On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
>>>> The announced RDP1 date is the first Monday of the new year. In taking
>>>> a closer look at the upcoming holiday schedule and accounting for
>>>> additional days off some will be taking before or after, this doesn't
>>>> allow enough time for the final stages of the review process to
>>>> complete, including CSR approval. It is quite possible that an
>>>> enhancement with a mostly-completed review and a CSR that is Finalized
>>>> this Thursday or Friday (Dec 19 or 20), won't be approved in time for
>>>> integration.
>>>>
>>>> To address this, we are delaying RDP1 by three days. The new RDP1 date
>>>> is:
>>>>
>>>> Thursday, Jan 9, 23:59 PST
>>>>
>>>> The dates for RDP2, code freeze, and GA are unchanged.
>>>>
>>>> Please be aware that this three-day extension isn't an invitation to
>>>> try to get additional features into 14 at the last minute, but rather
>>>> an adjustment to better align with the holiday schedule in order to
>>>> give the already-in-flight features that are nearing completion a
>>>> little more time to make it. It is still the case that if an
>>>> enhancement isn't ready (meaning API discussed & approved, code review
>>>> mostly done, and CSR finalized) by this Friday, it should be
>>>> retargeted to JavaFX 15.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
>>>>> As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59
>>>>> Pacific time).
>>>>>
>>>>> With the holidays approaching, please allow sufficient time for any
>>>>> feature that needs a CSR. New features should be far enough along in
>>>>> the review process so you can finalize the CSR before next Friday,
>>>>> Dec 20, or it is likely to miss the window for this release, in which
>>>>> case it can be targeted for JavaFX 15.
>>>>>
>>>>> During rampdown of JavaFX 14, the "master" branch of the jfx repo
>>>>> will be open for JavaFX 15 fixes.
>>>>>
>>>>> We will follow the same process as previous releases for getting
>>>>> fixes into JavaFX 14 during rampdown. I'll send a message with
>>>>> detailed information later, but generally candidates for fixing after
>>>>> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc
>>>>> bugs of any priority.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>>>>>> Here is the proposed schedule for JavaFX 14.
>>>>>>
>>>>>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>>>>>> RDP2: Feb 3, 2020
>>>>>> Freeze: Feb 24, 2020
>>>>>> GA: March 10, 2020
>>>>>>
>>>>>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is
>>>>>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>>>>>
>>>>>> Please let Johan or me know if you have any questions.
>>>>>>
>>>>>> -- Kevin
>>>>>>


From jvos at openjdk.java.net  Wed Jan  8 14:21:14 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 8 Jan 2020 14:21:14 GMT
Subject: [Integrated] RFR: 8236448: Remove unused and repair broken
 Android/Dalvik code
In-Reply-To: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
References: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>
Message-ID: <e08d4b8a-05ed-477f-9f68-bd2ea252aeb3@openjdk.org>

Changeset: e6587ff0
Author:    Johan Vos <jvos at openjdk.org>
Date:      2020-01-08 14:20:28 +0000
URL:       https://git.openjdk.java.net/jfx/commit/e6587ff0

8236448: Remove unused and repair broken Android/Dalvik code

Reviewed-by: kcr

! buildSrc/android.gradle
! modules/javafx.graphics/src/main/java/com/sun/glass/ui/android/DalvikInput.java
! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/AndroidInputDeviceRegistry.java
! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java
! modules/javafx.graphics/src/main/native-glass/monocle/EGL.c
! modules/javafx.graphics/src/main/native-glass/monocle/android/AndroidScreen.c
- modules/javafx.graphics/src/main/native-glass/monocle/android/dalvikInput.c
- modules/javafx.graphics/src/main/native-glass/monocle/android/dalvikInput.h
! modules/javafx.graphics/src/main/native-glass/monocle/android/dalvikUtils.c
+ modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.c
+ modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.h
! modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c
! modules/javafx.graphics/src/main/native-prism-es2/monocle/eglUtils.c

From mail at fabiankeller.de  Wed Jan  8 15:30:19 2020
From: mail at fabiankeller.de (Fabian Keller)
Date: Wed, 8 Jan 2020 16:30:19 +0100
Subject: OpenJFX is not using FontConfig
Message-ID: <CAJ=Ga_V1Z_UBvCX=ZFMkVsT5nrf+gU8wR=CeSBgRkftojW31Og@mail.gmail.com>

Hi,
I'm currently investigating a problem where openjfx is not using
FontConfig on a CentOS machine.

Error message:
...
Loading FontFactory com.sun.javafx.font.freetype.FTFactory
Subpixel: enabled
Freetype2 Loaded (version 2.8.0)
LCD support Disabled
Fallback fontDir is /root/jdk-11.0.5+10/lib/fonts exists = false
java.io.FileNotFoundException: null/allfonts.properties (No such file
or directory)
Fall back to opening the files
 *** FONTCONFIG LOCATED FONTS:
Not using FontConfig
Fontconfig returned no font for sans:regular:roman
...

I'm using openjfx bundled with my application in a fat jar.
(dependencies javafx-base, javafx-web, javafx-swing) (Tested openjfx
versions: 11, 11.0.1, 13, 13.0.1)
The jar is working without any problems on two different machines, one
with a fresh installation of CentOS 7.4 with Gnome.
On other existing machines (CentOS 7.4) i see the error above,
terminating with jvm core dump due to no available fonts.
I tested the behaviour with two jdk distributions from adoptopenjdk
(OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10) and Bellsoft
(bellsoft-jdk11.0.5+11).

FontConfig seem's to work properly
# fc-match sans.regular
DejaVuSans.ttf: "DejaVu Sans" "Book"
# fc-match sans:regular:roman
DejaVuSans.ttf: "DejaVu Sans" "Book"

The jvm command line i used:
java -Dprism.useFontConfig=true -Dprism.debugfonts=true
-Dprism.verbose=true -cp nalf.jar de.dummy.Main

I took a look at the source which produces the line "Not using FontConfig":
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java#L161

If I read correctly the only case where this output can happen is if
'useFontConfig' is false.

The only assignment of 'useFontConfig' is here:
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java#L52

useFontConfig should only be false if the property
'prism.useFontConfig' is not equals 'true'. But I set it explicitly to
"true" (default should also be true).


Does anybody have a clue, what's the problem or has anybody an idea
how to debug this further?


Best regards
Fabian Keller

From philip.race at oracle.com  Wed Jan  8 16:59:25 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 08 Jan 2020 08:59:25 -0800
Subject: OpenJFX is not using FontConfig
In-Reply-To: <CAJ=Ga_V1Z_UBvCX=ZFMkVsT5nrf+gU8wR=CeSBgRkftojW31Og@mail.gmail.com>
References: <CAJ=Ga_V1Z_UBvCX=ZFMkVsT5nrf+gU8wR=CeSBgRkftojW31Og@mail.gmail.com>
Message-ID: <5E160A6D.6070906@oracle.com>

Perhaps you could trace the process to see if we successfully load the 
shared library ?
Maybe we can't do that or can't initialise it for some reason.

But Centos 7.4 is the same as RH 7.4 and OL 7.4 so this is surprising.

Do you have the same fontconfig packages on working and non-working ?
For example do both (or neither) have the fontconfig-develop (or 
whatever it is called)
package as well as the runtime ?

What does a pure Java SE (java 2d) app do on the same machine ?
It also loads fontconfig to find fonts so does it succeed or does it 
fail too ?
Try an Oracle produced OpenJDK build to tet this.

-phil


On 1/8/20, 7:30 AM, Fabian Keller wrote:
> Hi,
> I'm currently investigating a problem where openjfx is not using
> FontConfig on a CentOS machine.
>
> Error message:
> ...
> Loading FontFactory com.sun.javafx.font.freetype.FTFactory
> Subpixel: enabled
> Freetype2 Loaded (version 2.8.0)
> LCD support Disabled
> Fallback fontDir is /root/jdk-11.0.5+10/lib/fonts exists = false
> java.io.FileNotFoundException: null/allfonts.properties (No such file
> or directory)
> Fall back to opening the files
>   *** FONTCONFIG LOCATED FONTS:
> Not using FontConfig
> Fontconfig returned no font for sans:regular:roman
> ...
>
> I'm using openjfx bundled with my application in a fat jar.
> (dependencies javafx-base, javafx-web, javafx-swing) (Tested openjfx
> versions: 11, 11.0.1, 13, 13.0.1)
> The jar is working without any problems on two different machines, one
> with a fresh installation of CentOS 7.4 with Gnome.
> On other existing machines (CentOS 7.4) i see the error above,
> terminating with jvm core dump due to no available fonts.
> I tested the behaviour with two jdk distributions from adoptopenjdk
> (OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10) and Bellsoft
> (bellsoft-jdk11.0.5+11).
>
> FontConfig seem's to work properly
> # fc-match sans.regular
> DejaVuSans.ttf: "DejaVu Sans" "Book"
> # fc-match sans:regular:roman
> DejaVuSans.ttf: "DejaVu Sans" "Book"
>
> The jvm command line i used:
> java -Dprism.useFontConfig=true -Dprism.debugfonts=true
> -Dprism.verbose=true -cp nalf.jar de.dummy.Main
>
> I took a look at the source which produces the line "Not using FontConfig":
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java#L161
>
> If I read correctly the only case where this output can happen is if
> 'useFontConfig' is false.
>
> The only assignment of 'useFontConfig' is here:
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java#L52
>
> useFontConfig should only be false if the property
> 'prism.useFontConfig' is not equals 'true'. But I set it explicitly to
> "true" (default should also be true).
>
>
> Does anybody have a clue, what's the problem or has anybody an idea
> how to debug this further?
>
>
> Best regards
> Fabian Keller

From nlisker at gmail.com  Wed Jan  8 18:19:06 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 8 Jan 2020 20:19:06 +0200
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <72e4e84c-873e-6857-cf4a-5c71638d1fa3@oracle.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
 <5DF98923.4070409@oracle.com>
 <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>
 <a4405c66-542b-f2b0-7a1a-800300f59bab@oracle.com>
 <CD81E1E3-B95F-4931-ADAC-3B3D07531726@oracle.com>
 <72e4e84c-873e-6857-cf4a-5c71638d1fa3@oracle.com>
Message-ID: <CA+0ynh_eDa_xyGnGP-0yLYcU=ttw-kGKmHVOjGMOc41wP7J-_g@mail.gmail.com>

I forgot to mention that I filed these:

https://bugs.openjdk.java.net/browse/SKARA-218
https://bugs.openjdk.java.net/browse/SKARA-217

They weren't triaged, so maybe the Skara team needs to be notified.

On Thu, Dec 19, 2019 at 6:24 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> FYI, for anyone interested, the Skara team submitted the following PR to
> modify the "ready for integration" message:
>
> https://github.com/openjdk/skara/pull/343
>
> We can file a follow-up RFE to have them consider adding "/reviewers" and
> "/csr" commands.
>
> -- Kevin
>
>
> On 12/18/2019 7:17 PM, Phil Race wrote:
>
> It would have to allow anyone who has reviewer status to add that comment.
> Not just the author since if they knew we would have less need for it.
>
> -Phil.
>
> On Dec 18, 2019, at 11:31 AM, Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
> That's an interesting idea. It would, of course, need to disallow reducing
> the number below the minimum specified in .jcheck/conf (e.g., we wouldn't
> allow "/reviewers 0").
>
> -- Kevin
>
>
> On 12/18/2019 10:36 AM, Nir Lisker wrote:
>
> The client libraries in the OpenJDK do as a default rule, excusing simple
>> fixes.
>>
>
> Then maybe it would be helpful to have a "/reviewers n" command that will
> tell the bot how many reviewers are needed. It's less convoluted than the
> CSR tracking and basically replaces the comment a reviewer would make
> anyway to inform the PR author how many reviewers they should wait for.
> Extending the bot to look for n reviewers instead of the current 1 should
> not be far fetched.
>
>
>
>>
>>
> On Wed, Dec 18, 2019 at 4:02 AM Philip Race <philip.race at oracle.com>
> wrote:
>
>>
>>
>> On 12/16/19, 4:14 PM, Nir Lisker wrote:
>> > Do other projects also have multi-reviewers requirements?
>>
>> The client libraries in the OpenJDK do as a default rule, excusing
>> simple fixes.
>>
>> >
>> > I would think that at least for a CSR, which is OpenJDK-wide, a request
>> > could be put in with the Skara to track it. A Reviewer (or Committer?)
>> > could invoke a /csr command which will require the PR author to provide
>> a
>> > link to the CSR, and check that it was approved as part of the patch
>> > approval process.
>>
>> I think that if there is a CSR sub-task in JBS skara can key off whether
>> that is approved.
>> This does mean skara needs to probe JBS but SFAIK its doing that a
>> hundred times
>> a minute anyway.
>>
>> -phil.
>>
>> >
>> > Not sure how complicated it would be to implement.
>> >
>> > - Nir
>> >
>> > On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth<
>> kevin.rushforth at oracle.com>
>> > wrote:
>> >
>> >> That's a good question about whether we can ask for a slight rewording
>> >> of the Skara bot message to indicate that there might be other things
>> to
>> >> check before "/integrate". I'll raise that question with the Skara
>> team.
>> >>
>> >> As an aside, I noticed the other day that you typed "/integrate" after
>> a
>> >> single review, but in that case, there was no clear indication from
>> Ajit
>> >> (the first reviewer and the sponsor) that a second review was required,
>> >> so I didn't comment on it.
>> >>
>> >> -- Kevin
>> >>
>> >>
>> >> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>> >>> Kevin,
>> >>>
>> >>> thanks for the clarification :) My bad that I didn't re-read the
>> >>> contrib.md. But then, who does? The lazy like myself do it
>> >>> occasionally only (down to once and then forget about it<g>)
>> >>>
>> >>> Maybe the bot message can be improved? With some indication that its
>> >>> (the bot's) knowledge about review requirements is limited, so would
>> >>> require a careful check by the contributor before actually post the
>> >>> /integrate comment? Actually, I think I goofed the other day, was
>> >>> safed only by Ajit who waited for the 2nd review before his /sponsor.
>> >>>
>> >>> -- Jeanette
>> >>>
>> >>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com>:
>> >>>
>> >>>> I added a comment to the two PRs in question, but it bears discussion
>> >>>> here.
>> >>>>
>> >>>> The Skara bot can't know whether all criteria have been met. It
>> >>>> can't, for example, know whether there are outstanding comments from
>> >>>> some reviewers that need to be addressed. Nor does it know which PRs
>> >>>> need two reviewers (or sometimes a third if there is a specific
>> >>>> person we would like to review it), which ones need a CSR, etc.
>> >>>>
>> >>>> So having it state authoritatively that the PR is ready to integrate
>> >>>> is a bit misleading. This is documented in the Code Review section of
>> >>>> the CONTRIBUTING [1] doc:
>> >>>>
>> >>>>> NOTE: while the Skara tooling will indicate that the PR is ready to
>> >>>>> integrate once the first reviewer with a "Reviewer" role in the
>> >>>>> project has approved it, this may or may not be sufficient depending
>> >>>>> on the type of fix. For example, you must wait for a second approval
>> >>>>> for enhancements or high-impact bug fixes.
>> >>>> If anyone can think of a way to improve this and make it more clear,
>> >>>> that would be helpful.
>> >>>>
>> >>>> -- Kevin
>> >>>>
>> >>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>> >>>>
>> >>>>
>> >>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>> >>>>> Looks like it assumes a pull request as properly reviewed as soon as
>> >>>>> it gets a single approve - independent on how many reviewers are
>> >>>>> required, see f.i.
>> >>>>>
>> >>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>> >>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>> >>>>>
>> >>>>> -- Jeanette
>> >>>>>
>> >>>
>> >>>
>> >>
>>
>
>
>

From nlisker at gmail.com  Wed Jan  8 18:31:54 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 8 Jan 2020 20:31:54 +0200
Subject: Should Skara tooling invalidate approvals when new commits are
 pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]
In-Reply-To: <c8c7a4fe-faca-1afc-d8ff-a59dda0a5497@oracle.com>
References: <c8c7a4fe-faca-1afc-d8ff-a59dda0a5497@oracle.com>
Message-ID: <CA+0ynh896r13RHUUK-TrRYjMSqp0SEdKv-7-cquaWdvJGkKVkQ@mail.gmail.com>

Looks like an all-or-nothing situation - either any commit requires
re-approval or no commit requires re-approval. In this case, I would say
that all commits should require re-approval since it's the safer approach.
Having the issue stay in approved state after a significant change is much
worse than requiring the reviewers to take a look at an insignificant
commit and re-approve. The time is takes for a reviewer to go over a
comment or formatting change is short and, I believe, not intrusive to
their workflow.

On Tue, Dec 31, 2019 at 7:48 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Since this isn't directly related to the PR in question, I'm starting a
> new thread.
>
> On 12/20/2019 7:22 PM, Philip Race wrote:
> > On 12/20/19, 7:04 PM, Scott Palmer wrote:
> >> I'm not sure if I'me supposed to try to integrate now that I've made
> >> that 10 ->  0 change, or if the new change resets the need for review...
> >
> > It shows ready, which surprises me.
> > Still learning skara .. I'd expect any change to reset as how can it
> > know if it is
> > a  good or insignificant change or not no matter how the commenter
> > characterised the issue ?
>
> Pushing a new commit doesn't automatically invalidate existing
> approvals, although it is highlighted in the "Approvers" section that
> the approval was for a prior commit:
>
>      Approvers
>          Phil Race (prr - Reviewer) Note! Review applies to f846ad6
>
> I remember bringing this up with the Skara team during my initial
> testing, since I also had wondered whether pushing a new commit should
> invalidate approvals. The current policy allows for doing trivial fixes
> brought up when approving a review (e.g., a change in a comment or
> formatting) without requiring all reviewers to re-approve. It matches
> current practice for email-based reviews, so I think the current
> behavior is a reasonable default.
>
> They did say that they could implement an optional feature (i.e., a
> project would need to opt-in to this behavior, probably via a
> .jcheck/conf property) to invalidate all approvals upon pushing a new
> commit, but I don't think an RFE was filed to track it.
>
> This seems like it could be a valuable feature, although it does come
> with a slight cost in terms of timing and flexibility. What do others
> think?
>
> -- Kevin
>
>

From jvos at openjdk.java.net  Wed Jan  8 19:16:10 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 8 Jan 2020 19:16:10 GMT
Subject: RFR: 8236808: javafx_iio can not be used in static environment
Message-ID: <_JWiI5DVD1nZKpMWN9OyCKHbuuUPzI05gBYZMwwq5-8=.bbd8bc07-ebb3-4b25-9be4-896e4aab6f7e@github.com>

The static JNI_OnLoad naming should be used whenever we are building a static lib (not only for iOS).
We now have the STATIC_BUILD property to determine if we are making a
static build, so we no longer need to check on ios specific patterns.

Fix JDK-8236808

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

Commits:
 - 54c14bb8: The static JNI_OnLoad naming should be used whenever we are building

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

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

From johan at lodgon.com  Wed Jan  8 19:26:00 2020
From: johan at lodgon.com (Johan Vos)
Date: Wed, 8 Jan 2020 20:26:00 +0100
Subject: Should Skara tooling invalidate approvals when new commits are
 pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]
In-Reply-To: <CA+0ynh896r13RHUUK-TrRYjMSqp0SEdKv-7-cquaWdvJGkKVkQ@mail.gmail.com>
References: <c8c7a4fe-faca-1afc-d8ff-a59dda0a5497@oracle.com>
 <CA+0ynh896r13RHUUK-TrRYjMSqp0SEdKv-7-cquaWdvJGkKVkQ@mail.gmail.com>
Message-ID: <CAK7C+XjgQjsVcvFJrBPg5ahqCRP8S9uWQicBVAJcENfkbqJD6A@mail.gmail.com>

I agree. If the fix is trivial, the time for the reviewer will be really
short. The more complex the fix, the more time it will take -- with the
risk of being delayed to the next release.
The github interface makes it very easy to inspect the new commit, hence a
typo in javadoc can easily be fixed and re-approved.

I think this approach is safer than the approach were "trivial" fixes don't
need re-approval, as that approach leaves more room for interpretation (and
probably even more interactions with the reviewers ("is this a trivial
fix?")).

- Johan

Op wo 8 jan. 2020 om 19:34 schreef Nir Lisker <nlisker at gmail.com>:

> Looks like an all-or-nothing situation - either any commit requires
> re-approval or no commit requires re-approval. In this case, I would say
> that all commits should require re-approval since it's the safer approach.
> Having the issue stay in approved state after a significant change is much
> worse than requiring the reviewers to take a look at an insignificant
> commit and re-approve. The time is takes for a reviewer to go over a
> comment or formatting change is short and, I believe, not intrusive to
> their workflow.
>
> On Tue, Dec 31, 2019 at 7:48 PM Kevin Rushforth <
> kevin.rushforth at oracle.com>
> wrote:
>
> > Since this isn't directly related to the PR in question, I'm starting a
> > new thread.
> >
> > On 12/20/2019 7:22 PM, Philip Race wrote:
> > > On 12/20/19, 7:04 PM, Scott Palmer wrote:
> > >> I'm not sure if I'me supposed to try to integrate now that I've made
> > >> that 10 ->  0 change, or if the new change resets the need for
> review...
> > >
> > > It shows ready, which surprises me.
> > > Still learning skara .. I'd expect any change to reset as how can it
> > > know if it is
> > > a  good or insignificant change or not no matter how the commenter
> > > characterised the issue ?
> >
> > Pushing a new commit doesn't automatically invalidate existing
> > approvals, although it is highlighted in the "Approvers" section that
> > the approval was for a prior commit:
> >
> >      Approvers
> >          Phil Race (prr - Reviewer) Note! Review applies to f846ad6
> >
> > I remember bringing this up with the Skara team during my initial
> > testing, since I also had wondered whether pushing a new commit should
> > invalidate approvals. The current policy allows for doing trivial fixes
> > brought up when approving a review (e.g., a change in a comment or
> > formatting) without requiring all reviewers to re-approve. It matches
> > current practice for email-based reviews, so I think the current
> > behavior is a reasonable default.
> >
> > They did say that they could implement an optional feature (i.e., a
> > project would need to opt-in to this behavior, probably via a
> > .jcheck/conf property) to invalidate all approvals upon pushing a new
> > commit, but I don't think an RFE was filed to track it.
> >
> > This seems like it could be a valuable feature, although it does come
> > with a slight cost in terms of timing and flexibility. What do others
> > think?
> >
> > -- Kevin
> >
> >
>

From kevin.rushforth at oracle.com  Wed Jan  8 19:34:22 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 8 Jan 2020 11:34:22 -0800
Subject: Should Skara tooling invalidate approvals when new commits are
 pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]
In-Reply-To: <CAK7C+XjgQjsVcvFJrBPg5ahqCRP8S9uWQicBVAJcENfkbqJD6A@mail.gmail.com>
References: <c8c7a4fe-faca-1afc-d8ff-a59dda0a5497@oracle.com>
 <CA+0ynh896r13RHUUK-TrRYjMSqp0SEdKv-7-cquaWdvJGkKVkQ@mail.gmail.com>
 <CAK7C+XjgQjsVcvFJrBPg5ahqCRP8S9uWQicBVAJcENfkbqJD6A@mail.gmail.com>
Message-ID: <482dd6a0-befd-6c95-e430-fc8789be6fd0@oracle.com>

Does anyone strongly feel otherwise? If not, then I'll request the Skara 
team to enable this feature.

-- Kevin


On 1/8/2020 11:26 AM, Johan Vos wrote:
> I agree. If the fix is trivial, the time for the reviewer will be 
> really short. The more complex the fix, the more time it will take -- 
> with the risk of being delayed to the next release.
> The github interface makes it very easy to inspect the new commit, 
> hence a typo in javadoc can easily be fixed and re-approved.
>
> I think this approach is safer than the approach were "trivial" fixes 
> don't need re-approval, as that approach leaves more room for 
> interpretation (and probably even more interactions with the reviewers 
> ("is this a trivial fix?")).
>
> - Johan
>
> Op wo 8 jan. 2020 om 19:34 schreef Nir Lisker <nlisker at gmail.com 
> <mailto:nlisker at gmail.com>>:
>
>     Looks like an all-or-nothing situation - either any commit requires
>     re-approval or no commit requires re-approval. In this case, I
>     would say
>     that all commits should require re-approval since it's the safer
>     approach.
>     Having the issue stay in approved state after a significant change
>     is much
>     worse than requiring the reviewers to take a look at an insignificant
>     commit and re-approve. The time is takes for a reviewer to go over a
>     comment or formatting change is short and, I believe, not intrusive to
>     their workflow.
>
>     On Tue, Dec 31, 2019 at 7:48 PM Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>     wrote:
>
>     > Since this isn't directly related to the PR in question, I'm
>     starting a
>     > new thread.
>     >
>     > On 12/20/2019 7:22 PM, Philip Race wrote:
>     > > On 12/20/19, 7:04 PM, Scott Palmer wrote:
>     > >> I'm not sure if I'me supposed to try to integrate now that
>     I've made
>     > >> that 10 ->? 0 change, or if the new change resets the need
>     for review...
>     > >
>     > > It shows ready, which surprises me.
>     > > Still learning skara .. I'd expect any change to reset as how
>     can it
>     > > know if it is
>     > > a? good or insignificant change or not no matter how the commenter
>     > > characterised the issue ?
>     >
>     > Pushing a new commit doesn't automatically invalidate existing
>     > approvals, although it is highlighted in the "Approvers" section
>     that
>     > the approval was for a prior commit:
>     >
>     >? ? ? Approvers
>     >? ? ? ? ? Phil Race (prr - Reviewer) Note! Review applies to f846ad6
>     >
>     > I remember bringing this up with the Skara team during my initial
>     > testing, since I also had wondered whether pushing a new commit
>     should
>     > invalidate approvals. The current policy allows for doing
>     trivial fixes
>     > brought up when approving a review (e.g., a change in a comment or
>     > formatting) without requiring all reviewers to re-approve. It
>     matches
>     > current practice for email-based reviews, so I think the current
>     > behavior is a reasonable default.
>     >
>     > They did say that they could implement an optional feature (i.e., a
>     > project would need to opt-in to this behavior, probably via a
>     > .jcheck/conf property) to invalidate all approvals upon pushing
>     a new
>     > commit, but I don't think an RFE was filed to track it.
>     >
>     > This seems like it could be a valuable feature, although it does
>     come
>     > with a slight cost in terms of timing and flexibility. What do
>     others
>     > think?
>     >
>     > -- Kevin
>     >
>     >
>


From nlisker at openjdk.java.net  Thu Jan  9 00:06:34 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 9 Jan 2020 00:06:34 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
Message-ID: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>

The private field `lastPlayFinished` is responsible for 2 cases where an animation in `STOPPED` status does not play after `play()` is called if the rate is negative:

1. When the animation is created, it is `STOPPED` and `lastPlayFinished` is `false`. Setting a negative rate and calling `play()` will not jump to the end of the animation (in order to play it backwards) because the `if (lastPlayedFinished)` check is `false`. Creating the animation with `lastPlayFinished = true` fixes this.
2. When the animation is stopped (if it was not `STOPPED` already), `jumpTo(Duration.ZERO)` sets `lastPlayFinished` to `false`, which causes the same issue above with `play()`. Setting `lastPlayFinished = true` at the end `stop()` fixes this issue.

A test was added for case 2 to check that the playing head indeed jumps to the end of the animation. Without this fix, it stays at the start. Testing case 1 will require a new animation instance since the one in the test is used prior, but I'm not sure it's very helpful.

I'm still somewhat confused as to what constitutes a "last play finished". Any `jumpTo` resets `lastPlayFinished` to `false`, even if the jump is to the start/end of the animation. In this case, stopping an animation, jumping to its start/end, setting the rate to negative/positive, and playing, will do nothing as the end condition is reached immediately. This is what the behavior that was fixed for cases 1 and 2, but maybe this is also incorrect behavior for jumping to start/end.

A test app is included in the "parent" [bug](https://bugs.openjdk.java.net/browse/JDK-8210238), which also mentions a bug relating to **pausing** and playing backwards, so be mindful of it when testing.

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

Commits:
 - 3332a97f: Initial push of 8236753

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

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

From tsayao at openjdk.java.net  Thu Jan  9 02:00:08 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 9 Jan 2020 02:00:08 GMT
Subject: [Rev 06] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <KAYi7WcpCuBdCUl4c2FYpc1IdUrBV3mgysyv6DP4EJg=.0b0025ab-899b-4239-a044-51299466dfbb@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 0dc70ab3: Use gtk_window_set_default_size for before-map sizing which is the appropriate function

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/e4d2a1d2..0dc70ab3

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.06
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.05-06

  Stats: 66 lines in 2 files changed: 32 ins; 18 del; 16 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From kcr at openjdk.java.net  Thu Jan  9 02:40:39 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 9 Jan 2020 02:40:39 GMT
Subject: RFR: 8236733: Change JavaFX release version to 15
In-Reply-To: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>
References: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>
Message-ID: <HZkAFDWO8AOelSQbTJ7_y97B4G6Qlrwf15UFi272wz4=.43e5abfd-aa28-4f41-9c64-8d30d436a3e5@github.com>

On Thu, 9 Jan 2020 02:39:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> JDK-8236733](https://bugs.openjdk.java.net/browse/JDK-8236733).
> 
> Bump the release version to 15. As noted in the JBS issue, I will wait until right after the `jfx14` fork to integrate this.

Reviewer: @arapte

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

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

From kcr at openjdk.java.net  Thu Jan  9 02:40:39 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 9 Jan 2020 02:40:39 GMT
Subject: RFR: 8236733: Change JavaFX release version to 15
Message-ID: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>

JDK-8236733](https://bugs.openjdk.java.net/browse/JDK-8236733).

Bump the release version to 15. As noted in the JBS issue, I will wait until right after the `jfx14` fork to integrate this.

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

Commits:
 - 50f38ab6: 8236733: Change JavaFX release version to 15

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

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

From kcr at openjdk.java.net  Thu Jan  9 02:54:14 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 9 Jan 2020 02:54:14 GMT
Subject: RFR: 8236808: javafx_iio can not be used in static environment
In-Reply-To: <_JWiI5DVD1nZKpMWN9OyCKHbuuUPzI05gBYZMwwq5-8=.bbd8bc07-ebb3-4b25-9be4-896e4aab6f7e@github.com>
References: <_JWiI5DVD1nZKpMWN9OyCKHbuuUPzI05gBYZMwwq5-8=.bbd8bc07-ebb3-4b25-9be4-896e4aab6f7e@github.com>
Message-ID: <CVPGxTvuRpSEooucf61zyJ647w_CkTu-kOTf-FBMx-E=.0cf51dde-fe7b-4362-b1a1-14ce0188fc6e@github.com>

On Wed, 8 Jan 2020 19:14:29 GMT, Johan Vos <jvos at openjdk.org> wrote:

> The static JNI_OnLoad naming should be used whenever we are building a static lib (not only for iOS).
> We now have the STATIC_BUILD property to determine if we are making a
> static build, so we no longer need to check on ios specific patterns.
> 
> Fix JDK-8236808



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

Marked as reviewed by kcr (Lead).

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

From jvos at openjdk.java.net  Thu Jan  9 07:17:16 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 9 Jan 2020 07:17:16 GMT
Subject: [Integrated] RFR: 8236808: javafx_iio can not be used in static
 environment
In-Reply-To: <_JWiI5DVD1nZKpMWN9OyCKHbuuUPzI05gBYZMwwq5-8=.bbd8bc07-ebb3-4b25-9be4-896e4aab6f7e@github.com>
References: <_JWiI5DVD1nZKpMWN9OyCKHbuuUPzI05gBYZMwwq5-8=.bbd8bc07-ebb3-4b25-9be4-896e4aab6f7e@github.com>
Message-ID: <920d44cf-c6ac-48db-84fa-dceffae36d0f@openjdk.org>

Changeset: f9070263
Author:    Johan Vos <jvos at openjdk.org>
Date:      2020-01-09 07:16:52 +0000
URL:       https://git.openjdk.java.net/jfx/commit/f9070263

8236808: javafx_iio can not be used in static environment

Reviewed-by: kcr

! modules/javafx.graphics/src/main/native-iio/jpegloader.c

From adam at adamish.com  Thu Jan  9 08:04:07 2020
From: adam at adamish.com (Adam Granger)
Date: Thu, 09 Jan 2020 00:04:07 -0800
Subject: Memory leak in JavaFX 8 when changing skins
Message-ID: <785950b91556abdf0073e5641129333823ebaa3f@webmail.adamish.com>


Greetings, 

I realise this is now legacy for most people but we still widely use
JavaFX 8. 

I appear to have discovered a memory leak when skin is changed

The constructor
com.sun.javafx.scene.control.skin.BehaviorSkinBase.BehaviorSkinBase
adds an event listener 

?? control.addEventHandler(ContextMenuEvent.CONTEXT_MENU_REQUESTED,
contextMenuHandler);

However this is never removed in the dispose() which prevents garbage
collection of the previous skin.

This problem is amplified by fact JavaFX appears to reload skins
unnecessarily in a complex use case involving JFXPanel? - I've as-yet
been unable to produce a SSCCE for this

What I've discovered so far
?- CSS is reprocessed 

?- javafx.scene.CssStyleHelper.canReuseStyleHelper(Node, StyleMap)
returns false
?- node.styleHelper.resetToInitialValues(node); is called which then
causes the "stock" skin load
?- custom skin (-fx-skin in our application CSS) is then loaded

?- stock skin cannot be GC'd and neither can our custom skin
?- appears to affect any subclass of BehaviorSkinBase

Please could you confirm my analysis of this problem and suggest any
workarounds?

Regards,

Adam


From David.Grieve at microsoft.com  Thu Jan  9 13:58:20 2020
From: David.Grieve at microsoft.com (David Grieve)
Date: Thu, 9 Jan 2020 13:58:20 +0000
Subject: [EXTERNAL] Memory leak in JavaFX 8 when changing skins
In-Reply-To: <785950b91556abdf0073e5641129333823ebaa3f@webmail.adamish.com>
References: <785950b91556abdf0073e5641129333823ebaa3f@webmail.adamish.com>
Message-ID: <BN8PR21MB1281CC64887E1E7B86B71BF39B390@BN8PR21MB1281.namprd21.prod.outlook.com>

Possible workarounds would be to use Control.setSkin instead of -fx-skin, or to bind the skin property after it has been set to something other than the default.  CSS should not mess with a bound property.

> -----Original Message-----
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> Adam Granger
> Sent: Thursday, January 9, 2020 3:04 AM
> To: openjfx-dev at openjdk.java.net
> Subject: [EXTERNAL] Memory leak in JavaFX 8 when changing skins
> 
> 
> Greetings,
> 
> I realise this is now legacy for most people but we still widely use JavaFX 8.
> 
> I appear to have discovered a memory leak when skin is changed
> 
> The constructor
> com.sun.javafx.scene.control.skin.BehaviorSkinBase.BehaviorSkinBase
> adds an event listener
> 
> ?? control.addEventHandler(ContextMenuEvent.CONTEXT_MENU_REQUESTE
> D,
> contextMenuHandler);
> 
> However this is never removed in the dispose() which prevents garbage
> collection of the previous skin.
> 
> This problem is amplified by fact JavaFX appears to reload skins unnecessarily
> in a complex use case involving JFXPanel? - I've as-yet been unable to
> produce a SSCCE for this
> 
> What I've discovered so far
> ?- CSS is reprocessed
> 
> ?- javafx.scene.CssStyleHelper.canReuseStyleHelper(Node, StyleMap)
> returns false
> ?- node.styleHelper.resetToInitialValues(node); is called which then causes
> the "stock" skin load
> ?- custom skin (-fx-skin in our application CSS) is then loaded
> 
> ?- stock skin cannot be GC'd and neither can our custom skin
> ?- appears to affect any subclass of BehaviorSkinBase
> 
> Please could you confirm my analysis of this problem and suggest any
> workarounds?
> 
> Regards,
> 
> Adam


From tom.schindl at bestsolution.at  Thu Jan  9 14:48:40 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 9 Jan 2020 15:48:40 +0100
Subject: DnD Move does not work on OS-X
Message-ID: <6da9010f-e888-6cdb-79cf-35ed844a052d@bestsolution.at>

Hi,

I must be doing something completely wrong or there is a major bug in
JavaFX-DnD from Java-8 upwards to JavaFX-14-ea.

If you run the attached application on OS-X the and press the CMD-key
while dragging you get null for the getTransferMode() inside DragOver
and you don't get a DragDropped and null on the DragDone.

I tracked that back to View#notifyDragOver() where one gets 0 from the
native side. So am I missing something in my code?

I also tried with
https://docs.oracle.com/javafx/2/drag_drop/jfxpub-drag_drop.htm and it
does not work either.

So I guess it's a major bug in openjfx but before filing a jira-ticket I
wanted to make extra sure it's not a stupid mistake, my german operating
system, ...

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
-------------- next part --------------
package bla;

import java.util.UUID;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.input.ClipboardContent;
import javafx.scene.input.Dragboard;
import javafx.scene.input.TransferMode;
import javafx.scene.layout.HBox;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.shape.Rectangle;
import javafx.stage.Stage;

public class SampleApp extends Application {

	@Override
	public void start(Stage primaryStage) throws Exception {
		
		HBox b = new HBox(50);
		
		Rectangle sourceR = new Rectangle(300, 300);
		sourceR.setOnDragDetected( evt -> {
			Dragboard dragboard = sourceR.startDragAndDrop(TransferMode.ANY);
			
			ClipboardContent content = new ClipboardContent();
	        content.putString(UUID.randomUUID().toString());
	        dragboard.setContent(content);
	        
	        evt.consume();
		});
		sourceR.setOnDragDone( evt -> System.err.println("Done: " + evt.getTransferMode()));
		sourceR.setFill(Color.RED);
		
		Rectangle targetR = new Rectangle(300, 300);
		targetR.setOnDragOver( evt -> {
			evt.acceptTransferModes(TransferMode.ANY);
			System.err.println(evt.getTransferMode());
			evt.consume();
		});
		targetR.setOnDragDropped( evt -> {
			System.err.println("Completed: " + evt.getTransferMode());
			evt.setDropCompleted(true);
			evt.consume();
		});
		targetR.setFill(Color.BLUE);
		
		b.getChildren().setAll(sourceR, targetR);
		
		Scene s = new Scene(new VBox(b), 800, 600);
		primaryStage.setScene(s);
		primaryStage.show();
		
	}

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

From arapte at openjdk.java.net  Thu Jan  9 16:12:06 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 9 Jan 2020 16:12:06 GMT
Subject: RFR: 8236733: Change JavaFX release version to 15
In-Reply-To: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>
References: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>
Message-ID: <SykvqHmX92qW6rPjKp-77Yt8NKX_JsCeAI5WzHKWKw0=.949780c1-9af7-4887-9791-21bfac53ed01@github.com>

On Thu, 9 Jan 2020 02:39:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> JDK-8236733](https://bugs.openjdk.java.net/browse/JDK-8236733).
> 
> Bump the release version to 15. As noted in the JBS issue, I will wait until right after the `jfx14` fork to integrate this.

Looks good to me.

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

Marked as reviewed by arapte (Reviewer).

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

From arapte at openjdk.java.net  Thu Jan  9 16:20:36 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 9 Jan 2020 16:20:36 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <PTQzJ7NSc38A5BInppE5ik8--7HbLWCa_y21VIXbtb4=.274fce44-bb1c-42d7-9f53-9533347581b7@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
 <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>
 <dJY6uX8R7fbRyiftmCyh3TuqdUGGy63zll2Qqv3vDnQ=.6dbcd745-a5fd-483c-aa46-16c5b36434b3@github.com>
 <yyD8hlcbDx35EajGmbiPkrynBIsHvjC4HX8AbFBmVmA=.cdeac3c5-a77e-4379-bbf1-be10ab4bcbde@github.com>
 <PTQzJ7NSc38A5BInppE5ik8--7HbLWCa_y21VIXbtb4=.274fce44-bb1c-42d7-9f53-9533347581b7@github.com>
Message-ID: <ZQy8sW1pS9dRsSvoL5uu4vC7155f8vgXCXzz4vNJ6Ak=.f2e15a46-43bd-4a61-a7ec-eb47eefccc07@github.com>

On Fri, 3 Jan 2020 23:50:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi Johan, I did miss to verify this angle.
>> But have checked the code now and can confirm that, in a given function for all possible calls to `setMemErrorFlag()` there exists a call to `readAndClearMemErrorFlag()` in the same function. So it looks safe to remove the memory checks from `dispose()`
> 
> I also looked at the code and don't see any mismatches (including those called from the `ACQUIRE_SURFACE` macro). I suppose you could restore the call, but since we are in a disposer thread throwing an exception doesn't seem like the right thing to do. You could log the error, but if we are sure there can be no pending errors, it might not be worth the effort.

Yes Kevin, After looking at the code it can be concluded that there are no mismatches. So It seems good to remove those checks. But just in case of safety can keep those as logs too.

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

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

From nlisker at openjdk.java.net  Thu Jan  9 18:00:29 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 9 Jan 2020 18:00:29 GMT
Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <zJwg7ZYL4g4Wkkof2-9QMNv7KbM_yvX6yUhJaevIFt4=.c066ee9c-800e-442c-95bb-d733986c5227@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <Wuf0jfTK70vHWQmVQSM1WnS3volV0aCGxBJQ2DI1X6k=.18bae9da-83d1-4749-829a-37a08b7c4955@github.com>
 <zJwg7ZYL4g4Wkkof2-9QMNv7KbM_yvX6yUhJaevIFt4=.c066ee9c-800e-442c-95bb-d733986c5227@github.com>
Message-ID: <rp90fiaLbPYlOQyr2YCZvdqm4BV4zSuEwC1pxxRItIs=.60afaa79-5956-4516-a347-af02420d74ca@github.com>

On Fri, 3 Jan 2020 23:02:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>>> I still need to test your sample app on Mac.
>> 
>> I get the error with your sample app. It fails on Mac or Linux (Ubuntu 16.04) with the same error as I reported above.
> 
> The error was for the cases of 2 and 3 lights (I was testing 1) and should be fixed now. My fault with copy-paste... that's why we use loops, but I guess this is some optimization for the es2 pipeline. I wonder if it's really worth it over a single shader looping over the number of lights like d3d does.

> This will need a fair bit of testing to ensure that there are no regressions either in functionality or (especially) performance, in addition to tests for the new functionality.

Which tests for the new functionality should I write? Up to the shader itself it's mostly just passing on variables, and the API is standard `DoubleProperty`s. I can test the dirty bits / redraw logic.

> On the performance aspect, the inner loop of the lighting calculation now has an additional if test for the max range and additional arithmetic calculations for the attenuation. What we will need is a test program that we can run on Mac and Windows to measure the performance of rendering in a fill-rate-limited case. Ideally, we would not pay much of a performance hit in the default case where `ca == 1, la == 0, qa == 0`, but we first need to be able to measure the drop in performance before we can say whether it is acceptable.

Can you point me to a similar performance test? I didn't see a way to easily measure FPS.
I don't know how to avoid the `if` test for the `maxRange`, I'm open to suggestions. The only thing I can think of is if `maxRange` is infinite (the default), we will swap the shader for one that doesn't make that check. However, swapping shaders also costs performance.

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

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

From kcr at openjdk.java.net  Fri Jan 10 00:19:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Jan 2020 00:19:55 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <ZQy8sW1pS9dRsSvoL5uu4vC7155f8vgXCXzz4vNJ6Ak=.f2e15a46-43bd-4a61-a7ec-eb47eefccc07@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
 <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>
 <dJY6uX8R7fbRyiftmCyh3TuqdUGGy63zll2Qqv3vDnQ=.6dbcd745-a5fd-483c-aa46-16c5b36434b3@github.com>
 <yyD8hlcbDx35EajGmbiPkrynBIsHvjC4HX8AbFBmVmA=.cdeac3c5-a77e-4379-bbf1-be10ab4bcbde@github.com>
 <PTQzJ7NSc38A5BInppE5ik8--7HbLWCa_y21VIXbtb4=.274fce44-bb1c-42d7-9f53-9533347581b7@github.com>
 <ZQy8sW1pS9dRsSvoL5uu4vC7155f8vgXCXzz4vNJ6Ak=.f2e15a46-43bd-4a61-a7ec-eb47eefccc07@github.com>
Message-ID: <RR91qceXGlD0s1vXG4NM-VCCIye208mx46U2_Pfrl5k=.d8d5e390-e7b9-4261-bd58-d4378ece7c3f@github.com>

On Thu, 9 Jan 2020 16:20:19 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> I also looked at the code and don't see any mismatches (including those called from the `ACQUIRE_SURFACE` macro). I suppose you could restore the call, but since we are in a disposer thread throwing an exception doesn't seem like the right thing to do. You could log the error, but if we are sure there can be no pending errors, it might not be worth the effort.
> 
> Yes Kevin, After looking at the code it can be concluded that there are no mismatches. So It seems good to remove those checks. But just in case of safety can keep those as logs too.

I don't have a strong preference. Either removing the checks or leaving them in (with a log message rather than an exception) is fine with me.

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

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

From kcr at openjdk.java.net  Fri Jan 10 00:20:45 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Jan 2020 00:20:45 GMT
Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <S5zMy0iS2Ci2IOfpLz71K6C2PDY6YgXV1M4GYk2Plq0=.7ec6e83d-9ab7-4fa6-8166-cf9e61ac837b@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <VwPeDOOli1pbRVmsImVjH-6Rf7Drpfsk0VnXLXh_Ee4=.94c5fd52-2f05-4c4d-945a-01da7933e64f@github.com>
 <5wmco96mDV2o6049nG257Ac_7cUWQzkRXClNSDHdTYY=.c046919f-25fb-4437-894a-2c5ed5ebc936@github.com>
 <S5zMy0iS2Ci2IOfpLz71K6C2PDY6YgXV1M4GYk2Plq0=.7ec6e83d-9ab7-4fa6-8166-cf9e61ac837b@github.com>
Message-ID: <2zH_P2Wsk4sJxjVr4Ld1hkmqvle077ttr6mQxfxgLv0=.3d1b3909-dac8-4114-9dc6-f575da7adfca@github.com>

On Sat, 4 Jan 2020 18:22:29 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Right. This needs to talk about pixels. Perhaps there is a way to make it more clear that we are talking about pixels that are part of a rendered Shape3D, but I don't have a good suggestion right now.
> 
> Maybe
> 
> A light source that radiates light equally in all directions away from itself. The location of the light
> source is a single point in space. The light affects {@code Shape3D}s in its {@code scope}. Any pixels in
> the light's {@code range} that belong to a {@code Shape3D} will be illuminated by it according to the
> computation specified in {@link PhongMaterial}.
> The docs of `PhongMaterial` will need need to be updated too.

Yes, I think that change to the docs looks good.

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

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

From kcr at openjdk.java.net  Fri Jan 10 00:34:37 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Jan 2020 00:34:37 GMT
Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <rp90fiaLbPYlOQyr2YCZvdqm4BV4zSuEwC1pxxRItIs=.60afaa79-5956-4516-a347-af02420d74ca@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <r7B_LSrZ7OS0wqsJuY0Jb4fYMoApWm2PfEnHGqCRhX8=.204cd343-9a42-4b64-8589-25f1a31d02cf@github.com>
 <Wuf0jfTK70vHWQmVQSM1WnS3volV0aCGxBJQ2DI1X6k=.18bae9da-83d1-4749-829a-37a08b7c4955@github.com>
 <zJwg7ZYL4g4Wkkof2-9QMNv7KbM_yvX6yUhJaevIFt4=.c066ee9c-800e-442c-95bb-d733986c5227@github.com>
 <rp90fiaLbPYlOQyr2YCZvdqm4BV4zSuEwC1pxxRItIs=.60afaa79-5956-4516-a347-af02420d74ca@github.com>
Message-ID: <IIh_dXaELTwdwmm_re5S1CN-1Y6FDMCgLlZkxyLSHFM=.502200a8-8dbc-49ab-b5c2-78b1ac34d7f4@github.com>

On Thu, 9 Jan 2020 18:00:19 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The error was for the cases of 2 and 3 lights (I was testing 1) and should be fixed now. My fault with copy-paste... that's why we use loops, but I guess this is some optimization for the es2 pipeline. I wonder if it's really worth it over a single shader looping over the number of lights like d3d does.
> 
>> This will need a fair bit of testing to ensure that there are no regressions either in functionality or (especially) performance, in addition to tests for the new functionality.
> 
> Which tests for the new functionality should I write? Up to the shader itself it's mostly just passing on variables, and the API is standard `DoubleProperty`s. I can test the dirty bits / redraw logic.
> 
>> On the performance aspect, the inner loop of the lighting calculation now has an additional if test for the max range and additional arithmetic calculations for the attenuation. What we will need is a test program that we can run on Mac and Windows to measure the performance of rendering in a fill-rate-limited case. Ideally, we would not pay much of a performance hit in the default case where `ca == 1, la == 0, qa == 0`, but we first need to be able to measure the drop in performance before we can say whether it is acceptable.
> 
> Can you point me to a similar performance test? I didn't see a way to easily measure FPS.
> I don't know how to avoid the `if` test for the `maxRange`, I'm open to suggestions. The only thing I can think of is if `maxRange` is infinite (the default), we will swap the shader for one that doesn't make that check. However, swapping shaders also costs performance.

We have a few performance tests in apps/performance, but I don't know how up to date they are. They might give you a starting point on how to measure FPS, but really the harder part is going to be coming up with a workload -- a scene with a number of Shape3Ds with large triangles (so that they are fill-rate limited) and 1-3 lights, etc -- that you can use to measure rendering performance without measuring overhead. Typically you want a scene that is rendering continuously in the < 30 fps range, and more like 10 fps to minimize the overhead even more.

Before we figure out whether we need to double the number of shaders (which was one of the ideas that I had as well), we need to know how much of a problem it is. Is it < 2% performance drop on typical cases on a variety of machines or it is a 25% drop (or more likely somewhere in between). If the perf drop is negligible, then it isn't worth doubling the shaders. If it is significant, then we probably need to.

If we do need to double the shaders, I wouldn't do it based on the maxRange being infinite, rather I would do it based on whether attenuation is being used. That way the existing shaders would be unchanged, while the new shader would deal with both attenuation and the maxRange test.

Hopefully, there won't be enough of a perf hit to require doubling the shaders, but we need to be able to measure it.

For functional testing, in addition to the simple API tests, we want to make sure that the basic rendering is working with and without attenuation. Some sort of visual test where you verify that attenuation is / isn't happening as well as testing the cutoff. I wouldn't get too fancy with these...just a sanity test.

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

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

From kcr at openjdk.java.net  Fri Jan 10 00:38:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Jan 2020 00:38:15 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
Message-ID: <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>

On Wed, 8 Jan 2020 23:52:07 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> The private field `lastPlayFinished` is responsible for 2 cases where an animation in `STOPPED` status does not play after `play()` is called if the rate is negative:
> 
> 1. When the animation is created, it is `STOPPED` and `lastPlayFinished` is `false`. Setting a negative rate and calling `play()` will not jump to the end of the animation (in order to play it backwards) because the `if (lastPlayedFinished)` check is `false`. Creating the animation with `lastPlayFinished = true` fixes this. However, `SequentialTransitionPlayTest#testCycleReverse`'s initial state test implies that the original behavior is correct. *That test currently fails with this change.* Either the fix is reverted or the test is corrected.
> 2. When the animation is stopped (if it was not `STOPPED` already), `jumpTo(Duration.ZERO)` sets `lastPlayFinished` to `false`, which causes the same issue above with `play()`. Setting `lastPlayFinished = true` at the end `stop()` fixes this issue.
> 
> A test was added for case 2 to check that the playing head indeed jumps to the end of the animation. Without this fix, it stays at the start.
> 
> I'm still somewhat confused as to what constitutes a "last play finished". Any `jumpTo` resets `lastPlayFinished` to `false`, even if the jump is to the start/end of the animation. In this case, stopping an animation, jumping to its start/end, setting the rate to negative/positive, and playing, will do nothing as the end condition is reached immediately. This is what the behavior that was fixed for cases 1 and 2, but maybe this is also incorrect behavior for jumping to start/end.
> 
> A test app is included in the "parent" [bug](https://bugs.openjdk.java.net/browse/JDK-8210238), which also mentions a bug relating to **pausing** and playing backwards, so be mindful of it when testing.

I'll review this next week. This seems a fine candidate for openjfx14, so it (along with a couple other pending reviews that can be for 14) will be a good test of targeting a PR to the stabilization branch.

I also request @arapte to review.

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

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

From kcr at openjdk.java.net  Fri Jan 10 00:40:04 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Jan 2020 00:40:04 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
Message-ID: <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>

On Fri, 10 Jan 2020 00:37:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The private field `lastPlayFinished` is responsible for 2 cases where an animation in `STOPPED` status does not play after `play()` is called if the rate is negative:
>> 
>> 1. When the animation is created, it is `STOPPED` and `lastPlayFinished` is `false`. Setting a negative rate and calling `play()` will not jump to the end of the animation (in order to play it backwards) because the `if (lastPlayedFinished)` check is `false`. Creating the animation with `lastPlayFinished = true` fixes this. However, `SequentialTransitionPlayTest#testCycleReverse`'s initial state test implies that the original behavior is correct. *That test currently fails with this change.* Either the fix is reverted or the test is corrected.
>> 2. When the animation is stopped (if it was not `STOPPED` already), `jumpTo(Duration.ZERO)` sets `lastPlayFinished` to `false`, which causes the same issue above with `play()`. Setting `lastPlayFinished = true` at the end `stop()` fixes this issue.
>> 
>> A test was added for case 2 to check that the playing head indeed jumps to the end of the animation. Without this fix, it stays at the start.
>> 
>> I'm still somewhat confused as to what constitutes a "last play finished". Any `jumpTo` resets `lastPlayFinished` to `false`, even if the jump is to the start/end of the animation. In this case, stopping an animation, jumping to its start/end, setting the rate to negative/positive, and playing, will do nothing as the end condition is reached immediately. This is what the behavior that was fixed for cases 1 and 2, but maybe this is also incorrect behavior for jumping to start/end.
>> 
>> A test app is included in the "parent" [bug](https://bugs.openjdk.java.net/browse/JDK-8210238), which also mentions a bug relating to **pausing** and playing backwards, so be mindful of it when testing.
> 
> I'll review this next week. This seems a fine candidate for openjfx14, so it (along with a couple other pending reviews that can be for 14) will be a good test of targeting a PR to the stabilization branch.
> 
> I also request @arapte to review.

I should add that it will depend on whether there are any regressions. One thing we do need to be careful of is introducing regressions during rampdown.

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

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

From tsayao at openjdk.java.net  Fri Jan 10 01:54:45 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Fri, 10 Jan 2020 01:54:45 GMT
Subject: [Rev 07] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <IOCCrwt-0L6-pa-5to2XVboH9GekZ-rfZrZDcQQhCDA=.181a6fa7-ee6b-48fb-8281-a7556e009dff@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 209b7ac7: Better alternative calculation for no _NET_FRAME_EXTENTS WM extension

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/0dc70ab3..209b7ac7

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.07
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.06-07

  Stats: 70 lines in 2 files changed: 54 ins; 3 del; 13 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From arapte at openjdk.java.net  Fri Jan 10 08:18:35 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 10 Jan 2020 08:18:35 GMT
Subject: RFR: 8227619: Potential memory leak in javafx.scene.control.ListView
Message-ID: <H8CFzXyzXsNE1-fPC0iCMQvBqMFx6J-7b6IiZ4GXu-U=.b0760f71-59f3-4c77-b72b-47422ff39027@github.com>

`ListView` does not get GCed because `SelectedItemsReadOnlyObservableList` adds a `ListChangeListener` to the (`ObservableList`) items of `ListView`.

Adding a `WeakListChangeListener` instead of `ListChangeListener` fixes the issue.

Added a unit test and verified that existing tests do not fail due to this change.

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

Commits:
 - 60ee7d03: 8227619: Potential memory leak in javafx.scene.control.ListView

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

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

From r.lichtenberger at gmail.com  Fri Jan 10 08:30:09 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Fri, 10 Jan 2020 09:30:09 +0100
Subject: Build Problems due to deprecations (linux)
Message-ID: <CA+f4zAF8wQhAiEZG2wh5pAF8OYEa5N6Y4HVuVnxV4zXFfyoQSA@mail.gmail.com>

 I've tried to run a build of OpenJFX and it fails due to some deprecations
within gtk-2:

...

In file included from /usr/include/gtk-2.0/gtk/gtkobject.h:37,

                 from /usr/include/gtk-2.0/gtk/gtkwidget.h:36,
                 from /usr/include/gtk-2.0/gtk/gtkcontainer.h:35,
                 from /usr/include/gtk-2.0/gtk/gtkbin.h:35,
                 from /usr/include/gtk-2.0/gtk/gtkwindow.h:36,
                 from /usr/include/gtk-2.0/gtk/gtkdialog.h:35,
                 from /usr/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
                 from /usr/include/gtk-2.0/gtk/gtk.h:33,
                 from
/home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:36:

/usr/include/gtk-2.0/gtk/gtktypeutils.h:236:1: error: 'GTypeDebugFlags' is
deprecated [-Werror=deprecated-declarations]
  236 | void            gtk_type_init   (GTypeDebugFlags debug_flags);
      | ^~~~
In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/glib-2.0/gio/gioenums.h:28,
                 from /usr/include/glib-2.0/gio/giotypes.h:28,
                 from /usr/include/glib-2.0/gio/gio.h:26,
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
                 from
/home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:36:

/usr/include/glib-2.0/gobject/gtype.h:679:1: note: declared here
  679 | {
      | ^
In file included from /usr/include/gtk-2.0/gtk/gtktoolitem.h:31,
                 from /usr/include/gtk-2.0/gtk/gtktoolbutton.h:30,
                 from /usr/include/gtk-2.0/gtk/gtkmenutoolbutton.h:30,
                 from /usr/include/gtk-2.0/gtk/gtk.h:126,
                 from
/home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:36:

/usr/include/gtk-2.0/gtk/gtktooltips.h:73:3: error: 'GTimeVal' is
deprecated: Use 'GDateTime' instead [-Werror=deprecated-declarations]
   73 |   GTimeVal last_popdown;
      |   ^~~~~~~~
In file included from /usr/include/glib-2.0/glib/galloca.h:32,
                 from /usr/include/glib-2.0/glib.h:30,
                 from /usr/include/glib-2.0/gobject/gbinding.h:28,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/glib-2.0/gio/gioenums.h:28,
                 from /usr/include/glib-2.0/gio/giotypes.h:28,
                 from /usr/include/glib-2.0/gio/gio.h:26,
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
                 from
/home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:36:

/usr/include/glib-2.0/glib/gtypes.h:551:8: note: declared here
  551 | struct _GTimeVal
      |        ^~~~~~~~~

...

Questions:

* Should I open a bug for that?

* How can I turn off  -Werror to proceed with the local build for now. I
thought there was something in
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX but I can't
find it (anymore)


Best regards,

Robert

From r.lichtenberger at gmail.com  Fri Jan 10 08:52:02 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Fri, 10 Jan 2020 09:52:02 +0100
Subject: "Using an IDE" Page outdated
Message-ID: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>

I've noticed that https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
longer exists, etc.).

Could someone please update this page so that it is easier for newcomers to
dive into the development of OpenJFX.

Thanks,
Robert

From kcr at openjdk.java.net  Fri Jan 10 13:20:14 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Jan 2020 13:20:14 GMT
Subject: [Integrated] RFR: 8236733: Change JavaFX release version to 15
In-Reply-To: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>
References: <DEv5rytXTDRT93yu0v3F66VKWhGwTqHQm4t7HRvxwNk=.46004e6b-c35f-434e-a18c-4f173786e430@github.com>
Message-ID: <ade68867-f26c-442a-a81d-d290ff684a95@openjdk.org>

Changeset: a557dd95
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-10 13:19:21 +0000
URL:       https://git.openjdk.java.net/jfx/commit/a557dd95

8236733: Change JavaFX release version to 15

Reviewed-by: arapte

! build.properties
! modules/javafx.base/src/test/java/test/com/sun/javafx/runtime/VersionInfoTest.java

From kevin.rushforth at oracle.com  Fri Jan 10 15:52:35 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 10 Jan 2020 07:52:35 -0800
Subject: OpenJFX 14 is in Rampdown Phase One (RDP1)
Message-ID: <aa85391f-e476-3852-803d-6379a47f9ce0@oracle.com>

OpenJFX 14 is now in Rampdown Phase One (RDP1) [1]. We have forked a new 
jfx14 branch [2] for stabilizing the OpenJFX 14 release.

Here is the short summary of what this means:

- The master branch of the jfx repo is available for integrating bug 
fixes or enhancements for OpenJFX 15. Most fixes will be integrated to 
master for 15.

- The jfx14 branch of the jfx repo is now open for integrating fixes for 
OpenJFX 14 that meet the RDP1 criteria as outlined below.

- Reviewers and Committers now have an additional responsibility to 
verify the target branch of each pull request.

- I will periodically sync jfx14 --> master, meaning that developers 
should integrate fixes to one or the other, not both


DETAILS:

P1-P3 bug fixes, and test or doc fixes of any priority are good 
candidates for integrating to jfx14 during RDP1. The only hard 
restriction is that enhancements need explicit approval, over and above 
the review of the PR, to go into jfx14. The bar for such approval is 
high: we do not anticipate approving any more enhancements. We also need 
to be careful to avoid potentially risky fixes during this time. Note 
that these restrictions apply to the jfx14 branch. The master branch is 
open for all openjfx15 fixes, including enhancements.

With the switch to git for our official repo, we are now using a single 
openjdk/jfx GitHub repo with stabilization branches [3] rather than 
creating separate stabilization repos, which we used to do with 
Mercurial. The jfx14 branch of the openjdk/jfx git repo is conceptually 
the same as the 13-dev/rt HG repo that was used for stabilizing 
openjfx13, but the mechanics are slightly different, so please be aware, 
especially if you are a Reviewer or Committer in the Project. This 
change should make it much easier for developers (no need to clone from 
multiple repos), and will allow all pull requests to all be in the same 
place, but care needs to be taken for any PR that is targeted to jfx14 
to ensure that it doesn't contain any commits from master after the 
jfx14 fork date. What that means is that if you intend a PR to be for 
jfx14, don't merge master into your local source branch.

IMPORTANT: Reviewers and Committers now have an extra responsibility to 
double-check the target branch of each PR that they review, integrate, 
or sponsor. By default a PR will be targeted to `master` which is the 
main development line (OpenJFX 15 as of today). A PR should be targeted 
to `jfx14` if, and only if, it is intended for OpenJFX 14 and meets the 
criteria for the current rampdown phase (we're in RDP1 as of today). 
Reviewers are advised to be extra cautious in approving potentially 
risky fixes targeted to `jfx14`. If there is a concern, then a reviewer 
can as part of the review indicate that the PR should be retargeted to 
`master` for 15. Reviewers also need to be extra careful when reviewing 
PRs targeted to jfx14 that it doesn't mistakenly contain any commits 
from the master branch. You'll be able to tell because the diffs will 
contain changes that are not part of the fix being reviewed. Such a PR 
will either need to be closed and redone, or it will need to be rebased 
and force-pushed.

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

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

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

3. No explicit approval (no JBS labels) is needed to integrate P4 bugs 
to jfx14 branch during RDP1, as long as those bugs have otherwise met 
the usual code review criteria. Having said that, most P4 bugs should 
now go into master for openjfx15, since we do not want to risk anything 
that would destabilize the openjfx14 release without a compelling 
reason. Also, we have less than 4 weeks until RDP2 of openjfx14 and we 
would be better served fixing higher priority bugs. Note that doc bugs 
and test bugs of any priority are fine to fix for openjfx14 during this 
time.

Let me know if there are any questions.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-December/024331.html

[2] https://github.com/openjdk/jfx/tree/jfx14

[3] https://github.com/openjdk/jfx/branches/all

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


From nlisker at gmail.com  Fri Jan 10 16:52:26 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 10 Jan 2020 18:52:26 +0200
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
Message-ID: <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>

Hi Robert,

I've brought this up in the past.

I think that the best solution is for someone from the community to take
that task. I try to keep the Eclipse section updated, we will need someone
for the other IDE's.

- Nir

On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:

> I've noticed that
> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
> longer exists, etc.).
>
> Could someone please update this page so that it is easier for newcomers to
> dive into the development of OpenJFX.
>
> Thanks,
> Robert
>

From kevin.rushforth at oracle.com  Fri Jan 10 17:01:46 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 10 Jan 2020 09:01:46 -0800
Subject: Retargeting JBS bugs to openjfx15
Message-ID: <78f23350-91d0-e87f-a5a5-c78eb3521527@oracle.com>

Now that we are in RDP1 for openjfx14, it's time to move all 
enhancements and most P4-P5 bugs (excluding doc and test bugs) to 
openjfx15. I plan to do a bulk move for these bugs shortly. If an 
assignee of a particular P4 bug later wants to propose a PR for the 
jfx14 branch, and if the reviewers agree it is safe enough and worth 
getting in, then the JBS bug can have its fix version updated back to 
openjfx14.

Additionally, many P3 bugs should be moved, but that can be done on a 
case-by-case basis.

-- Kevin


From nlisker at gmail.com  Sat Jan 11 01:08:08 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 11 Jan 2020 03:08:08 +0200
Subject: Rate of embedded animations
In-Reply-To: <e9dee0f6-aba6-b787-849c-6f319049a99f@oracle.com>
References: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>
 <e9dee0f6-aba6-b787-849c-6f319049a99f@oracle.com>
Message-ID: <CA+0ynh8COobS1QUiiwQOaEtv=3ph9RqKAniUqG3xfw0vcnbNmg@mail.gmail.com>

>
> What happens if you set the rate of the parent transition and then set the
> rate of a child animation?
>
What if you bind to the rate of a child animation?


There is already some code that touches this in the Animation's rate
property:

public void invalidated() {
    final double newRate = getRate();
    if (isRunningEmbedded()) {
        if (isBound()) {
            unbind();
        }
        set(oldRate);
        throw new IllegalStateException("Cannot set rate of embedded
animation while running.");
    }

isRunningEmbedded checks for a parent animation that is not STOPPED. That
means that the rate of a child animation can only change while the parent
is stopped, but it is ignored (the child's ClipEnvelope's rate is updated
to the parent's rate instead).
Binding to the rate property is never an issue, but it does give
meaningless results since the rate is ignored. Binding the rate property
itself will cause it to be unbinded.

If we go with option 1, which is almost the current situation, there is
only some cleanup needed when it comes to the relation between the
Animation's rate and its ClipEnvelope's rate.

If we go with option 2, we can eliminate the duplication of rate in the
Animation and the ClipEnvelope (though ClipEvenope to Animation is somewhat
like a peer to a Node, which duplicates the values as well, so maybe we
want that?). The children's rate will always be the parent's rate. In this
case the above code should probably be modified to account for STOPPED
parents as well. A bound rate property will be unbinded and setting it will
be either ignored or throw an exception.

I'll note that currentRate is eliminated from the ClipEnvelope in the fix
I'm working on, but as it's read-only, it's a different story.

As long as the implementation
> is consistent in ignoring the rate property from the child Animation,
> this seems like a fine solution and is consistent with other properties
> where one property overrides another without modifying it.


Which other properties? delay, autoReverse, and cycleCount all work
separately on the parent and child. For example, if both parent and child
have autoReverse = true and cycleCount = 2, the animation will play
forwards, backwards, forwards, backwards, so both are taken into account.


On Wed, Jan 8, 2020 at 1:14 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> A rate in a "parent" transition should probably override the rate in a
> child Animation. There are a couple ways to do it, and it sounds like it
> doesn't really implement it right.
>
> 1. The public rate property values of child Animations within a parent
> Transition are ignored, but not updated. As long as the implementation
> is consistent in ignoring the rate property from the child Animation,
> this seems like a fine solution and is consistent with other properties
> where one property overrides another without modifying it.
>
> 2. Setting a rate on the parent Transition actually modifies the child
> node. This can work, but has more issues. What happens if you set the
> rate of the parent tansition and then set the rate of a child animation?
> What if you bind to the rate of a child animation?
>
> -- Kevin
>
> On 1/1/2020 1:04 PM, Nir Lisker wrote:
> > Hi,
> >
> > As part of my work in the animations package I've come across an
> undefined
> > spec. Is the rate of an animation that is embedded in a
> Parallel/Sequential
> > transition inherited and overridden by its parent?
> >
> > If I have an animations with a rate of 1 and a parent with a rate of 2,
> and
> > I add the animation to the parent, does the rate property change from 1
> to
> > 2 (generating a change/invalidation event etc.)? Then, should any
> > subsequent changes to the parent's rate trigger a change in the child's
> > rate?
> >
> > The implementation is a bit messy in this regard. The rate and
> currentRate
> > values exist in both Animation and its ClipEnvelope, which is the source
> > for a couple of bugs. For example, changing the rate of a
> > ParallelTransition changes the child's ClipEnvelope's rate and
> currentRate,
> > but only the animation's currentRate (and not rate). Is it supposed to be
> > this way?
> >
> > What is clear is that it's not possible to change the rate of the
> embedded
> > animation directly.
> >
> > The docs do not talk about the rate of an embedded animation (they do
> talk
> > about the node property though).
> >
> > - Nir
>
>

From nlisker at gmail.com  Sat Jan 11 02:45:42 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 11 Jan 2020 04:45:42 +0200
Subject: Rate of embedded animations
In-Reply-To: <CA+0ynh8COobS1QUiiwQOaEtv=3ph9RqKAniUqG3xfw0vcnbNmg@mail.gmail.com>
References: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>
 <e9dee0f6-aba6-b787-849c-6f319049a99f@oracle.com>
 <CA+0ynh8COobS1QUiiwQOaEtv=3ph9RqKAniUqG3xfw0vcnbNmg@mail.gmail.com>
Message-ID: <CA+0ynh-XP4Zxno62bAddKkyvqWMAMofcoOKWrLKdzd4yAY0BjA@mail.gmail.com>

I forgot to bring up https://bugs.openjdk.java.net/browse/JDK-8200206,
which is also relevant to this discussion. The solution to that one is
probably allowing only 1 parent, similar to the scenegraph policy. That
will avoid parent animations fighting over the state of common children
animations.

On Sat, Jan 11, 2020 at 3:08 AM Nir Lisker <nlisker at gmail.com> wrote:

> What happens if you set the rate of the parent transition and then set the
>> rate of a child animation?
>>
> What if you bind to the rate of a child animation?
>
>
> There is already some code that touches this in the Animation's rate
> property:
>
> public void invalidated() {
>     final double newRate = getRate();
>     if (isRunningEmbedded()) {
>         if (isBound()) {
>             unbind();
>         }
>         set(oldRate);
>         throw new IllegalStateException("Cannot set rate of embedded
> animation while running.");
>     }
>
> isRunningEmbedded checks for a parent animation that is not STOPPED. That
> means that the rate of a child animation can only change while the parent
> is stopped, but it is ignored (the child's ClipEnvelope's rate is updated
> to the parent's rate instead).
> Binding to the rate property is never an issue, but it does give
> meaningless results since the rate is ignored. Binding the rate property
> itself will cause it to be unbinded.
>
> If we go with option 1, which is almost the current situation, there is
> only some cleanup needed when it comes to the relation between the
> Animation's rate and its ClipEnvelope's rate.
>
> If we go with option 2, we can eliminate the duplication of rate in the
> Animation and the ClipEnvelope (though ClipEvenope to Animation is somewhat
> like a peer to a Node, which duplicates the values as well, so maybe we
> want that?). The children's rate will always be the parent's rate. In this
> case the above code should probably be modified to account for STOPPED
> parents as well. A bound rate property will be unbinded and setting it will
> be either ignored or throw an exception.
>
> I'll note that currentRate is eliminated from the ClipEnvelope in the fix
> I'm working on, but as it's read-only, it's a different story.
>
> As long as the implementation
>> is consistent in ignoring the rate property from the child Animation,
>> this seems like a fine solution and is consistent with other properties
>> where one property overrides another without modifying it.
>
>
> Which other properties? delay, autoReverse, and cycleCount all work
> separately on the parent and child. For example, if both parent and child
> have autoReverse = true and cycleCount = 2, the animation will play
> forwards, backwards, forwards, backwards, so both are taken into account.
>
>
> On Wed, Jan 8, 2020 at 1:14 AM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> A rate in a "parent" transition should probably override the rate in a
>> child Animation. There are a couple ways to do it, and it sounds like it
>> doesn't really implement it right.
>>
>> 1. The public rate property values of child Animations within a parent
>> Transition are ignored, but not updated. As long as the implementation
>> is consistent in ignoring the rate property from the child Animation,
>> this seems like a fine solution and is consistent with other properties
>> where one property overrides another without modifying it.
>>
>> 2. Setting a rate on the parent Transition actually modifies the child
>> node. This can work, but has more issues. What happens if you set the
>> rate of the parent tansition and then set the rate of a child animation?
>> What if you bind to the rate of a child animation?
>>
>> -- Kevin
>>
>> On 1/1/2020 1:04 PM, Nir Lisker wrote:
>> > Hi,
>> >
>> > As part of my work in the animations package I've come across an
>> undefined
>> > spec. Is the rate of an animation that is embedded in a
>> Parallel/Sequential
>> > transition inherited and overridden by its parent?
>> >
>> > If I have an animations with a rate of 1 and a parent with a rate of 2,
>> and
>> > I add the animation to the parent, does the rate property change from 1
>> to
>> > 2 (generating a change/invalidation event etc.)? Then, should any
>> > subsequent changes to the parent's rate trigger a change in the child's
>> > rate?
>> >
>> > The implementation is a bit messy in this regard. The rate and
>> currentRate
>> > values exist in both Animation and its ClipEnvelope, which is the source
>> > for a couple of bugs. For example, changing the rate of a
>> > ParallelTransition changes the child's ClipEnvelope's rate and
>> currentRate,
>> > but only the animation's currentRate (and not rate). Is it supposed to
>> be
>> > this way?
>> >
>> > What is clear is that it's not possible to change the rate of the
>> embedded
>> > animation directly.
>> >
>> > The docs do not talk about the rate of an embedded animation (they do
>> talk
>> > about the node property though).
>> >
>> > - Nir
>>
>>

From kcr at openjdk.java.net  Sat Jan 11 17:53:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 11 Jan 2020 17:53:55 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
Message-ID: <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>

On Tue, 7 Jan 2020 09:46:03 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
> This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).
> 
> Issue.
> - `Parent.viewOrderChildren` is a list of children sorted according to view order.
> - `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.
> 
> - Below is the scenario mentioned in this issue,
> 1. `TabPane` is created with few `tabs`.
> 2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
> 3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
> 4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
> So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.
> 
> Fix:
> Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
> `Parent.viewOrderChildren` will be computed on next `pulse`.
> This will maintain lazy computation of `Parent.viewOrderChildren`. 
> 
> Added a system test, fails without fix and passes with. No failures in existing tests.

@arapte - This bug looks like a good candidate for JavaFX 14. Can you retarget this PR to the jfx14 branch?

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

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

From tsayao at openjdk.java.net  Sun Jan 12 01:00:42 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Sun, 12 Jan 2020 01:00:42 GMT
Subject: [Rev 08] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <HCzBEfh3P9nuhZ-HL45CFiWJTjQKiSzY7iykbuPgmPM=.6350360a-a2d8-4ea5-8535-78faf9a1b054@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 9850bb71: Fix dialog with owner sizing

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/209b7ac7..9850bb71

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.08
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.07-08

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

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

From tsayao at openjdk.java.net  Sun Jan 12 01:28:47 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Sun, 12 Jan 2020 01:28:47 GMT
Subject: [Rev 09] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <_76aIZTlPIWQOheXR83SrgOL-lYXe4pWvfPNSS0Dgrk=.4ac927c8-d489-4fdb-939a-b40ab069f54e@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f99aebcf: Maybe fix background

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/9850bb71..f99aebcf

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.09
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.08-09

  Stats: 12 lines in 1 file changed: 6 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From tsayao at openjdk.java.net  Sun Jan 12 21:11:59 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Sun, 12 Jan 2020 21:11:59 GMT
Subject: [Rev 10] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <nQ8tNepTa-Dd_18WrAMs9RvOOvE5sCS8QD3zwBTvUsY=.268d26cd-3f72-41d2-989f-0d23cec2fadd@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> 
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f35fa9b1: Big cleanup

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/f99aebcf..f35fa9b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.10
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.09-10

  Stats: 1836 lines in 5 files changed: 634 ins; 765 del; 437 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From abhinay_agarwal at live.com  Mon Jan 13 05:45:22 2020
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Mon, 13 Jan 2020 05:45:22 +0000
Subject: Maximized undecorated stage
In-Reply-To: <81781b6e-63c9-7fed-da3e-690afd0fe97d@oracle.com>
References: <PS1PR03MB470070FB7C44A6BEDC65F39AE73C0@PS1PR03MB4700.apcprd03.prod.outlook.com>,
 <81781b6e-63c9-7fed-da3e-690afd0fe97d@oracle.com>
Message-ID: <PS1PR03MB47007BDD81AC398F67DDEFB8E7350@PS1PR03MB4700.apcprd03.prod.outlook.com>

Hi Kevin,

Sounds logical.

I will file an issue in the JBS.

Best regards,
Abhinay
________________________________
From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Sent: Wednesday, January 8, 2020 4:36 AM
To: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Subject: Re: Maximized undecorated stage

Ideally, we wouldn't have this sort of platform-specific behavior. I can
see why the underlying platform might not support the concept of
maximizing an undecorated stage, so we either need to disable it on
Windows, live with the behavior, or else find some solution on macOS and
Linux.

-- Kevin


On 1/6/2020 1:43 AM, Abhinay Agarwal wrote:
> Hi,
>
> If maximize property is set to true for an undecorated Stage, the following behaviour is observed on different platforms:
>
>    *   Windows: Undecorated stage is maximized
>    *   MacOS: Undecorated stage is not maximized
>    *   Linux(Ubuntu): Undecorated stage is not maximized
>
> The following piece of code can be used to reproduce the behaviour:
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.Label;
> import javafx.scene.layout.StackPane;
> import javafx.stage.Stage;
> import javafx.stage.StageStyle;
>
> public class MaximizedStage extends Application {
>      public void start (Stage stage) {
>          StackPane sp = new StackPane(new Label("Hello"));
>          stage.setScene(new Scene (sp, 500, 500));
>          stage.initStyle(StageStyle.UNDECORATED);
>          stage.show();
>          stage.setMaximized(true);
>      }
> }
>
>   Is there a reason why the stage gets maximized on Windows but fails on other platforms?
>
> Regards,
> Abhinay


From thiago.sayao at clamed.com.br  Mon Jan 13 11:52:41 2020
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Mon, 13 Jan 2020 11:52:41 +0000
Subject: [Rev 08] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <HCzBEfh3P9nuhZ-HL45CFiWJTjQKiSzY7iykbuPgmPM=.6350360a-a2d8-4ea5-8535-78faf9a1b054@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>,
 <HCzBEfh3P9nuhZ-HL45CFiWJTjQKiSzY7iykbuPgmPM=.6350360a-a2d8-4ea5-8535-78faf9a1b054@github.com>
Message-ID: <CP2P15201MB2228FD1EFB096B2A7E71720BDE350@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

Hello users of this list.

While fixing some bugs on glass-gtk backend I had some noticed some quite complex logic to mimic windows behavior on linux - for example, on linux window decorations are a job do the window manager - which may vary. So window sizes does not account decorations.

Also, the gtk2 -> gtk3 migration could use some improvement because gtk3 does a lot of "deprecations" - even inside the gtk3 release cycle.

There was a lot of code regarding applets and web start, which are discontinued.

So this PR simplifies te code (specially sizing a positioning of windows), updates to gtk3 recent changes (while being compatible with older releases)  and removes web start / applet code.

It also eliminates some restrictions on DND. It will work with all text formats and all image formats that both gtk and javafx supports.

It's working very well. So if anyone is willing to test, or take a look.

I need to do more testing on:

  *   Mouse grabs to mimic windows behavior;
  *   Native _setBackground call

Any pointers on uses cases for this is appreciated.

Cheers.


________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Thiago Milczarek Sayao <tsayao at openjdk.java.net>
Enviado: s?bado, 11 de janeiro de 2020 22:00
Para: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Assunto: Re: [Rev 08] RFR: WIP: 8236651: Simplify and update glass gtk backend

> This proposed change does the following:
>
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
>
>
> In general it reduces code size and complexity and hands more work to gtk.
>
> Important notice: As I could not test the code for handling web start and web applets because browsers do not support it anymore and java has removed "javaws", I took the liberty to remove the code. Will restore if necessary.
>
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 9850bb71: Fix dialog with owner sizing

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/209b7ac7..9850bb71

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.08
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.07-08

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

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

From arapte at openjdk.java.net  Mon Jan 13 16:49:57 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 13 Jan 2020 16:49:57 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
 <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>
Message-ID: <SqRVa5K3OG5_J7Jr008FlEdvsHT0mQpO2n_tM6l1hww=.0ba849dc-aa8b-40ea-9983-d166f7918d50@github.com>

On Mon, 13 Jan 2020 16:49:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @arapte - This bug looks like a good candidate for JavaFX 14. Can you retarget this PR to the jfx14 branch?
> 
> This will need a second reviewer.
> 
> @aghaisas can you review this, too?

> 
> 
> @arapte - This bug looks like a good candidate for JavaFX 14. Can you retarget this PR to the jfx14 branch?

Thanks for guiding Kevin, PR is now targeted to jfx14.

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

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

From kcr at openjdk.java.net  Mon Jan 13 16:49:57 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 13 Jan 2020 16:49:57 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
Message-ID: <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>

On Sat, 11 Jan 2020 17:53:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
>> This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).
>> 
>> Issue.
>> - `Parent.viewOrderChildren` is a list of children sorted according to view order.
>> - `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.
>> 
>> - Below is the scenario mentioned in this issue,
>> 1. `TabPane` is created with few `tabs`.
>> 2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
>> 3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
>> 4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
>> So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.
>> 
>> Fix:
>> Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
>> `Parent.viewOrderChildren` will be computed on next `pulse`.
>> This will maintain lazy computation of `Parent.viewOrderChildren`. 
>> 
>> Added a system test, fails without fix and passes with. No failures in existing tests.
> 
> @arapte - This bug looks like a good candidate for JavaFX 14. Can you retarget this PR to the jfx14 branch?

This will need a second reviewer.

@aghaisas can you review this, too?

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

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

From nlisker at gmail.com  Mon Jan 13 16:59:03 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 13 Jan 2020 18:59:03 +0200
Subject: "Using an IDE" Page outdated
In-Reply-To: <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
Message-ID: <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>

Never seen this problem before. Did you run a Gradle build? [1] It needs to
generated required resources.

Also, the Eclipse files for some projects are not updated (though for the
modules they are fine, so it's not the problem you are having). My patch
for them was pending review by other Eclipse users and no one tested it, so
if you are up for it I could resume work on it.

- Nir

[1]
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest

On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
r.lichtenberger at synedra.com> wrote:

> Hmm. Eclipse would suit me fine, so I've tried to import a current OpenJFX
> repository to Eclipse but it gives me (among others) this error:
>
> Description    Resource    Path    Location    Type
> Cannot nest
> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
> inside library
> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'    base
>     Build path    Build Path Problem
>
> The Workspace was completely new, all the other stuff (JDK 12, Java
> Compiliance Level) should be ok.
>
> Do you have any idea what is going wrong here? Smells like module system
> problems :-(.
>
>
> Best regards,
>
> Robert
> On 2020-01-10 17:52, Nir Lisker wrote:
>
> Hi Robert,
>
> I've brought this up in the past.
>
> I think that the best solution is for someone from the community to take
> that task. I try to keep the Eclipse section updated, we will need someone
> for the other IDE's.
>
> - Nir
>
> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
> r.lichtenberger at gmail.com> wrote:
>
>> I've noticed that
>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
>> longer exists, etc.).
>>
>> Could someone please update this page so that it is easier for newcomers
>> to
>> dive into the development of OpenJFX.
>>
>> Thanks,
>> Robert
>>
>

From tsayao at openjdk.java.net  Tue Jan 14 01:05:48 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 14 Jan 2020 01:05:48 GMT
Subject: [Rev 11] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <JhwWV8e_w6eGPPEaS7a9VEqAz2SPO5R1JlbCMNNpBTA=.7946bf17-f4b5-4983-a16d-d6d3f93b4166@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code.
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 4b555624: Allow undecorated windows to be maximized.

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/f35fa9b1..4b555624

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.11
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.10-11

  Stats: 20 lines in 2 files changed: 13 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From thiago.sayao at clamed.com.br  Tue Jan 14 01:06:54 2020
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Tue, 14 Jan 2020 01:06:54 +0000
Subject: Maximized undecorated stage
In-Reply-To: <PS1PR03MB47007BDD81AC398F67DDEFB8E7350@PS1PR03MB4700.apcprd03.prod.outlook.com>
References: <PS1PR03MB470070FB7C44A6BEDC65F39AE73C0@PS1PR03MB4700.apcprd03.prod.outlook.com>,
 <81781b6e-63c9-7fed-da3e-690afd0fe97d@oracle.com>,
 <PS1PR03MB47007BDD81AC398F67DDEFB8E7350@PS1PR03MB4700.apcprd03.prod.outlook.com>
Message-ID: <CP2P15201MB2228A71B2E7CEE04DA7EFCECDE340@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

I have fixed it on Linux:

https://github.com/openjdk/jfx/pull/77


Can be ported to the current code:

void WindowContext::set_maximized(bool maximize) {
    is_maximized = maximize;
    if (maximize) {
        // enable the functionality
        GdkWMFunction wmf = (GdkWMFunction)(gdk_windowManagerFunctions | GDK_FUNC_MAXIMIZE);
        gdk_window_set_functions(gdk_window, wmf);

        gtk_window_maximize(GTK_WINDOW(gtk_widget));
    } else {
        gtk_window_unmaximize(GTK_WINDOW(gtk_widget));
    }
}

________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Abhinay Agarwal <abhinay_agarwal at live.com>
Enviado: segunda-feira, 13 de janeiro de 2020 02:45
Para: Kevin Rushforth <kevin.rushforth at oracle.com>; openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Assunto: Re: Maximized undecorated stage

Hi Kevin,

Sounds logical.

I will file an issue in the JBS.

Best regards,
Abhinay
________________________________
From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Sent: Wednesday, January 8, 2020 4:36 AM
To: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Subject: Re: Maximized undecorated stage

Ideally, we wouldn't have this sort of platform-specific behavior. I can
see why the underlying platform might not support the concept of
maximizing an undecorated stage, so we either need to disable it on
Windows, live with the behavior, or else find some solution on macOS and
Linux.

-- Kevin


On 1/6/2020 1:43 AM, Abhinay Agarwal wrote:
> Hi,
>
> If maximize property is set to true for an undecorated Stage, the following behaviour is observed on different platforms:
>
>    *   Windows: Undecorated stage is maximized
>    *   MacOS: Undecorated stage is not maximized
>    *   Linux(Ubuntu): Undecorated stage is not maximized
>
> The following piece of code can be used to reproduce the behaviour:
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.Label;
> import javafx.scene.layout.StackPane;
> import javafx.stage.Stage;
> import javafx.stage.StageStyle;
>
> public class MaximizedStage extends Application {
>      public void start (Stage stage) {
>          StackPane sp = new StackPane(new Label("Hello"));
>          stage.setScene(new Scene (sp, 500, 500));
>          stage.initStyle(StageStyle.UNDECORATED);
>          stage.show();
>          stage.setMaximized(true);
>      }
> }
>
>   Is there a reason why the stage gets maximized on Windows but fails on other platforms?
>
> Regards,
> Abhinay


From r.lichtenberger at gmail.com  Tue Jan 14 07:12:21 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 08:12:21 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
Message-ID: <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>

Yes, I did run a gradle build (for which I had to tweak
buildSrc/linux.gradle to ignore some deprecations -- see my other post to
the list) successfully.

I use a completely fresh workspace, updated my JFX sources, I use Eclipse
2019-12 and jdk-13.0.1+9 on Fedora 31.

These are my steps:
* open eclipse,
* choose "Import projects" then "Gradle" -> "Existing Gradle project"
* give the top level folder of my repository (/home/rli/PWEs/jfx in my case)
* Use the gradle wrapper (i.e. no changes on the wizards next page)
* The project structure is given correctly, so I click finish

Eclipse then loads the projects but gives out the aforementioned error.

I've made a 1-minute video clip showing my steps:
https://youtu.be/S9WnOHCbWLI

I'll try to find out what is going wrong here. Could you tell me which
versions (JFX sources, Eclipse, JDK) you are using?


Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker <nlisker at gmail.com>:

> Never seen this problem before. Did you run a Gradle build? [1] It needs to
> generated required resources.
>
> Also, the Eclipse files for some projects are not updated (though for the
> modules they are fine, so it's not the problem you are having). My patch
> for them was pending review by other Eclipse users and no one tested it, so
> if you are up for it I could resume work on it.
>
> - Nir
>
> [1]
>
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
>
> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
> r.lichtenberger at synedra.com> wrote:
>
> > Hmm. Eclipse would suit me fine, so I've tried to import a current
> OpenJFX
> > repository to Eclipse but it gives me (among others) this error:
> >
> > Description    Resource    Path    Location    Type
> > Cannot nest
> >
> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
> > inside library
> > 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'    base
> >     Build path    Build Path Problem
> >
> > The Workspace was completely new, all the other stuff (JDK 12, Java
> > Compiliance Level) should be ok.
> >
> > Do you have any idea what is going wrong here? Smells like module system
> > problems :-(.
> >
> >
> > Best regards,
> >
> > Robert
> > On 2020-01-10 17:52, Nir Lisker wrote:
> >
> > Hi Robert,
> >
> > I've brought this up in the past.
> >
> > I think that the best solution is for someone from the community to take
> > that task. I try to keep the Eclipse section updated, we will need
> someone
> > for the other IDE's.
> >
> > - Nir
> >
> > On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
> > r.lichtenberger at gmail.com> wrote:
> >
> >> I've noticed that
> >> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
> >> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
> >> longer exists, etc.).
> >>
> >> Could someone please update this page so that it is easier for newcomers
> >> to
> >> dive into the development of OpenJFX.
> >>
> >> Thanks,
> >> Robert
> >>
> >
>

From tom.schindl at bestsolution.at  Tue Jan 14 07:53:26 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 14 Jan 2020 08:53:26 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
Message-ID: <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>

Hi,

I think Nir nor I uses them as gradle Projects because you have the
.classpath, .project, ... .

Tom

On 14.01.20 08:12, Robert Lichtenberger wrote:
> Yes, I did run a gradle build (for which I had to tweak
> buildSrc/linux.gradle to ignore some deprecations -- see my other post to
> the list) successfully.
> 
> I use a completely fresh workspace, updated my JFX sources, I use Eclipse
> 2019-12 and jdk-13.0.1+9 on Fedora 31.
> 
> These are my steps:
> * open eclipse,
> * choose "Import projects" then "Gradle" -> "Existing Gradle project"
> * give the top level folder of my repository (/home/rli/PWEs/jfx in my case)
> * Use the gradle wrapper (i.e. no changes on the wizards next page)
> * The project structure is given correctly, so I click finish
> 
> Eclipse then loads the projects but gives out the aforementioned error.
> 
> I've made a 1-minute video clip showing my steps:
> https://youtu.be/S9WnOHCbWLI
> 
> I'll try to find out what is going wrong here. Could you tell me which
> versions (JFX sources, Eclipse, JDK) you are using?
> 
> 
> Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker <nlisker at gmail.com>:
> 
>> Never seen this problem before. Did you run a Gradle build? [1] It needs to
>> generated required resources.
>>
>> Also, the Eclipse files for some projects are not updated (though for the
>> modules they are fine, so it's not the problem you are having). My patch
>> for them was pending review by other Eclipse users and no one tested it, so
>> if you are up for it I could resume work on it.
>>
>> - Nir
>>
>> [1]
>>
>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
>>
>> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
>> r.lichtenberger at synedra.com> wrote:
>>
>>> Hmm. Eclipse would suit me fine, so I've tried to import a current
>> OpenJFX
>>> repository to Eclipse but it gives me (among others) this error:
>>>
>>> Description    Resource    Path    Location    Type
>>> Cannot nest
>>>
>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
>>> inside library
>>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'    base
>>>     Build path    Build Path Problem
>>>
>>> The Workspace was completely new, all the other stuff (JDK 12, Java
>>> Compiliance Level) should be ok.
>>>
>>> Do you have any idea what is going wrong here? Smells like module system
>>> problems :-(.
>>>
>>>
>>> Best regards,
>>>
>>> Robert
>>> On 2020-01-10 17:52, Nir Lisker wrote:
>>>
>>> Hi Robert,
>>>
>>> I've brought this up in the past.
>>>
>>> I think that the best solution is for someone from the community to take
>>> that task. I try to keep the Eclipse section updated, we will need
>> someone
>>> for the other IDE's.
>>>
>>> - Nir
>>>
>>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
>>> r.lichtenberger at gmail.com> wrote:
>>>
>>>> I've noticed that
>>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
>>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
>>>> longer exists, etc.).
>>>>
>>>> Could someone please update this page so that it is easier for newcomers
>>>> to
>>>> dive into the development of OpenJFX.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>
>>

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From r.lichtenberger at gmail.com  Tue Jan 14 08:11:36 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 09:11:36 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
Message-ID: <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>

I've tried to import using "General" -> "Existing Projects in Workspace"
but get lots of errors as well. When reducing the imported projects to
base, graphics and controls:
* base is ok
* graphics has these errors:
Description Resource Path Location Type
Project 'graphics' is missing required source folder: 'build/hlsl/Decora'
graphics Build path Build Path Problem
Project 'graphics' is missing required source folder: 'build/hlsl/Prism'
graphics Build path Build Path Problem
* controls won't build due to errors in graphics

Is hlsl the "High Level Shading Language" which may be specific to Windows?

Am Di., 14. Jan. 2020 um 08:53 Uhr schrieb Tom Schindl <
tom.schindl at bestsolution.at>:

> Hi,
>
> I think Nir nor I uses them as gradle Projects because you have the
> .classpath, .project, ... .
>
> Tom
>
> On 14.01.20 08:12, Robert Lichtenberger wrote:
> > Yes, I did run a gradle build (for which I had to tweak
> > buildSrc/linux.gradle to ignore some deprecations -- see my other post to
> > the list) successfully.
> >
> > I use a completely fresh workspace, updated my JFX sources, I use Eclipse
> > 2019-12 and jdk-13.0.1+9 on Fedora 31.
> >
> > These are my steps:
> > * open eclipse,
> > * choose "Import projects" then "Gradle" -> "Existing Gradle project"
> > * give the top level folder of my repository (/home/rli/PWEs/jfx in my
> case)
> > * Use the gradle wrapper (i.e. no changes on the wizards next page)
> > * The project structure is given correctly, so I click finish
> >
> > Eclipse then loads the projects but gives out the aforementioned error.
> >
> > I've made a 1-minute video clip showing my steps:
> > https://youtu.be/S9WnOHCbWLI
> >
> > I'll try to find out what is going wrong here. Could you tell me which
> > versions (JFX sources, Eclipse, JDK) you are using?
> >
> >
> > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker <nlisker at gmail.com
> >:
> >
> >> Never seen this problem before. Did you run a Gradle build? [1] It
> needs to
> >> generated required resources.
> >>
> >> Also, the Eclipse files for some projects are not updated (though for
> the
> >> modules they are fine, so it's not the problem you are having). My patch
> >> for them was pending review by other Eclipse users and no one tested
> it, so
> >> if you are up for it I could resume work on it.
> >>
> >> - Nir
> >>
> >> [1]
> >>
> >>
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
> >>
> >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
> >> r.lichtenberger at synedra.com> wrote:
> >>
> >>> Hmm. Eclipse would suit me fine, so I've tried to import a current
> >> OpenJFX
> >>> repository to Eclipse but it gives me (among others) this error:
> >>>
> >>> Description    Resource    Path    Location    Type
> >>> Cannot nest
> >>>
> >>
> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
> >>> inside library
> >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'    base
> >>>     Build path    Build Path Problem
> >>>
> >>> The Workspace was completely new, all the other stuff (JDK 12, Java
> >>> Compiliance Level) should be ok.
> >>>
> >>> Do you have any idea what is going wrong here? Smells like module
> system
> >>> problems :-(.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Robert
> >>> On 2020-01-10 17:52, Nir Lisker wrote:
> >>>
> >>> Hi Robert,
> >>>
> >>> I've brought this up in the past.
> >>>
> >>> I think that the best solution is for someone from the community to
> take
> >>> that task. I try to keep the Eclipse section updated, we will need
> >> someone
> >>> for the other IDE's.
> >>>
> >>> - Nir
> >>>
> >>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
> >>> r.lichtenberger at gmail.com> wrote:
> >>>
> >>>> I've noticed that
> >>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
> >>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
> >>>> longer exists, etc.).
> >>>>
> >>>> Could someone please update this page so that it is easier for
> newcomers
> >>>> to
> >>>> dive into the development of OpenJFX.
> >>>>
> >>>> Thanks,
> >>>> Robert
> >>>>
> >>>
> >>
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From nlisker at gmail.com  Tue Jan 14 08:22:56 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 14 Jan 2020 10:22:56 +0200
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
Message-ID: <CA+0ynh8DXVQ8+khLenNVGW7KPkkrrRudZcug_9FkVzwTsyGz8w@mail.gmail.com>

I think your errors come from the note under "Using Gradle" in the Eclipse
instructions. Gradle doesn't know how to create the correct Eclipse files,
so it overrides the ones in the repo with its incorrect ones. Try to revert
the changes to .project and .classpath files.

You might still get a few errors when looking for external jars because the
root project name is different, but these are trivial to fix. The base
modules should have no errors at the very least.

I should update the instructions to talk about the new repository since the
current ones still mention mercurial.

Is hlsl the "High Level Shading Language" which may be specific to Windows?


Yes, but it should be ignored on non-Windows systems. I will have to
recheck if there's any issue on Linux next time I boot into it, I don't
remember any issues there.

>
>

On Tue, Jan 14, 2020 at 10:12 AM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:

> I've tried to import using "General" -> "Existing Projects in Workspace"
> but get lots of errors as well. When reducing the imported projects to
> base, graphics and controls:
> * base is ok
> * graphics has these errors:
> Description Resource Path Location Type
> Project 'graphics' is missing required source folder: 'build/hlsl/Decora'
> graphics Build path Build Path Problem
> Project 'graphics' is missing required source folder: 'build/hlsl/Prism'
> graphics Build path Build Path Problem
> * controls won't build due to errors in graphics
>
> Is hlsl the "High Level Shading Language" which may be specific to Windows?
>
> Am Di., 14. Jan. 2020 um 08:53 Uhr schrieb Tom Schindl <
> tom.schindl at bestsolution.at>:
>
> > Hi,
> >
> > I think Nir nor I uses them as gradle Projects because you have the
> > .classpath, .project, ... .
> >
> > Tom
> >
> > On 14.01.20 08:12, Robert Lichtenberger wrote:
> > > Yes, I did run a gradle build (for which I had to tweak
> > > buildSrc/linux.gradle to ignore some deprecations -- see my other post
> to
> > > the list) successfully.
> > >
> > > I use a completely fresh workspace, updated my JFX sources, I use
> Eclipse
> > > 2019-12 and jdk-13.0.1+9 on Fedora 31.
> > >
> > > These are my steps:
> > > * open eclipse,
> > > * choose "Import projects" then "Gradle" -> "Existing Gradle project"
> > > * give the top level folder of my repository (/home/rli/PWEs/jfx in my
> > case)
> > > * Use the gradle wrapper (i.e. no changes on the wizards next page)
> > > * The project structure is given correctly, so I click finish
> > >
> > > Eclipse then loads the projects but gives out the aforementioned error.
> > >
> > > I've made a 1-minute video clip showing my steps:
> > > https://youtu.be/S9WnOHCbWLI
> > >
> > > I'll try to find out what is going wrong here. Could you tell me which
> > > versions (JFX sources, Eclipse, JDK) you are using?
> > >
> > >
> > > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker <
> nlisker at gmail.com
> > >:
> > >
> > >> Never seen this problem before. Did you run a Gradle build? [1] It
> > needs to
> > >> generated required resources.
> > >>
> > >> Also, the Eclipse files for some projects are not updated (though for
> > the
> > >> modules they are fine, so it's not the problem you are having). My
> patch
> > >> for them was pending review by other Eclipse users and no one tested
> > it, so
> > >> if you are up for it I could resume work on it.
> > >>
> > >> - Nir
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
> > >>
> > >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
> > >> r.lichtenberger at synedra.com> wrote:
> > >>
> > >>> Hmm. Eclipse would suit me fine, so I've tried to import a current
> > >> OpenJFX
> > >>> repository to Eclipse but it gives me (among others) this error:
> > >>>
> > >>> Description    Resource    Path    Location    Type
> > >>> Cannot nest
> > >>>
> > >>
> >
> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
> > >>> inside library
> > >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'
> base
> > >>>     Build path    Build Path Problem
> > >>>
> > >>> The Workspace was completely new, all the other stuff (JDK 12, Java
> > >>> Compiliance Level) should be ok.
> > >>>
> > >>> Do you have any idea what is going wrong here? Smells like module
> > system
> > >>> problems :-(.
> > >>>
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Robert
> > >>> On 2020-01-10 17:52, Nir Lisker wrote:
> > >>>
> > >>> Hi Robert,
> > >>>
> > >>> I've brought this up in the past.
> > >>>
> > >>> I think that the best solution is for someone from the community to
> > take
> > >>> that task. I try to keep the Eclipse section updated, we will need
> > >> someone
> > >>> for the other IDE's.
> > >>>
> > >>> - Nir
> > >>>
> > >>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
> > >>> r.lichtenberger at gmail.com> wrote:
> > >>>
> > >>>> I've noticed that
> > >>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
> > >>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which
> no
> > >>>> longer exists, etc.).
> > >>>>
> > >>>> Could someone please update this page so that it is easier for
> > newcomers
> > >>>> to
> > >>>> dive into the development of OpenJFX.
> > >>>>
> > >>>> Thanks,
> > >>>> Robert
> > >>>>
> > >>>
> > >>
> >
> > --
> > Tom Schindl, CTO
> > BestSolution.at EDV Systemhaus GmbH
> > Salurnerstrasse 15. A-6020 Innsbruck
> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >
>

From tom.schindl at bestsolution.at  Tue Jan 14 08:23:42 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 14 Jan 2020 09:23:42 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
Message-ID: <c5e7bdf6-9af9-c7dc-9bd0-5d7b0b42920a@bestsolution.at>

Well those are created by the build not?

I have to confess, that I did not setup Eclipse for OpenJFX-Development
lately but I'm fairly certain those directories are generated by the build.

Tom

On 14.01.20 09:11, Robert Lichtenberger wrote:
> I've tried to import using "General" -> "Existing Projects in Workspace"
> but get lots of errors as well. When reducing the imported projects to
> base, graphics and controls:
> * base is ok
> * graphics has these errors:
> Description Resource Path Location Type
> Project 'graphics' is missing required source folder:
> 'build/hlsl/Decora' graphics Build path Build Path Problem
> Project 'graphics' is missing required source folder: 'build/hlsl/Prism'
> graphics Build path Build Path Problem
> * controls won't build due to errors in graphics
> 
> Is hlsl the "High Level Shading Language" which may be specific to Windows?
> 
> Am Di., 14. Jan. 2020 um 08:53?Uhr schrieb Tom Schindl
> <tom.schindl at bestsolution.at <mailto:tom.schindl at bestsolution.at>>:
> 
>     Hi,
> 
>     I think Nir nor I uses them as gradle Projects because you have the
>     .classpath, .project, ... .
> 
>     Tom
> 
>     On 14.01.20 08:12, Robert Lichtenberger wrote:
>     > Yes, I did run a gradle build (for which I had to tweak
>     > buildSrc/linux.gradle to ignore some deprecations -- see my other
>     post to
>     > the list) successfully.
>     >
>     > I use a completely fresh workspace, updated my JFX sources, I use
>     Eclipse
>     > 2019-12 and jdk-13.0.1+9 on Fedora 31.
>     >
>     > These are my steps:
>     > * open eclipse,
>     > * choose "Import projects" then "Gradle" -> "Existing Gradle project"
>     > * give the top level folder of my repository (/home/rli/PWEs/jfx
>     in my case)
>     > * Use the gradle wrapper (i.e. no changes on the wizards next page)
>     > * The project structure is given correctly, so I click finish
>     >
>     > Eclipse then loads the projects but gives out the aforementioned
>     error.
>     >
>     > I've made a 1-minute video clip showing my steps:
>     > https://youtu.be/S9WnOHCbWLI
>     >
>     > I'll try to find out what is going wrong here. Could you tell me which
>     > versions (JFX sources, Eclipse, JDK) you are using?
>     >
>     >
>     > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker
>     <nlisker at gmail.com <mailto:nlisker at gmail.com>>:
>     >
>     >> Never seen this problem before. Did you run a Gradle build? [1]
>     It needs to
>     >> generated required resources.
>     >>
>     >> Also, the Eclipse files for some projects are not updated (though
>     for the
>     >> modules they are fine, so it's not the problem you are having).
>     My patch
>     >> for them was pending review by other Eclipse users and no one
>     tested it, so
>     >> if you are up for it I could resume work on it.
>     >>
>     >> - Nir
>     >>
>     >> [1]
>     >>
>     >>
>     https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
>     >>
>     >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
>     >> r.lichtenberger at synedra.com <mailto:r.lichtenberger at synedra.com>>
>     wrote:
>     >>
>     >>> Hmm. Eclipse would suit me fine, so I've tried to import a current
>     >> OpenJFX
>     >>> repository to Eclipse but it gives me (among others) this error:
>     >>>
>     >>> Description? ? Resource? ? Path? ? Location? ? Type
>     >>> Cannot nest
>     >>>
>     >>
>     'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
>     >>> inside library
>     >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'?
>     ? base
>     >>>? ? ?Build path? ? Build Path Problem
>     >>>
>     >>> The Workspace was completely new, all the other stuff (JDK 12, Java
>     >>> Compiliance Level) should be ok.
>     >>>
>     >>> Do you have any idea what is going wrong here? Smells like
>     module system
>     >>> problems :-(.
>     >>>
>     >>>
>     >>> Best regards,
>     >>>
>     >>> Robert
>     >>> On 2020-01-10 17:52, Nir Lisker wrote:
>     >>>
>     >>> Hi Robert,
>     >>>
>     >>> I've brought this up in the past.
>     >>>
>     >>> I think that the best solution is for someone from the community
>     to take
>     >>> that task. I try to keep the Eclipse section updated, we will need
>     >> someone
>     >>> for the other IDE's.
>     >>>
>     >>> - Nir
>     >>>
>     >>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
>     >>> r.lichtenberger at gmail.com <mailto:r.lichtenberger at gmail.com>> wrote:
>     >>>
>     >>>> I've noticed that
>     >>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
>     >>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt",
>     which no
>     >>>> longer exists, etc.).
>     >>>>
>     >>>> Could someone please update this page so that it is easier for
>     newcomers
>     >>>> to
>     >>>> dive into the development of OpenJFX.
>     >>>>
>     >>>> Thanks,
>     >>>> Robert
>     >>>>
>     >>>
>     >>
> 
>     -- 
>     Tom Schindl, CTO
>     BestSolution.at EDV Systemhaus GmbH
>     Salurnerstrasse 15. A-6020 Innsbruck
>     Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From r.lichtenberger at gmail.com  Tue Jan 14 08:36:54 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 09:36:54 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
Message-ID: <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>

I've just simply removed the two missing source folders and only one error
remains:
* The blank final field dialog may not have been initialized Dialog.java
/controls/src/main/java/javafx/scene/control line 521
which seems to me like an error within the eclipse compiler.

Ignoring this error, I've tried to execute
test.javafx.scene.control.ButtonTest from the IDE but get:

> Graphics Device initialization failed for :  es2, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> java.lang.RuntimeException: java.lang.RuntimeException: Error initializing
> QuantumRenderer: no suitable pipeline found
> at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
> ...
>
Debugging into com.sun.prism.GraphicsPipeline I can see that for
com.sun.prism.es2.ES2Pipeline I get this exception:
java.lang.UnsatisfiedLinkError: no prism_es2 in java.library.path:
[/usr/lib64/mysql, /opt/synedra/lib/opencv-dcm,
/home/rli/devel/repository/tool/linux/64, ., /usr/java/packages/lib,
/usr/lib64, /lib64, /lib, /usr/lib]

As mentioned on the wiki, I've added
-Djava.library.path=/home/rli/PWEs/jfx/modules/javafx.graphics/build/module-lib
as VM argument which fixes the loading of ES2Pipeline.

However I still can't run the test, I get:
java.lang.ExceptionInInitializerError
at
javafx.controls/test.javafx.scene.control.ButtonTest.setup(ButtonTest.java:83)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
...
Caused by: java.lang.IllegalStateException: Toolkit not initialized
at
javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
at
javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
at
javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
at
javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
at javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
... 25 more

java.lang.NullPointerException
at
javafx.controls/test.javafx.scene.control.ButtonTest.after(ButtonTest.java:93)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
...

it seems the test does not wait for the toolkit to be initialized ...

Am Di., 14. Jan. 2020 um 09:11 Uhr schrieb Robert Lichtenberger <
r.lichtenberger at gmail.com>:

> I've tried to import using "General" -> "Existing Projects in Workspace"
> but get lots of errors as well. When reducing the imported projects to
> base, graphics and controls:
> * base is ok
> * graphics has these errors:
> Description Resource Path Location Type
> Project 'graphics' is missing required source folder: 'build/hlsl/Decora'
> graphics Build path Build Path Problem
> Project 'graphics' is missing required source folder: 'build/hlsl/Prism'
> graphics Build path Build Path Problem
> * controls won't build due to errors in graphics
>
> Is hlsl the "High Level Shading Language" which may be specific to Windows?
>
> Am Di., 14. Jan. 2020 um 08:53 Uhr schrieb Tom Schindl <
> tom.schindl at bestsolution.at>:
>
>> Hi,
>>
>> I think Nir nor I uses them as gradle Projects because you have the
>> .classpath, .project, ... .
>>
>> Tom
>>
>> On 14.01.20 08:12, Robert Lichtenberger wrote:
>> > Yes, I did run a gradle build (for which I had to tweak
>> > buildSrc/linux.gradle to ignore some deprecations -- see my other post
>> to
>> > the list) successfully.
>> >
>> > I use a completely fresh workspace, updated my JFX sources, I use
>> Eclipse
>> > 2019-12 and jdk-13.0.1+9 on Fedora 31.
>> >
>> > These are my steps:
>> > * open eclipse,
>> > * choose "Import projects" then "Gradle" -> "Existing Gradle project"
>> > * give the top level folder of my repository (/home/rli/PWEs/jfx in my
>> case)
>> > * Use the gradle wrapper (i.e. no changes on the wizards next page)
>> > * The project structure is given correctly, so I click finish
>> >
>> > Eclipse then loads the projects but gives out the aforementioned error.
>> >
>> > I've made a 1-minute video clip showing my steps:
>> > https://youtu.be/S9WnOHCbWLI
>> >
>> > I'll try to find out what is going wrong here. Could you tell me which
>> > versions (JFX sources, Eclipse, JDK) you are using?
>> >
>> >
>> > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker <
>> nlisker at gmail.com>:
>> >
>> >> Never seen this problem before. Did you run a Gradle build? [1] It
>> needs to
>> >> generated required resources.
>> >>
>> >> Also, the Eclipse files for some projects are not updated (though for
>> the
>> >> modules they are fine, so it's not the problem you are having). My
>> patch
>> >> for them was pending review by other Eclipse users and no one tested
>> it, so
>> >> if you are up for it I could resume work on it.
>> >>
>> >> - Nir
>> >>
>> >> [1]
>> >>
>> >>
>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
>> >>
>> >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
>> >> r.lichtenberger at synedra.com> wrote:
>> >>
>> >>> Hmm. Eclipse would suit me fine, so I've tried to import a current
>> >> OpenJFX
>> >>> repository to Eclipse but it gives me (among others) this error:
>> >>>
>> >>> Description    Resource    Path    Location    Type
>> >>> Cannot nest
>> >>>
>> >>
>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
>> >>> inside library
>> >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'
>> base
>> >>>     Build path    Build Path Problem
>> >>>
>> >>> The Workspace was completely new, all the other stuff (JDK 12, Java
>> >>> Compiliance Level) should be ok.
>> >>>
>> >>> Do you have any idea what is going wrong here? Smells like module
>> system
>> >>> problems :-(.
>> >>>
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Robert
>> >>> On 2020-01-10 17:52, Nir Lisker wrote:
>> >>>
>> >>> Hi Robert,
>> >>>
>> >>> I've brought this up in the past.
>> >>>
>> >>> I think that the best solution is for someone from the community to
>> take
>> >>> that task. I try to keep the Eclipse section updated, we will need
>> >> someone
>> >>> for the other IDE's.
>> >>>
>> >>> - Nir
>> >>>
>> >>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
>> >>> r.lichtenberger at gmail.com> wrote:
>> >>>
>> >>>> I've noticed that
>> >>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
>> >>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which
>> no
>> >>>> longer exists, etc.).
>> >>>>
>> >>>> Could someone please update this page so that it is easier for
>> newcomers
>> >>>> to
>> >>>> dive into the development of OpenJFX.
>> >>>>
>> >>>> Thanks,
>> >>>> Robert
>> >>>>
>> >>>
>> >>
>>
>> --
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Salurnerstrasse 15. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>
>

From tom.schindl at bestsolution.at  Tue Jan 14 08:47:26 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 14 Jan 2020 09:47:26 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
 <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>
Message-ID: <96dfdb57-dad2-6118-52aa-9da8c508c1d9@bestsolution.at>

On 14.01.20 09:36, Robert Lichtenberger wrote:
> I've just simply removed the two missing source folders and only one
> error remains:
> * The blank final field dialog may not have been initialized Dialog.java
> /controls/src/main/java/javafx/scene/control line 521
> which seems to me like an error within the eclipse compiler.
> 
> Ignoring this error, I've tried to execute

yes it is and it is already logged in Bugzilla there - you can just
remove final in your local workspace ;-)

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From tom.schindl at bestsolution.at  Tue Jan 14 08:50:07 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 14 Jan 2020 09:50:07 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <96dfdb57-dad2-6118-52aa-9da8c508c1d9@bestsolution.at>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
 <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>
 <96dfdb57-dad2-6118-52aa-9da8c508c1d9@bestsolution.at>
Message-ID: <8c5c0f52-3df3-f467-5801-6f606ea8f1dc@bestsolution.at>

I think the issue there is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=507629 as Nir commented
there as well I'm fairly sure this is the one you see ;-)

Tom

On 14.01.20 09:47, Tom Schindl wrote:
> On 14.01.20 09:36, Robert Lichtenberger wrote:
>> I've just simply removed the two missing source folders and only one
>> error remains:
>> * The blank final field dialog may not have been initialized Dialog.java
>> /controls/src/main/java/javafx/scene/control line 521
>> which seems to me like an error within the eclipse compiler.
>>
>> Ignoring this error, I've tried to execute
> 
> yes it is and it is already logged in Bugzilla there - you can just
> remove final in your local workspace ;-)
> 
> Tom
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From nlisker at gmail.com  Tue Jan 14 08:49:55 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 14 Jan 2020 10:49:55 +0200
Subject: "Using an IDE" Page outdated
In-Reply-To: <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
 <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>
Message-ID: <CA+0ynh_-7MaSj51VJCmLPr9bqO1QApJQzyd259dECOa=dsijJg@mail.gmail.com>

>
> The blank final field dialog may not have been initialized Dialog.java


 This is mentioned in the note under "Configure Eclipse to use the latest
JDK".

Did you end up reverting the .classpath and .project files?

On Tue, Jan 14, 2020 at 10:37 AM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:

> I've just simply removed the two missing source folders and only one error
> remains:
> * The blank final field dialog may not have been initialized Dialog.java
> /controls/src/main/java/javafx/scene/control line 521
> which seems to me like an error within the eclipse compiler.
>
> Ignoring this error, I've tried to execute
> test.javafx.scene.control.ButtonTest from the IDE but get:
>
> > Graphics Device initialization failed for :  es2, sw
> > Error initializing QuantumRenderer: no suitable pipeline found
> > java.lang.RuntimeException: java.lang.RuntimeException: Error
> initializing
> > QuantumRenderer: no suitable pipeline found
> > at
> >
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
> > ...
> >
> Debugging into com.sun.prism.GraphicsPipeline I can see that for
> com.sun.prism.es2.ES2Pipeline I get this exception:
> java.lang.UnsatisfiedLinkError: no prism_es2 in java.library.path:
> [/usr/lib64/mysql, /opt/synedra/lib/opencv-dcm,
> /home/rli/devel/repository/tool/linux/64, ., /usr/java/packages/lib,
> /usr/lib64, /lib64, /lib, /usr/lib]
>
> As mentioned on the wiki, I've added
>
> -Djava.library.path=/home/rli/PWEs/jfx/modules/javafx.graphics/build/module-lib
> as VM argument which fixes the loading of ES2Pipeline.
>
> However I still can't run the test, I get:
> java.lang.ExceptionInInitializerError
> at
>
> javafx.controls/test.javafx.scene.control.ButtonTest.setup(ButtonTest.java:83)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> ...
> Caused by: java.lang.IllegalStateException: Toolkit not initialized
> at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
> at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
> at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
> at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
> at javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
> ... 25 more
>
> java.lang.NullPointerException
> at
>
> javafx.controls/test.javafx.scene.control.ButtonTest.after(ButtonTest.java:93)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> ...
>
> it seems the test does not wait for the toolkit to be initialized ...
>
> Am Di., 14. Jan. 2020 um 09:11 Uhr schrieb Robert Lichtenberger <
> r.lichtenberger at gmail.com>:
>
> > I've tried to import using "General" -> "Existing Projects in Workspace"
> > but get lots of errors as well. When reducing the imported projects to
> > base, graphics and controls:
> > * base is ok
> > * graphics has these errors:
> > Description Resource Path Location Type
> > Project 'graphics' is missing required source folder: 'build/hlsl/Decora'
> > graphics Build path Build Path Problem
> > Project 'graphics' is missing required source folder: 'build/hlsl/Prism'
> > graphics Build path Build Path Problem
> > * controls won't build due to errors in graphics
> >
> > Is hlsl the "High Level Shading Language" which may be specific to
> Windows?
> >
> > Am Di., 14. Jan. 2020 um 08:53 Uhr schrieb Tom Schindl <
> > tom.schindl at bestsolution.at>:
> >
> >> Hi,
> >>
> >> I think Nir nor I uses them as gradle Projects because you have the
> >> .classpath, .project, ... .
> >>
> >> Tom
> >>
> >> On 14.01.20 08:12, Robert Lichtenberger wrote:
> >> > Yes, I did run a gradle build (for which I had to tweak
> >> > buildSrc/linux.gradle to ignore some deprecations -- see my other post
> >> to
> >> > the list) successfully.
> >> >
> >> > I use a completely fresh workspace, updated my JFX sources, I use
> >> Eclipse
> >> > 2019-12 and jdk-13.0.1+9 on Fedora 31.
> >> >
> >> > These are my steps:
> >> > * open eclipse,
> >> > * choose "Import projects" then "Gradle" -> "Existing Gradle project"
> >> > * give the top level folder of my repository (/home/rli/PWEs/jfx in my
> >> case)
> >> > * Use the gradle wrapper (i.e. no changes on the wizards next page)
> >> > * The project structure is given correctly, so I click finish
> >> >
> >> > Eclipse then loads the projects but gives out the aforementioned
> error.
> >> >
> >> > I've made a 1-minute video clip showing my steps:
> >> > https://youtu.be/S9WnOHCbWLI
> >> >
> >> > I'll try to find out what is going wrong here. Could you tell me which
> >> > versions (JFX sources, Eclipse, JDK) you are using?
> >> >
> >> >
> >> > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker <
> >> nlisker at gmail.com>:
> >> >
> >> >> Never seen this problem before. Did you run a Gradle build? [1] It
> >> needs to
> >> >> generated required resources.
> >> >>
> >> >> Also, the Eclipse files for some projects are not updated (though for
> >> the
> >> >> modules they are fine, so it's not the problem you are having). My
> >> patch
> >> >> for them was pending review by other Eclipse users and no one tested
> >> it, so
> >> >> if you are up for it I could resume work on it.
> >> >>
> >> >> - Nir
> >> >>
> >> >> [1]
> >> >>
> >> >>
> >>
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
> >> >>
> >> >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger <
> >> >> r.lichtenberger at synedra.com> wrote:
> >> >>
> >> >>> Hmm. Eclipse would suit me fine, so I've tried to import a current
> >> >> OpenJFX
> >> >>> repository to Eclipse but it gives me (among others) this error:
> >> >>>
> >> >>> Description    Resource    Path    Location    Type
> >> >>> Cannot nest
> >> >>>
> >> >>
> >>
> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
> >> >>> inside library
> >> >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'
> >> base
> >> >>>     Build path    Build Path Problem
> >> >>>
> >> >>> The Workspace was completely new, all the other stuff (JDK 12, Java
> >> >>> Compiliance Level) should be ok.
> >> >>>
> >> >>> Do you have any idea what is going wrong here? Smells like module
> >> system
> >> >>> problems :-(.
> >> >>>
> >> >>>
> >> >>> Best regards,
> >> >>>
> >> >>> Robert
> >> >>> On 2020-01-10 17:52, Nir Lisker wrote:
> >> >>>
> >> >>> Hi Robert,
> >> >>>
> >> >>> I've brought this up in the past.
> >> >>>
> >> >>> I think that the best solution is for someone from the community to
> >> take
> >> >>> that task. I try to keep the Eclipse section updated, we will need
> >> >> someone
> >> >>> for the other IDE's.
> >> >>>
> >> >>> - Nir
> >> >>>
> >> >>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
> >> >>> r.lichtenberger at gmail.com> wrote:
> >> >>>
> >> >>>> I've noticed that
> >> >>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
> >> >>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which
> >> no
> >> >>>> longer exists, etc.).
> >> >>>>
> >> >>>> Could someone please update this page so that it is easier for
> >> newcomers
> >> >>>> to
> >> >>>> dive into the development of OpenJFX.
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Robert
> >> >>>>
> >> >>>
> >> >>
> >>
> >> --
> >> Tom Schindl, CTO
> >> BestSolution.at EDV Systemhaus GmbH
> >> Salurnerstrasse 15. A-6020 Innsbruck
> >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >>
> >
>

From r.lichtenberger at gmail.com  Tue Jan 14 10:08:28 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 11:08:28 +0100
Subject: "Using an IDE" Page outdated
In-Reply-To: <8c5c0f52-3df3-f467-5801-6f606ea8f1dc@bestsolution.at>
References: <CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com>
 <CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com>
 <911eff89-8fe0-159c-c37a-39c05aa4f0b1@synedra.com>
 <CA+0ynh8zhnXt_UahnV7jGtf=qQCVHuSP3gov3TXVwP1d_xJuiw@mail.gmail.com>
 <CA+f4zAF3io_e3LNmnXeVVc4rVGsTNoc-gf2G=TmJ+coX=9b7Bg@mail.gmail.com>
 <2b78ec0d-b6c1-ca1b-cb0e-e7a8bbe79e7a@bestsolution.at>
 <CA+f4zAHjfsqjsXoi_zzZXej2h4kfGc7JVu84JyrgX6z1+sqOcg@mail.gmail.com>
 <CA+f4zAHkoVbdyty1qsLfsncv=KbdeqqKXWdH7DngJXuNTjL4Gg@mail.gmail.com>
 <96dfdb57-dad2-6118-52aa-9da8c508c1d9@bestsolution.at>
 <8c5c0f52-3df3-f467-5801-6f606ea8f1dc@bestsolution.at>
Message-ID: <CA+f4zAHRa3g-fMbHyWP+wEn+Ke6NFQxB1LF6ZRM6+gE-pWoSEg@mail.gmail.com>

>
> Did you end up reverting the .classpath and .project files?
>
I started over, not importing as gradle but  as java projects.

I also just found
https://openjfx-dev.openjdk.java.narkive.com/AVCV7WXg/problem-running-tests-in-module-controls-inside-eclipse
and with Tom's hint:

> i run them with
>
> -Djava.library.path=/Users/tomschindl/OpenJFX/openjdk-jfx/build/sdk/lib
> -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit
>
I was finally able to run a test.

Maybe Nir could add a note about those two properties in the section
""JUnit tests"?

To sum up my findings/problems:
* gradlew is not executable; This should easily be changeable and would
make live easier for linux developers
* Building with gradle didn't work out of the box due to deprecations in
GTK2;
* The netbeans/intellij parts of the Wiki page seem to be the most outdated
whereas Nir is maintaining the eclipse part quite well. Maybe we should put
eclipse to the top and/or recommend using eclipse then. Or at least warn
the reader in the sections about netbeans and intellij beeing outdated. I
am a longtime eclipse user but after reading the wiki page tried netbeans
first (and failed miserably...)
* Using gradle/buildship in eclipse is not the "preferred" way. Maybe we
should remove this way altogether so as to not mislead people. I admit not
having read the wiki thouroughly enough though :-).
* hlsl problem under linux
* To run unit tests two VM arguments must be set. These should be mentioned
in the wiki.

Thanks to everyone for helping me ;-).



Am Di., 14. Jan. 2020 um 09:50 Uhr schrieb Tom Schindl <
tom.schindl at bestsolution.at>:

> I think the issue there is
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=507629 as Nir commented
> there as well I'm fairly sure this is the one you see ;-)
>
> Tom
>
> On 14.01.20 09:47, Tom Schindl wrote:
> > On 14.01.20 09:36, Robert Lichtenberger wrote:
> >> I've just simply removed the two missing source folders and only one
> >> error remains:
> >> * The blank final field dialog may not have been initialized Dialog.java
> >> /controls/src/main/java/javafx/scene/control line 521
> >> which seems to me like an error within the eclipse compiler.
> >>
> >> Ignoring this error, I've tried to execute
> >
> > yes it is and it is already logged in Bugzilla there - you can just
> > remove final in your local workspace ;-)
> >
> > Tom
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From r.lichtenberger at gmail.com  Tue Jan 14 11:00:56 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 12:00:56 +0100
Subject: Running Web-Tests from eclipse
Message-ID: <CA+f4zAEizNG4zG=h9LPWJATpbbjEMyY6+QiDc6e0skDtcaRCNQ@mail.gmail.com>

As a follow-up to the long thread on using an IDE. I just found out that
running test.javafx.scene.web.WebViewTest is not possible with
-Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit.

The test simply fails to start (waiting forever for
com.sun.javafx.application.PlatformImpl.startupLatch).

Instead one needs to add the graphics library and the webkit library with
e.g.
-Djava.library.path=/home/rli/PWEs/jfx/modules/javafx.graphics/build/module-lib:/home/rli/PWEs/jfx/modules/javafx.web/build/module-lib

Maybe this could also be added to the wiki page?

From tsayao at openjdk.java.net  Tue Jan 14 11:31:11 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 14 Jan 2020 11:31:11 GMT
Subject: RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <RTNlL4YgDTkU1J2hxEldvHgLAHAYTBNcAR4OdIGS9vI=.b219fd7a-1f0a-4bcb-9d31-8b2b8b18bc15@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
 <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
 <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>
 <RTNlL4YgDTkU1J2hxEldvHgLAHAYTBNcAR4OdIGS9vI=.b219fd7a-1f0a-4bcb-9d31-8b2b8b18bc15@github.com>
Message-ID: <DQhahySKkmtA9PENyqEI6bpVxfJGjQHr9eEcOc0cHP8=.83ebd7d3-5f6f-4da7-a610-2678223446c4@github.com>

On Mon, 6 Jan 2020 22:57:31 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This sort of enhancement needs to be discussed on the openjfx-dev mailing list first. While the WIP PR might be used to illustrate what you have in mind to propose, it is premature to actually review the implementation without first discussing whether and it makes sense to do it, what the high-level goals are, etc.
> 
> I understand. Will do that when the code works 100%. I have submitted the PR to avoid duplicated efforts and let people test it (if anyone is willing).

Sizing and positioning completed and fairly tested.

Will look into mouse grabbing.

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

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

From r.lichtenberger at gmail.com  Tue Jan 14 11:40:31 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 12:40:31 +0100
Subject: Removing unneeded imports from testcode
Message-ID: <CA+f4zAG+aMpKrWW8cBTtAJj8fW0NncwM8nFaMPb+i1ODvhV1nQ@mail.gmail.com>

I'm in the process of preparing a fix for JDK-8236912 and I (or rather
eclipse) have noticed that WebViewTest contains an import of
java.util.concurrent.FutureTask that is not needed.
What is the correct way of handling such things:
* Including them into the Pull-Request for the fix of JDK-8236912
* Leaving the unneeded import as-is.
* Opening another issue
Best regards,
Robert

From kevin.rushforth at oracle.com  Tue Jan 14 11:51:38 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Jan 2020 03:51:38 -0800
Subject: Removing unneeded imports from testcode
In-Reply-To: <CA+f4zAG+aMpKrWW8cBTtAJj8fW0NncwM8nFaMPb+i1ODvhV1nQ@mail.gmail.com>
References: <CA+f4zAG+aMpKrWW8cBTtAJj8fW0NncwM8nFaMPb+i1ODvhV1nQ@mail.gmail.com>
Message-ID: <8350ec61-262c-a7eb-1253-2adaa23faa76@oracle.com>

As a general rule, we avoid unrelated fixes. If your fix needed to add 
any new import, then I don't mind removing unused ones at the same time. 
If not, then you can either leave it as-is or file a cleanup issue.

-- Kevin


For test fixes, I don't mind

On 1/14/2020 3:40 AM, Robert Lichtenberger wrote:
> I'm in the process of preparing a fix for JDK-8236912 and I (or rather
> eclipse) have noticed that WebViewTest contains an import of
> java.util.concurrent.FutureTask that is not needed.
> What is the correct way of handling such things:
> * Including them into the Pull-Request for the fix of JDK-8236912
> * Leaving the unneeded import as-is.
> * Opening another issue
> Best regards,
> Robert


From rlichten at openjdk.java.net  Tue Jan 14 12:02:20 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 12:02:20 GMT
Subject: RFR: 8236912: Preventing NPE when clicking WebView with forward/back
 mouse buttons
Message-ID: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>

As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).

The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.

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

Commits:
 - 542ff60e: Fix null pointer exception when clicking into WebViews with forward/back mouse button.
 - 2109d5a0: Merge remote-tracking branch 'upstream/master'
 - acfa63be: Merge remote-tracking branch 'upstream/master'
 - 7c5cf198: 8232524: Test cleanup: terminate background thread upon failure.
 - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
 - 8ecf3545: JDK-8232524 fixed.

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

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

From kcr at openjdk.java.net  Tue Jan 14 12:06:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Jan 2020 12:06:58 GMT
Subject: RFR: 8236912: Preventing NPE when clicking WebView with
 forward/back mouse buttons
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <vyihkpGBA2thJMZ861iH21nt0gqHYEaxDt0_l_jzT-g=.e1972d36-a24f-4ece-8172-9e2d14509042@github.com>

On Tue, 14 Jan 2020 12:01:11 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
> 
> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.

The PR title should match the title of the bug report in JBS exactly. Can you change it to:

8236912: NullPointerException when clicking in WebView with Button 4 or Button 5

This will need two reviewers. I'll review it and also request @guruhb to review.

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

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

From r.lichtenberger at gmail.com  Tue Jan 14 12:09:29 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 13:09:29 +0100
Subject: RFR: 8236912: Preventing NPE when clicking WebView with
 forward/back mouse buttons
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <CA+f4zAE7ridhdDrzU=sGAnHPcZkJX_UyhdH8-1ZPy-ajm23rWg@mail.gmail.com>

How strange: Other commits to the master branch of my forked repository
(relating to another issue, already integrated into OpenJFX) are also
showing up here. But the change really only consists of 542ff60e which
contains the fix for JDK-8236912. My older contributions were not checked
into a separate branch (of my fork), maybe that was the problem. If there
is anything else I did wrong, please tell me ;-).

The Changes-Link and the Webrev correctly show that only two files are
changed.

Am Di., 14. Jan. 2020 um 13:02 Uhr schrieb Robert Lichtenberger <
rlichten at openjdk.java.net>:

> As documented in JDK-8236912, WebView did not check whether the idMap
> really contained a mapping for the given button, making it prone to errors,
> when things are extended (as has happened here).
>
> The fix consists of two test cases that show the problem in unfixed
> WebViews and a fix which works analogously to the check whether the given
> event type is mapped.
>
> -------------
>
> Commits:
>  - 542ff60e: Fix null pointer exception when clicking into WebViews with
> forward/back mouse button.
>  - 2109d5a0: Merge remote-tracking branch 'upstream/master'
>  - acfa63be: Merge remote-tracking branch 'upstream/master'
>  - 7c5cf198: 8232524: Test cleanup: terminate background thread upon
> failure.
>  - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for
> copying/iterating
>  - 8ecf3545: JDK-8232524 fixed.
>
> Changes: https://git.openjdk.java.net/jfx/pull/85/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/85/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8236912
>   Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/85.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/85/head:pull/85
>
> PR: https://git.openjdk.java.net/jfx/pull/85
>

From r.lichtenberger at gmail.com  Tue Jan 14 12:11:44 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 13:11:44 +0100
Subject: RFR: 8236912: Preventing NPE when clicking WebView with
 forward/back mouse buttons
In-Reply-To: <vyihkpGBA2thJMZ861iH21nt0gqHYEaxDt0_l_jzT-g=.e1972d36-a24f-4ece-8172-9e2d14509042@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <vyihkpGBA2thJMZ861iH21nt0gqHYEaxDt0_l_jzT-g=.e1972d36-a24f-4ece-8172-9e2d14509042@github.com>
Message-ID: <CA+f4zAHf+FUwU1dh1Jj8JmJEUc5_v11xCa+rWGaaic_kSDWO7g@mail.gmail.com>

PR title changed.

Am Di., 14. Jan. 2020 um 13:07 Uhr schrieb Kevin Rushforth <
kcr at openjdk.java.net>:

> On Tue, 14 Jan 2020 12:01:11 GMT, Robert Lichtenberger <
> rlichten at openjdk.org> wrote:
>
> > As documented in JDK-8236912, WebView did not check whether the idMap
> really contained a mapping for the given button, making it prone to errors,
> when things are extended (as has happened here).
> >
> > The fix consists of two test cases that show the problem in unfixed
> WebViews and a fix which works analogously to the check whether the given
> event type is mapped.
>
> The PR title should match the title of the bug report in JBS exactly. Can
> you change it to:
>
> 8236912: NullPointerException when clicking in WebView with Button 4 or
> Button 5
>
> This will need two reviewers. I'll review it and also request @guruhb to
> review.
>
> -------------
>
> PR: https://git.openjdk.java.net/jfx/pull/85
>

From ghb at openjdk.java.net  Tue Jan 14 12:12:46 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Tue, 14 Jan 2020 12:12:46 GMT
Subject: RFR: 8236912: NullPointerException when clicking in WebView with
 Button 4 or Button 5
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>

On Tue, 14 Jan 2020 12:01:11 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
> 
> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.

+1, Looks good to me.

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

Marked as reviewed by ghb (Reviewer).

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

From kcr at openjdk.java.net  Tue Jan 14 12:16:29 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Jan 2020 12:16:29 GMT
Subject: RFR: 8236912: NullPointerException when clicking in WebView with
 Button 4 or Button 5
In-Reply-To: <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>
Message-ID: <gTqbf531fT_bJoRmtcXSg5-8-oIhvi8g9Vui-LqCOAM=.a57c5d3f-c18c-4f7c-88e0-da5a91e299bf@github.com>

On Tue, 14 Jan 2020 12:12:37 GMT, Guru Hb <ghb at openjdk.org> wrote:

>> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
>> 
>> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.
> 
> +1, Looks good to me.

@effad - The extra commits and merge are no problem, provided that you want to get this into openjfx15.

However, if you intend to get this into openjfx14, as currently targeted in JBS, then you will need to:

1. Rebase your `JDK-8236912` branch on top of the upstream `jfx14` branch
2. Force-push your branch: `git push --force origin JDK-8236912`
3. Edit this PR and change the target to the `jfx14` branch

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

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

From kcr at openjdk.java.net  Tue Jan 14 12:40:30 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Jan 2020 12:40:30 GMT
Subject: RFR: 8236912: NullPointerException when clicking in WebView with
 Button 4 or Button 5
In-Reply-To: <gTqbf531fT_bJoRmtcXSg5-8-oIhvi8g9Vui-LqCOAM=.a57c5d3f-c18c-4f7c-88e0-da5a91e299bf@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>
 <gTqbf531fT_bJoRmtcXSg5-8-oIhvi8g9Vui-LqCOAM=.a57c5d3f-c18c-4f7c-88e0-da5a91e299bf@github.com>
Message-ID: <OIF3MOxabo7wWFjxEg-dtvRxB9WZDO8UGEmmeONUSeQ=.e7ef0826-4eb2-4c72-a9c1-8ece5ed0a1ae@github.com>

On Tue, 14 Jan 2020 12:16:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> +1, Looks good to me.
> 
> @effad - The extra commits and merge are no problem, provided that you want to get this into openjfx15.
> 
> However, if you intend to get this into openjfx14, as currently targeted in JBS, then you will need to:
> 
> 1. Rebase your `JDK-8236912` branch on top of the upstream `jfx14` branch
> 2. Force-push your branch: `git push --force origin JDK-8236912`
> 3. Edit this PR and change the target to the `jfx14` branch

NOTE that this PR is not yet ready for integration. In addition to needing one more reviewer (me), there is the open question of which branch it should be targeted to.

@effad I think that this should go into openjfx14, so the above steps I listed will allow for this.

@guruhb can you please cancel your review (click the "re-request review" icon next to your review) until the above is done?

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

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

From rlichten at openjdk.java.net  Tue Jan 14 12:53:06 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 12:53:06 GMT
Subject: [Rev 01] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <txJxLzLS5XoynesZme0zk9vwM4q93vBhjsqkRUooejY=.cd505c30-a29e-4c4b-b13d-1524961bd296@github.com>

> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
> 
> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.

The pull request has been updated with 2 additional commits.

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

Added commits:
 - 283c5476: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
 - 6aecab95: JDK-8232524 fixed.

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/85/files
  - new: https://git.openjdk.java.net/jfx/pull/85/files/542ff60e..283c5476

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

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

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

From rlichten at openjdk.java.net  Tue Jan 14 12:56:47 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 12:56:47 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <OIF3MOxabo7wWFjxEg-dtvRxB9WZDO8UGEmmeONUSeQ=.e7ef0826-4eb2-4c72-a9c1-8ece5ed0a1ae@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>
 <gTqbf531fT_bJoRmtcXSg5-8-oIhvi8g9Vui-LqCOAM=.a57c5d3f-c18c-4f7c-88e0-da5a91e299bf@github.com>
 <OIF3MOxabo7wWFjxEg-dtvRxB9WZDO8UGEmmeONUSeQ=.e7ef0826-4eb2-4c72-a9c1-8ece5ed0a1ae@github.com>
Message-ID: <E9daO0AAs7PyUZ-DyGhbIpm7oBCZTUx46ZbnkuUQo_4=.43a7d37f-64b7-4ce4-bd73-133c58878336@github.com>

On Tue, 14 Jan 2020 12:40:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @effad - The extra commits and merge are no problem, provided that you want to get this into openjfx15.
>> 
>> However, if you intend to get this into openjfx14, as currently targeted in JBS, then you will need to:
>> 
>> 1. Rebase your `JDK-8236912` branch on top of the upstream `jfx14` branch
>> 2. Force-push your branch: `git push --force origin JDK-8236912`
>> 3. Edit this PR and change the target to the `jfx14` branch
> 
> NOTE that this PR is not yet ready for integration. In addition to needing one more reviewer (me), there is the open question of which branch it should be targeted to.
> 
> @effad I think that this should go into openjfx14, so the above steps I listed will allow for this.
> 
> @guruhb can you please cancel your review (click the "re-request review" icon next to your review) until the above is done?

I've rebased my branch like this:
git fetch upstream
git rebase upstream/jfx14
git pull
git push
and changed the base branch of this PR to jfx14. Hope that was the correct way to do this ;-).

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

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

From kcr at openjdk.java.net  Tue Jan 14 14:00:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Jan 2020 14:00:15 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <E9daO0AAs7PyUZ-DyGhbIpm7oBCZTUx46ZbnkuUQo_4=.43a7d37f-64b7-4ce4-bd73-133c58878336@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>
 <gTqbf531fT_bJoRmtcXSg5-8-oIhvi8g9Vui-LqCOAM=.a57c5d3f-c18c-4f7c-88e0-da5a91e299bf@github.com>
 <OIF3MOxabo7wWFjxEg-dtvRxB9WZDO8UGEmmeONUSeQ=.e7ef0826-4eb2-4c72-a9c1-8ece5ed0a1ae@github.com>
 <E9daO0AAs7PyUZ-DyGhbIpm7oBCZTUx46ZbnkuUQo_4=.43a7d37f-64b7-4ce4-bd73-133c58878336@github.com>
Message-ID: <_O90urpActWZWHMTxjUwlZo3FDy3sFVX5ENvK9W7w18=.378f3f6f-5d3e-46fd-90d1-3c7a3000209b@github.com>

On Tue, 14 Jan 2020 12:56:32 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> NOTE that this PR is not yet ready for integration. In addition to needing one more reviewer (me), there is the open question of which branch it should be targeted to.
>> 
>> @effad I think that this should go into openjfx14, so the above steps I listed will allow for this.
>> 
>> @guruhb can you please cancel your review (click the "re-request review" icon next to your review) until the above is done?
> 
> I've rebased my branch like this:
> git fetch upstream
> git rebase upstream/jfx14
> git pull
> git push
> and changed the base branch of this PR to jfx14. Hope that was the correct way to do this ;-).

Your branch still has commits from `master` after jfx14 was branched. This was the problem:
git pull

This pulled in additional changes from master that were already in your branch and effectively undid the rebase. You need to redo it, but this time instead of pulling changes after you rebase, you should simply do:
git push --force origin JDK-8236912

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

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

From rlichten at openjdk.java.net  Tue Jan 14 14:07:18 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 14:07:18 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <QOiPsHWNbw9QDAzD5ahZQh3bIVrvfHJ_vZxj_O8pWYA=.67a0edee-1272-49ae-bd61-5acaeef8f1e1@github.com>

> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
> 
> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.

The pull request has been updated with a new target base due to a merge or a rebase.

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

Commits:
 - 8c3f6017: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
 - 829920cf: JDK-8232524 fixed.
 - 401b4484: Fix null pointer exception when clicking into WebViews with forward/back mouse button.
 - 3bf7e920: 8236733: Change JavaFX release version to 15
 - 0967bbd3: 8232524: Test cleanup: terminate background thread upon failure.
 - e50b0533: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
 - 9d1979e7: JDK-8232524 fixed.

Changes: https://git.openjdk.java.net/jfx/pull/85/files
 Webrev: https://webrevs.openjdk.java.net/jfx/85/webrev.02
  Stats: 205 lines in 6 files changed: 198 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/85/head:pull/85

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

From rlichten at openjdk.java.net  Tue Jan 14 14:12:37 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 14:12:37 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <_O90urpActWZWHMTxjUwlZo3FDy3sFVX5ENvK9W7w18=.378f3f6f-5d3e-46fd-90d1-3c7a3000209b@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <umQtlayLgcOofGusmCehR7h-jTnXv5HMIm0Bp0hm5y8=.ba8c837b-b388-4a96-bf3e-1d74a3c0477a@github.com>
 <gTqbf531fT_bJoRmtcXSg5-8-oIhvi8g9Vui-LqCOAM=.a57c5d3f-c18c-4f7c-88e0-da5a91e299bf@github.com>
 <OIF3MOxabo7wWFjxEg-dtvRxB9WZDO8UGEmmeONUSeQ=.e7ef0826-4eb2-4c72-a9c1-8ece5ed0a1ae@github.com>
 <E9daO0AAs7PyUZ-DyGhbIpm7oBCZTUx46ZbnkuUQo_4=.43a7d37f-64b7-4ce4-bd73-133c58878336@github.com>
 <_O90urpActWZWHMTxjUwlZo3FDy3sFVX5ENvK9W7w18=.378f3f6f-5d3e-46fd-90d1-3c7a3000209b@github.com>
Message-ID: <l5ulJzK0tlJS4bXZiJ_WTQZ1NQrmWjOvm2Af-9eeYec=.0cae2c92-e712-47cc-bf02-d0d80507c551@github.com>

On Tue, 14 Jan 2020 14:00:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I've rebased my branch like this:
>> git fetch upstream
>> git rebase upstream/jfx14
>> git pull
>> git push
>> and changed the base branch of this PR to jfx14. Hope that was the correct way to do this ;-).
> 
> Your branch still has commits from `master` after jfx14 was branched. This was the problem:
> git pull
> 
> This pulled in additional changes from master that were already in your branch and effectively undid the rebase. You need to redo it, but this time instead of pulling changes after you rebase, you should simply do:
> git push --force origin JDK-8236912

> ```
> git push --force origin JDK-8236912
> ```
I did 
git rebase upstream/jfx14
git push --force origin JDK-8236912
but that has messed up things further, didn't it?

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

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

From ghb at openjdk.java.net  Tue Jan 14 14:13:57 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Tue, 14 Jan 2020 14:13:57 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <QOiPsHWNbw9QDAzD5ahZQh3bIVrvfHJ_vZxj_O8pWYA=.67a0edee-1272-49ae-bd61-5acaeef8f1e1@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <QOiPsHWNbw9QDAzD5ahZQh3bIVrvfHJ_vZxj_O8pWYA=.67a0edee-1272-49ae-bd61-5acaeef8f1e1@github.com>
Message-ID: <K0-aPkHG2TzZUNF7JN5gBCx0P0-j51nXxx68NjrpC58=.4022cae9-b5a2-4d9c-8b97-af3ae4caa086@github.com>

On Tue, 14 Jan 2020 14:13:54 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
>> 
>> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.
> 
> The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Partially reviewed, Need to re-check after the change of branch.

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

Changes requested by ghb (Reviewer).

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

From kcr at openjdk.java.net  Tue Jan 14 14:43:24 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Jan 2020 14:43:24 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <K0-aPkHG2TzZUNF7JN5gBCx0P0-j51nXxx68NjrpC58=.4022cae9-b5a2-4d9c-8b97-af3ae4caa086@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <QOiPsHWNbw9QDAzD5ahZQh3bIVrvfHJ_vZxj_O8pWYA=.67a0edee-1272-49ae-bd61-5acaeef8f1e1@github.com>
 <K0-aPkHG2TzZUNF7JN5gBCx0P0-j51nXxx68NjrpC58=.4022cae9-b5a2-4d9c-8b97-af3ae4caa086@github.com>
Message-ID: <LYcWUshx8wdZcEdDusy1CEjlwht2nv_BrJ9NTHu0BP0=.502bca0f-b2d6-4d0d-ace2-bc2b24f0b432@github.com>

On Tue, 14 Jan 2020 14:13:45 GMT, Guru Hb <ghb at openjdk.org> wrote:

>> The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
> 
> Partially reviewed, Need to re-check after the change of branch.

Oh, I see the problem. In addition to rebasing you need to exclude any commits that are from the `master` branch and are not your. So what you really need to do is:

git rebase -i upstream/jfx14
<EDIT THE LIST OF COMMITS AND DROP ANY THAT ARE NOT YOURS>
git push --force origin JDK-8236912

Sorry for not anticipating this problem.

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

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

From rlichten at openjdk.java.net  Tue Jan 14 14:50:45 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 14:50:45 GMT
Subject: [Rev 03] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>

> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
> 
> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.

Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.

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

Added commits:
 - aa03cf1f: Fix null pointer exception when clicking into WebViews with forward/back mouse button.

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/85/files
  - new: https://git.openjdk.java.net/jfx/pull/85/files/8c3f6017..aa03cf1f

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

  Stats: 187 lines in 4 files changed: 0 ins; 183 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/85/head:pull/85

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

From rlichten at openjdk.java.net  Tue Jan 14 14:55:45 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 14 Jan 2020 14:55:45 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <LYcWUshx8wdZcEdDusy1CEjlwht2nv_BrJ9NTHu0BP0=.502bca0f-b2d6-4d0d-ace2-bc2b24f0b432@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <QOiPsHWNbw9QDAzD5ahZQh3bIVrvfHJ_vZxj_O8pWYA=.67a0edee-1272-49ae-bd61-5acaeef8f1e1@github.com>
 <K0-aPkHG2TzZUNF7JN5gBCx0P0-j51nXxx68NjrpC58=.4022cae9-b5a2-4d9c-8b97-af3ae4caa086@github.com>
 <LYcWUshx8wdZcEdDusy1CEjlwht2nv_BrJ9NTHu0BP0=.502bca0f-b2d6-4d0d-ace2-bc2b24f0b432@github.com>
Message-ID: <Eyvn_lUzHYQJE-nKD6mtFzYoxvvyexFR-0Vz0n3RcXs=.0c0037f7-d1ce-4a43-b515-ba834b04f528@github.com>

On Tue, 14 Jan 2020 14:43:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Partially reviewed, Need to re-check after the change of branch.
> 
> Oh, I see the problem. In addition to rebasing you need to exclude any commits that are from the `master` branch and are not your. So what you really need to do is:
> 
> git rebase -i upstream/jfx14
> <EDIT THE LIST OF COMMITS AND DROP ANY THAT ARE NOT YOURS>
> git push --force origin JDK-8236912
> 
> Sorry for not anticipating this problem.

> Sorry for not anticipating this problem.
I am sorry for not knowing git well enough. Thank you for your patience and help ;-). I think the PR now contains what it should ;-).

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

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

From kcr at openjdk.java.net  Tue Jan 14 15:08:47 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Jan 2020 15:08:47 GMT
Subject: [Rev 02] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <Eyvn_lUzHYQJE-nKD6mtFzYoxvvyexFR-0Vz0n3RcXs=.0c0037f7-d1ce-4a43-b515-ba834b04f528@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <QOiPsHWNbw9QDAzD5ahZQh3bIVrvfHJ_vZxj_O8pWYA=.67a0edee-1272-49ae-bd61-5acaeef8f1e1@github.com>
 <K0-aPkHG2TzZUNF7JN5gBCx0P0-j51nXxx68NjrpC58=.4022cae9-b5a2-4d9c-8b97-af3ae4caa086@github.com>
 <LYcWUshx8wdZcEdDusy1CEjlwht2nv_BrJ9NTHu0BP0=.502bca0f-b2d6-4d0d-ace2-bc2b24f0b432@github.com>
 <Eyvn_lUzHYQJE-nKD6mtFzYoxvvyexFR-0Vz0n3RcXs=.0c0037f7-d1ce-4a43-b515-ba834b04f528@github.com>
Message-ID: <Gk-FzFbuS2wGUmUhO8d8LuTzU5l-2SVM2aeMqQfxd6Y=.0184e1d5-1f61-4f96-872f-f55b7e84c83a@github.com>

On Tue, 14 Jan 2020 14:55:31 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Oh, I see the problem. In addition to rebasing you need to exclude any commits that are from the `master` branch and are not your. So what you really need to do is:
>> 
>> git rebase -i upstream/jfx14
>> <EDIT THE LIST OF COMMITS AND DROP ANY THAT ARE NOT YOURS>
>> git push --force origin JDK-8236912
>> 
>> Sorry for not anticipating this problem.
> 
>> Sorry for not anticipating this problem.
> I am sorry for not knowing git well enough. Thank you for your patience and help ;-). I think the PR now contains what it should ;-).

Yes, it looks fine now, so it is ready for review. And this is one thing that can be a bit tricky about using git with multiple branches.

Btw, I was going to suggest `git rebase -i` the first time (it's what I always do in such a situation), but thought I could save you a step. Lesson learned. :)

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

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

From johan.vos at gluonhq.com  Tue Jan 14 15:22:08 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 14 Jan 2020 16:22:08 +0100
Subject: Backport 8224636 to OpenJFX 11
Message-ID: <CABxFH2EpR8V=N4FLG9X9refydeZWhb=iVy-dgTcoXzO-0uHWog@mail.gmail.com>

Hi Kevin,

I request permission to backport JDK-8224636 to OpenJFX 11 (11-dev).
The patch applies clean.

- Johan

From kevin.rushforth at oracle.com  Tue Jan 14 15:25:14 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Jan 2020 07:25:14 -0800
Subject: Backport 8224636 to OpenJFX 11
In-Reply-To: <CABxFH2EpR8V=N4FLG9X9refydeZWhb=iVy-dgTcoXzO-0uHWog@mail.gmail.com>
References: <CABxFH2EpR8V=N4FLG9X9refydeZWhb=iVy-dgTcoXzO-0uHWog@mail.gmail.com>
Message-ID: <255fe8f5-8211-167b-4c89-6dd73af334ee@oracle.com>

Approved.

On 1/14/2020 7:22 AM, Johan Vos wrote:
> Hi Kevin,
>
> I request permission to backport JDK-8224636 to OpenJFX 11 (11-dev).
> The patch applies clean.
>
> - Johan


From arapte at openjdk.java.net  Tue Jan 14 16:50:31 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 14 Jan 2020 16:50:31 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
 <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
Message-ID: <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>

On Fri, 10 Jan 2020 00:39:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I'll review this next week. This seems a fine candidate for openjfx14, so it (along with a couple other pending reviews that can be for 14) will be a good test of targeting a PR to the stabilization branch.
>> 
>> I also request @arapte to review.
> 
> I should add that it will depend on whether there are any regressions. One thing we do need to be careful of is introducing regressions during rampdown.

The fix looks good to me.
After this change the steps needed for playing an `Animation` backwards will change.
Earlier this was documented with `Animation.play()` API as below.
-------------
To play an `Animation` backwards from the end:
animation.setRate(negative rate);
animation.jumpTo(overall duration of animation);
animation.play();
-------------

After this PR call to `jumpTo()` won't be needed here.
So this PR may need a document change for `Animation.play()`.
Also to note that the behavior of above mentioned three calls remains same with the changes in this change.

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

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

From kevin.rushforth at oracle.com  Tue Jan 14 17:02:49 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Jan 2020 09:02:49 -0800
Subject: [14] RFR: Request to sync January 2020 CPU changes into jfx [jfx14
 branch]
Message-ID: <65a9396a-6e8c-d0c4-535a-8297625cecf4@oracle.com>

Johan and Phil,

I request approval to sync changes from to the just-released January 
2020 CPU release into the 'jfx14' branch of the 'jfx' repo. Here is the 
aggregate set of changes for the fixes:

https://github.com/kevinrushforth/jfx/compare/f907026...16cea41

The aggregate diffs are empty, since subsequent changes in mainline 
superseded each of these fixes, but it is still a good idea to push them 
(as we have done in the past in similar situations).

NOTE: Since this is an integration of already-reviewed fixes into the 
jfx14 branch of the jfx repo, I will push it directly rather than via a 
pull request.

-- Kevin


From kevin.rushforth at oracle.com  Tue Jan 14 17:03:16 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Jan 2020 09:03:16 -0800
Subject: [11][13] RFR: Request to backport October 2019 CPU changes
Message-ID: <e74f0f5f-6bbf-78b5-77ef-2a299f7389a0@oracle.com>

Hi Johan,

I request approval to backport the changes from the just-released 
January 2020 CPU to 11-dev and 13-dev.

https://cr.openjdk.java.net/~kcr/cpu-2001-sync/11-dev/webrev/

This is a straight backport (patch applies cleanly) of the four FX fixes 
that went into the January CPU. The 13-dev patches are 100% identical to 
the 11-dev, so I only posted one of them.

Thanks.

-- Kevin



From johan.vos at gluonhq.com  Tue Jan 14 17:06:03 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 14 Jan 2020 18:06:03 +0100
Subject: [14] RFR: Request to sync January 2020 CPU changes into jfx
 [jfx14 branch]
In-Reply-To: <65a9396a-6e8c-d0c4-535a-8297625cecf4@oracle.com>
References: <65a9396a-6e8c-d0c4-535a-8297625cecf4@oracle.com>
Message-ID: <CABxFH2E+rg8ww5JAMfyZ7_6nVEgtjdOZ6BE=FbDrBT37swUu7A@mail.gmail.com>

Approved.

On Tue, Jan 14, 2020, 18:03 Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Johan and Phil,
>
> I request approval to sync changes from to the just-released January
> 2020 CPU release into the 'jfx14' branch of the 'jfx' repo. Here is the
> aggregate set of changes for the fixes:
>
> https://github.com/kevinrushforth/jfx/compare/f907026...16cea41
>
> The aggregate diffs are empty, since subsequent changes in mainline
> superseded each of these fixes, but it is still a good idea to push them
> (as we have done in the past in similar situations).
>
> NOTE: Since this is an integration of already-reviewed fixes into the
> jfx14 branch of the jfx repo, I will push it directly rather than via a
> pull request.
>
> -- Kevin
>
>

From johan.vos at gluonhq.com  Tue Jan 14 17:06:35 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 14 Jan 2020 18:06:35 +0100
Subject: [11][13] RFR: Request to backport October 2019 CPU changes
In-Reply-To: <e74f0f5f-6bbf-78b5-77ef-2a299f7389a0@oracle.com>
References: <e74f0f5f-6bbf-78b5-77ef-2a299f7389a0@oracle.com>
Message-ID: <CABxFH2GWWo_ppDEXsTRd9MSCFhbitX8Q=spKPhud2=XX+EezjA@mail.gmail.com>

Approved.

On Tue, Jan 14, 2020, 18:04 Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Hi Johan,
>
> I request approval to backport the changes from the just-released
> January 2020 CPU to 11-dev and 13-dev.
>
> https://cr.openjdk.java.net/~kcr/cpu-2001-sync/11-dev/webrev/
>
> This is a straight backport (patch applies cleanly) of the four FX fixes
> that went into the January CPU. The 13-dev patches are 100% identical to
> the 11-dev, so I only posted one of them.
>
> Thanks.
>
> -- Kevin
>
>
>

From johan.vos at gluonhq.com  Tue Jan 14 17:46:10 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 14 Jan 2020 18:46:10 +0100
Subject: RFR: Request to backport patches into JFX-11
Message-ID: <CABxFH2H0R+0B8ioobhLuKxm1MniL+fUVqaEv9g-+jFOy1EnH2Q@mail.gmail.com>

Hi Kevin,

I ask permission to backport the following issues into 11-dev:

JDK-8231590 <https://bugs.openjdk.java.net/browse/JDK-8231590>: Update
location of jfx repo to GitHub in third-party legal files
JDK-8231854 <https://bugs.openjdk.java.net/browse/JDK-8231854>:  Change
Mercurial to git in various README files
JDK-8218640 <https://bugs.openjdk.java.net/browse/JDK-8218640>: Update
ICU4C to version 64.2
JDK-8232522 <https://bugs.openjdk.java.net/browse/JDK-8232522>: FX: Update
copyright year in docs, readme files to 2020

- Johan

From kevin.rushforth at oracle.com  Tue Jan 14 17:51:56 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Jan 2020 09:51:56 -0800
Subject: RFR: Request to backport patches into JFX-11
In-Reply-To: <CABxFH2H0R+0B8ioobhLuKxm1MniL+fUVqaEv9g-+jFOy1EnH2Q@mail.gmail.com>
References: <CABxFH2H0R+0B8ioobhLuKxm1MniL+fUVqaEv9g-+jFOy1EnH2Q@mail.gmail.com>
Message-ID: <460a2c7a-e9c2-73bc-1bad-d832a57e5548@oracle.com>

Approved.

-- Kevin

On 1/14/2020 9:46 AM, Johan Vos wrote:
> Hi Kevin,
>
> I ask permission to backport the following issues into 11-dev:
>
> JDK-8231590 <https://bugs.openjdk.java.net/browse/JDK-8231590>: Update
> location of jfx repo to GitHub in third-party legal files
> JDK-8231854 <https://bugs.openjdk.java.net/browse/JDK-8231854>:  Change
> Mercurial to git in various README files
> JDK-8218640 <https://bugs.openjdk.java.net/browse/JDK-8218640>: Update
> ICU4C to version 64.2
> JDK-8232522 <https://bugs.openjdk.java.net/browse/JDK-8232522>: FX: Update
> copyright year in docs, readme files to 2020
>
> - Johan


From swpalmer at gmail.com  Tue Jan 14 19:22:50 2020
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 14 Jan 2020 14:22:50 -0500
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
 <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
 <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
Message-ID: <7A65156C-D306-48E1-A43C-5720C70439E2@gmail.com>



> On Jan 14, 2020, at 11:50 AM, Ambarish Rapte <arapte at openjdk.java.net> wrote:
> 
> On Fri, 10 Jan 2020 00:39:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>>> I'll review this next week. This seems a fine candidate for openjfx14, so it (along with a couple other pending reviews that can be for 14) will be a good test of targeting a PR to the stabilization branch.
>>> 
>>> I also request @arapte to review.
>> 
>> I should add that it will depend on whether there are any regressions. One thing we do need to be careful of is introducing regressions during rampdown.
> 
> The fix looks good to me.
> After this change the steps needed for playing an `Animation` backwards will change.
> Earlier this was documented with `Animation.play()` API as below.
> -------------
> To play an `Animation` backwards from the end:
> animation.setRate(negative rate);
> animation.jumpTo(overall duration of animation);
> animation.play();
> -------------
> 
> After this PR call to `jumpTo()` won't be needed here.
> So this PR may need a document change for `Animation.play()`.
> Also to note that the behavior of above mentioned three calls remains same with the changes in this change.

If the jumpTo isn?t required, then this isn?t this a change in behaviour?  I?m wonder in particular if this has an effect on cycleCount.

If cycleCount is set to 2 does the animation play the same number of times with or without the jumpTo both before and after this change?

Scott

From tsayao at openjdk.java.net  Wed Jan 15 02:16:09 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 15 Jan 2020 02:16:09 GMT
Subject: [Rev 12] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <NOnm4RJ0RXRdXZm3Dz17U29A-dvGvkReDY_b6Ofy07Y=.ef2bfcd6-b006-4640-81ee-85ce0ede53a0@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code.
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 2bfac077: Mouse pointer grab

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/4b555624..2bfac077

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.12
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.11-12

  Stats: 94 lines in 3 files changed: 81 ins; 10 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From nlisker at gmail.com  Wed Jan 15 06:15:05 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 15 Jan 2020 08:15:05 +0200
Subject: Running Web-Tests from eclipse
In-Reply-To: <CA+f4zAEizNG4zG=h9LPWJATpbbjEMyY6+QiDc6e0skDtcaRCNQ@mail.gmail.com>
References: <CA+f4zAEizNG4zG=h9LPWJATpbbjEMyY6+QiDc6e0skDtcaRCNQ@mail.gmail.com>
Message-ID: <CA+0ynh9By8PK0xHKqkWh7G4bnpq6AYQ=7G6WroHr0PFhJSKE0g@mail.gmail.com>

I updated the eclipse instructions. Have a look.

Thanks,
Nir

On Tue, Jan 14, 2020 at 1:01 PM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:

> As a follow-up to the long thread on using an IDE. I just found out that
> running test.javafx.scene.web.WebViewTest is not possible with
> -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit.
>
> The test simply fails to start (waiting forever for
> com.sun.javafx.application.PlatformImpl.startupLatch).
>
> Instead one needs to add the graphics library and the webkit library with
> e.g.
>
> -Djava.library.path=/home/rli/PWEs/jfx/modules/javafx.graphics/build/module-lib:/home/rli/PWEs/jfx/modules/javafx.web/build/module-lib
>
> Maybe this could also be added to the wiki page?
>

From r.lichtenberger at gmail.com  Wed Jan 15 06:54:55 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Wed, 15 Jan 2020 07:54:55 +0100
Subject: Running Web-Tests from eclipse
In-Reply-To: <CA+0ynh9By8PK0xHKqkWh7G4bnpq6AYQ=7G6WroHr0PFhJSKE0g@mail.gmail.com>
References: <CA+f4zAEizNG4zG=h9LPWJATpbbjEMyY6+QiDc6e0skDtcaRCNQ@mail.gmail.com>
 <CA+0ynh9By8PK0xHKqkWh7G4bnpq6AYQ=7G6WroHr0PFhJSKE0g@mail.gmail.com>
Message-ID: <CA+f4zAG-h6oWgqP7jPZPW2gE01h8vGFYtV4hV8RJsBPYfdKJiw@mail.gmail.com>

This looks good to me.

Thanks,
Robert

Am Mi., 15. Jan. 2020 um 07:15 Uhr schrieb Nir Lisker <nlisker at gmail.com>:

> I updated the eclipse instructions. Have a look.
>
> Thanks,
> Nir
>
> On Tue, Jan 14, 2020 at 1:01 PM Robert Lichtenberger <
> r.lichtenberger at gmail.com> wrote:
>
>> As a follow-up to the long thread on using an IDE. I just found out that
>> running test.javafx.scene.web.WebViewTest is not possible with
>> -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit.
>>
>> The test simply fails to start (waiting forever for
>> com.sun.javafx.application.PlatformImpl.startupLatch).
>>
>> Instead one needs to add the graphics library and the webkit library with
>> e.g.
>>
>> -Djava.library.path=/home/rli/PWEs/jfx/modules/javafx.graphics/build/module-lib:/home/rli/PWEs/jfx/modules/javafx.web/build/module-lib
>>
>> Maybe this could also be added to the wiki page?
>>
>

From johan.vos at gluonhq.com  Wed Jan 15 10:30:33 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 15 Jan 2020 11:30:33 +0100
Subject: RFR: 8237194: increase release version in 11-dev
Message-ID: <CABxFH2HJY7a4sT-SomJsXczbqzLd=qQOpT2RvuUhq1yf-GremA@mail.gmail.com>

Hi Kevin,

Please review http://cr.openjdk.java.net/~jvos/8237194/webrev.00/ which is
a fix for https://bugs.openjdk.java.net/browse/JDK-8237194

Thanks,

- Johan

From johan.vos at gluonhq.com  Wed Jan 15 10:44:01 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 15 Jan 2020 11:44:01 +0100
Subject: RFR: 8237195: increase release version in 13-dev
Message-ID: <CABxFH2FuLi99qcmBB19F912RfDinq7wz=OjkQOUgVuT_ccRRcg@mail.gmail.com>

Hi Kevin,

Please review http://cr.openjdk.java.net/~jvos/8237195/webrev.00/ which
fixes https://bugs.openjdk.java.net/browse/JDK-8237195

Thanks,

- Johan

From kevin.rushforth at oracle.com  Wed Jan 15 14:46:37 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 15 Jan 2020 06:46:37 -0800
Subject: RFR: 8237194: increase release version in 11-dev
In-Reply-To: <CABxFH2HJY7a4sT-SomJsXczbqzLd=qQOpT2RvuUhq1yf-GremA@mail.gmail.com>
References: <CABxFH2HJY7a4sT-SomJsXczbqzLd=qQOpT2RvuUhq1yf-GremA@mail.gmail.com>
Message-ID: <f038c85b-e1d2-f31c-fd2a-9a826e3cf69d@oracle.com>

+1

-- Kevin

On 1/15/2020 2:30 AM, Johan Vos wrote:
> Hi Kevin,
>
> Please review http://cr.openjdk.java.net/~jvos/8237194/webrev.00/ which is
> a fix for https://bugs.openjdk.java.net/browse/JDK-8237194
>
> Thanks,
>
> - Johan


From kevin.rushforth at oracle.com  Wed Jan 15 14:47:03 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 15 Jan 2020 06:47:03 -0800
Subject: RFR: 8237195: increase release version in 13-dev
In-Reply-To: <CABxFH2FuLi99qcmBB19F912RfDinq7wz=OjkQOUgVuT_ccRRcg@mail.gmail.com>
References: <CABxFH2FuLi99qcmBB19F912RfDinq7wz=OjkQOUgVuT_ccRRcg@mail.gmail.com>
Message-ID: <f8c5cfa3-afb2-359f-1000-e7e8c5473f4d@oracle.com>

+1

-- Kevin


On 1/15/2020 2:44 AM, Johan Vos wrote:
> Hi Kevin,
>
> Please review http://cr.openjdk.java.net/~jvos/8237195/webrev.00/ which
> fixes https://bugs.openjdk.java.net/browse/JDK-8237195
>
> Thanks,
>
> - Johan


From johan.vos at gluonhq.com  Wed Jan 15 16:46:51 2020
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 15 Jan 2020 17:46:51 +0100
Subject: RFR: 8237203: release notes for 13.0.2
Message-ID: <CABxFH2GstTFJe-s=tPteMU-1=VC_Cz=eD1QDD05U3xM9RK3JPg@mail.gmail.com>

Hi Kevin,

Please review http://cr.openjdk.java.net/~jvos/8237203/webrev.00/ which
provides a fix for https://bugs.openjdk.java.net/browse/JDK-8237203

thanks,

- Johan

From kevin.rushforth at oracle.com  Wed Jan 15 16:49:04 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 15 Jan 2020 08:49:04 -0800
Subject: RFR: 8237203: release notes for 13.0.2
In-Reply-To: <CABxFH2GstTFJe-s=tPteMU-1=VC_Cz=eD1QDD05U3xM9RK3JPg@mail.gmail.com>
References: <CABxFH2GstTFJe-s=tPteMU-1=VC_Cz=eD1QDD05U3xM9RK3JPg@mail.gmail.com>
Message-ID: <86456747-edd2-f4f3-c9f1-e05df340e6bd@oracle.com>

+1

-- Kevin


On 1/15/2020 8:46 AM, Johan Vos wrote:
> Hi Kevin,
>
> Please review http://cr.openjdk.java.net/~jvos/8237203/webrev.00/ which
> provides a fix for https://bugs.openjdk.java.net/browse/JDK-8237203
>
> thanks,
>
> - Johan


From ebresiedev at gmail.com  Wed Jan 15 20:42:01 2020
From: ebresiedev at gmail.com (Eric Bresie)
Date: Wed, 15 Jan 2020 14:42:01 -0600
Subject: "Using an IDE" Page outdated (Openjfx)
In-Reply-To: CA+0ynh9g3SubanxaDM3hVy6wVxLK6qWH6r_1yOadvz_wansStA@mail.gmail.com
References: CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com
 CA+f4zAEcxMyDG5PKk5hQB5ziKA2fCth7aAiBkwTjLtb_T0RJ6g@mail.gmail.com
Message-ID: <939010e4-7425-475c-9b54-b612a4cf6e24@Erics-iPhone-X>

Anyone on the Netbeans community want to provide any updates on the openjfx IDE page listed below?

Eric Bresie
Ebresie at gmail.com
> On January 10, 2020 at 10:52:26 AM CST, Nir Lisker <nlisker at gmail.com> wrote:
> Hi Robert,
>
> I've brought this up in the past.
>
> I think that the best solution is for someone from the community to take
> that task. I try to keep the Eclipse section updated, we will need someone
> for the other IDE's.
>
> - Nir
>
> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger <
> r.lichtenberger at gmail.com> wrote:
>
> > I've noticed that
> > https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
> > seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no
> > longer exists, etc.).
> >
> > Could someone please update this page so that it is easier for newcomers to
> > dive into the development of OpenJFX.
> >
> > Thanks,
> > Robert
> >

From nlisker at openjdk.java.net  Thu Jan 16 01:06:49 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 16 Jan 2020 01:06:49 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
 <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
 <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
Message-ID: <rZiAhPnuGcar7pYndMgtciD3CdsppEezhnNfVj6NNtc=.fa6bb3ff-2990-436b-a1ae-acec56663af6@github.com>

On Tue, 14 Jan 2020 16:50:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> I should add that it will depend on whether there are any regressions. One thing we do need to be careful of is introducing regressions during rampdown.
> 
> The fix looks good to me.
> After this change the steps needed for playing an `Animation` backwards will change.
> Earlier this was documented with `Animation.play()` API as below.
> 
> -------------
> To play an `Animation` backwards from the end:
> animation.setRate(negative rate);
> animation.jumpTo(overall duration of animation);
> animation.play();
> -------------
> 
> After this PR call to `jumpTo()` won't be needed here.
> So this PR may need a document change for `Animation.play()`.
> Also to note that the behavior of above mentioned three calls remains same with the changes in this change.

> If cycleCount is set to 2 does the animation play the same number of times with or without the jumpTo both before and after this change?

Before the change:
* With `jumpTo`: plays backwards 2 times.
* Without `jumpTo`: doesn't play no mater how many times you call `play()`. Compare with the case where `cycleCount` is 1, in which case the first call does nothing (moves the playing head to the start) and the second one plays backwards.

After the change:
* With `jumpTo`: plays backwards 2 times.
* Without `jumpTo`: plays backwards 2 times.

> If the jumpTo isn't required, then this isn't this a change in behaviour?

Current code with `jumpTo` will behave the same. The question (which I presented initially) is whether this behavior is considered a bug or not when it comes to the initial state of an animation. It is certainly a bug when `stop()` is called, so I assume it is similar for the initial state.

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

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

From nlisker at openjdk.java.net  Thu Jan 16 01:10:11 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 16 Jan 2020 01:10:11 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <rZiAhPnuGcar7pYndMgtciD3CdsppEezhnNfVj6NNtc=.fa6bb3ff-2990-436b-a1ae-acec56663af6@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
 <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
 <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
 <rZiAhPnuGcar7pYndMgtciD3CdsppEezhnNfVj6NNtc=.fa6bb3ff-2990-436b-a1ae-acec56663af6@github.com>
Message-ID: <TtzBSdvUXDRZeBuWZ5wMB89uX8CL97KnMw2yk243JKI=.d31759e7-1884-4182-a2b9-330ecdfe8e77@github.com>

On Thu, 16 Jan 2020 01:06:30 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The fix looks good to me.
>> After this change the steps needed for playing an `Animation` backwards will change.
>> Earlier this was documented with `Animation.play()` API as below.
>> 
>> -------------
>> To play an `Animation` backwards from the end:
>> animation.setRate(negative rate);
>> animation.jumpTo(overall duration of animation);
>> animation.play();
>> -------------
>> 
>> After this PR call to `jumpTo()` won't be needed here.
>> So this PR may need a document change for `Animation.play()`.
>> Also to note that the behavior of above mentioned three calls remains same with the changes in this change.
> 
>> If cycleCount is set to 2 does the animation play the same number of times with or without the jumpTo both before and after this change?
> 
> Before the change:
> * With `jumpTo`: plays backwards 2 times.
> * Without `jumpTo`: doesn't play no mater how many times you call `play()`. Compare with the case where `cycleCount` is 1, in which case the first call does nothing (moves the playing head to the start) and the second one plays backwards.
> 
> After the change:
> * With `jumpTo`: plays backwards 2 times.
> * Without `jumpTo`: plays backwards 2 times.
> 
>> If the jumpTo isn't required, then this isn't this a change in behaviour?
> 
> Current code with `jumpTo` will behave the same. The question (which I presented initially) is whether this behavior is considered a bug or not when it comes to the initial state of an animation. It is certainly a bug when `stop()` is called, so I assume it is similar for the initial state.

> So this PR may need a document change for `Animation.play()`

Yes, and the docs need clarification in other places anyway. The [parent issue](https://bugs.openjdk.java.net/browse/JDK-8210238) from which this bug was isolated talks about these. Not sure at what point I will go over it since `Animation` is going to get some more changes in the (hopefully) near future.

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

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

From tom.schindl at bestsolution.at  Thu Jan 16 07:31:04 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 16 Jan 2020 08:31:04 +0100
Subject: DnD Move does not work on OS-X
In-Reply-To: <6da9010f-e888-6cdb-79cf-35ed844a052d@bestsolution.at>
References: <6da9010f-e888-6cdb-79cf-35ed844a052d@bestsolution.at>
Message-ID: <d848609f-fdd5-bab5-2dc1-53bf24a89cc9@bestsolution.at>

I filed https://bugs.openjdk.java.net/browse/JDK-8237329

Tom

On 09.01.20 15:48, Tom Schindl wrote:
> I also tried with
> https://docs.oracle.com/javafx/2/drag_drop/jfxpub-drag_drop.htm and it
> does not work either.

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From arapte at openjdk.java.net  Thu Jan 16 11:28:52 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 16 Jan 2020 11:28:52 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
Message-ID: <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>

On Thu, 16 Jan 2020 10:55:11 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1306:
> 
>> 1305:             int verticalTileNb = (int) Math.ceil(height / (double) maxTextureSize);
>> 1306:             int horizontalTileNb = (int) Math.ceil(width / (double) maxTextureSize);
>> 1307:             for (int i = 0; i < horizontalTileNb; i++) {
> 
> A suggestion for this arithmetic.
> int verticalTileNb = height / maxTextureSize + 1;
> int horizontalTileNb = width / maxTextureSize + 1;
> This will avoid the type casting and floating point operations. However I leave it to you to change or not.

Assuming `Nb` in `verticalTileNb` stands for number, I would recommend to change the names as `numVerticalTiles` and `numHorizontalTiles`

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

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

From arapte at openjdk.java.net  Thu Jan 16 11:28:50 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 16 Jan 2020 11:28:50 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
Message-ID: <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>

On Thu, 16 Jan 2020 11:28:46 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 1 additional commit.

The fix itself looks good and seems safe for 14.
I do have few minor changes in test file and suggestions in fix code, please take a look.
Also verified that large sized snapshots are created correctly.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1303:

> 1302:         if (height > maxTextureSize || width > maxTextureSize) {
> 1303:             // The requested size for the screenshot is to big to fit a single texture,
> 1304:             // so we need to take several snapshot tiles and merge them into single image (fixes JDK-8088198)

Should be `too` big to fit

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1306:

> 1305:             int verticalTileNb = (int) Math.ceil(height / (double) maxTextureSize);
> 1306:             int horizontalTileNb = (int) Math.ceil(width / (double) maxTextureSize);
> 1307:             for (int i = 0; i < horizontalTileNb; i++) {

A suggestion for this arithmetic.
int verticalTileNb = height / maxTextureSize + 1;
int horizontalTileNb = width / maxTextureSize + 1;
This will avoid the type casting and floating point operations. However I leave it to you to change or not.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1312:

> 1311:                     int tileWidth = Math.min(maxTextureSize, width - xOffset);
> 1312:                     int tileHeight = Math.min(maxTextureSize, height - yOffset);
> 1313:                     WritableImage tile = doSnapshotTile(scene, xMin + xOffset, yMin + yOffset, tileWidth, tileHeight, root, transform, depthBuffer, fill, camera, null);

`int xOffset = i * maxTextureSize;`
`int tileWidth = Math.min(maxTextureSize, width - xOffset);`

These two lines should be moved to the outer loop of horizontal tabs.

tests/system/src/test/java/test/javafx/scene/Snapshot3Test.java line 1:

> 1: package test.javafx.scene;
> 2: 

Copyright header should be added to all new files. You can copy the header from any other file ([header sample](https://github.com/openjdk/jfx/blob/20325e1c3ec4c4e81af74d3d43bf3a803dbe1a51/tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java#L1).)
Only change would be that, this file would contain only year `2020` in the copyright header.

tests/system/src/test/java/test/javafx/scene/Snapshot3Test.java line 39:

> 38:     public void teardownEach() {
> 39:     }
> 40: 

This empty method is not needed.

tests/system/src/test/java/test/javafx/scene/Snapshot3Test.java line 65:

> 64: 
> 65: 

Please remove the extra empty lines, 3, 62, 65.

tests/system/src/test/java/test/javafx/scene/Snapshot3Test.java line 59:

> 58:             Image image = rect.snapshot(params, null);
> 59:             assertEquals(VALUE_LARGER_THAN_TEXTURE_SIZE, (int) image.getHeight());
> 60:         });

Should add `assertNull(image);` before the `assertEquals`

tests/system/src/test/java/test/javafx/scene/Snapshot3Test.java line 11:

> 10: 
> 11: import static org.junit.Assert.*;
> 12: 

Usually we avoid wild imports and import only the specific classes.

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

Changes requested by arapte (Reviewer).

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

From mpaus at openjdk.java.net  Thu Jan 16 11:56:20 2020
From: mpaus at openjdk.java.net (Michael Paus)
Date: Thu, 16 Jan 2020 11:56:20 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
 <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>
Message-ID: <2iH6z7Dd7E8YmNP5c09iujnjjlD_BnYYMJBM0QeJ4lc=.c1e76c10-abe4-4633-864e-71b2ab07c840@github.com>

On Thu, 16 Jan 2020 10:55:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1306:
>> 
>>> 1305:             int verticalTileNb = (int) Math.ceil(height / (double) maxTextureSize);
>>> 1306:             int horizontalTileNb = (int) Math.ceil(width / (double) maxTextureSize);
>>> 1307:             for (int i = 0; i < horizontalTileNb; i++) {
>> 
>> A suggestion for this arithmetic.
>> int verticalTileNb = height / maxTextureSize + 1;
>> int horizontalTileNb = width / maxTextureSize + 1;
>> This will avoid the type casting and floating point operations. However I leave it to you to change or not.
> 
> Assuming `Nb` in `verticalTileNb` stands for number, I would recommend to change the names as `numVerticalTiles` and `numHorizontalTiles`

I think the proposed code changes are wrong in case that `height / maxTextureSize` is an exact integer. (Same for width). I normally add the 1 only if `height  % maxTextureSize != 0`

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

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

From arapte at openjdk.java.net  Thu Jan 16 11:59:47 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 16 Jan 2020 11:59:47 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
Message-ID: <Pmq2La_m4hUt-XbSMUWO6fXGfIeP9qpvUZNZdk8eOQk=.2bf4f781-29cd-4700-9586-d40fa30ad473@github.com>

On Thu, 16 Jan 2020 11:28:21 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix itself looks good and seems safe for 14.
> I do have few minor changes in test file and suggestions in fix code, please take a look.
> Also verified that large sized snapshots are created correctly.

> 
> 
> Upon closer inspection, I believe that the tests I added in Snapshot3Test are indeed redundant and less complete than the 4 ignored test in Snapshot2Test.
> I therefore propose to remove Snapshot3Test.java entirely and to re-enable the 4 testSnapshotBig* test instead.

I did miss this comment, The test in `Snapshot2Test` look sufficient and you can get rid of `Snapshot3Test.java` and so all my comments :)

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu Jan 16 13:57:00 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 16 Jan 2020 13:57:00 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <2iH6z7Dd7E8YmNP5c09iujnjjlD_BnYYMJBM0QeJ4lc=.c1e76c10-abe4-4633-864e-71b2ab07c840@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
 <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>
 <2iH6z7Dd7E8YmNP5c09iujnjjlD_BnYYMJBM0QeJ4lc=.c1e76c10-abe4-4633-864e-71b2ab07c840@github.com>
Message-ID: <ygFJRqBY1XRI_vM2eLBZgxu2fBawLhRV-jL7SDC8Bgg=.3c695258-3ef3-4503-95e6-a742105504b7@github.com>

On Thu, 16 Jan 2020 11:56:10 GMT, Michael Paus <mpaus at openjdk.org> wrote:

>> Assuming `Nb` in `verticalTileNb` stands for number, I would recommend to change the names as `numVerticalTiles` and `numHorizontalTiles`
> 
> I think the proposed code changes are wrong in case that `height / maxTextureSize` is an exact integer. (Same for width). I normally add the 1 only if `height  % maxTextureSize != 0`

Indeed, substituting the floating math for integer math requires an extra test on the remainder to be correct. 
Since this code isn't located in a tight loop, I'm not sure this optimization is worth making the code less straight forward. What do you all think?

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu Jan 16 14:07:26 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 16 Jan 2020 14:07:26 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>

> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
> 
> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
> Other than that, the logic used to do the actual snapshot is unchanged.
> 
> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

The pull request has been updated with 2 additional commits.

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

Added commits:
 - 50191728: Several changes following code review
 - d4ecb734: Removed Snapshot3Test.java and re-enabled ignored tests in Snapshot2Test.java

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/68/files
  - new: https://git.openjdk.java.net/jfx/pull/68/files/9986809d..50191728

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

  Stats: 82 lines in 3 files changed: 1 ins; 71 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/68.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/68/head:pull/68

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

From mpaus at openjdk.java.net  Thu Jan 16 14:16:51 2020
From: mpaus at openjdk.java.net (Michael Paus)
Date: Thu, 16 Jan 2020 14:16:51 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <ygFJRqBY1XRI_vM2eLBZgxu2fBawLhRV-jL7SDC8Bgg=.3c695258-3ef3-4503-95e6-a742105504b7@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
 <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>
 <2iH6z7Dd7E8YmNP5c09iujnjjlD_BnYYMJBM0QeJ4lc=.c1e76c10-abe4-4633-864e-71b2ab07c840@github.com>
 <ygFJRqBY1XRI_vM2eLBZgxu2fBawLhRV-jL7SDC8Bgg=.3c695258-3ef3-4503-95e6-a742105504b7@github.com>
Message-ID: <RAXG1dHMd3JBSoplePZJ0DsX9Cfu2iq2M28U1PMAyCo=.2411fc8f-7dec-4790-a7fe-27618f54a42a@github.com>

On Thu, 16 Jan 2020 13:56:44 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I think the proposed code changes are wrong in case that `height / maxTextureSize` is an exact integer. (Same for width). I normally add the 1 only if `height  % maxTextureSize != 0`
> 
> Indeed, substituting the floating math for integer math requires an extra test on the remainder to be correct. 
> Since this code isn't located in a tight loop, I'm not sure this optimization is worth making the code less straight forward. What do you all think?

I think it is not worth it.

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

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

From kcr at openjdk.java.net  Thu Jan 16 14:26:36 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 16 Jan 2020 14:26:36 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <RAXG1dHMd3JBSoplePZJ0DsX9Cfu2iq2M28U1PMAyCo=.2411fc8f-7dec-4790-a7fe-27618f54a42a@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
 <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>
 <2iH6z7Dd7E8YmNP5c09iujnjjlD_BnYYMJBM0QeJ4lc=.c1e76c10-abe4-4633-864e-71b2ab07c840@github.com>
 <ygFJRqBY1XRI_vM2eLBZgxu2fBawLhRV-jL7SDC8Bgg=.3c695258-3ef3-4503-95e6-a742105504b7@github.com>
 <RAXG1dHMd3JBSoplePZJ0DsX9Cfu2iq2M28U1PMAyCo=.2411fc8f-7dec-4790-a7fe-27618f54a42a@github.com>
Message-ID: <vI3KN9R0BSI9iUdttOpBFg09lQvj8-ROGIVPyMpZn44=.5cd440c1-b270-4c62-8f28-87c4ce4894e1@github.com>

On Thu, 16 Jan 2020 14:16:37 GMT, Michael Paus <mpaus at openjdk.org> wrote:

>> Indeed, substituting the floating math for integer math requires an extra test on the remainder to be correct. 
>> Since this code isn't located in a tight loop, I'm not sure this optimization is worth making the code less straight forward. What do you all think?
> 
> I think it is not worth it.

I agree. I do like the suggestion to rename the variables, though.

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu Jan 16 16:19:58 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 16 Jan 2020 16:19:58 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
Message-ID: <_KvVLKw85jkJ5h2Ktk4U9dqTIHdVmhujxTVvFcAMJSE=.e9213e77-1853-49fb-b985-e67bfb8fae45@github.com>

On Thu, 16 Jan 2020 10:58:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1312:
> 
>> 1311:                     int tileWidth = Math.min(maxTextureSize, width - xOffset);
>> 1312:                     int tileHeight = Math.min(maxTextureSize, height - yOffset);
>> 1313:                     WritableImage tile = doSnapshotTile(scene, xMin + xOffset, yMin + yOffset, tileWidth, tileHeight, root, transform, depthBuffer, fill, camera, null);
> 
> `int xOffset = i * maxTextureSize;`
> `int tileWidth = Math.min(maxTextureSize, width - xOffset);`
> 
> These two lines should be moved to the outer loop of horizontal tabs.

done in 501917284e0490d16b1831fcd854e31a779449b9

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu Jan 16 16:20:38 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 16 Jan 2020 16:20:38 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
Message-ID: <JMBslIkCUcbPVRbxvDi9ddWnLlWUTS8mpNXJ1FGJ4UM=.2a95ac90-f598-46d2-a605-8945704e23f6@github.com>

On Thu, 16 Jan 2020 10:47:26 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1303:
> 
>> 1302:         if (height > maxTextureSize || width > maxTextureSize) {
>> 1303:             // The requested size for the screenshot is to big to fit a single texture,
>> 1304:             // so we need to take several snapshot tiles and merge them into single image (fixes JDK-8088198)
> 
> Should be `too` big to fit

done in 501917284e0490d16b1831fcd854e31a779449b9

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

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

From wookey.dean at gmail.com  Thu Jan 16 16:33:36 2020
From: wookey.dean at gmail.com (Dean Wookey)
Date: Thu, 16 Jan 2020 18:33:36 +0200
Subject: CssStyleHelper canReuseStyleHelper
Message-ID: <CAKZ_BFhsnYkWUXCROPXvjoFRYJ3JRpfZ5nPj_WFFNoB+Q7GwRw@mail.gmail.com>

Hi Ajit, David,

I came accross a potential issue introduced by JDK-8090462 (
https://bugs.openjdk.java.net/browse/JDK-8090462), (
https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab).
The issue is in the canReuseStyleHelper method. canReuseStyleHelper is
called as a result of changes to the scene graph and for other reasons. The
original code found the parent helper in the following way:

        Styleable parent = node.getStyleableParent();
        while (parent != null) {
            if (parent instanceof Node) {
                parentHelper = ((Node) parent).styleHelper;
                if (parentHelper != null) break;
            }
            parent = parent.getStyleableParent();
        }

This gets the parent helper for the new parent of the node. The code now (
https://github.com/openjdk/jfx/blob/20325e1c3ec4c4e81af74d3d43bf3a803dbe1a51/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java#L322
):

        CssStyleHelper parentHelper =
getStyleHelper(node.styleHelper.firstStyleableAncestor);

gets the helper of the previous parent of the node since
firstStyleableAncestor hasn't been updated to reflect the current state of
the scene graph yet. This means if you move a node, it could keep its
CssStyleHelper even if it's under completely new parents.

I'm not sure if this is actually causing any problems. It would be helpful
if I knew the kind of things that could go wrong if you reuse a style
helper so that I could design a test that highlighted the issue.

Can you perhaps think of cases where this could go badly?

Dean

From github.com+7450507+fthevenet at openjdk.java.net  Thu Jan 16 16:45:31 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 16 Jan 2020 16:45:31 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <vI3KN9R0BSI9iUdttOpBFg09lQvj8-ROGIVPyMpZn44=.5cd440c1-b270-4c62-8f28-87c4ce4894e1@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>
 <nCiXDONT6fAH2UbyPuNlv6gZSLRfvPY6cdGUybnFizc=.fcdcba5f-1086-4089-828c-86d12031f441@github.com>
 <24CUZqZ2Q14eKcfZHO_3N7R0Xh6Y2OflY1gQKEk2TJs=.1e454465-c305-4111-b35a-6a29ff8f1046@github.com>
 <2iH6z7Dd7E8YmNP5c09iujnjjlD_BnYYMJBM0QeJ4lc=.c1e76c10-abe4-4633-864e-71b2ab07c840@github.com>
 <ygFJRqBY1XRI_vM2eLBZgxu2fBawLhRV-jL7SDC8Bgg=.3c695258-3ef3-4503-95e6-a742105504b7@github.com>
 <RAXG1dHMd3JBSoplePZJ0DsX9Cfu2iq2M28U1PMAyCo=.2411fc8f-7dec-4790-a7fe-27618f54a42a@github.com>
 <vI3KN9R0BSI9iUdttOpBFg09lQvj8-ROGIVPyMpZn44=.5cd440c1-b270-4c62-8f28-87c4ce4894e1@github.com>
Message-ID: <tjKgkzFsEAZDMoH8jCMGX3vcl7CVxNEO61BvE_U0q5I=.52eff089-17ba-4d34-b88d-5e4780704954@github.com>

On Thu, 16 Jan 2020 14:26:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think it is not worth it.
> 
> I agree. I do like the suggestion to rename the variables, though.

done in 501917284e0490d16b1831fcd854e31a779449b9

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

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

From nlisker at openjdk.java.net  Thu Jan 16 17:00:50 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 16 Jan 2020 17:00:50 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
Message-ID: <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>

On Thu, 16 Jan 2020 17:00:47 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 2 additional commits.

I tested this fix against the repro code in https://github.com/javafxports/openjdk-jfx/issues/433 (which is [JDK-8222238](https://bugs.openjdk.java.net/browse/JDK-8222238)), but there is still an NPE. I'm not certain that this fix is supposed to solve that bug, but according to the comments, the root cause is the same as [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082), which is related to this one. It's worth to take a look to see if something was missed.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1290:

> 1289:         int yMin = (int)Math.floor(y);
> 1290:         int xMax = (int)Math.ceil(x + w);
> 1291:         int yMax = (int)Math.ceil(y + h);

While you're working in the area, this code can be written as

        int width, height;
        if (wimg == null) {
            int xMax = (int)Math.ceil(x + w);
            int yMax = (int)Math.ceil(y + h);
            width = Math.max(xMax - xMin, 1);
            height = Math.max(yMax - yMin, 1);
            wimg = new WritableImage(width, height);
        } else {

to avoid unnecessary computations.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1313:

> 1312:                     int tileHeight = Math.min(maxTextureSize, height - yOffset);
> 1313:                     WritableImage tile = doSnapshotTile(scene, xMin + xOffset, yMin + yOffset, tileWidth, tileHeight, root, transform, depthBuffer, fill, camera, null);
> 1314:                     wimg.getPixelWriter().setPixels(xOffset, yOffset, tileWidth, tileHeight, tile.getPixelReader(), 0, 0);

This line is too long and needs to break into 2. I think that the limit is 135 characters.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1316:

> 1315:                 }
> 1316:             }
> 1317:         } else {

I would extract this code into its own method similar to `doSnapshotTile`:

`assemble(scene, xMin, yMin, width, height, root, transform, depthBuffer, fill, camera, wimg, maxTextureSize);`

(`assemble` is a bad name, I didn't think about a better one).

The method can return he resulting `WritableImage`, but it is not needed since it is manipulated via "side-effects". I would, however, bring it line with the `else` clause - either both use `wimg = methodName(..., wimg, ...);` or just `methodName(..., wimg, ...);`. This is fine since the input `WritableImage` is never `null`. From a readability point of view, using return values seems better.

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



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

From David.Grieve at microsoft.com  Thu Jan 16 19:01:38 2020
From: David.Grieve at microsoft.com (David Grieve)
Date: Thu, 16 Jan 2020 19:01:38 +0000
Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
In-Reply-To: <CAKZ_BFhsnYkWUXCROPXvjoFRYJ3JRpfZ5nPj_WFFNoB+Q7GwRw@mail.gmail.com>
References: <CAKZ_BFhsnYkWUXCROPXvjoFRYJ3JRpfZ5nPj_WFFNoB+Q7GwRw@mail.gmail.com>
Message-ID: <BN8PR21MB128173D99FC7DACF75728B6C9B360@BN8PR21MB1281.namprd21.prod.outlook.com>

I'd create a scenegraph 

                 R 
         .-----+-----.
         A               B
   .----+----.
   C            D

Where C and D are Labels. Then I'd set a font style on A and a different font style on B. 
C and D should pick up the font style of A. Then move D to B and see if it still has A's 
font style. 

It may be necessary to have a more deeply nested scene graph. 

The potential issue is that the node that got moved could pick up the old set of styles
if the style helper is not renewed. 

Ultimately, canReuseStyleHelper will return false if the set of styles for the 
new parent (line 110 or so in CssStyleHelper.java) are different. 

> -----Original Message-----
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> Dean Wookey
> Sent: Thursday, January 16, 2020 11:34 AM
> To: openjfx-dev at openjdk.java.net Mailing <openjfx-
> dev at openjdk.java.net>; David Grieve <david.grieve at oracle.com>
> Cc: aghaisas at openjdk.org
> Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
> 
> Hi Ajit, David,
> 
> I came accross a potential issue introduced by JDK-8090462 (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .openjdk.java.net%2Fbrowse%2FJDK-
> 8090462&amp;data=02%7C01%7Cdavid.grieve%40microsoft.com%7C235930d
> fab7f4f7f15ba08d79aa21774%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> C0%7C637147893881930150&amp;sdata=awsMTPYkp7GmSrYsoy9I6M%2F6uj
> X7thgZhBVY9UKcjpU%3D&amp;reserved=0), (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenjdk%2Fjfx%2Fcommit%2F834b0d05e7a2a8351403ec4a121ea
> b312d80fd24%23diff-
> 9ec098280fa1aeed53c70243347e76ab&amp;data=02%7C01%7Cdavid.grieve%
> 40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f141
> af91ab2d7cd011db47%7C1%7C0%7C637147893881930150&amp;sdata=ZhWS
> dmlJ9rLzIkqnohWTacJKPb8FNrG5yApF0fwP8g4%3D&amp;reserved=0).
> The issue is in the canReuseStyleHelper method. canReuseStyleHelper is
> called as a result of changes to the scene graph and for other reasons. The
> original code found the parent helper in the following way:
> 
>         Styleable parent = node.getStyleableParent();
>         while (parent != null) {
>             if (parent instanceof Node) {
>                 parentHelper = ((Node) parent).styleHelper;
>                 if (parentHelper != null) break;
>             }
>             parent = parent.getStyleableParent();
>         }
> 
> This gets the parent helper for the new parent of the node. The code now (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenjdk%2Fjfx%2Fblob%2F20325e1c3ec4c4e81af74d3d43bf3a803
> dbe1a51%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fjavafx%
> 2Fscene%2FCssStyleHelper.java%23L322&amp;data=02%7C01%7Cdavid.griev
> e%40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C637147893881930150&amp;sdata=nJR
> 3ocKaIsf6HWNjHtseEbqLbEvbW7%2FzQS1B%2F39GVyI%3D&amp;reserved=
> 0
> ):
> 
>         CssStyleHelper parentHelper =
> getStyleHelper(node.styleHelper.firstStyleableAncestor);
> 
> gets the helper of the previous parent of the node since
> firstStyleableAncestor hasn't been updated to reflect the current state of the
> scene graph yet. This means if you move a node, it could keep its
> CssStyleHelper even if it's under completely new parents.
> 
> I'm not sure if this is actually causing any problems. It would be helpful if I
> knew the kind of things that could go wrong if you reuse a style helper so
> that I could design a test that highlighted the issue.
> 
> Can you perhaps think of cases where this could go badly?
> 
> Dean

From r.lichtenberger at gmail.com  Fri Jan 17 07:29:43 2020
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Fri, 17 Jan 2020 08:29:43 +0100
Subject: Correct branch for PR?
Message-ID: <CA+f4zAEbNwV1qrFB27ZgYQdd9MpaEUC8D4pALvYAxST05aLDNA@mail.gmail.com>

I have a testcase + fix ready for JDK-8237372 (A null pointer exception in
TabPaneSkin if only a mouse release event is sent to the skin).

To avoid the kind of confusion I created with my last pull request ;-)
* For what branch should I create the pull request? (From my point of view
jfx14 is preferable, since this is a real bug affecting our software)
* Will pull requests for jfx14 (like my last one) be automatically pushed
forward to the master branch?

Best regards,
Robert

From wookey.dean at gmail.com  Fri Jan 17 09:50:29 2020
From: wookey.dean at gmail.com (Dean Wookey)
Date: Fri, 17 Jan 2020 11:50:29 +0200
Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
In-Reply-To: <BN8PR21MB128173D99FC7DACF75728B6C9B360@BN8PR21MB1281.namprd21.prod.outlook.com>
References: <CAKZ_BFhsnYkWUXCROPXvjoFRYJ3JRpfZ5nPj_WFFNoB+Q7GwRw@mail.gmail.com>
 <BN8PR21MB128173D99FC7DACF75728B6C9B360@BN8PR21MB1281.namprd21.prod.outlook.com>
Message-ID: <CAKZ_BFiqNHcNy=tP9RkSyfb1xu5k6j_HzxKn_Yj9GWqLWmJPpg@mail.gmail.com>

Hi David,

Thanks, I wrote that test as a graphics module test and it does fail.
https://gist.github.com/DeanWookey/2624945e3ba037f00c39c0bfd0b22cef

It passes if you move

node.styleHelper.firstStyleableAncestor = findFirstStyleableAncestor(node);
(line 134)

to line 321. I imagine there is some performance impact if you do this. I'm
not sure it affects anything other than fonts at the moment. Pseudoclasses
recalculate the entire tree every time, so they appear to be fine.

Dean

On Thu, Jan 16, 2020 at 9:01 PM David Grieve <David.Grieve at microsoft.com>
wrote:

> I'd create a scenegraph
>
>                  R
>          .-----+-----.
>          A               B
>    .----+----.
>    C            D
>
> Where C and D are Labels. Then I'd set a font style on A and a different
> font style on B.
> C and D should pick up the font style of A. Then move D to B and see if it
> still has A's
> font style.
>
> It may be necessary to have a more deeply nested scene graph.
>
> The potential issue is that the node that got moved could pick up the old
> set of styles
> if the style helper is not renewed.
>
> Ultimately, canReuseStyleHelper will return false if the set of styles for
> the
> new parent (line 110 or so in CssStyleHelper.java) are different.
>
> > -----Original Message-----
> > From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> > Dean Wookey
> > Sent: Thursday, January 16, 2020 11:34 AM
> > To: openjfx-dev at openjdk.java.net Mailing <openjfx-
> > dev at openjdk.java.net>; David Grieve <david.grieve at oracle.com>
> > Cc: aghaisas at openjdk.org
> > Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
> >
> > Hi Ajit, David,
> >
> > I came accross a potential issue introduced by JDK-8090462 (
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> > .openjdk.java.net%2Fbrowse%2FJDK-
> > 8090462&amp;data=02%7C01%7Cdavid.grieve%40microsoft.com%7C235930d
> > fab7f4f7f15ba08d79aa21774%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> > C0%7C637147893881930150&amp;sdata=awsMTPYkp7GmSrYsoy9I6M%2F6uj
> > X7thgZhBVY9UKcjpU%3D&amp;reserved=0), (
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fopenjdk%2Fjfx%2Fcommit%2F834b0d05e7a2a8351403ec4a121ea
> > b312d80fd24%23diff-
> > 9ec098280fa1aeed53c70243347e76ab&amp;data=02%7C01%7Cdavid.grieve%
> > 40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637147893881930150&amp;sdata=ZhWS
> > dmlJ9rLzIkqnohWTacJKPb8FNrG5yApF0fwP8g4%3D&amp;reserved=0).
> > The issue is in the canReuseStyleHelper method. canReuseStyleHelper is
> > called as a result of changes to the scene graph and for other reasons.
> The
> > original code found the parent helper in the following way:
> >
> >         Styleable parent = node.getStyleableParent();
> >         while (parent != null) {
> >             if (parent instanceof Node) {
> >                 parentHelper = ((Node) parent).styleHelper;
> >                 if (parentHelper != null) break;
> >             }
> >             parent = parent.getStyleableParent();
> >         }
> >
> > This gets the parent helper for the new parent of the node. The code now
> (
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fopenjdk%2Fjfx%2Fblob%2F20325e1c3ec4c4e81af74d3d43bf3a803
> > dbe1a51%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fjavafx%
> > 2Fscene%2FCssStyleHelper.java%23L322&amp;data=02%7C01%7Cdavid.griev
> > e%40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f
> > 141af91ab2d7cd011db47%7C1%7C0%7C637147893881930150&amp;sdata=nJR
> > 3ocKaIsf6HWNjHtseEbqLbEvbW7%2FzQS1B%2F39GVyI%3D&amp;reserved=
> > 0
> > ):
> >
> >         CssStyleHelper parentHelper =
> > getStyleHelper(node.styleHelper.firstStyleableAncestor);
> >
> > gets the helper of the previous parent of the node since
> > firstStyleableAncestor hasn't been updated to reflect the current state
> of the
> > scene graph yet. This means if you move a node, it could keep its
> > CssStyleHelper even if it's under completely new parents.
> >
> > I'm not sure if this is actually causing any problems. It would be
> helpful if I
> > knew the kind of things that could go wrong if you reuse a style helper
> so
> > that I could design a test that highlighted the issue.
> >
> > Can you perhaps think of cases where this could go badly?
> >
> > Dean
>

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 17 11:28:17 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 17 Jan 2020 11:28:17 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
 <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
Message-ID: <16XxegMp9uAyf0Ni0BZBbd0npwtacp2YZtL7f7Fgvq0=.96a3a6cf-cbfd-4ffa-b7f7-8336914150f4@github.com>

On Thu, 16 Jan 2020 17:00:32 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 2 additional commits.
> 
> I tested this fix against the repro code in https://github.com/javafxports/openjdk-jfx/issues/433 (which is [JDK-8222238](https://bugs.openjdk.java.net/browse/JDK-8222238)), but there is still an NPE. I'm not certain that this fix is supposed to solve that bug, but according to the comments, the root cause is the same as [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082), which is related to this one. It's worth to take a look to see if something was missed.

> 
> 
> I tested this fix against the repro code in [javafxports/openjdk-jfx#433](https://github.com/javafxports/openjdk-jfx/issues/433) (which is [JDK-8222238](https://bugs.openjdk.java.net/browse/JDK-8222238)), but there is still an NPE. I'm not certain that this fix is supposed to solve that bug, but according to the comments, the root cause is the same as [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082), which is related to this one. It's worth to take a look to see if something was missed.

Although JDK-8189082 (and potentially others) are indeed likely to share the same root cause, the fix proposed here won't have an effect on anything else than snapshots, since the tiling is done at the Scene level rather than within QuantumToolkit.
I purposefully choose to take the "easy" way out to limit the potential side-effects of the change, but I agree that on the other hand supporting tiling when needed directly in QuantumToolkit::renderToImage would have the potential to solve a whole category of issues.
Also, from a very pragmatic angle, because of the increased complexity and scope and the risks that come with it, I'm not very optimistic that this change could realistically make it into jfx14 and to be honest I'm quite eager to get the screenshot feature in my app working properly ASAP.

I'd be willing to try and work on a more generic fix under the umbrella of JDK-8189082, that'd be targeted at 15, while still having this fix included as part 14; but that means this should (ideally) be reverted once it becomes useless. 
I don't know if the idea of having a "temporary fix" approach seems acceptable in that context.

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

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

From thiago.sayao at clamed.com.br  Fri Jan 17 11:32:44 2020
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Fri, 17 Jan 2020 11:32:44 +0000
Subject: Correct branch for PR?
In-Reply-To: <CA+f4zAEbNwV1qrFB27ZgYQdd9MpaEUC8D4pALvYAxST05aLDNA@mail.gmail.com>
References: <CA+f4zAEbNwV1qrFB27ZgYQdd9MpaEUC8D4pALvYAxST05aLDNA@mail.gmail.com>
Message-ID: <CP2P15201MB222862085239D216E9893633DE310@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

AFAIK, use master. They will decide to backport to a point release or not.


________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Robert Lichtenberger <r.lichtenberger at gmail.com>
Enviado: sexta-feira, 17 de janeiro de 2020 04:29
Para: openjfx-dev at openjdk.java.net Mailing <openjfx-dev at openjdk.java.net>
Assunto: Correct branch for PR?

I have a testcase + fix ready for JDK-8237372 (A null pointer exception in
TabPaneSkin if only a mouse release event is sent to the skin).

To avoid the kind of confusion I created with my last pull request ;-)
* For what branch should I create the pull request? (From my point of view
jfx14 is preferable, since this is a real bug affecting our software)
* Will pull requests for jfx14 (like my last one) be automatically pushed
forward to the master branch?

Best regards,
Robert

From wookey.dean at gmail.com  Fri Jan 17 11:57:59 2020
From: wookey.dean at gmail.com (Dean Wookey)
Date: Fri, 17 Jan 2020 13:57:59 +0200
Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
In-Reply-To: <CAKZ_BFiqNHcNy=tP9RkSyfb1xu5k6j_HzxKn_Yj9GWqLWmJPpg@mail.gmail.com>
References: <CAKZ_BFhsnYkWUXCROPXvjoFRYJ3JRpfZ5nPj_WFFNoB+Q7GwRw@mail.gmail.com>
 <BN8PR21MB128173D99FC7DACF75728B6C9B360@BN8PR21MB1281.namprd21.prod.outlook.com>
 <CAKZ_BFiqNHcNy=tP9RkSyfb1xu5k6j_HzxKn_Yj9GWqLWmJPpg@mail.gmail.com>
Message-ID: <CAKZ_BFjvdoStMjiRY5Gs1LmwYtnaDEdy4Oo5hH2pD7NP7PDHEw@mail.gmail.com>

It's also a problem with variables defined in css, as well as inherited
values like visibility (cursor seems to work differently), eg:
.a { col: red; }
.b { col: blue; }
.leaf { -fx-background-color: col}

Then move leaf from branch a to b.

Likewise
.a { visibility: collapse; }
.b { visibility: visible; }
.leaf { visibility: inherit;}

If you move a node from branch a to branch b, it stays invisible. Again
that one like fix solves all these problems.

I've created JDK-8237469 <https://bugs.openjdk.java.net/browse/JDK-8237469>.

On Fri, Jan 17, 2020 at 11:50 AM Dean Wookey <wookey.dean at gmail.com> wrote:

> Hi David,
>
> Thanks, I wrote that test as a graphics module test and it does fail.
> https://gist.github.com/DeanWookey/2624945e3ba037f00c39c0bfd0b22cef
>
> It passes if you move
>
> node.styleHelper.firstStyleableAncestor =
> findFirstStyleableAncestor(node); (line 134)
>
> to line 321. I imagine there is some performance impact if you do this.
> I'm not sure it affects anything other than fonts at the moment.
> Pseudoclasses recalculate the entire tree every time, so they appear to be
> fine.
>
> Dean
>
> On Thu, Jan 16, 2020 at 9:01 PM David Grieve <David.Grieve at microsoft.com>
> wrote:
>
>> I'd create a scenegraph
>>
>>                  R
>>          .-----+-----.
>>          A               B
>>    .----+----.
>>    C            D
>>
>> Where C and D are Labels. Then I'd set a font style on A and a different
>> font style on B.
>> C and D should pick up the font style of A. Then move D to B and see if
>> it still has A's
>> font style.
>>
>> It may be necessary to have a more deeply nested scene graph.
>>
>> The potential issue is that the node that got moved could pick up the old
>> set of styles
>> if the style helper is not renewed.
>>
>> Ultimately, canReuseStyleHelper will return false if the set of styles
>> for the
>> new parent (line 110 or so in CssStyleHelper.java) are different.
>>
>> > -----Original Message-----
>> > From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
>> > Dean Wookey
>> > Sent: Thursday, January 16, 2020 11:34 AM
>> > To: openjfx-dev at openjdk.java.net Mailing <openjfx-
>> > dev at openjdk.java.net>; David Grieve <david.grieve at oracle.com>
>> > Cc: aghaisas at openjdk.org
>> > Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
>> >
>> > Hi Ajit, David,
>> >
>> > I came accross a potential issue introduced by JDK-8090462 (
>> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
>> > .openjdk.java.net%2Fbrowse%2FJDK-
>> > 8090462&amp;data=02%7C01%7Cdavid.grieve%40microsoft.com%7C235930d
>> > fab7f4f7f15ba08d79aa21774%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
>> > C0%7C637147893881930150&amp;sdata=awsMTPYkp7GmSrYsoy9I6M%2F6uj
>> > X7thgZhBVY9UKcjpU%3D&amp;reserved=0), (
>> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> > ub.com%2Fopenjdk%2Fjfx%2Fcommit%2F834b0d05e7a2a8351403ec4a121ea
>> > b312d80fd24%23diff-
>> > 9ec098280fa1aeed53c70243347e76ab&amp;data=02%7C01%7Cdavid.grieve%
>> > 40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f141
>> > af91ab2d7cd011db47%7C1%7C0%7C637147893881930150&amp;sdata=ZhWS
>> > dmlJ9rLzIkqnohWTacJKPb8FNrG5yApF0fwP8g4%3D&amp;reserved=0).
>> > The issue is in the canReuseStyleHelper method. canReuseStyleHelper is
>> > called as a result of changes to the scene graph and for other reasons.
>> The
>> > original code found the parent helper in the following way:
>> >
>> >         Styleable parent = node.getStyleableParent();
>> >         while (parent != null) {
>> >             if (parent instanceof Node) {
>> >                 parentHelper = ((Node) parent).styleHelper;
>> >                 if (parentHelper != null) break;
>> >             }
>> >             parent = parent.getStyleableParent();
>> >         }
>> >
>> > This gets the parent helper for the new parent of the node. The code
>> now (
>> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> > ub.com%2Fopenjdk%2Fjfx%2Fblob%2F20325e1c3ec4c4e81af74d3d43bf3a803
>> > dbe1a51%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fjavafx%
>> > 2Fscene%2FCssStyleHelper.java%23L322&amp;data=02%7C01%7Cdavid.griev
>> > e%40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f
>> > 141af91ab2d7cd011db47%7C1%7C0%7C637147893881930150&amp;sdata=nJR
>> > 3ocKaIsf6HWNjHtseEbqLbEvbW7%2FzQS1B%2F39GVyI%3D&amp;reserved=
>> > 0
>> > ):
>> >
>> >         CssStyleHelper parentHelper =
>> > getStyleHelper(node.styleHelper.firstStyleableAncestor);
>> >
>> > gets the helper of the previous parent of the node since
>> > firstStyleableAncestor hasn't been updated to reflect the current state
>> of the
>> > scene graph yet. This means if you move a node, it could keep its
>> > CssStyleHelper even if it's under completely new parents.
>> >
>> > I'm not sure if this is actually causing any problems. It would be
>> helpful if I
>> > knew the kind of things that could go wrong if you reuse a style helper
>> so
>> > that I could design a test that highlighted the issue.
>> >
>> > Can you perhaps think of cases where this could go badly?
>> >
>> > Dean
>>
>

From kevin.rushforth at oracle.com  Fri Jan 17 13:02:37 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 17 Jan 2020 05:02:37 -0800
Subject: Correct branch for PR?
In-Reply-To: <CA+f4zAEbNwV1qrFB27ZgYQdd9MpaEUC8D4pALvYAxST05aLDNA@mail.gmail.com>
References: <CA+f4zAEbNwV1qrFB27ZgYQdd9MpaEUC8D4pALvYAxST05aLDNA@mail.gmail.com>
Message-ID: <8e8eb6fc-2271-4393-a60e-46e83a48b87f@oracle.com>

Since this is a P3 bug, you can target this to jfx14 as long as the fix 
is safe. The reviewers might ask for it to be retargeted to master, but 
that won't be a problem (going the other way is the direction that 
requires more care and a possible rebase).

-- Kevin


On 1/16/2020 11:29 PM, Robert Lichtenberger wrote:
> I have a testcase + fix ready for JDK-8237372 (A null pointer exception in
> TabPaneSkin if only a mouse release event is sent to the skin).
>
> To avoid the kind of confusion I created with my last pull request ;-)
> * For what branch should I create the pull request? (From my point of view
> jfx14 is preferable, since this is a real bug affecting our software)
> * Will pull requests for jfx14 (like my last one) be automatically pushed
> forward to the master branch?
>
> Best regards,
> Robert


From dwookey at openjdk.java.net  Fri Jan 17 14:18:02 2020
From: dwookey at openjdk.java.net (Dean Wookey)
Date: Fri, 17 Jan 2020 14:18:02 GMT
Subject: RFR: 8237469: CssStyleHelper reuse check fixed
Message-ID: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>

Everything passes with the fix and 5 of the new tests fail without the fix.

removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
movingBranchToDifferentBranchGetsNewCssVariableTest
removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
removingThenAddingNodeToDifferentBranchGetsIneritableStyle
movingNodeToDifferentBranchGetsNewFontStyleTest

I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?

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

Commits:
 - 0749dde7: 8237469: Fixed whitespace issues
 - 4e696401: 8237469: CssStyleHelper reuse check fixed

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 17 14:28:02 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 17 Jan 2020 14:28:02 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>

> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
> 
> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
> Other than that, the logic used to do the actual snapshot is unchanged.
> 
> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

The pull request has been updated with 2 additional commits.

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

Added commits:
 - 8966936f: Wrapped long line
 - 8e44dea2: Refactored height & weight calculation to avoid unnecessary computations

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/68/files
  - new: https://git.openjdk.java.net/jfx/pull/68/files/50191728..8966936f

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

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 17 14:39:31 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 17 Jan 2020 14:39:31 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
 <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
Message-ID: <MRWYUG_0EVW-xnDKjNECMSzPoED952_vYVS85nN3JUQ=.658e8241-1516-4140-b3f5-ae760d99ef82@github.com>

On Thu, 16 Jan 2020 16:08:05 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 2 additional commits.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1316:
> 
>> 1315:                 }
>> 1316:             }
>> 1317:         } else {
> 
> I would extract this code into its own method similar to `doSnapshotTile`:
> 
> `assemble(scene, xMin, yMin, width, height, root, transform, depthBuffer, fill, camera, wimg, maxTextureSize);`
> 
> (`assemble` is a bad name, I didn't think about a better one).
> 
> The method can return he resulting `WritableImage`, but it is not needed since it is manipulated via "side-effects". I would, however, bring it line with the `else` clause - either both use `wimg = methodName(..., wimg, ...);` or just `methodName(..., wimg, ...);`. This is fine since the input `WritableImage` is never `null`. From a readability point of view, using return values seems better.

I'm not 100% convinced this would really add much to the readability of the code; I extracted the code from `doSnapshotTile` in its own method because it is called twice (on both sides of the `if (height > maxTextureSize || width > maxTextureSize)` condition, actually), but this isn't the case here.
I've got no strong feeling against it either, so I don't know; anybody else care to comment?

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 17 17:26:10 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 17 Jan 2020 17:26:10 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <16XxegMp9uAyf0Ni0BZBbd0npwtacp2YZtL7f7Fgvq0=.96a3a6cf-cbfd-4ffa-b7f7-8336914150f4@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
 <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
 <16XxegMp9uAyf0Ni0BZBbd0npwtacp2YZtL7f7Fgvq0=.96a3a6cf-cbfd-4ffa-b7f7-8336914150f4@github.com>
Message-ID: <MZaJE8onY2-IVX7T7B1xNyltAAdbAwof5UcmnPQGv8I=.2490626b-998d-44aa-a8dd-2eb725068e89@github.com>

On Fri, 17 Jan 2020 11:28:03 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I tested this fix against the repro code in https://github.com/javafxports/openjdk-jfx/issues/433 (which is [JDK-8222238](https://bugs.openjdk.java.net/browse/JDK-8222238)), but there is still an NPE. I'm not certain that this fix is supposed to solve that bug, but according to the comments, the root cause is the same as [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082), which is related to this one. It's worth to take a look to see if something was missed.
> 
>> 
>> 
>> I tested this fix against the repro code in [javafxports/openjdk-jfx#433](https://github.com/javafxports/openjdk-jfx/issues/433) (which is [JDK-8222238](https://bugs.openjdk.java.net/browse/JDK-8222238)), but there is still an NPE. I'm not certain that this fix is supposed to solve that bug, but according to the comments, the root cause is the same as [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082), which is related to this one. It's worth to take a look to see if something was missed.
> 
> Although JDK-8189082 (and potentially others) are indeed likely to share the same root cause, the fix proposed here won't have an effect on anything else than snapshots, since the tiling is done at the Scene level rather than within QuantumToolkit.
> I purposefully choose to take the "easy" way out to limit the potential side-effects of the change, but I agree that on the other hand supporting tiling when needed directly in QuantumToolkit::renderToImage would have the potential to solve a whole category of issues.
> Also, from a very pragmatic angle, because of the increased complexity and scope and the risks that come with it, I'm not very optimistic that this change could realistically make it into jfx14 and to be honest I'm quite eager to get the screenshot feature in my app working properly ASAP.
> 
> I'd be willing to try and work on a more generic fix under the umbrella of JDK-8189082, that'd be targeted at 15, while still having this fix included as part 14; but that means this should (ideally) be reverted once it becomes useless. 
> I don't know if the idea of having a "temporary fix" approach seems acceptable in that context.

Wel,l upon closer inspection it appears `QuantumToolkit::renderToImage` is only really used by `Scene::doSnapshot` anyway. Rendering of a the content of an NGSubScene (the underlying issue in JDK-8189082) is handled in a completely different code path, and I suspect this is also true for Canvas, where I hear a similar kind of issue exists.
So from my (admittedly limited) understanding, fixing all problems at once would requires handling the tiling transparently within `RTTexture` (or more exactly inside all of its GraphicsPipeline specifics implementations) which seems quite a bit more complicated and risky.

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

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

From kcr at openjdk.java.net  Fri Jan 17 18:40:46 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 18:40:46 GMT
Subject: RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
Message-ID: <pP2WtgqCodNglJIXEfRACgtcyqrGduoUFHJdUT5rVUk=.75810328-2ff6-41ad-9c42-05caea1c18f1@github.com>

On Fri, 17 Jan 2020 14:09:54 GMT, Dean Wookey <dwookey at openjdk.org> wrote:

> Everything passes with the fix and 5 of the new tests fail without the fix.
> 
> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
> movingBranchToDifferentBranchGetsNewCssVariableTest
> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
> movingNodeToDifferentBranchGetsNewFontStyleTest
> 
> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
> 
> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab

I mentioned this in the JBS bug as well: I suspect that [JDK-8234877](https://bugs.openjdk.java.net/browse/JDK-8234877) has the same root cause as this one. Can you run the HelloCSS test program as described in that bug with your patch from this PR and see if it also fixes that bug?

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

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

From kcr at openjdk.java.net  Fri Jan 17 18:42:45 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 18:42:45 GMT
Subject: RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <pP2WtgqCodNglJIXEfRACgtcyqrGduoUFHJdUT5rVUk=.75810328-2ff6-41ad-9c42-05caea1c18f1@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
 <pP2WtgqCodNglJIXEfRACgtcyqrGduoUFHJdUT5rVUk=.75810328-2ff6-41ad-9c42-05caea1c18f1@github.com>
Message-ID: <2fHHhFU9n2ggGfbJNU4aQj31qItjC930t2rMhcWLy1Q=.a8310b33-3b27-4f4f-a7e9-c021745f0b1b@github.com>

On Fri, 17 Jan 2020 18:40:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Everything passes with the fix and 5 of the new tests fail without the fix.
>> 
>> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
>> movingBranchToDifferentBranchGetsNewCssVariableTest
>> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
>> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
>> movingNodeToDifferentBranchGetsNewFontStyleTest
>> 
>> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
>> 
>> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab
> 
> I mentioned this in the JBS bug as well: I suspect that [JDK-8234877](https://bugs.openjdk.java.net/browse/JDK-8234877) has the same root cause as this one. Can you run the HelloCSS test program as described in that bug with your patch from this PR and see if it also fixes that bug?

This will need (at least) two reviewers. I request @aghaisas and @dsgrieve to review (I'll review it as well next week, once I'm done with the more urgent reviews).

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

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

From kcr at openjdk.java.net  Fri Jan 17 19:22:37 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 19:22:37 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <MRWYUG_0EVW-xnDKjNECMSzPoED952_vYVS85nN3JUQ=.658e8241-1516-4140-b3f5-ae760d99ef82@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
 <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
 <MRWYUG_0EVW-xnDKjNECMSzPoED952_vYVS85nN3JUQ=.658e8241-1516-4140-b3f5-ae760d99ef82@github.com>
Message-ID: <iSQrO6XViPILT9dSwO_-zKpw8axj96HJXznJDhxyUZo=.8273353b-9ce7-4fb8-8b0f-7bc82c15d86e@github.com>

On Fri, 17 Jan 2020 14:39:14 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1316:
>> 
>>> 1315:                 }
>>> 1316:             }
>>> 1317:         } else {
>> 
>> I would extract this code into its own method similar to `doSnapshotTile`:
>> 
>> `assemble(scene, xMin, yMin, width, height, root, transform, depthBuffer, fill, camera, wimg, maxTextureSize);`
>> 
>> (`assemble` is a bad name, I didn't think about a better one).
>> 
>> The method can return he resulting `WritableImage`, but it is not needed since it is manipulated via "side-effects". I would, however, bring it line with the `else` clause - either both use `wimg = methodName(..., wimg, ...);` or just `methodName(..., wimg, ...);`. This is fine since the input `WritableImage` is never `null`. From a readability point of view, using return values seems better.
> 
> I'm not 100% convinced this would really add much to the readability of the code; I extracted the code from `doSnapshotTile` in its own method because it is called twice (on both sides of the `if (height > maxTextureSize || width > maxTextureSize)` condition, actually), but this isn't the case here.
> I've got no strong feeling against it either, so I don't know; anybody else care to comment?

I also don't have a strong opinion, so I'm OK with you leaving it as-is.

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

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

From nlisker at openjdk.java.net  Fri Jan 17 19:25:06 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 17 Jan 2020 19:25:06 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <iSQrO6XViPILT9dSwO_-zKpw8axj96HJXznJDhxyUZo=.8273353b-9ce7-4fb8-8b0f-7bc82c15d86e@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
 <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
 <MRWYUG_0EVW-xnDKjNECMSzPoED952_vYVS85nN3JUQ=.658e8241-1516-4140-b3f5-ae760d99ef82@github.com>
 <iSQrO6XViPILT9dSwO_-zKpw8axj96HJXznJDhxyUZo=.8273353b-9ce7-4fb8-8b0f-7bc82c15d86e@github.com>
Message-ID: <aLQR-QRs7TwVge9HiiQYytIXpLh-jY20nvmKse4Mv8w=.838f51b1-bffb-4127-b079-c92d66eb3f10@github.com>

On Fri, 17 Jan 2020 19:22:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I'm not 100% convinced this would really add much to the readability of the code; I extracted the code from `doSnapshotTile` in its own method because it is called twice (on both sides of the `if (height > maxTextureSize || width > maxTextureSize)` condition, actually), but this isn't the case here.
>> I've got no strong feeling against it either, so I don't know; anybody else care to comment?
> 
> I also don't have a strong opinion, so I'm OK with you leaving it as-is.

Fine to leave as-is.

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

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

From kcr at openjdk.java.net  Fri Jan 17 19:32:07 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 19:32:07 GMT
Subject: [Rev 02] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <MZaJE8onY2-IVX7T7B1xNyltAAdbAwof5UcmnPQGv8I=.2490626b-998d-44aa-a8dd-2eb725068e89@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <zCH5kV69PQWkoWtZTMIEy1-2jIJcYz-206ptaZwoQYQ=.f590eb87-63cb-4f7a-ba0e-b0cef394b676@github.com>
 <I_m2yEGbfIxvdDrW68I3oionC1uy8UPvl32xT_z5Hs0=.6a5388d1-3dcf-4ba7-8def-93120b33c42d@github.com>
 <16XxegMp9uAyf0Ni0BZBbd0npwtacp2YZtL7f7Fgvq0=.96a3a6cf-cbfd-4ffa-b7f7-8336914150f4@github.com>
 <MZaJE8onY2-IVX7T7B1xNyltAAdbAwof5UcmnPQGv8I=.2490626b-998d-44aa-a8dd-2eb725068e89@github.com>
Message-ID: <UBT_R7_ObiJd0j-41oxq1LF7wT4IEgC0z8oaFU9Y35U=.0fee3748-2a36-4ace-8867-549216f61257@github.com>

On Fri, 17 Jan 2020 17:25:51 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>>> 
>>> 
>>> I tested this fix against the repro code in [javafxports/openjdk-jfx#433](https://github.com/javafxports/openjdk-jfx/issues/433) (which is [JDK-8222238](https://bugs.openjdk.java.net/browse/JDK-8222238)), but there is still an NPE. I'm not certain that this fix is supposed to solve that bug, but according to the comments, the root cause is the same as [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082), which is related to this one. It's worth to take a look to see if something was missed.
>> 
>> Although JDK-8189082 (and potentially others) are indeed likely to share the same root cause, the fix proposed here won't have an effect on anything else than snapshots, since the tiling is done at the Scene level rather than within QuantumToolkit.
>> I purposefully choose to take the "easy" way out to limit the potential side-effects of the change, but I agree that on the other hand supporting tiling when needed directly in QuantumToolkit::renderToImage would have the potential to solve a whole category of issues.
>> Also, from a very pragmatic angle, because of the increased complexity and scope and the risks that come with it, I'm not very optimistic that this change could realistically make it into jfx14 and to be honest I'm quite eager to get the screenshot feature in my app working properly ASAP.
>> 
>> I'd be willing to try and work on a more generic fix under the umbrella of JDK-8189082, that'd be targeted at 15, while still having this fix included as part 14; but that means this should (ideally) be reverted once it becomes useless. 
>> I don't know if the idea of having a "temporary fix" approach seems acceptable in that context.
> 
> Wel,l upon closer inspection it appears `QuantumToolkit::renderToImage` is only really used by `Scene::doSnapshot` anyway. Rendering of a the content of an NGSubScene (the underlying issue in JDK-8189082) is handled in a completely different code path, and I suspect this is also true for Canvas, where I hear a similar kind of issue exists.
> So from my (admittedly limited) understanding, fixing all problems at once would requires handling the tiling transparently within `RTTexture` (or more exactly inside all of its GraphicsPipeline specifics implementations) which seems quite a bit more complicated and risky.

> upon closer inspection it appears `QuantumToolkit::renderToImage` is only really used by `Scene::doSnapshot` anyway.

Correct.

> So from my (admittedly limited) understanding, fixing all problems at once would requires handling the tiling transparently within `RTTexture` (or more exactly inside all of its GraphicsPipeline specifics implementations) which seems quite a bit more complicated and risky.

That would be one approach (extending RTT to handle tiling automatically), but I'm not at all sure that it would be the best one. It would as you note, be more complicated and risky.

I have no problem with your current proposed approach. I agree with @arapte that this seems safe for openjfx14. To that end, can you retarget this PR to the `jfx14` branch? Since there are no post-jfx14 commits from master in your local branch, this should be as simple as editing the PR and changing the target.

Then we can complete the review, hopefully next week.

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

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

From kcr at openjdk.java.net  Fri Jan 17 22:48:29 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 22:48:29 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <TtzBSdvUXDRZeBuWZ5wMB89uX8CL97KnMw2yk243JKI=.d31759e7-1884-4182-a2b9-330ecdfe8e77@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
 <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
 <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
 <rZiAhPnuGcar7pYndMgtciD3CdsppEezhnNfVj6NNtc=.fa6bb3ff-2990-436b-a1ae-acec56663af6@github.com>
 <TtzBSdvUXDRZeBuWZ5wMB89uX8CL97KnMw2yk243JKI=.d31759e7-1884-4182-a2b9-330ecdfe8e77@github.com>
Message-ID: <Blj16clSWFcS8So7JaK7H9K3nRzxCH5CIKp8hBb-Vm8=.e152b8d9-35ab-45f0-b752-8a5d5d3a75b9@github.com>

On Thu, 16 Jan 2020 01:09:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>>> If cycleCount is set to 2 does the animation play the same number of times with or without the jumpTo both before and after this change?
>> 
>> Before the change:
>> * With `jumpTo`: plays backwards 2 times.
>> * Without `jumpTo`: doesn't play no mater how many times you call `play()`. Compare with the case where `cycleCount` is 1, in which case the first call does nothing (moves the playing head to the start) and the second one plays backwards.
>> 
>> After the change:
>> * With `jumpTo`: plays backwards 2 times.
>> * Without `jumpTo`: plays backwards 2 times.
>> 
>>> If the jumpTo isn't required, then this isn't this a change in behaviour?
>> 
>> Current code with `jumpTo` will behave the same. The question (which I presented initially) is whether this behavior is considered a bug or not when it comes to the initial state of an animation. It is certainly a bug when `stop()` is called, so I assume it is similar for the initial state.
> 
>> So this PR may need a document change for `Animation.play()`
> 
> Yes, and the docs need clarification in other places anyway. The [parent issue](https://bugs.openjdk.java.net/browse/JDK-8210238) from which this bug was isolated talks about these. Not sure at what point I will go over it since `Animation` is going to get some more changes in the (hopefully) near future.

Based on my testing, and thinking through all of the implications of the fix, I think the proposed fix is correct. I modified the Timeline.java test program attached to [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) to add controls for auto-reverse and cycle count (1, 2, or INDEFINITE), and attached it as TimelineTest2.java. I tried several combinations, and the change in behavior looks correct in all cases to me.

As you point out in the description, the failing unit test, [SequentialTransitionPlayTest.testCycleReverse](https://github.com/openjdk/jfx/blob/16cea4111b25a00f812b2f6ba8a54adbcffc1c86/modules/javafx.graphics/src/test/java/test/javafx/animation/SequentialTransitionPlayTest.java#L632) is coded to test for the existing behavior when you first call play with `rate = -1`. I think it likely that this is merely because that's how it worked rather than because there was deliberate thought given to whether it was the right behavior. So I think the right thing to do is fix the test.

You also mentioned that jumping, even to the start or end, sets `lastPlayFinished` to `false`. I believe this is correct behavior and should not be changed.

As part of my testing, I ran into what may be a bug, but since the behavior is the same with or without your patch, I think it would be best to file a new bug and deal with it separately (if, in fact, it is a bug).

Here are the steps I used:

1. Run TimelineTest2
2. Select cycle=2; Select AutoReverse
3. Play animation: it correctly goes forward from start to end and then backwards from end to start
3. Set rate=-1
5. Play animation: BUG? It still goes forward from start to end and then backwards from end to start
Subsequent calls to play do what I would expect, in that it goes backwards from end to start and then forward from start to end.
The same thing happens when switching back to rate=1 : the first time it continues the direction it was prior to changing the rate.

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

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

From kcr at openjdk.java.net  Fri Jan 17 23:18:40 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 23:18:40 GMT
Subject: [Rev 03] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>
Message-ID: <gxjfTxOHYj7IX9ul8ajYzrgqwOJPsbV7P0TCNP8Im1M=.e30cf9ea-a130-441e-838b-08fdf5853cf7@github.com>

On Fri, 17 Jan 2020 23:18:40 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
>> 
>> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.
> 
> Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.

Looks good to me.

@guruhb can you re-review this when you get a chance?

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Fri Jan 17 23:40:36 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Jan 2020 23:40:36 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <SqRVa5K3OG5_J7Jr008FlEdvsHT0mQpO2n_tM6l1hww=.0ba849dc-aa8b-40ea-9983-d166f7918d50@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
 <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>
 <SqRVa5K3OG5_J7Jr008FlEdvsHT0mQpO2n_tM6l1hww=.0ba849dc-aa8b-40ea-9983-d166f7918d50@github.com>
Message-ID: <j1IXcdF74HRQLt-vsMhHDWQHElfKaK9unX7-6O1ugno=.84fb6cb4-a897-4d06-8848-e2bdf0155b25@github.com>

On Mon, 13 Jan 2020 16:49:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> This will need a second reviewer.
>> 
>> @aghaisas can you review this, too?
> 
>> 
>> 
>> @arapte - This bug looks like a good candidate for JavaFX 14. Can you retarget this PR to the jfx14 branch?
> 
> Thanks for guiding Kevin, PR is now targeted to jfx14.

The fix looks good. I'll take a closer look at the unit test later.

Speaking of tests...since the addition of the `TabPane` reordering logic was a victim of the already-existing leak in the `viewOrderChildren` list in `Parent`, it should be possible to write a test case using a Group node and a few Shape nodes, using setViewOrder directly on the Group node (this would be in addition to the system test you wrote). Can you take a look at adding one? It might even be possible to do it as a `javafx.graphics` module unit test rather than a system test, although you would need to see if the bug reproduced there (I suspect it will).

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

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

From nlisker at openjdk.java.net  Sat Jan 18 02:07:47 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 18 Jan 2020 02:07:47 GMT
Subject: [Rev 01] RFR: 8236753: Animations do not play backwards after
 being stopped
In-Reply-To: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
Message-ID: <8E-6q3Esm-3cPv-QMMoPIqTFW2jOgwFHCKPIwFG1MlI=.4f298bff-55ad-4243-975f-0c32992c2cdc@github.com>

> The private field `lastPlayFinished` is responsible for 2 cases where an animation in `STOPPED` status does not play after `play()` is called if the rate is negative:
> 
> 1. When the animation is created, it is `STOPPED` and `lastPlayFinished` is `false`. Setting a negative rate and calling `play()` will not jump to the end of the animation (in order to play it backwards) because the `if (lastPlayedFinished)` check is `false`. Creating the animation with `lastPlayFinished = true` fixes this. However, `SequentialTransitionPlayTest#testCycleReverse`'s initial state test implies that the original behavior is correct. *That test currently fails with this change.* Either the fix is reverted or the test is corrected.
> 2. When the animation is stopped (if it was not `STOPPED` already), `jumpTo(Duration.ZERO)` sets `lastPlayFinished` to `false`, which causes the same issue above with `play()`. Setting `lastPlayFinished = true` at the end `stop()` fixes this issue.
> 
> A test was added for case 2 to check that the playing head indeed jumps to the end of the animation. Without this fix, it stays at the start.
> 
> I'm still somewhat confused as to what constitutes a "last play finished". Any `jumpTo` resets `lastPlayFinished` to `false`, even if the jump is to the start/end of the animation. In this case, stopping an animation, jumping to its start/end, setting the rate to negative/positive, and playing, will do nothing as the end condition is reached immediately. This is what the behavior that was fixed for cases 1 and 2, but maybe this is also incorrect behavior for jumping to start/end.
> 
> A test app is included in the "parent" [bug](https://bugs.openjdk.java.net/browse/JDK-8210238), which also mentions a bug relating to **pausing** and playing backwards, so be mindful of it when testing.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 18098da9: Fixed SequentialTransitionPlayTest.testCycleReverse test

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/82/files
  - new: https://git.openjdk.java.net/jfx/pull/82/files/3332a97f..18098da9

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

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

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

From nlisker at openjdk.java.net  Sat Jan 18 02:14:45 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 18 Jan 2020 02:14:45 GMT
Subject: RFR: 8236753: Animations do not play backwards after being stopped
In-Reply-To: <Blj16clSWFcS8So7JaK7H9K3nRzxCH5CIKp8hBb-Vm8=.e152b8d9-35ab-45f0-b752-8a5d5d3a75b9@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <uZxmN1FZ1WjBOMtzhDhEg0P2fNkjdX5iHm86A5NCdpw=.6c9361ef-e2be-4bbe-a69b-b9b68adf7711@github.com>
 <LAa9di3ukc70BVs-oiJCDJoIqQZSevD_0Shx8ccugUM=.40c5e7d0-aec5-4b9a-9d29-2b13e335d39c@github.com>
 <cUrHSp2OfO56cZlC2zOL19tIxGcCP8OoIjMIr4irupY=.3dc711ee-6bfd-4cb4-bdbb-db8354784d88@github.com>
 <rZiAhPnuGcar7pYndMgtciD3CdsppEezhnNfVj6NNtc=.fa6bb3ff-2990-436b-a1ae-acec56663af6@github.com>
 <TtzBSdvUXDRZeBuWZ5wMB89uX8CL97KnMw2yk243JKI=.d31759e7-1884-4182-a2b9-330ecdfe8e77@github.com>
 <Blj16clSWFcS8So7JaK7H9K3nRzxCH5CIKp8hBb-Vm8=.e152b8d9-35ab-45f0-b752-8a5d5d3a75b9@github.com>
Message-ID: <YEnec44uT2OAgx7xd6c7fag4Wb5QdvQ4SSQ8JWSSJsc=.0d79319c-5e44-49c5-ae10-2468f4277ba4@github.com>

On Fri, 17 Jan 2020 22:48:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> So this PR may need a document change for `Animation.play()`
>> 
>> Yes, and the docs need clarification in other places anyway. The [parent issue](https://bugs.openjdk.java.net/browse/JDK-8210238) from which this bug was isolated talks about these. Not sure at what point I will go over it since `Animation` is going to get some more changes in the (hopefully) near future.
> 
> Based on my testing, and thinking through all of the implications of the fix, I think the proposed fix is correct. I modified the Timeline.java test program attached to [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) to add controls for auto-reverse and cycle count (1, 2, or INDEFINITE), and attached it as TimelineTest2.java. I tried several combinations, and the change in behavior looks correct in all cases to me.
> 
> As you point out in the description, the failing unit test, [SequentialTransitionPlayTest.testCycleReverse](https://github.com/openjdk/jfx/blob/16cea4111b25a00f812b2f6ba8a54adbcffc1c86/modules/javafx.graphics/src/test/java/test/javafx/animation/SequentialTransitionPlayTest.java#L632) is coded to test for the existing behavior when you first call play with `rate = -1`. I think it likely that this is merely because that's how it worked rather than because there was deliberate thought given to whether it was the right behavior. So I think the right thing to do is fix the test.
> 
> You also mentioned that jumping, even to the start or end, sets `lastPlayFinished` to `false`. I believe this is correct behavior and should not be changed.
> 
> As part of my testing, I ran into what may be a bug, but since the behavior is the same with or without your patch, I think it would be best to file a new bug and deal with it separately (if, in fact, it is a bug).
> 
> Here are the steps I used:
> 
> 1. Run TimelineTest2
> 2. Select cycle=2; Select AutoReverse
> 3. Play animation: it correctly goes forward from start to end and then backwards from end to start
> 3. Set rate=-1
> 5. Play animation: BUG? It still goes forward from start to end and then backwards from end to start
> Subsequent calls to play do what I would expect, in that it goes backwards from end to start and then forward from start to end.
> The same thing happens when switching back to rate=1 : the first time it continues the direction it was prior to changing the rate.

> So I think the right thing to do is fix the test.

Since the animation plays from the end for an arbitrary duration (at least I think it's arbitrary, compared to a pulse), I changed the assert to check that the property value is in the playing range of the animation and not equals to some specific value.

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

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

From dwookey at openjdk.java.net  Sat Jan 18 08:12:19 2020
From: dwookey at openjdk.java.net (Dean Wookey)
Date: Sat, 18 Jan 2020 08:12:19 GMT
Subject: RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <2fHHhFU9n2ggGfbJNU4aQj31qItjC930t2rMhcWLy1Q=.a8310b33-3b27-4f4f-a7e9-c021745f0b1b@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
 <pP2WtgqCodNglJIXEfRACgtcyqrGduoUFHJdUT5rVUk=.75810328-2ff6-41ad-9c42-05caea1c18f1@github.com>
 <2fHHhFU9n2ggGfbJNU4aQj31qItjC930t2rMhcWLy1Q=.a8310b33-3b27-4f4f-a7e9-c021745f0b1b@github.com>
Message-ID: <43YjUCaYDCdc6JVLd91Y7q-ek8WUNRxI4wnV5Zdt-Z0=.92e2dfaa-24fa-4a81-88ed-8dee4732dc1d@github.com>

On Fri, 17 Jan 2020 18:42:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I mentioned this in the JBS bug as well: I suspect that [JDK-8234877](https://bugs.openjdk.java.net/browse/JDK-8234877) has the same root cause as this one. Can you run the HelloCSS test program as described in that bug with your patch from this PR and see if it also fixes that bug?
> 
> This will need (at least) two reviewers. I request @aghaisas and @dsgrieve to review (I'll review it as well next week, once I'm done with the more urgent reviews).

> I mentioned this in the JBS bug as well: I suspect that [JDK-8234877](https://bugs.openjdk.java.net/browse/JDK-8234877) has the same root cause as this one. Can you run the HelloCSS test program as described in that bug with your patch from this PR and see if it also fixes that bug?

I ran it and it seems to work. The button is always red in the red pane and always yellow in the yellow one.

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

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

From arapte at openjdk.java.net  Mon Jan 20 05:07:11 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 20 Jan 2020 05:07:11 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
Message-ID: <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>

On Mon, 20 Jan 2020 05:07:11 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 2 additional commits.

Looks good to me.
Below is just an observation about time taken by the API,
Platform: `Windows10`,  `maxTextureSize`: 4096
For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()` takes ~100 ms, and each call to `setPixels()` takes ~30 ms.

Please wait for one more approval before integrating.

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

Marked as reviewed by arapte (Reviewer).

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

From rlichten at openjdk.java.net  Mon Jan 20 10:02:15 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Mon, 20 Jan 2020 10:02:15 GMT
Subject: RFR: 8237372: NullPointerException in TabPaneSkin.stopDrag
Message-ID: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>

Test simulates a single mouse-released event.
Fix simply guards against the null case.

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

Commits:
 - 923a63b2: 8237372: NullPointerException in TabPaneSkin.stopDrag

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

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

From jvos at openjdk.java.net  Mon Jan 20 11:11:55 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Mon, 20 Jan 2020 11:11:55 GMT
Subject: RFR: 8237078: Media build code broken on XCode 11
Message-ID: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>

Fix JDK-8237078
replace the objc_msgSend call with a direct objC call.
The fix works on XCode 10.1 and XCode 11.3

Tested using
java  -Djfxmedia.platforms=OSXPlatform
with MediaPlayer playing an mp3.

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

Commits:
 - 33582c1d: Fix 8237078 : media build code broken on XCode 11

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Mon Jan 20 11:24:27 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Mon, 20 Jan 2020 11:24:27 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
Message-ID: <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>

On Mon, 20 Jan 2020 05:06:50 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 2 additional commits.
> 
> Looks good to me.
> Below is just an observation about time taken by the API,
> Platform: Windows10,  `maxTextureSize`: 4096
> For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()` takes ~100 ms, and each call to `setPixels()` takes ~30 ms.
> 
> Please wait for one more approval before integrating.

> 
> 
> Looks good to me.
> Below is just an observation about time taken by the API,
> Platform: Windows10, `maxTextureSize`: 4096
> For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()` takes ~100 ms, and each call to `setPixels()` takes ~30 ms.
> 
> Please wait for one more approval before integrating.

Do you have the same kind of measurements for similar uses cases without this patch? I'm expecting performances to remain the same for snapshots less than `maxTextureSize*maxTextureSize` in size, since there is no extra pixel copy in that case, and the rest of the code if globally unchanged.

Still there exists a window for performance regressions, which for instance on Windows 10 w/ the D3D rendering pipeline would be when one of the dimension of a snapshot is >4096  and <8192: in that case a snapshot would require up to 4 extra copy pixels steps with this patch.
This is due to the fact that the old code would accept to render in a texture of a size up to the non-clamped max texture size (8192 in D3D, 16384 in ES2), but because I couldn't find a clean way to access the non clamped maxTextureSize exposed by the render factory from the Scene class, I settled for Prsim.maxTextureSize, which is the clamped value (4096 by default).
I haven't dug deep enough in the code to understand precisely why the max texture size is clamped to 4096 by default, but assuming that it is for a good reason wouldn't that also apply in that case? Or is it always safe to use the non-clamped value in that particular case?

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

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

From github.com+725090+jkaving at openjdk.java.net  Mon Jan 20 14:53:01 2020
From: github.com+725090+jkaving at openjdk.java.net (Johan Kaving)
Date: Mon, 20 Jan 2020 14:53:01 GMT
Subject: RFR: 8236839: System menubar removed when other menubars are created
 or modified
Message-ID: <bE6bjH8iA9f5DKqF2VRBu1vIbNqAFaOXRb1fqdSN5dk=.d84dd6ae-1776-4326-88b8-cb8156980159@github.com>

This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the
current system menubar alone when other menubars are changed.

It also adds a test case that reproduces the problem before the fix.

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

Commits:
 - 7910ab27: Don't always remove system menubar

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

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

From kcr at openjdk.java.net  Mon Jan 20 14:53:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 20 Jan 2020 14:53:02 GMT
Subject: RFR: 8236839: System menubar removed when other menubars are
 created or modified
In-Reply-To: <qbwB15jqT5v9i6b7ZA52YTN9j0WXPbRJUdP0IZCR0qw=.24dd98b1-2ee5-4707-975b-4b194a137f68@github.com>
References: <bE6bjH8iA9f5DKqF2VRBu1vIbNqAFaOXRb1fqdSN5dk=.d84dd6ae-1776-4326-88b8-cb8156980159@github.com>
 <qbwB15jqT5v9i6b7ZA52YTN9j0WXPbRJUdP0IZCR0qw=.24dd98b1-2ee5-4707-975b-4b194a137f68@github.com>
Message-ID: <cP9_OUZg9rBR6W0b7rE7UwQaDP4efCHMw8xyHpHhzYU=.5d48d378-84be-4229-95db-a571616199f6@github.com>

On Tue, 14 Jan 2020 20:06:58 GMT, Johan Kaving <github.com+725090+jkaving at openjdk.org> wrote:

>> This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the
>> current system menubar alone when other menubars are changed.
>> 
>> It also adds a test case that reproduces the problem before the fix.
> 
> I just realised that I did not make the commit with the same email address that I used on the OCA (but both addresses are linked to my GitHub account).
> Will this be a problem?
> Should I redo the commit with the correct email address and do a force push to my branch?

No, it's not a problem. The commit email address doesn't matter as long as your OCA can be validated.

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

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

From github.com+725090+jkaving at openjdk.java.net  Mon Jan 20 14:53:02 2020
From: github.com+725090+jkaving at openjdk.java.net (Johan Kaving)
Date: Mon, 20 Jan 2020 14:53:02 GMT
Subject: RFR: 8236839: System menubar removed when other menubars are
 created or modified
In-Reply-To: <bE6bjH8iA9f5DKqF2VRBu1vIbNqAFaOXRb1fqdSN5dk=.d84dd6ae-1776-4326-88b8-cb8156980159@github.com>
References: <bE6bjH8iA9f5DKqF2VRBu1vIbNqAFaOXRb1fqdSN5dk=.d84dd6ae-1776-4326-88b8-cb8156980159@github.com>
Message-ID: <qbwB15jqT5v9i6b7ZA52YTN9j0WXPbRJUdP0IZCR0qw=.24dd98b1-2ee5-4707-975b-4b194a137f68@github.com>

On Tue, 14 Jan 2020 19:50:28 GMT, Johan Kaving <github.com+725090+jkaving at openjdk.org> wrote:

> This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the
> current system menubar alone when other menubars are changed.
> 
> It also adds a test case that reproduces the problem before the fix.

I just realised that I did not make the commit with the same email address that I used on the OCA (but both addresses are linked to my GitHub account).
Will this be a problem?
Should I redo the commit with the correct email address and do a force push to my branch?

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

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

From guru.hb at oracle.com  Mon Jan 20 16:46:43 2020
From: guru.hb at oracle.com (Guru)
Date: Mon, 20 Jan 2020 22:16:43 +0530
Subject: [RFR] 8233942: Update to 609.1 version of WebKit 
Message-ID: <174ECC19-3C9B-4068-B49C-6054451551A4@oracle.com>

Hi Kevin, Johan,

Please review the fix for : 
JBS : https://bugs.openjdk.java.net/browse/JDK-8233942 <https://bugs.openjdk.java.net/browse/JDK-8233942>
PR : https://github.com/openjdk/jfx/pull/91 <https://github.com/openjdk/jfx/pull/91>

Fix has latest GTK Webkit 2.26 (609.1) merged into jfx. 


Tested : Basic sanity by loading many Top 20 webpages using HelloWebView on three different platform (Mac OS X, Windows 10 and Linux). 


Thanks,
Guru

From ghb at openjdk.java.net  Tue Jan 21 09:27:28 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Tue, 21 Jan 2020 09:27:28 GMT
Subject: RFR: 8233942: Update to 609.1 version of WebKit
Message-ID: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>

Updated GTK Webkit 2.26 (609.1) into jfx.

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

Commits:
 - 8b48b1e0: 8233942: Update to 609.1 version of WebKit

Changes: https://git.openjdk.java.net/jfx/pull/91/files
 Webrev: https://webrevs.openjdk.java.net/jfx/91/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233942
  Stats: 279532 lines in 5731 files changed: 169844 ins; 72559 del; 37129 mod
  Patch: https://git.openjdk.java.net/jfx/pull/91.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/91/head:pull/91

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

From kcr at openjdk.java.net  Tue Jan 21 18:02:28 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 18:02:28 GMT
Subject: RFR: 8233942: Update to 609.1 version of WebKit
In-Reply-To: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
References: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
Message-ID: <Yy1OyIvjbLVDa2O8FRsRNjsf1_rSYI6ebBo6oSMLh7Q=.eb1f1b5a-af0e-4728-a6b0-eb3008fbb219@github.com>

On Mon, 20 Jan 2020 16:39:15 GMT, Guru Hb <ghb at openjdk.org> wrote:

> Updated GTK Webkit 2.26 (609.1) into jfx.

A sanity check of the patch looks good to me: I did a build / test on all three platforms. I'll do a bit more testing, and also review the JavaFX-specific files, before completing my review.

To the latter point, I took the patch, applied it to my personal fork, and then split it into two commits, one of which has the changes to the files that I wanted to take a closer look at (finding just those files in the original PR when there are over 5,000 files would be impractical -- impossible given GitHub's 3000 file limitation in the file diff veiwer).

In case this is useful to other reviewers, [click here](https://github.com/kevinrushforth/jfx/compare/fa6df1ecacc1334b256ffd96dd15cd7dfb1fc108...83d114aed6f9f30ebd90a567192537f62328ffa5) for the diffs. It only includes 87 files, many of which are cmake files for platforms other than `Java` so don't really need to be reviewed.

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

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

From kcr at openjdk.java.net  Tue Jan 21 18:44:42 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 18:44:42 GMT
Subject: RFR: 8237078: Media build code broken on XCode 11
In-Reply-To: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
References: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
Message-ID: <jQYnTCjEuyEjtt4VpJa_AzAGdFhHPD3KOyECD4z0k80=.2d846d71-6dda-488f-be2b-b20e09b56280@github.com>

On Mon, 20 Jan 2020 11:10:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Fix JDK-8237078
> replace the objc_msgSend call with a direct objC call.
> The fix works on XCode 10.1 and XCode 11.3
> 
> Tested using
> java  -Djfxmedia.platforms=OSXPlatform
> with MediaPlayer playing an mp3.

I verified the fix, and confirmed that the new code is executed. This seems safe enough that a single reviewer is sufficient, although @sashamatveev might want to review as well.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Tue Jan 21 19:06:41 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 19:06:41 GMT
Subject: RFR: 8233942: Update to 609.1 version of WebKit
In-Reply-To: <Yy1OyIvjbLVDa2O8FRsRNjsf1_rSYI6ebBo6oSMLh7Q=.eb1f1b5a-af0e-4728-a6b0-eb3008fbb219@github.com>
References: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
 <Yy1OyIvjbLVDa2O8FRsRNjsf1_rSYI6ebBo6oSMLh7Q=.eb1f1b5a-af0e-4728-a6b0-eb3008fbb219@github.com>
Message-ID: <up52A4YPhxfaIgTlHWtpWq1mXXwWwdj74fr-80wkxJ8=.b2aa93dd-6aa9-418f-8503-aab404b4851f@github.com>

On Tue, 21 Jan 2020 18:02:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Updated GTK Webkit 2.26 (609.1) into jfx.
> 
> A sanity check of the patch looks good to me: I did a build / test on all three platforms. I'll do a bit more testing, and also review the JavaFX-specific files, before completing my review.
> 
> To the latter point, I took the patch, applied it to my personal fork, and then split it into two commits, one of which has the changes to the files that I wanted to take a closer look at (finding just those files in the original PR when there are over 5,000 files would be impractical -- impossible given GitHub's 3000 file limitation in the file diff veiwer).
> 
> In case this is useful to other reviewers, [click here](https://github.com/kevinrushforth/jfx/compare/fa6df1ecacc1334b256ffd96dd15cd7dfb1fc108...83d114aed6f9f30ebd90a567192537f62328ffa5) for the diffs. It only includes 87 files, many of which are cmake files for platforms other than `Java` so don't really need to be reviewed.

This will need at least two reviewers, including myself and @johanvos

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

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

From kcr at openjdk.java.net  Tue Jan 21 19:12:07 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 19:12:07 GMT
Subject: RFR: 8233942: Update to 609.1 version of WebKit
In-Reply-To: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
References: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
Message-ID: <ZqzxK93suVKI9BIgz-DRZNLWUFzNFti1EYbV6FcNyJs=.f14a3ce7-9a80-4962-9669-b5e4e1fddfa3@github.com>

On Mon, 20 Jan 2020 16:39:15 GMT, Guru Hb <ghb at openjdk.org> wrote:

> Updated GTK Webkit 2.26 (609.1) into jfx.

Everything looks good to me.

Here are a couple things I noticed that may warrant a follow-up issue to address them:

1. Unimplemented methods:
    * FileSystemJava.cpp:
        * truncateFile
        * MappedFileData::MappedFileData
        * MappedFileData::mapFileHandle
        * unmapViewOfFile
    * FrameLoaderClientJava.cpp:
        * didSaveToPageCache
        * didRestoreFromPageCache

2. General cleanup:
    * PageCacheJava.cpp:
       // FIXME: Openjfx2.26 rename pagecache to backforwardcache

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Tue Jan 21 19:23:52 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 19:23:52 GMT
Subject: RFR: 8237372: NullPointerException in TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <21vrFgU1LwJj_HAVlFbBOUIiJ1uyk8smbibXgukRA5Y=.070dbce7-a338-4ab2-b74e-bd74dba60a44@github.com>

On Mon, 20 Jan 2020 10:00:55 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> Test simulates a single mouse-released event.
> Fix simply guards against the null case.

@arapte - can you review this?

The only question I have is whether is is expected that `dragTabHeader` can be null. If we understand why it is null, and that it isn't an error for it to be null, then the fix is fine. If its being null is unexpected, then the fix might just be masking the real problem. There isn't enough information in this PR to be able to evaluate this.

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

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

From kcr at openjdk.java.net  Tue Jan 21 19:57:57 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 19:57:57 GMT
Subject: [Rev 01] RFR: 8236753: Animations do not play backwards after
 being stopped
In-Reply-To: <8E-6q3Esm-3cPv-QMMoPIqTFW2jOgwFHCKPIwFG1MlI=.4f298bff-55ad-4243-975f-0c32992c2cdc@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <8E-6q3Esm-3cPv-QMMoPIqTFW2jOgwFHCKPIwFG1MlI=.4f298bff-55ad-4243-975f-0c32992c2cdc@github.com>
Message-ID: <wfwDJUXZmDmzV6ZG98bc-RvguoHfHW_Dl0E51IxLjjg=.45130587-b62b-4d14-80d6-dc10254e8a7a@github.com>

On Tue, 21 Jan 2020 19:57:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The private field `lastPlayFinished` is responsible for 2 cases where an animation in `STOPPED` status does not play after `play()` is called if the rate is negative:
>> 
>> 1. When the animation is created, it is `STOPPED` and `lastPlayFinished` is `false`. Setting a negative rate and calling `play()` will not jump to the end of the animation (in order to play it backwards) because the `if (lastPlayedFinished)` check is `false`. Creating the animation with `lastPlayFinished = true` fixes this. However, `SequentialTransitionPlayTest#testCycleReverse`'s initial state test implies that the original behavior is correct. *That test currently fails with this change.* Either the fix is reverted or the test is corrected.
>> 2. When the animation is stopped (if it was not `STOPPED` already), `jumpTo(Duration.ZERO)` sets `lastPlayFinished` to `false`, which causes the same issue above with `play()`. Setting `lastPlayFinished = true` at the end `stop()` fixes this issue.
>> 
>> A test was added for case 2 to check that the playing head indeed jumps to the end of the animation. Without this fix, it stays at the start.
>> 
>> I'm still somewhat confused as to what constitutes a "last play finished". Any `jumpTo` resets `lastPlayFinished` to `false`, even if the jump is to the start/end of the animation. In this case, stopping an animation, jumping to its start/end, setting the rate to negative/positive, and playing, will do nothing as the end condition is reached immediately. This is what the behavior that was fixed for cases 1 and 2, but maybe this is also incorrect behavior for jumping to start/end.
>> 
>> A test app is included in the "parent" [bug](https://bugs.openjdk.java.net/browse/JDK-8210238), which also mentions a bug relating to **pausing** and playing backwards, so be mindful of it when testing.
> 
> The pull request has been updated with 1 additional commit.

Approved.

The fix looks fine to me, and now passes all unit tests. The change you made to the test is what I would expect (I had done a similar thing locally to get them to pass when I was testing).

Regarding the question that came up earlier in the review about modifying the docs to remove the call to `jumpTo` from the example, I do not recommend changing the docs as part of this fix. The existing example code is still correct. More importantly, the code snippet in question is part of the docs for `Animation::play`, and isn't just talking about playing when stopped. If you play after a paused animation and want to play backwards from the end, then the `jumpTo` is still needed.

Additionally, there are other questionable aspects of the Animation docs. For example, consider the following:

> When rate > 0 (forward play), if an Animation is already positioned at the end, the first cycle will not be played

This is misleading in that it is only true after an explicit call to "jumpTo(end)". If you play a forward animation to completion, then it isn't. My point for bring it up is that I don't really want to make changes to the docs without considering the larger implications.

Please wait for @arapte to finish reviewing.

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

Marked as reviewed by kcr (Lead).

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

From michaelstrau2 at gmail.com  Tue Jan 21 19:59:25 2020
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 21 Jan 2020 20:59:25 +0100
Subject: Add command support for actionable controls
Message-ID: <CAJEpuXRZexz29zoW8k-fYzskU484ojxS+O53hZhiZ2uvW2m2SA@mail.gmail.com>

1. Abstract:
Controls that are derived from ButtonBase generally represent an operation
that is triggered by the control.
In many cases, the control also reflects whether the operation can
currently be invoked (i.e. whether the control is enabled or disabled), or
whether the operation is currently running.
Software patterns like MVVM often encapsulate this behavior for the purpose
of decoupling business logic from UI code.


2. Implementation:
I propose adding the following interface that represents the entirety of
such an operation:

interface Command<T> {
    ReadOnlyBooleanProperty canExecuteProperty();
    ReadOnlyBooleanProperty executingProperty();
    void execute();
    void execute(T parameter);
}

An application's business logic can expose operations as implementations of
the Command interface, and define the conditions when the operation can be
executed.

Additionally, ButtonBase should be extended by adding the following two
properties:

/**
 * The button's command, which is invoked whenever the button is fired.
 * If a command is set on the button, {@link Node#disableProperty()} is
automatically
 * bound to {@link Command#canExecuteProperty()}. Any previous binding is
removed.
 */
ObjectProperty<Command<?>> commandProperty();

/**
 * The button's command parameter.
 * When the command is invoked, this parameter will be passed to the
command implementation.
 */
ObjectProperty<Object> commandParameterProperty();

These two properties are lazily instantiated to prevent allocations if an
application doesn't use commands.
In general, Commands are an opt-in feature, so existing code that makes no
use of commands is not impacted.

The command is invoked whenever the control fires an ActionEvent. This can
be achieved by overriding Node.fireEvent(Event) in ButtonBase and checking
for the presence of an ActionEvent.

I can provide a PR with an implementation of this feature.

Michael

From tom.schindl at bestsolution.at  Tue Jan 21 20:13:58 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 21 Jan 2020 21:13:58 +0100
Subject: Add command support for actionable controls
In-Reply-To: <CAJEpuXRZexz29zoW8k-fYzskU484ojxS+O53hZhiZ2uvW2m2SA@mail.gmail.com>
References: <CAJEpuXRZexz29zoW8k-fYzskU484ojxS+O53hZhiZ2uvW2m2SA@mail.gmail.com>
Message-ID: <017bd4e8-7eba-6cb4-6704-69bf72940c17@bestsolution.at>

Hi,

I see where you are coming from but IMHO JavaFX should focus on being a
Graphic and UI-Toolkit and not leak any patterns into the core API.

These are just by 2 cents so other might have another opinion.

Tom

On 21.01.20 20:59, Michael Strau? wrote:
> 1. Abstract:
> Controls that are derived from ButtonBase generally represent an operation
> that is triggered by the control.
> In many cases, the control also reflects whether the operation can
> currently be invoked (i.e. whether the control is enabled or disabled), or
> whether the operation is currently running.
> Software patterns like MVVM often encapsulate this behavior for the purpose
> of decoupling business logic from UI code.
> 
> 
> 2. Implementation:
> I propose adding the following interface that represents the entirety of
> such an operation:
> 
> interface Command<T> {
>     ReadOnlyBooleanProperty canExecuteProperty();
>     ReadOnlyBooleanProperty executingProperty();
>     void execute();
>     void execute(T parameter);
> }
> 
> An application's business logic can expose operations as implementations of
> the Command interface, and define the conditions when the operation can be
> executed.
> 
> Additionally, ButtonBase should be extended by adding the following two
> properties:
> 
> /**
>  * The button's command, which is invoked whenever the button is fired.
>  * If a command is set on the button, {@link Node#disableProperty()} is
> automatically
>  * bound to {@link Command#canExecuteProperty()}. Any previous binding is
> removed.
>  */
> ObjectProperty<Command<?>> commandProperty();
> 
> /**
>  * The button's command parameter.
>  * When the command is invoked, this parameter will be passed to the
> command implementation.
>  */
> ObjectProperty<Object> commandParameterProperty();
> 
> These two properties are lazily instantiated to prevent allocations if an
> application doesn't use commands.
> In general, Commands are an opt-in feature, so existing code that makes no
> use of commands is not impacted.
> 
> The command is invoked whenever the control fires an ActionEvent. This can
> be achieved by overriding Node.fireEvent(Event) in ButtonBase and checking
> for the presence of an ActionEvent.
> 
> I can provide a PR with an implementation of this feature.
> 
> Michael
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From kevin.rushforth at oracle.com  Tue Jan 21 20:39:18 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 21 Jan 2020 12:39:18 -0800
Subject: Add command support for actionable controls
In-Reply-To: <017bd4e8-7eba-6cb4-6704-69bf72940c17@bestsolution.at>
References: <CAJEpuXRZexz29zoW8k-fYzskU484ojxS+O53hZhiZ2uvW2m2SA@mail.gmail.com>
 <017bd4e8-7eba-6cb4-6704-69bf72940c17@bestsolution.at>
Message-ID: <1a27bd9a-0ad3-2407-6e91-61783c55c123@oracle.com>

We are very unlikely to consider such an enhancement.

This would be a somewhat different take on the idea of an Actions 
framework, which has been discussed several times before without a good 
resolution.

-- Kevin


On 1/21/2020 12:13 PM, Tom Schindl wrote:
> Hi,
>
> I see where you are coming from but IMHO JavaFX should focus on being a
> Graphic and UI-Toolkit and not leak any patterns into the core API.
>
> These are just by 2 cents so other might have another opinion.
>
> Tom
>
> On 21.01.20 20:59, Michael Strau? wrote:
>> 1. Abstract:
>> Controls that are derived from ButtonBase generally represent an operation
>> that is triggered by the control.
>> In many cases, the control also reflects whether the operation can
>> currently be invoked (i.e. whether the control is enabled or disabled), or
>> whether the operation is currently running.
>> Software patterns like MVVM often encapsulate this behavior for the purpose
>> of decoupling business logic from UI code.
>>
>>
>> 2. Implementation:
>> I propose adding the following interface that represents the entirety of
>> such an operation:
>>
>> interface Command<T> {
>>      ReadOnlyBooleanProperty canExecuteProperty();
>>      ReadOnlyBooleanProperty executingProperty();
>>      void execute();
>>      void execute(T parameter);
>> }
>>
>> An application's business logic can expose operations as implementations of
>> the Command interface, and define the conditions when the operation can be
>> executed.
>>
>> Additionally, ButtonBase should be extended by adding the following two
>> properties:
>>
>> /**
>>   * The button's command, which is invoked whenever the button is fired.
>>   * If a command is set on the button, {@link Node#disableProperty()} is
>> automatically
>>   * bound to {@link Command#canExecuteProperty()}. Any previous binding is
>> removed.
>>   */
>> ObjectProperty<Command<?>> commandProperty();
>>
>> /**
>>   * The button's command parameter.
>>   * When the command is invoked, this parameter will be passed to the
>> command implementation.
>>   */
>> ObjectProperty<Object> commandParameterProperty();
>>
>> These two properties are lazily instantiated to prevent allocations if an
>> application doesn't use commands.
>> In general, Commands are an opt-in feature, so existing code that makes no
>> use of commands is not impacted.
>>
>> The command is invoked whenever the control fires an ActionEvent. This can
>> be achieved by overriding Node.fireEvent(Event) in ButtonBase and checking
>> for the presence of an ActionEvent.
>>
>> I can provide a PR with an implementation of this feature.
>>
>> Michael
>>


From almatvee at openjdk.java.net  Tue Jan 21 21:38:07 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 21 Jan 2020 21:38:07 GMT
Subject: RFR: 8237078: Media build code broken on XCode 11
In-Reply-To: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
References: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
Message-ID: <h6QcSQI6zySKiwORTkiX5x0NrBFWxxA22VYMKB41XRM=.55e393d8-dc14-4bb0-afdf-68d81770e908@github.com>

On Mon, 20 Jan 2020 11:10:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Fix JDK-8237078
> replace the objc_msgSend call with a direct objC call.
> The fix works on XCode 10.1 and XCode 11.3
> 
> Tested using
> java  -Djfxmedia.platforms=OSXPlatform
> with MediaPlayer playing an mp3.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

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

From kcr at openjdk.java.net  Tue Jan 21 21:53:47 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 21:53:47 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
Message-ID: <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>

On Mon, 20 Jan 2020 11:24:05 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> Looks good to me.
>> Below is just an observation about time taken by the API,
>> Platform: Windows10,  `maxTextureSize`: 4096
>> For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()` takes ~100 ms, and each call to `setPixels()` takes ~30 ms.
>> 
>> Please wait for one more approval before integrating.
> 
>> 
>> 
>> Looks good to me.
>> Below is just an observation about time taken by the API,
>> Platform: Windows10, `maxTextureSize`: 4096
>> For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()` takes ~100 ms, and each call to `setPixels()` takes ~30 ms.
>> 
>> Please wait for one more approval before integrating.
> 
> Do you have the same kind of measurements for similar uses cases without this patch? I'm expecting performances to remain the same for snapshots less than `maxTextureSize*maxTextureSize` in size, since there is no extra pixel copy in that case, and the rest of the code if globally unchanged.
> 
> Still there exists a window for performance regressions, which for instance on Windows 10 w/ the D3D rendering pipeline would be when one of the dimension of a snapshot is >4096  and <8192: in that case a snapshot would require up to 4 extra copy pixels steps with this patch.
> This is due to the fact that the old code would accept to render in a texture of a size up to the non-clamped max texture size (8192 in D3D, 16384 in ES2), but because I couldn't find a clean way to access the non clamped maxTextureSize exposed by the render factory from the Scene class, I settled for Prsim.maxTextureSize, which is the clamped value (4096 by default).
> I haven't dug deep enough in the code to understand precisely why the max texture size is clamped to 4096 by default, but assuming that it is for a good reason wouldn't that also apply in that case? Or is it always safe to use the non-clamped value in that particular case?

I haven't done any testing yet, but I have two comments on the patch:

1. Using the clamped texture size as the upper limit is the right thing to do, but `Prism.maxTexture` isn't guaranteed to be that size. The `Prism.maxTexture` constant represents the value to clamp the texture size to. In the event that D3D or OpenGL were to report a maximum less than the value of `Prism.maxTexture` (unlikely, but maybe on some low-end embedded systems?), then that value is what should be used. The way to get the clamped texture size is to call [`ResourceFactory::getMaximumTextureSize`](https://github.com/openjdk/jfx/blob/jfx14/modules/javafx.graphics/src/main/java/com/sun/prism/ResourceFactory.java#L222), but you can't do that directly from the scene graph code.

2. Allocating multiple `WritableImage` objects and using `PixelWriter::setPixels` to stitch them together will take more temporary memory, and is likely to be slower, than having the snapshot code write into a subimage of the larger allocated image directly.

Having said that, the current proposed solution is still better than the current behavior is almost all cases, although there could be a performance hit in the case of an 8K x 8K image, which will now be tiled. I want to do a more careful review and some testing. If any other users of snapshot have any comments or concerns, they would be welcome.

I think the best long-term solution might be to modify the [`QuantumToolkit::renderToImage`](https://github.com/openjdk/jfx/blob/jfx14/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java#L1490) method, although that would certainly be out of scope for JavaFX 14.

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

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

From kevin.rushforth at oracle.com  Tue Jan 21 23:30:26 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 21 Jan 2020 15:30:26 -0800
Subject: Rate of embedded animations
In-Reply-To: <CA+0ynh-XP4Zxno62bAddKkyvqWMAMofcoOKWrLKdzd4yAY0BjA@mail.gmail.com>
References: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>
 <e9dee0f6-aba6-b787-849c-6f319049a99f@oracle.com>
 <CA+0ynh8COobS1QUiiwQOaEtv=3ph9RqKAniUqG3xfw0vcnbNmg@mail.gmail.com>
 <CA+0ynh-XP4Zxno62bAddKkyvqWMAMofcoOKWrLKdzd4yAY0BjA@mail.gmail.com>
Message-ID: <851e9863-f7bd-8cd4-ba82-89b9ba52e1b7@oracle.com>

This got buried in my inbox, and I missed seeing it.

I'll respond inline.


On 1/10/2020 6:45 PM, Nir Lisker wrote:
> I forgot to bring up https://bugs.openjdk.java.net/browse/JDK-8200206, 
> which is also relevant to this discussion. The solution to that one is 
> probably allowing only 1 parent, similar to the scenegraph policy. 
> That will avoid parent animations fighting over the state of common 
> children animations.

Good point. Regardless of which approach (1 or 2) we go with, I agree 
that allowing only a single parent transition is best. I note that this 
would be a semantic change, though, so even though we ought to decide 
what we want the behavior to be, actually enforcing a single parent is 
probably best left to JavaFX 15 (I note that 
https://bugs.openjdk.java.net/browse/JDK-8200206 is targeted to 15).

> On Sat, Jan 11, 2020 at 3:08 AM Nir Lisker <nlisker at gmail.com 
> <mailto:nlisker at gmail.com>> wrote:
>
>         What happens if you set the rate of the parent transition and
>         then set the rate of a child animation?
>
>         What if you bind to the rate of a child animation? 
>
>
>     There is already some code that touches this in the Animation's
>     rate property:
>
>     public void invalidated() {
>     ? ? final double newRate = getRate();
>     ? ? if (isRunningEmbedded()) {
>     ? ? ? ? if (isBound()) {
>     ? ? ? ? ? ? unbind();
>     ? ? ? ? }
>     ? ? ? ? set(oldRate);
>     ? ? ? ? throw new IllegalStateException("Cannot set rate of
>     embedded animation while running.");
>     ? ? }
>
>     isRunningEmbedded checks for a parent animation that is not
>     STOPPED. That means that the rate of a child animation can only
>     change while the parent is stopped, but it is ignored (the child's
>     ClipEnvelope's rate is updated to the parent's rate instead).
>     Binding to the rate property is never an issue, but it does give
>     meaningless results since the rate is ignored. Binding the rate
>     property itself will cause it to be unbinded.
>
>     If we go with option 1, which is almost the current situation,
>     there is only some cleanup needed when it comes to the relation
>     between the Animation's rate and its ClipEnvelope's rate.
>

This (option 1) seems easiest, but I can see am argument for either 
approach.

Remind me again, which JBS bug you are planning to use to fix this issue?

>     If we go with option 2, we can eliminate the duplication of rate
>     in the Animation and the ClipEnvelope (though ClipEvenope to
>     Animation is somewhat like a peer to a Node, which duplicates the
>     values as well, so maybe we want that?). The children's rate will
>     always be the parent's rate. In this case the above code should
>     probably be modified to account for STOPPED parents as well. A
>     bound rate property will be unbinded and setting it will be either
>     ignored or throw an exception.
>

Yes, I would agree with this.

>
>     I'll note that currentRate is eliminated from the ClipEnvelope in
>     the fix I'm working on, but as it's read-only, it's a different story.
>
>         As long as the implementation
>         is consistent in ignoring the rate property from the child
>         Animation,
>         this seems like a fine solution and is consistent with other
>         properties
>         where one property overrides another without modifying it.
>
>
>     Which other properties?
>

I meant outside animation. Node.opacity for example. You can set it to 
any value and it is clamped on use. I realize that this is a different 
situation.


>     delay, autoReverse, and cycleCount all work separately on the
>     parent and child. For example, if both parent and child have
>     autoReverse = true and cycleCount = 2, the animation will play
>     forwards, backwards, forwards, backwards, so both are taken into
>     account.
>

OK.

-- Kevin


>     On Wed, Jan 8, 2020 at 1:14 AM Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>     wrote:
>
>         A rate in a "parent" transition should probably override the
>         rate in a
>         child Animation. There are a couple ways to do it, and it
>         sounds like it
>         doesn't really implement it right.
>
>         1. The public rate property values of child Animations within
>         a parent
>         Transition are ignored, but not updated. As long as the
>         implementation
>         is consistent in ignoring the rate property from the child
>         Animation,
>         this seems like a fine solution and is consistent with other
>         properties
>         where one property overrides another without modifying it.
>
>         2. Setting a rate on the parent Transition actually modifies
>         the child
>         node. This can work, but has more issues. What happens if you
>         set the
>         rate of the parent tansition and then set the rate of a child
>         animation?
>         What if you bind to the rate of a child animation?
>
>         -- Kevin
>
>         On 1/1/2020 1:04 PM, Nir Lisker wrote:
>         > Hi,
>         >
>         > As part of my work in the animations package I've come
>         across an undefined
>         > spec. Is the rate of an animation that is embedded in a
>         Parallel/Sequential
>         > transition inherited and overridden by its parent?
>         >
>         > If I have an animations with a rate of 1 and a parent with a
>         rate of 2, and
>         > I add the animation to the parent, does the rate property
>         change from 1 to
>         > 2 (generating a change/invalidation event etc.)? Then,
>         should any
>         > subsequent changes to the parent's rate trigger a change in
>         the child's
>         > rate?
>         >
>         > The implementation is a bit messy in this regard. The rate
>         and currentRate
>         > values exist in both Animation and its ClipEnvelope, which
>         is the source
>         > for a couple of bugs. For example, changing the rate of a
>         > ParallelTransition changes the child's ClipEnvelope's rate
>         and currentRate,
>         > but only the animation's currentRate (and not rate). Is it
>         supposed to be
>         > this way?
>         >
>         > What is clear is that it's not possible to change the rate
>         of the embedded
>         > animation directly.
>         >
>         > The docs do not talk about the rate of an embedded animation
>         (they do talk
>         > about the node property though).
>         >
>         > - Nir
>


From kcr at openjdk.java.net  Tue Jan 21 23:54:35 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 21 Jan 2020 23:54:35 GMT
Subject: RFR: 8237078: Media build code broken on XCode 11
In-Reply-To: <h6QcSQI6zySKiwORTkiX5x0NrBFWxxA22VYMKB41XRM=.55e393d8-dc14-4bb0-afdf-68d81770e908@github.com>
References: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
 <h6QcSQI6zySKiwORTkiX5x0NrBFWxxA22VYMKB41XRM=.55e393d8-dc14-4bb0-afdf-68d81770e908@github.com>
Message-ID: <esaLCc1L2qGrwAKrrv7GS4bP7zEt30vvPE-41c-HbL0=.b1f2d221-ff48-4e91-ad7c-1f8fc04f5eb5@github.com>

On Tue, 21 Jan 2020 21:37:54 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Fix JDK-8237078
>> replace the objc_msgSend call with a direct objC call.
>> The fix works on XCode 10.1 and XCode 11.3
>> 
>> Tested using
>> java  -Djfxmedia.platforms=OSXPlatform
>> with MediaPlayer playing an mp3.
> 
> Looks good.

@johanvos can you change the PR title to match the JBS title?

8237078: [macOS] Media build broken on XCode 11

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

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

From nlisker at gmail.com  Wed Jan 22 00:51:14 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 22 Jan 2020 02:51:14 +0200
Subject: Rate of embedded animations
In-Reply-To: <851e9863-f7bd-8cd4-ba82-89b9ba52e1b7@oracle.com>
References: <CA+0ynh-c2pN54SSoXjCLXGWo7c1GsyqwuAnNGx-mQsxwHD-sJg@mail.gmail.com>
 <e9dee0f6-aba6-b787-849c-6f319049a99f@oracle.com>
 <CA+0ynh8COobS1QUiiwQOaEtv=3ph9RqKAniUqG3xfw0vcnbNmg@mail.gmail.com>
 <CA+0ynh-XP4Zxno62bAddKkyvqWMAMofcoOKWrLKdzd4yAY0BjA@mail.gmail.com>
 <851e9863-f7bd-8cd4-ba82-89b9ba52e1b7@oracle.com>
Message-ID: <CA+0ynh9pXNnaz-3sgWZ8u6sQUaZ9EmQuOp6nKCzbo6FZV=2MOg@mail.gmail.com>

Then I will take approach 1 for now.

Remind me again, which JBS bug you are planning to use to fix this issue?


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

On Wed, Jan 22, 2020 at 1:31 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> This got buried in my inbox, and I missed seeing it.
>
> I'll respond inline.
>
>
> On 1/10/2020 6:45 PM, Nir Lisker wrote:
>
> I forgot to bring up https://bugs.openjdk.java.net/browse/JDK-8200206,
> which is also relevant to this discussion. The solution to that one is
> probably allowing only 1 parent, similar to the scenegraph policy. That
> will avoid parent animations fighting over the state of common children
> animations.
>
>
> Good point. Regardless of which approach (1 or 2) we go with, I agree that
> allowing only a single parent transition is best. I note that this would be
> a semantic change, though, so even though we ought to decide what we want
> the behavior to be, actually enforcing a single parent is probably best
> left to JavaFX 15 (I note that
> https://bugs.openjdk.java.net/browse/JDK-8200206 is targeted to 15).
>
> On Sat, Jan 11, 2020 at 3:08 AM Nir Lisker <nlisker at gmail.com> wrote:
>
>> What happens if you set the rate of the parent transition and then set
>>> the rate of a child animation?
>>>
>> What if you bind to the rate of a child animation?
>>
>>
>> There is already some code that touches this in the Animation's rate
>> property:
>>
>> public void invalidated() {
>>     final double newRate = getRate();
>>     if (isRunningEmbedded()) {
>>         if (isBound()) {
>>             unbind();
>>         }
>>         set(oldRate);
>>         throw new IllegalStateException("Cannot set rate of embedded
>> animation while running.");
>>     }
>>
>> isRunningEmbedded checks for a parent animation that is not STOPPED. That
>> means that the rate of a child animation can only change while the parent
>> is stopped, but it is ignored (the child's ClipEnvelope's rate is updated
>> to the parent's rate instead).
>> Binding to the rate property is never an issue, but it does give
>> meaningless results since the rate is ignored. Binding the rate property
>> itself will cause it to be unbinded.
>>
>> If we go with option 1, which is almost the current situation, there is
>> only some cleanup needed when it comes to the relation between the
>> Animation's rate and its ClipEnvelope's rate.
>>
>
> This (option 1) seems easiest, but I can see am argument for either
> approach.
>
> Remind me again, which JBS bug you are planning to use to fix this issue?
>
> If we go with option 2, we can eliminate the duplication of rate in the
>> Animation and the ClipEnvelope (though ClipEvenope to Animation is somewhat
>> like a peer to a Node, which duplicates the values as well, so maybe we
>> want that?). The children's rate will always be the parent's rate. In this
>> case the above code should probably be modified to account for STOPPED
>> parents as well. A bound rate property will be unbinded and setting it will
>> be either ignored or throw an exception.
>>
>
> Yes, I would agree with this.
>
>
>> I'll note that currentRate is eliminated from the ClipEnvelope in the fix
>> I'm working on, but as it's read-only, it's a different story.
>>
>> As long as the implementation
>>> is consistent in ignoring the rate property from the child Animation,
>>> this seems like a fine solution and is consistent with other properties
>>> where one property overrides another without modifying it.
>>
>>
>> Which other properties?
>>
>
> I meant outside animation. Node.opacity for example. You can set it to any
> value and it is clamped on use. I realize that this is a different
> situation.
>
>
> delay, autoReverse, and cycleCount all work separately on the parent and
>> child. For example, if both parent and child have autoReverse = true and
>> cycleCount = 2, the animation will play forwards, backwards, forwards,
>> backwards, so both are taken into account.
>>
>
> OK.
>
> -- Kevin
>
>
> On Wed, Jan 8, 2020 at 1:14 AM Kevin Rushforth <kevin.rushforth at oracle.com>
>> wrote:
>>
>>> A rate in a "parent" transition should probably override the rate in a
>>> child Animation. There are a couple ways to do it, and it sounds like it
>>> doesn't really implement it right.
>>>
>>> 1. The public rate property values of child Animations within a parent
>>> Transition are ignored, but not updated. As long as the implementation
>>> is consistent in ignoring the rate property from the child Animation,
>>> this seems like a fine solution and is consistent with other properties
>>> where one property overrides another without modifying it.
>>>
>>> 2. Setting a rate on the parent Transition actually modifies the child
>>> node. This can work, but has more issues. What happens if you set the
>>> rate of the parent tansition and then set the rate of a child animation?
>>> What if you bind to the rate of a child animation?
>>>
>>> -- Kevin
>>>
>>> On 1/1/2020 1:04 PM, Nir Lisker wrote:
>>> > Hi,
>>> >
>>> > As part of my work in the animations package I've come across an
>>> undefined
>>> > spec. Is the rate of an animation that is embedded in a
>>> Parallel/Sequential
>>> > transition inherited and overridden by its parent?
>>> >
>>> > If I have an animations with a rate of 1 and a parent with a rate of
>>> 2, and
>>> > I add the animation to the parent, does the rate property change from
>>> 1 to
>>> > 2 (generating a change/invalidation event etc.)? Then, should any
>>> > subsequent changes to the parent's rate trigger a change in the child's
>>> > rate?
>>> >
>>> > The implementation is a bit messy in this regard. The rate and
>>> currentRate
>>> > values exist in both Animation and its ClipEnvelope, which is the
>>> source
>>> > for a couple of bugs. For example, changing the rate of a
>>> > ParallelTransition changes the child's ClipEnvelope's rate and
>>> currentRate,
>>> > but only the animation's currentRate (and not rate). Is it supposed to
>>> be
>>> > this way?
>>> >
>>> > What is clear is that it's not possible to change the rate of the
>>> embedded
>>> > animation directly.
>>> >
>>> > The docs do not talk about the rate of an embedded animation (they do
>>> talk
>>> > about the node property though).
>>> >
>>> > - Nir
>>>
>>>
>

From arapte at openjdk.java.net  Wed Jan 22 09:03:12 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 22 Jan 2020 09:03:12 GMT
Subject: RFR: 8237372: NullPointerException in TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <WScZ8yNafusZ-Vo_Ch-YcrQwBE8iL3w2-RMbXHinaAM=.c4f9f50f-123a-4292-9077-368ee8c0135f@github.com>

On Mon, 20 Jan 2020 10:00:55 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> Test simulates a single mouse-released event.
> Fix simply guards against the null case.

The scenario mentioned in [JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372) seems valid scenario. However I am not sure if the scenario can be avoided or not. Irrespective of that, the code in question should be corrected. Suggested a minor change.

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

> 2215:         // Animate tab header being dragged to its final position.
> 2216:         if (dragTabHeader != null) {
> 2217:             dragHeaderSourceX = dragTabHeader.getLayoutX();

This is a situation when reorder was not started.
So a check as `else if (dragState == DragState.REORDER)` seems more correct instead of `null` check. With this `else if` the `return;` on line 2213 can be removed.

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



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

From jvos at openjdk.java.net  Wed Jan 22 12:27:30 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 22 Jan 2020 12:27:30 GMT
Subject: [Integrated] RFR: 8237078: Media build code broken on XCode 11
In-Reply-To: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
References: <pnHONoqIqxdpE5i9viyeNnoHGorur5aH9YrlHk4lkaA=.43dc9538-8bf2-46a5-bddc-6b388cdc341b@github.com>
Message-ID: <1f4a9337-0371-4c79-9ded-74288c11e8e1@openjdk.org>

Changeset: be22e853
Author:    Johan Vos <jvos at openjdk.org>
Date:      2020-01-22 12:26:17 +0000
URL:       https://git.openjdk.java.net/jfx/commit/be22e853

8237078: [macOS] Media build broken on XCode 11

Reviewed-by: kcr, almatvee

! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.mm

From Rony.Flatscher at wu.ac.at  Wed Jan 22 13:44:01 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Wed, 22 Jan 2020 14:44:01 +0100
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
Message-ID: <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>

Last November I submitted an appropriate bug report and mailed the testcase on November 27th per
Oracle's request without hearing anything to this date.

Therefore I was wondering how long such an assessment usually takes place and what to do? (Maybe it
"fell off the desk" due to the end-of-year stress and Christmas vacation?) Any advice?

---rony


On 21.11.2019 15:39, Rony G. Flatscher wrote:
> As the zip-archive attachment got stripped, for a brief time the zip-archive can be fetched from
> <https://www.dropbox.com/s/l4uesrwm0iw5vb9/testcaseFXMLLoaderScriptEngines.zip?dl=0>.
>
> ---rony
>
> On 21.11.2019 15:29, Rony G. Flatscher wrote:
>> On 15.11.2019 16:08, Rony G. Flatscher wrote:
>>> On 14.11.2019 22:57, Kevin Rushforth wrote:
>>>> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote:
>>>>> On 14.11.2019 16:34, Rony G. Flatscher wrote:
>>>>>> On 13.11.2019 19:50, Kevin Rushforth wrote:
>>>>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
>>>>> ... cut ...
>>>>>>>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all
>>>>>>>> opensource) for
>>>>>>>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a
>>>>>>>> script to
>>>>>>>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be
>>>>>>>> o.k.?
>>>>>>> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to
>>>>>>> use that for a regression test / unit test.
>>>>> If test units really seem to be important in this particular case, one possibility would be to
>>>>> create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow
>>>>> the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and
>>>>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval()
>>>>> methods return the ScriptContext at invocation time in order to allow inspection of the Bindings.
>>>>> This way it would become also possible to write in addition test units that also check whether all
>>>>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings.
>>>> Something like that seems reasonable, and would avoid a dependence on Nashorn, which in addition
>>>> to having all the problems you mentioned, is deprecated for removal.
>>>>
>>>>> However,
>>>> Did you have something more to add?
>>> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake and without noticing.
>>>
>>> Will study all the procedures and create a testcase to be submitted at <https://bugreport.java.com/>
>>> as per your advice (and will report back under this thread once submitted). The testcase would use
>>> an artificial ScriptEngine implementation that could be used for testunit testing as well. This
>>> might take a while due to other obligations that I will have to meet during the next few days.
>>>
>>> ---rony
>> O.K., so came up with a test case that contains an artificial script engine implementation for
>> logging the eval() invocations together with the scripts to execute and the ScriptContext
>> ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is meant to be also usable
>> for creating script engine related test units for Java script hosts.)
>>
>> Packaged the source and binaries of that script engine as jar file that one merely needs to put on
>> the CLASSPATH or add as a module.
>>
>> An updated FXMLLoader patch suggesting a fix is included as well. This version appends the line
>> number to the file name if the script to be evaluated is embedded in the fxml-file, such that in
>> case of an error it becomes possible to quickly find it in larger fxml files.
>>
>> With the zip-archive done I went to the Oracle Java Bug Database and just entered a bug report at
>> <https://bugreport.java.com/bugreport/submit_start.do> got the internal "ID : 9062887".
>>
>> As it was not possible to attach/upload the zip-archive at this point, I will attach the zip-archive
>> (contains all sources and binaries) to this e-mail. The contained <readme.txt> reads:
>>
>>     Testcase that demonstrates that FXMLLoader does not set [1]
>>     ScriptEngine.FILENAME and [2] ScriptEngine.ARGV entries in
>>     ScriptContext.ENGINE_SCOPE Bindings.
>>
>>     To run the test case:
>>
>>     - unzip testcaseFXMLLoaderScriptEngines.zip,
>>
>>     - change into "testcaseFXMLLoaderScriptEngines" subdirectory,
>>
>>     - run the testcase by issuing the following command:
>>
>>     ? - Unix:
>>
>>     ??????? java -cp .:RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope
>>
>>     ? - Windows:
>>
>>     ??????? java -cp .;RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope
>>
>>     FXMLLoaderTestCase4ScriptEngineScope loads "demo_01.fxml" which is a controller
>>     that uses the pseudo script language rgf.scriptEngine.RgfPseudoScriptEngine,
>>     which logs the eval() invocations with the script code and the Bindings of the
>>     ScriptContext.
>>
>>     Comparing "demo_01.fxml" and the output of the above test case demonstrates that
>>     FXMLLoader does not popuplate the [3] ENGINE_SCOPE Bindings with the filename of
>>     the script that gets evaluated, nor does add the ARGV entry to the ENGINE_SCOPE
>>     Bindings in the case of events (just an entry named "event").
>>
>>     In case of errors (during development or deployment) it is not possible
>>     therefore to point to the file (external file or the fxml-file defining
>>     explicitly script code) in which a runtime error has occurred.
>>
>>     In the case of an event callback, if ARGV was defined the script code could
>>     directly fetch and interact with the supplied event object argument.? In the
>>     case that a script engine does not automatically make Bindings entry available
>>     as implicit variables (e.g.? for scoping reasons) it becomes cumbersome or even
>>     impossible in some script engine implementations (if they do not provide access
>>     to the Bindings) to get at the event argument of the callback invocation.
>>
>>     The JSR-223 specifications lists all the (reserved) ScriptEngine constants that
>>     are meant to be used as reserved keys for the ENGINE_SCOPE Bindings, whenever
>>     appropriate cf.? [0] p.? l50 ff.? (A ScriptEngine is supposed to populate and
>>     maintain the ENGINE_SCOPE Bindings hence the definition of these constants with
>>     the class.)
>>
>>     Running the above program on Windows yields the output captured and supplied in
>>     [4].
>>
>>     The supplied patch [5] changes FXMLLoader.java such,
>>
>>     - that the ScriptEngine.FILENAME entry is always set in the ENGINE_SCOPE
>>     ? Bindings. In the case that the scripts are hosted in a fxml-file that file
>>     ? path will be used together with an appended string that hints at the location
>>     ? in the fxml file from where the script has been taken for evaluation. In the
>>     ? case of event handling scripts that appended string hints at the location in
>>     ? the fxml-file where the event attribute with the script code got used.
>>
>>     - and that the ScriptEngine.ARGV entry is always set in the ENGINE_SCOPE
>>     ? Bindings for event callbacks using the 'event' object as the single argument.
>>
>>     Applying the patch and running the above program on Linux yields the output
>>     captured and supplied in [6].
>>
>>     ---
>>
>>     The jar-file [7] needs merely to be put on the CLASSPATH (or MODULE_PATH as a
>>     proper module-info.class is included, the module name is "rgf.scriptEngine") to
>>     make the pseudo scripting language available and to run the supplied testcase.
>>     The RgfPseudoScriptEngine (script engine name and extension is "rpsl")
>>     implementation should also make it possible to create test units for asserting
>>     that Java script hosts are populating the ScriptContext Bindings according to
>>     specifications.
>>
>>     All Java classes come with their source code (the script engine service file and
>>     module-info.{java|class} are contained in the jar file).
>>
>>     Having signed the OCA you may use all of the supplied code freely.
>>
>>     If there is anything you need or that I could provide, please let me know.
>>
>>     ---rony
>>
>>     [0] JSR-223 specification at <https://jcp.org/en/jsr/detail?id=223>, download
>>     ??? <https://jcp.org/aboutJava/communityprocess/pfd/jsr223/index.html>:
>>     ??? "java_scripting-1_0-fr-spec.pdf"
>>
>>     [1]
>>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngine.html#FILENAME>
>>
>>     [2]
>>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngine.html#ARGV>
>>
>>     [3]
>>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptContext.html#ENGINE_SCOPE>
>>
>>     [4] Output of running the testcase on Windows (Java 8): "info/Demo_output_without_fix.txt"
>>
>>     [5] FXMLLoader patch: "info/diff_add_FILENAME_ARGV_to_FXMLLoader_preferable_20191121.txt"
>>
>>     [6] Output of running the testcase after patching FXMLLoader with [5] on Linux (OpenJDK 11.0.5):
>>     ??? "info/Demo_output_with_fix_and_linenumbers.txt"
>>
>>     [7] Pseudo script engine implementation to be put on the CLASSPATH or MODULE_PATH (module
>>     ??? name "rgf.scriptEngine"): <RgfPseudoScriptEngine.jar>
>>
>>     [8] FXML test case:
>>
>>     ??? - FXMLLoaderTestCase4ScriptEngineScope.{java|class}
>>     ????? ... loads "demo_01.rxml" and dumps the engine and global Bindings
>>
>>     ??? - demo_01.fxml
>>     ??? ... FXML file using scripts in the pseudo script language [7] as controller,
>>     ??????? either as external or embedded scripts, including scripts for event
>>     ??????? handling Action and MouseClicked events
>>
>>     ??? - demo_01_bottomscript.rpsl? ... serving as external script file
>>
>>     ??? - demo_01_middlescript.rpsl? ... serving as external script file
>>
>>     ??? - demo_01_topscript.rpsl???? ... serving as external script file
>>
>> If there is anything else I can/should do, please advise.
>> (Being on the road in the next few days it might take me until the beginning of next week to get back.)
>>
>> ---rony


From dgrieve at openjdk.java.net  Wed Jan 22 15:00:48 2020
From: dgrieve at openjdk.java.net (David Grieve)
Date: Wed, 22 Jan 2020 15:00:48 GMT
Subject: RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
Message-ID: <4nH9CJeHvFv63JTh0thKODzzPH2N9Cp0wlgo7oYwGvQ=.17d9dbb4-1658-4d15-9815-7884f8674c7c@github.com>

On Fri, 17 Jan 2020 14:09:54 GMT, Dean Wookey <dwookey at openjdk.org> wrote:

> Everything passes with the fix and 5 of the new tests fail without the fix.
> 
> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
> movingBranchToDifferentBranchGetsNewCssVariableTest
> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
> movingNodeToDifferentBranchGetsNewFontStyleTest
> 
> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
> 
> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab

Changes requested by dgrieve (Reviewer).

modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 134:

> 133:             node.styleHelper.triggerStates.addAll(triggerStates[0]);
> 134: 
> 135:             updateParentTriggerStates(node, depth, triggerStates);

In canReuseStyleHelper, there is this check
       // If the style maps are the same instance, we can re-use the current styleHelper if the cacheContainer is null.
        // Under this condition, there are no styles for this node _and_ no styles inherit.
        if (node.styleHelper.cacheContainer == null) {
            return true;
        }
And later in the same function is a check for (parent == null) that returns true. In both cases, firstStyleableAncestor will still point to the old first-styleable ancestor.

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

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

From dwookey at openjdk.java.net  Wed Jan 22 15:25:30 2020
From: dwookey at openjdk.java.net (Dean Wookey)
Date: Wed, 22 Jan 2020 15:25:30 GMT
Subject: RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <4nH9CJeHvFv63JTh0thKODzzPH2N9Cp0wlgo7oYwGvQ=.17d9dbb4-1658-4d15-9815-7884f8674c7c@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
 <4nH9CJeHvFv63JTh0thKODzzPH2N9Cp0wlgo7oYwGvQ=.17d9dbb4-1658-4d15-9815-7884f8674c7c@github.com>
Message-ID: <uo2TvsNo7NmzV3hqW2kBN9g9uS2Mh8MNDslrBLnpjxI=.8171cd01-e432-41d0-921b-ab7de56d78be@github.com>

On Wed, 22 Jan 2020 15:00:14 GMT, David Grieve <dgrieve at openjdk.org> wrote:

>> Everything passes with the fix and 5 of the new tests fail without the fix.
>> 
>> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
>> movingBranchToDifferentBranchGetsNewCssVariableTest
>> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
>> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
>> movingNodeToDifferentBranchGetsNewFontStyleTest
>> 
>> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
>> 
>> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab
> 
> modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 134:
> 
>> 133:             node.styleHelper.triggerStates.addAll(triggerStates[0]);
>> 134: 
>> 135:             updateParentTriggerStates(node, depth, triggerStates);
> 
> In canReuseStyleHelper, there is this check
>        // If the style maps are the same instance, we can re-use the current styleHelper if the cacheContainer is null.
>         // Under this condition, there are no styles for this node _and_ no styles inherit.
>         if (node.styleHelper.cacheContainer == null) {
>             return true;
>         }
> And later in the same function is a check for (parent == null) that returns true. In both cases, firstStyleableAncestor will still point to the old first-styleable ancestor.

Thanks. For some reason I thought all the early exits out of the method returned false. I'll push a fix.

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

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

From anthonyv.be at outlook.com  Wed Jan 22 16:07:53 2020
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Wed, 22 Jan 2020 16:07:53 +0000
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>,
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
Message-ID: <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>

Hi Rony

Your issue has been converted into a JDK issue, with your testcase attached [1]. Normally you should?ve received an e-mail at the time of this conversion, but you can check this yourself by using the internal review ID as in [2]. If you?d like to contribute a fix, see [3].

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8234959
[2] https://bugs.openjdk.java.net/browse/JI-9062887
[3] https://github.com/openjdk/jfx


From: Rony G. Flatscher<mailto:Rony.Flatscher at wu.ac.at>
Sent: Wednesday, 22 January 2020 14:44
To: openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net>
Subject: Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

Last November I submitted an appropriate bug report and mailed the testcase on November 27th per
Oracle's request without hearing anything to this date.

Therefore I was wondering how long such an assessment usually takes place and what to do? (Maybe it
"fell off the desk" due to the end-of-year stress and Christmas vacation?) Any advice?

---rony


On 21.11.2019 15:39, Rony G. Flatscher wrote:
> As the zip-archive attachment got stripped, for a brief time the zip-archive can be fetched from
> <https://www.dropbox.com/s/l4uesrwm0iw5vb9/testcaseFXMLLoaderScriptEngines.zip?dl=0>.
>
> ---rony
>
> On 21.11.2019 15:29, Rony G. Flatscher wrote:
>> On 15.11.2019 16:08, Rony G. Flatscher wrote:
>>> On 14.11.2019 22:57, Kevin Rushforth wrote:
>>>> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote:
>>>>> On 14.11.2019 16:34, Rony G. Flatscher wrote:
>>>>>> On 13.11.2019 19:50, Kevin Rushforth wrote:
>>>>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
>>>>> ... cut ...
>>>>>>>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all
>>>>>>>> opensource) for
>>>>>>>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a
>>>>>>>> script to
>>>>>>>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be
>>>>>>>> o.k.?
>>>>>>> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to
>>>>>>> use that for a regression test / unit test.
>>>>> If test units really seem to be important in this particular case, one possibility would be to
>>>>> create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow
>>>>> the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and
>>>>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval()
>>>>> methods return the ScriptContext at invocation time in order to allow inspection of the Bindings.
>>>>> This way it would become also possible to write in addition test units that also check whether all
>>>>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings.
>>>> Something like that seems reasonable, and would avoid a dependence on Nashorn, which in addition
>>>> to having all the problems you mentioned, is deprecated for removal.
>>>>
>>>>> However,
>>>> Did you have something more to add?
>>> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake and without noticing.
>>>
>>> Will study all the procedures and create a testcase to be submitted at <https://bugreport.java.com/>
>>> as per your advice (and will report back under this thread once submitted). The testcase would use
>>> an artificial ScriptEngine implementation that could be used for testunit testing as well. This
>>> might take a while due to other obligations that I will have to meet during the next few days.
>>>
>>> ---rony
>> O.K., so came up with a test case that contains an artificial script engine implementation for
>> logging the eval() invocations together with the scripts to execute and the ScriptContext
>> ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is meant to be also usable
>> for creating script engine related test units for Java script hosts.)
>>
>> Packaged the source and binaries of that script engine as jar file that one merely needs to put on
>> the CLASSPATH or add as a module.
>>
>> An updated FXMLLoader patch suggesting a fix is included as well. This version appends the line
>> number to the file name if the script to be evaluated is embedded in the fxml-file, such that in
>> case of an error it becomes possible to quickly find it in larger fxml files.
>>
>> With the zip-archive done I went to the Oracle Java Bug Database and just entered a bug report at
>> <https://bugreport.java.com/bugreport/submit_start.do> got the internal "ID : 9062887".
>>
>> As it was not possible to attach/upload the zip-archive at this point, I will attach the zip-archive
>> (contains all sources and binaries) to this e-mail. The contained <readme.txt> reads:
>>
>>     Testcase that demonstrates that FXMLLoader does not set [1]
>>     ScriptEngine.FILENAME and [2] ScriptEngine.ARGV entries in
>>     ScriptContext.ENGINE_SCOPE Bindings.
>>
>>     To run the test case:
>>
>>     - unzip testcaseFXMLLoaderScriptEngines.zip,
>>
>>     - change into "testcaseFXMLLoaderScriptEngines" subdirectory,
>>
>>     - run the testcase by issuing the following command:
>>
>>       - Unix:
>>
>>             java -cp .:RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope
>>
>>       - Windows:
>>
>>             java -cp .;RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope
>>
>>     FXMLLoaderTestCase4ScriptEngineScope loads "demo_01.fxml" which is a controller
>>     that uses the pseudo script language rgf.scriptEngine.RgfPseudoScriptEngine,
>>     which logs the eval() invocations with the script code and the Bindings of the
>>     ScriptContext.
>>
>>     Comparing "demo_01.fxml" and the output of the above test case demonstrates that
>>     FXMLLoader does not popuplate the [3] ENGINE_SCOPE Bindings with the filename of
>>     the script that gets evaluated, nor does add the ARGV entry to the ENGINE_SCOPE
>>     Bindings in the case of events (just an entry named "event").
>>
>>     In case of errors (during development or deployment) it is not possible
>>     therefore to point to the file (external file or the fxml-file defining
>>     explicitly script code) in which a runtime error has occurred.
>>
>>     In the case of an event callback, if ARGV was defined the script code could
>>     directly fetch and interact with the supplied event object argument.  In the
>>     case that a script engine does not automatically make Bindings entry available
>>     as implicit variables (e.g.  for scoping reasons) it becomes cumbersome or even
>>     impossible in some script engine implementations (if they do not provide access
>>     to the Bindings) to get at the event argument of the callback invocation.
>>
>>     The JSR-223 specifications lists all the (reserved) ScriptEngine constants that
>>     are meant to be used as reserved keys for the ENGINE_SCOPE Bindings, whenever
>>     appropriate cf.  [0] p.  l50 ff.  (A ScriptEngine is supposed to populate and
>>     maintain the ENGINE_SCOPE Bindings hence the definition of these constants with
>>     the class.)
>>
>>     Running the above program on Windows yields the output captured and supplied in
>>     [4].
>>
>>     The supplied patch [5] changes FXMLLoader.java such,
>>
>>     - that the ScriptEngine.FILENAME entry is always set in the ENGINE_SCOPE
>>       Bindings. In the case that the scripts are hosted in a fxml-file that file
>>       path will be used together with an appended string that hints at the location
>>       in the fxml file from where the script has been taken for evaluation. In the
>>       case of event handling scripts that appended string hints at the location in
>>       the fxml-file where the event attribute with the script code got used.
>>
>>     - and that the ScriptEngine.ARGV entry is always set in the ENGINE_SCOPE
>>       Bindings for event callbacks using the 'event' object as the single argument.
>>
>>     Applying the patch and running the above program on Linux yields the output
>>     captured and supplied in [6].
>>
>>     ---
>>
>>     The jar-file [7] needs merely to be put on the CLASSPATH (or MODULE_PATH as a
>>     proper module-info.class is included, the module name is "rgf.scriptEngine") to
>>     make the pseudo scripting language available and to run the supplied testcase.
>>     The RgfPseudoScriptEngine (script engine name and extension is "rpsl")
>>     implementation should also make it possible to create test units for asserting
>>     that Java script hosts are populating the ScriptContext Bindings according to
>>     specifications.
>>
>>     All Java classes come with their source code (the script engine service file and
>>     module-info.{java|class} are contained in the jar file).
>>
>>     Having signed the OCA you may use all of the supplied code freely.
>>
>>     If there is anything you need or that I could provide, please let me know.
>>
>>     ---rony
>>
>>     [0] JSR-223 specification at <https://jcp.org/en/jsr/detail?id=223>, download
>>         <https://jcp.org/aboutJava/communityprocess/pfd/jsr223/index.html>:
>>         "java_scripting-1_0-fr-spec.pdf"
>>
>>     [1]
>>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngine.html#FILENAME>
>>
>>     [2]
>>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngine.html#ARGV>
>>
>>     [3]
>>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptContext.html#ENGINE_SCOPE>
>>
>>     [4] Output of running the testcase on Windows (Java 8): "info/Demo_output_without_fix.txt"
>>
>>     [5] FXMLLoader patch: "info/diff_add_FILENAME_ARGV_to_FXMLLoader_preferable_20191121.txt"
>>
>>     [6] Output of running the testcase after patching FXMLLoader with [5] on Linux (OpenJDK 11.0.5):
>>         "info/Demo_output_with_fix_and_linenumbers.txt"
>>
>>     [7] Pseudo script engine implementation to be put on the CLASSPATH or MODULE_PATH (module
>>         name "rgf.scriptEngine"): <RgfPseudoScriptEngine.jar>
>>
>>     [8] FXML test case:
>>
>>         - FXMLLoaderTestCase4ScriptEngineScope.{java|class}
>>           ... loads "demo_01.rxml" and dumps the engine and global Bindings
>>
>>         - demo_01.fxml
>>         ... FXML file using scripts in the pseudo script language [7] as controller,
>>             either as external or embedded scripts, including scripts for event
>>             handling Action and MouseClicked events
>>
>>         - demo_01_bottomscript.rpsl  ... serving as external script file
>>
>>         - demo_01_middlescript.rpsl  ... serving as external script file
>>
>>         - demo_01_topscript.rpsl     ... serving as external script file
>>
>> If there is anything else I can/should do, please advise.
>> (Being on the road in the next few days it might take me until the beginning of next week to get back.)
>>
>> ---rony


From dwookey at openjdk.java.net  Wed Jan 22 16:26:10 2020
From: dwookey at openjdk.java.net (Dean Wookey)
Date: Wed, 22 Jan 2020 16:26:10 GMT
Subject: [Rev 01] RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
Message-ID: <8GTA0ist_AM_kquybyA5mj-dq6FPH5fO-vYXb1Ir-Xc=.57c7a535-c6e6-4745-8781-81be60dd212a@github.com>

> Everything passes with the fix and 5 of the new tests fail without the fix.
> 
> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
> movingBranchToDifferentBranchGetsNewCssVariableTest
> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
> movingNodeToDifferentBranchGetsNewFontStyleTest
> 
> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
> 
> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 782f55e3: 8237469: Moved firstStyleableAncestor call to before canReuseStyleHelper can return true

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/87/files
  - new: https://git.openjdk.java.net/jfx/pull/87/files/0749dde7..782f55e3

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

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

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

From dgrieve at openjdk.java.net  Wed Jan 22 17:03:50 2020
From: dgrieve at openjdk.java.net (David Grieve)
Date: Wed, 22 Jan 2020 17:03:50 GMT
Subject: [Rev 01] RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <8GTA0ist_AM_kquybyA5mj-dq6FPH5fO-vYXb1Ir-Xc=.57c7a535-c6e6-4745-8781-81be60dd212a@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
 <8GTA0ist_AM_kquybyA5mj-dq6FPH5fO-vYXb1Ir-Xc=.57c7a535-c6e6-4745-8781-81be60dd212a@github.com>
Message-ID: <F5_M77Oags355e5IOz46I6J-pE7Lb-_t7i3_q0xPhdI=.4c2c2ed1-25b4-41bd-a475-a5473b63073a@github.com>

On Wed, 22 Jan 2020 17:03:49 GMT, Dean Wookey <dwookey at openjdk.org> wrote:

>> Everything passes with the fix and 5 of the new tests fail without the fix.
>> 
>> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
>> movingBranchToDifferentBranchGetsNewCssVariableTest
>> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
>> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
>> movingNodeToDifferentBranchGetsNewFontStyleTest
>> 
>> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
>> 
>> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by dgrieve (Reviewer).

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

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

From Rony.Flatscher at wu.ac.at  Wed Jan 22 17:52:12 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Wed, 22 Jan 2020 18:52:12 +0100
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
 <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
Message-ID: <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>

Hi Anthony,

On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
> Your issue has been converted into a JDK issue, with your testcase attached [1].

Thank you *very* much for this information!

> Normally you should?ve received an e-mail at the time of this conversion,

Just searched all my e-mail folders and could not find it (looking for "FXMLLoader" in the subject
of e-mails as the bug title contains that word) but could not find a matching e-mail for whatever
reasons.

> but you can check this yourself by using the internal review ID as in [2]. If you?d like to
> contribute a fix, see [3].
>
> ?
>
> Kind regards, Anthony
>
> ?
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8234959
> <https://bugs.openjdk.java.net/browse/JDK-8234959>
>
> [2] https://bugs.openjdk.java.net/browse/JI-9062887 <https://bugs.openjdk.java.net/browse/JI-9062887>
>
> [3] https://github.com/openjdk/jfx <https://github.com/openjdk/jfx>
>
Thank you also for these links (and I learned something new on how to check for it using the
internal review id with your [2], thanks a lot for this hint as well)!

Will go back and study all the necessary procedures (forgot a lot since reading them the last time)
and will try to contribute the fix in the proper way but it may take me a little while (currently
quite busy around here).

---

Maybe one more question: there would be an optimization possible by compiling scripts for script
engines that have the javax.script.Compilable interface implemented and use the compiled version to
execute/evaluate the scripts (may be helpful for event handler code e.g. for onMouseMove event
handlers). Can the fix include such an optimization or should there be a separate discussion/RFE for
it beforehand? (Adding this would be trivial in the context of the fix, however the bug description
would not hint at such an optimization.)

---rony



From arapte at openjdk.java.net  Wed Jan 22 17:55:05 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 22 Jan 2020 17:55:05 GMT
Subject: [Rev 01] RFR: 8232824: Removing TabPane with strong referenced
 content causes memory leak from weak one
In-Reply-To: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
Message-ID: <xeQ6D2Wnk4E-5-90iLYbQNh3WEVKXjvcRNUmhsPiC0M=.8379623d-d3e1-410e-ab53-0696dbc01741@github.com>

> This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
> This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).
> 
> Issue.
> - `Parent.viewOrderChildren` is a list of children sorted according to view order.
> - `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.
> 
> - Below is the scenario mentioned in this issue,
> 1. `TabPane` is created with few `tabs`.
> 2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
> 3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
> 4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
> So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.
> 
> Fix:
> Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
> `Parent.viewOrderChildren` will be computed on next `pulse`.
> This will maintain lazy computation of `Parent.viewOrderChildren`. 
> 
> Added a system test, fails without fix and passes with. No failures in existing tests.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - d64f6c86: Adding system test using Group and Shape

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/79/files
  - new: https://git.openjdk.java.net/jfx/pull/79/files/cbcc3161..d64f6c86

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

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

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

From arapte at openjdk.java.net  Wed Jan 22 17:55:06 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 22 Jan 2020 17:55:06 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <j1IXcdF74HRQLt-vsMhHDWQHElfKaK9unX7-6O1ugno=.84fb6cb4-a897-4d06-8848-e2bdf0155b25@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
 <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>
 <SqRVa5K3OG5_J7Jr008FlEdvsHT0mQpO2n_tM6l1hww=.0ba849dc-aa8b-40ea-9983-d166f7918d50@github.com>
 <j1IXcdF74HRQLt-vsMhHDWQHElfKaK9unX7-6O1ugno=.84fb6cb4-a897-4d06-8848-e2bdf0155b25@github.com>
Message-ID: <W9xY8M-hGxOS6kUI9DLyinTSrEooYw3VTSOEWqkoQtk=.3b54a38e-32f3-433a-a6f0-98fc8c05250e@github.com>

On Fri, 17 Jan 2020 23:40:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> 
>>> 
>>> @arapte - This bug looks like a good candidate for JavaFX 14. Can you retarget this PR to the jfx14 branch?
>> 
>> Thanks for guiding Kevin, PR is now targeted to jfx14.
> 
> The fix looks good. I'll take a closer look at the unit test later.
> 
> Speaking of tests...since the addition of the `TabPane` reordering logic was a victim of the already-existing leak in the `viewOrderChildren` list in `Parent`, it should be possible to write a test case using a Group node and a few Shape nodes, using setViewOrder directly on the Group node (this would be in addition to the system test you wrote). Can you take a look at adding one? It might even be possible to do it as a `javafx.graphics` module unit test rather than a system test, although you would need to see if the bug reproduced there (I suspect it will).

> 
> 
> The fix looks good. I'll take a closer look at the unit test later.
> 
> Speaking of tests...since the addition of the `TabPane` reordering logic was a victim of the already-existing leak in the `viewOrderChildren` list in `Parent`, it should be possible to write a test case using a Group node and a few Shape nodes, using setViewOrder directly on the Group node (this would be in addition to the system test you wrote). Can you take a look at adding one? It might even be possible to do it as a `javafx.graphics` module unit test rather than a system test, although you would need to see if the bug reproduced there (I suspect it will).

Hello Kevin,
The bug can be reproduced with system test written using `Group` and `Shape` which is very similar to `TabPaneHeaderLeakTest` test. but it seems the bug is not reproducible with unit test. I tried a unit test very similar to the newly added system test `ShapeViewOrderLeakTest`, but looks like `Parent.viewOrderChildren` list does not get populated and so the issue does not occur.

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

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

From arapte at openjdk.java.net  Wed Jan 22 17:55:27 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 22 Jan 2020 17:55:27 GMT
Subject: [Rev 01] RFR: 8236753: Animations do not play backwards after
 being stopped
In-Reply-To: <8E-6q3Esm-3cPv-QMMoPIqTFW2jOgwFHCKPIwFG1MlI=.4f298bff-55ad-4243-975f-0c32992c2cdc@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
 <8E-6q3Esm-3cPv-QMMoPIqTFW2jOgwFHCKPIwFG1MlI=.4f298bff-55ad-4243-975f-0c32992c2cdc@github.com>
Message-ID: <18PZuXiOMp72fLfEUoajufFMHuGSpw5Rt9DVSs4FWPs=.93e171dc-a66f-4c71-8d29-e97780a32612@github.com>

On Wed, 22 Jan 2020 17:55:27 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The private field `lastPlayFinished` is responsible for 2 cases where an animation in `STOPPED` status does not play after `play()` is called if the rate is negative:
>> 
>> 1. When the animation is created, it is `STOPPED` and `lastPlayFinished` is `false`. Setting a negative rate and calling `play()` will not jump to the end of the animation (in order to play it backwards) because the `if (lastPlayedFinished)` check is `false`. Creating the animation with `lastPlayFinished = true` fixes this. However, `SequentialTransitionPlayTest#testCycleReverse`'s initial state test implies that the original behavior is correct. *That test currently fails with this change.* Either the fix is reverted or the test is corrected.
>> 2. When the animation is stopped (if it was not `STOPPED` already), `jumpTo(Duration.ZERO)` sets `lastPlayFinished` to `false`, which causes the same issue above with `play()`. Setting `lastPlayFinished = true` at the end `stop()` fixes this issue.
>> 
>> A test was added for case 2 to check that the playing head indeed jumps to the end of the animation. Without this fix, it stays at the start.
>> 
>> I'm still somewhat confused as to what constitutes a "last play finished". Any `jumpTo` resets `lastPlayFinished` to `false`, even if the jump is to the start/end of the animation. In this case, stopping an animation, jumping to its start/end, setting the rate to negative/positive, and playing, will do nothing as the end condition is reached immediately. This is what the behavior that was fixed for cases 1 and 2, but maybe this is also incorrect behavior for jumping to start/end.
>> 
>> A test app is included in the "parent" [bug](https://bugs.openjdk.java.net/browse/JDK-8210238), which also mentions a bug relating to **pausing** and playing backwards, so be mindful of it when testing.
> 
> The pull request has been updated with 1 additional commit.

The changes look good to me.

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

Marked as reviewed by arapte (Reviewer).

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

From jvos at openjdk.java.net  Wed Jan 22 18:29:00 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 22 Jan 2020 18:29:00 GMT
Subject: RFR: 8233942: Update to 609.1 version of WebKit
In-Reply-To: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
References: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
Message-ID: <y-Uv8c4FSwWacC77ZnBeNJagE13xrrKUxQVUvFgl8Z8=.41bd81f0-d8b6-4b89-981d-80d42e0c9630@github.com>

On Mon, 20 Jan 2020 16:39:15 GMT, Guru Hb <ghb at openjdk.org> wrote:

> Updated GTK Webkit 2.26 (609.1) into jfx.

Marked as reviewed by jvos (Reviewer).

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

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

From nlisker at openjdk.java.net  Wed Jan 22 20:58:33 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 22 Jan 2020 20:58:33 GMT
Subject: [Integrated] RFR: 8236753: Animations do not play backwards after
 being stopped
In-Reply-To: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
Message-ID: <f56a83a0-6ee3-482f-802f-aae303cd91ee@openjdk.org>

Changeset: 9ae37f1f
Author:    Nir Lisker <nlisker at openjdk.org>
Date:      2020-01-22 20:58:12 +0000
URL:       https://git.openjdk.java.net/jfx/commit/9ae37f1f

8236753: Animations do not play backwards after being stopped

Reviewed-by: kcr, arapte

! modules/javafx.graphics/src/main/java/javafx/animation/Animation.java
! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationTest.java
! modules/javafx.graphics/src/test/java/test/javafx/animation/SequentialTransitionPlayTest.java

From kcr at openjdk.java.net  Wed Jan 22 23:58:51 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 22 Jan 2020 23:58:51 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <W9xY8M-hGxOS6kUI9DLyinTSrEooYw3VTSOEWqkoQtk=.3b54a38e-32f3-433a-a6f0-98fc8c05250e@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
 <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>
 <SqRVa5K3OG5_J7Jr008FlEdvsHT0mQpO2n_tM6l1hww=.0ba849dc-aa8b-40ea-9983-d166f7918d50@github.com>
 <j1IXcdF74HRQLt-vsMhHDWQHElfKaK9unX7-6O1ugno=.84fb6cb4-a897-4d06-8848-e2bdf0155b25@github.com>
 <W9xY8M-hGxOS6kUI9DLyinTSrEooYw3VTSOEWqkoQtk=.3b54a38e-32f3-433a-a6f0-98fc8c05250e@github.com>
Message-ID: <VDPS1HUmLLfEVgCjBpeOPSfMQzZNMAKRUVQ4I86akz4=.b817ea68-7d75-41b8-875d-fd9ba151d010@github.com>

On Wed, 22 Jan 2020 17:53:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The fix looks good. I'll take a closer look at the unit test later.
>> 
>> Speaking of tests...since the addition of the `TabPane` reordering logic was a victim of the already-existing leak in the `viewOrderChildren` list in `Parent`, it should be possible to write a test case using a Group node and a few Shape nodes, using setViewOrder directly on the Group node (this would be in addition to the system test you wrote). Can you take a look at adding one? It might even be possible to do it as a `javafx.graphics` module unit test rather than a system test, although you would need to see if the bug reproduced there (I suspect it will).
> 
>> 
>> 
>> The fix looks good. I'll take a closer look at the unit test later.
>> 
>> Speaking of tests...since the addition of the `TabPane` reordering logic was a victim of the already-existing leak in the `viewOrderChildren` list in `Parent`, it should be possible to write a test case using a Group node and a few Shape nodes, using setViewOrder directly on the Group node (this would be in addition to the system test you wrote). Can you take a look at adding one? It might even be possible to do it as a `javafx.graphics` module unit test rather than a system test, although you would need to see if the bug reproduced there (I suspect it will).
> 
> Hello Kevin,
> The bug can be reproduced with system test written using `Group` and `Shape` which is very similar to `TabPaneHeaderLeakTest` test. but it seems the bug is not reproducible with unit test. I tried a unit test very similar to the newly added system test `ShapeViewOrderLeakTest`, but looks like `Parent.viewOrderChildren` list does not get populated and so the issue does not occur.

> The bug can be reproduced with system test written using `Group` and `Shape` which is very similar to `TabPaneHeaderLeakTest` test. but it seems the bug is not reproducible with unit test. I tried a unit test very similar to the newly added system test `ShapeViewOrderLeakTest`, but looks like `Parent.viewOrderChildren` list does not get populated and so the issue does not occur.

Did you run a pulse? That would be needed in order to sync the changes down to the peer. In any event, it is fine to use a system test if you can't get it to fail with a unit test.

I have three cleanup comments that are apply to both of the new tests. The first is the most important of these.

1. Test classes should not extend from `javafx.application.Application`. You should use a nested class that extends Application. See [this comment on PR #34](https://github.com/openjdk/jfx/pull/34#pullrequestreview-322619657) for at least one reason why.

2. The initFX method can be simplified using a pattern we've adopted in our newer tests. See [QuadraticCssTimeTest.java](https://github.com/openjdk/jfx/blob/jfx14/tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java#L84)

3. Most tests run `startupLatch::countDown` in a `Platform.runLater` call.

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

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

From tsayao at openjdk.java.net  Thu Jan 23 01:06:09 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 23 Jan 2020 01:06:09 GMT
Subject: [Rev 13] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <G3ux8WflY8pdHu6GC3Uxi3ciqpLFFr4kVK-4DAyYGw4=.ab4558d1-28f0-4bb2-b70a-1a09881de05b@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code.
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - cb2d9fb6: Work on mouse grab

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/2bfac077..cb2d9fb6

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.13
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.12-13

  Stats: 27 lines in 2 files changed: 17 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From ajoseph at openjdk.java.net  Thu Jan 23 02:25:24 2020
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Thu, 23 Jan 2020 02:25:24 GMT
Subject: RFR: 8233942: Update to 609.1 version of WebKit
In-Reply-To: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
References: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
Message-ID: <otopWwiDRqtbhPHI1g2EdmPch1p9R4TSJ-fgIR26YMQ=.4728d96a-334a-4d3f-9cde-c67beeb62ddb@github.com>

On Mon, 20 Jan 2020 16:39:15 GMT, Guru Hb <ghb at openjdk.org> wrote:

> Updated GTK Webkit 2.26 (609.1) into jfx.

Marked as reviewed by ajoseph (Author).

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

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

From arapte at openjdk.java.net  Thu Jan 23 12:46:05 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 23 Jan 2020 12:46:05 GMT
Subject: [Rev 02] RFR: 8232824: Removing TabPane with strong referenced
 content causes memory leak from weak one
In-Reply-To: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
Message-ID: <EZipNaeszEZaxzDogVu1z6kHV-7Id0ey5Tmbm7TerQs=.3c1da96f-d789-4a28-8d59-70ea025e84c8@github.com>

> This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
> This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).
> 
> Issue.
> - `Parent.viewOrderChildren` is a list of children sorted according to view order.
> - `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.
> 
> - Below is the scenario mentioned in this issue,
> 1. `TabPane` is created with few `tabs`.
> 2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
> 3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
> 4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
> So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.
> 
> Fix:
> Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
> `Parent.viewOrderChildren` will be computed on next `pulse`.
> This will maintain lazy computation of `Parent.viewOrderChildren`. 
> 
> Added a system test, fails without fix and passes with. No failures in existing tests.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 7c204691: Fixed review comments

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/79/files
  - new: https://git.openjdk.java.net/jfx/pull/79/files/d64f6c86..7c204691

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

  Stats: 61 lines in 2 files changed: 6 ins; 10 del; 45 mod
  Patch: https://git.openjdk.java.net/jfx/pull/79.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/79/head:pull/79

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

From arapte at openjdk.java.net  Thu Jan 23 12:46:06 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 23 Jan 2020 12:46:06 GMT
Subject: RFR: 8232824: Removing TabPane with strong referenced content
 causes memory leak from weak one
In-Reply-To: <VDPS1HUmLLfEVgCjBpeOPSfMQzZNMAKRUVQ4I86akz4=.b817ea68-7d75-41b8-875d-fd9ba151d010@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <jdcrnN6s5B9jU-7Ezv2wbrjXgqH-xqO-nOZtsLjajeA=.4542d3dc-b86a-4c4e-90c8-450d6d737cd7@github.com>
 <YWrwLQ4ciC1Vj1orxWh38PqZuZg2uJBxZZGml0UtyF8=.748803b3-0297-424d-88a1-9ecff324bea4@github.com>
 <SqRVa5K3OG5_J7Jr008FlEdvsHT0mQpO2n_tM6l1hww=.0ba849dc-aa8b-40ea-9983-d166f7918d50@github.com>
 <j1IXcdF74HRQLt-vsMhHDWQHElfKaK9unX7-6O1ugno=.84fb6cb4-a897-4d06-8848-e2bdf0155b25@github.com>
 <W9xY8M-hGxOS6kUI9DLyinTSrEooYw3VTSOEWqkoQtk=.3b54a38e-32f3-433a-a6f0-98fc8c05250e@github.com>
 <VDPS1HUmLLfEVgCjBpeOPSfMQzZNMAKRUVQ4I86akz4=.b817ea68-7d75-41b8-875d-fd9ba151d010@github.com>
Message-ID: <lSVjubuQ7KDO57acr1jbtBzbnLqh5v_3jigezY5CX14=.812b9f5c-8381-47ba-b00b-df6336848c54@github.com>

On Wed, 22 Jan 2020 23:58:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> 
>>> 
>>> The fix looks good. I'll take a closer look at the unit test later.
>>> 
>>> Speaking of tests...since the addition of the `TabPane` reordering logic was a victim of the already-existing leak in the `viewOrderChildren` list in `Parent`, it should be possible to write a test case using a Group node and a few Shape nodes, using setViewOrder directly on the Group node (this would be in addition to the system test you wrote). Can you take a look at adding one? It might even be possible to do it as a `javafx.graphics` module unit test rather than a system test, although you would need to see if the bug reproduced there (I suspect it will).
>> 
>> Hello Kevin,
>> The bug can be reproduced with system test written using `Group` and `Shape` which is very similar to `TabPaneHeaderLeakTest` test. but it seems the bug is not reproducible with unit test. I tried a unit test very similar to the newly added system test `ShapeViewOrderLeakTest`, but looks like `Parent.viewOrderChildren` list does not get populated and so the issue does not occur.
> 
>> The bug can be reproduced with system test written using `Group` and `Shape` which is very similar to `TabPaneHeaderLeakTest` test. but it seems the bug is not reproducible with unit test. I tried a unit test very similar to the newly added system test `ShapeViewOrderLeakTest`, but looks like `Parent.viewOrderChildren` list does not get populated and so the issue does not occur.
> 
> Did you run a pulse? That would be needed in order to sync the changes down to the peer. In any event, it is fine to use a system test if you can't get it to fail with a unit test.
> 
> I have three cleanup comments that apply to both of the new tests. The first is the most important of these.
> 
> 1. Test classes should not extend from `javafx.application.Application`. You should use a nested class that extends Application. See [this comment on PR #34](https://github.com/openjdk/jfx/pull/34#pullrequestreview-322619657) for at least one reason why.
> 
> 2. The initFX method can be simplified using a pattern we've adopted in our newer tests. See [QuadraticCssTimeTest.java](https://github.com/openjdk/jfx/blob/jfx14/tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java#L84)
> 
> 3. Most tests run `startupLatch::countDown` in a `Platform.runLater` call.

> Did you run a pulse? That would be needed in order to sync the changes down to the peer. In any event, it is fine to use a system test if you can't get it to fail with a unit test.
> 

Yes Kevin, I had tried using `Toolkit.getToolkit().firePulse();`. But the test did not fail without fix.
I am not sure if I am missing anything with unit test, Ideally it should reproduce with unit test too.

Have updated the PR to fix the other review comments.

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

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

From tsayao at openjdk.java.net  Thu Jan 23 12:51:24 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 23 Jan 2020 12:51:24 GMT
Subject: [Rev 14] RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <dSirZpgjn001Uaiwhpkn35JPLfxojixEkcOQu3_RE6E=.a52a5498-06fb-4c70-a4aa-b23988ba4248@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases) ;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing;
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code;
> - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491;
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> ![image](https://user-images.githubusercontent.com/30704286/71791073-58779d00-3012-11ea-89e5-07588f7a41cc.png)

The pull request has been updated with a new target base due to a merge or a rebase.

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

Commits:
 - 694641f6: JDK-8236651 Simplify and update glass gtk backend
 - 9397a748: Merge pull request #4 from openjdk/master

Changes: https://git.openjdk.java.net/jfx/pull/77/files
 Webrev: https://webrevs.openjdk.java.net/jfx/77/webrev.14
  Stats: 3361 lines in 12 files changed: 777 ins; 1802 del; 782 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From kcr at openjdk.java.net  Thu Jan 23 12:52:00 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 23 Jan 2020 12:52:00 GMT
Subject: [Rev 02] RFR: 8232824: Removing TabPane with strong referenced
 content causes memory leak from weak one
In-Reply-To: <EZipNaeszEZaxzDogVu1z6kHV-7Id0ey5Tmbm7TerQs=.3c1da96f-d789-4a28-8d59-70ea025e84c8@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <EZipNaeszEZaxzDogVu1z6kHV-7Id0ey5Tmbm7TerQs=.3c1da96f-d789-4a28-8d59-70ea025e84c8@github.com>
Message-ID: <2Y5QNeY4sMG6Y3FWMI14RxXQcnCT311CAZx4gf1irrI=.8c21fe31-b92d-403d-80f4-ddf03c881dc8@github.com>

On Thu, 23 Jan 2020 12:51:59 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
>> This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).
>> 
>> Issue.
>> - `Parent.viewOrderChildren` is a list of children sorted according to view order.
>> - `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.
>> 
>> - Below is the scenario mentioned in this issue,
>> 1. `TabPane` is created with few `tabs`.
>> 2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
>> 3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
>> 4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
>> So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.
>> 
>> Fix:
>> Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
>> `Parent.viewOrderChildren` will be computed on next `pulse`.
>> This will maintain lazy computation of `Parent.viewOrderChildren`. 
>> 
>> Added a system test, fails without fix and passes with. No failures in existing tests.
> 
> The pull request has been updated with 1 additional commit.

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From jpereda at openjdk.java.net  Thu Jan 23 13:11:52 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Thu, 23 Jan 2020 13:11:52 GMT
Subject: RFR: 8157224: isNPOTSupported check is too strict
Message-ID: <ZXEdw9ECDOGQx2sK1qsLiPlaNQYemOEvOJJejz8dvG4=.935bc7a3-295e-4162-9ab1-51c688f1619c@github.com>

This PR enables support for 3D on iOS devices, as they use OpenGL ES 2.0, which has (limited) support for npot support.

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

Commits:
 - 1bef8cf6: Enable 3D support on iOS

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

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

From kcr at openjdk.java.net  Thu Jan 23 13:16:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 23 Jan 2020 13:16:06 GMT
Subject: RFR: 8157224: isNPOTSupported check is too strict
In-Reply-To: <ZXEdw9ECDOGQx2sK1qsLiPlaNQYemOEvOJJejz8dvG4=.935bc7a3-295e-4162-9ab1-51c688f1619c@github.com>
References: <ZXEdw9ECDOGQx2sK1qsLiPlaNQYemOEvOJJejz8dvG4=.935bc7a3-295e-4162-9ab1-51c688f1619c@github.com>
Message-ID: <oXbj87NqEWFY0BjSFafF6bi4D5cSkIBkepv808xlCaI=.1be7788a-7034-41e1-b3c1-8a13d32ff779@github.com>

On Thu, 23 Jan 2020 13:02:42 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR enables support for 3D on iOS devices, as they use OpenGL ES 2.0, which has (limited) support for npot support.

Marked as reviewed by kcr (Lead).

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

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

From thiago.sayao at clamed.com.br  Thu Jan 23 13:30:01 2020
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Thu, 23 Jan 2020 13:30:01 +0000
Subject: Machine hangs when build with -PCOMPILE_WEBKIT=true
Message-ID: <CP2P15201MB2228EB60A929AFDD04B065D6DE0F0@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

Hi,

I have tried on different machines - they totally hang or present a fatal compiler error when compiling webkit.

Sometimes (rarely) it works.

This is on Ubuntu 18.04.3.

Anyone has got this problem and found a solution?

Cheers.

From tsayao at openjdk.java.net  Thu Jan 23 14:17:02 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 23 Jan 2020 14:17:02 GMT
Subject: RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <DQhahySKkmtA9PENyqEI6bpVxfJGjQHr9eEcOc0cHP8=.83ebd7d3-5f6f-4da7-a610-2678223446c4@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
 <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
 <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>
 <RTNlL4YgDTkU1J2hxEldvHgLAHAYTBNcAR4OdIGS9vI=.b219fd7a-1f0a-4bcb-9d31-8b2b8b18bc15@github.com>
 <DQhahySKkmtA9PENyqEI6bpVxfJGjQHr9eEcOc0cHP8=.83ebd7d3-5f6f-4da7-a610-2678223446c4@github.com>
Message-ID: <Wzhzx22aR7zQaYtrCfRCVB8R9k3HbkRbPgD_ZjKQpHo=.1b8d7f79-487a-475b-bbd6-6972b82fa7dd@github.com>

On Tue, 14 Jan 2020 11:30:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> I understand. Will do that when the code works 100%. I have submitted the PR to avoid duplicated efforts and let people test it (if anyone is willing).
> 
> Sizing and positioning completed and fairly tested.
> 
> Will look into mouse grabbing.

Performance test (on my setup, it runs slightly faster with this patch):

import javafx.application.Application;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.stage.Stage;

import java.time.Duration;
import java.time.Instant;
import java.util.Timer;
import java.util.TimerTask;

public class HelloFx extends Application {

    public HelloFx() {
    }

    @Override
    public void start(Stage stage) {
        Instant start = Instant.now();

        Scene mainScene = new Scene(new Label("Perfomance test"), 600, 600);
        stage.setScene(mainScene);
        stage.show();

        for (int i=0; i<1000; i++) {
            Stage stage1 = new Stage();
            Scene scene = new Scene(new Label("hi"), 200, 200);
            stage1.setScene(scene);

            stage1.setOnShown(e -> new Timer().schedule(
                    new TimerTask() {
                        @Override
                        public void run() {
                            Platform.runLater(stage1::hide);
                        }
                    },
                    100
            ));

            stage1.showAndWait();
        }

        stage.close();

        Instant end = Instant.now();

        System.out.println(Duration.between(start, end).toString()
                .substring(2)
                .replaceAll("(\\d[HMS])(?!$)", "$1 ")
                .toLowerCase());

        Platform.exit();
    }
}

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

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

From kcr at openjdk.java.net  Thu Jan 23 14:37:41 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 23 Jan 2020 14:37:41 GMT
Subject: [Integrated] RFR: 8157224: isNPOTSupported check is too strict
In-Reply-To: <ZXEdw9ECDOGQx2sK1qsLiPlaNQYemOEvOJJejz8dvG4=.935bc7a3-295e-4162-9ab1-51c688f1619c@github.com>
References: <ZXEdw9ECDOGQx2sK1qsLiPlaNQYemOEvOJJejz8dvG4=.935bc7a3-295e-4162-9ab1-51c688f1619c@github.com>
Message-ID: <c8f86d39-31e1-49bb-afd7-358a911816b4@openjdk.org>

Changeset: f5ee9631
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-23 14:36:36 +0000
URL:       https://git.openjdk.java.net/jfx/commit/f5ee9631

8157224: isNPOTSupported check is too strict

Reviewed-by: kcr

! modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Pipeline.java

From anthonyv.be at outlook.com  Thu Jan 23 17:09:43 2020
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Thu, 23 Jan 2020 18:09:43 +0100
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
 <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
 <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
Message-ID: <AM0PR07MB6372F3BA13060B97A8E4FACBE80F0@AM0PR07MB6372.eurprd07.prod.outlook.com>


On 22/01/2020 18:52, Rony G. Flatscher wrote:
> Hi Anthony,
>
> On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
>> Your issue has been converted into a JDK issue, with your testcase 
>> attached [1].
>
> Thank you *very* much for this information!
>
>> Normally you should?ve received an e-mail at the time of this 
>> conversion,
>
> Just searched all my e-mail folders and could not find it (looking for 
> "FXMLLoader" in the subject of e-mails as the bug title contains that 
> word) but could not find a matching e-mail for whatever reasons.
>
>> but you can check this yourself by using the internal review ID as in 
>> [2]. If you?d like to contribute a fix, see [3].
>>
>> Kind regards, Anthony
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8234959 
>> <https://bugs.openjdk.java.net/browse/JDK-8234959>
>>
>> [2] https://bugs.openjdk.java.net/browse/JI-9062887 
>> <https://bugs.openjdk.java.net/browse/JI-9062887>
>>
>> [3] https://github.com/openjdk/jfx <https://github.com/openjdk/jfx>
>>
> Thank you also for these links (and I learned something new on how to 
> check for it using the internal review id with your [2], thanks a lot 
> for this hint as well)!
>
> Will go back and study all the necessary procedures (forgot a lot 
> since reading them the last time) and will try to contribute the fix 
> in the proper way but it may take me a little while (currently quite 
> busy around here).
>
> ---
>
> Maybe one more question: there would be an optimization possible by 
> compiling scripts for script engines that have the 
> javax.script.Compilable interface implemented and use the compiled 
> version to execute/evaluate the scripts (may be helpful for event 
> handler code e.g. for onMouseMove event handlers). Can the fix include 
> such an optimization or should there be a separate discussion/RFE for 
> it beforehand? (Adding this would be trivial in the context of the 
> fix, however the bug description would not hint at such an optimization.)
>
In my opinion, this should be filed as a separate issue, since it's 
unrelated to the current issue and is an enhancement, rather than a bug.
>
> ---rony
>
>
Kind regards, Anthony

From ghb at openjdk.java.net  Thu Jan 23 18:53:35 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Thu, 23 Jan 2020 18:53:35 GMT
Subject: [Integrated] RFR: 8233942: Update to 609.1 version of WebKit
In-Reply-To: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
References: <v4QXDwSeW8SOIS_2dtncmZKzbyDTBslWnHm1MR09mpo=.3b896740-46c6-4b10-a3a0-8fec53354bc5@github.com>
Message-ID: <0eb0e3fb-c938-442e-82f6-554924e8a3f3@openjdk.org>

Changeset: b2d85645
Author:    Guru Hb <ghb at openjdk.org>
Date:      2020-01-23 18:52:57 +0000
URL:       https://git.openjdk.java.net/jfx/commit/b2d85645

8233942: Update to 609.1 version of WebKit

Co-authored-by: Guru HB <guru.hb at oracle.com>
Co-authored-by: Arun Joseph <arun.aj.joseph at oracle.com>
Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
Reviewed-by: kcr, jvos, ajoseph

! modules/javafx.web/src/main/legal/webkit.md
! modules/javafx.web/src/main/native/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/APICast.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSAPIGlobalObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSBase.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSBaseInternal.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSBasePrivate.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSCallbackConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSCallbackObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSCallbackObjectFunctions.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSClassRef.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSClassRef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSContext.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSContextPrivate.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSContextRef.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSContextRef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSContextRefInternal.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSContextRefPrivate.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSManagedValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSObjectRef.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSObjectRef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSObjectRefPrivate.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSRemoteInspector.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSScript.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSScriptInternal.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSScriptRef.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSScriptSourceProvider.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSStringRef.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSTypedArray.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSValuePrivate.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSValueRef.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSValueRef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSVirtualMachineInternal.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSVirtualMachinePrivate.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/OpaqueJSString.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/API/WebKitAvailability.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/JavaScriptCore/DerivedSources-input.xcfilelist
! modules/javafx.web/src/main/native/Source/JavaScriptCore/DerivedSources-output.xcfilelist
! modules/javafx.web/src/main/native/Source/JavaScriptCore/DerivedSources.make
- modules/javafx.web/src/main/native/Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd
! modules/javafx.web/src/main/native/Source/JavaScriptCore/KeywordLookupGenerator.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/PlatformJava.cmake
- modules/javafx.web/src/main/native/Source/JavaScriptCore/PlatformPlayStation.cmake
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Scripts/check-xcfilelists.sh
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Scripts/jsmin.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Scripts/make-js-file-arrays.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_combined_header.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_wrapper_header.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Scripts/wkbuiltins/builtins_templates.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/Sources.txt
! modules/javafx.web/src/main/native/Source/JavaScriptCore/SourcesGTK.txt
! modules/javafx.web/src/main/native/Source/JavaScriptCore/SourcesWPE.txt
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64EAssembler.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Registers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARMv7Assembler.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARMv7Registers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/AbortReason.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/AbstractMacroAssembler.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/CPU.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/CPU.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/CodeLocation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/LinkBuffer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/LinkBuffer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MIPSAssembler.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MIPSRegisters.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerX86.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerX86Common.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerX86_64.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ProbeStack.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/RegisterInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/X86Assembler.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/X86Registers.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/X86_64Registers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/testmasm.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ArgumentRegValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ArgumentRegValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3AtomicValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3AtomicValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Bank.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3BasicBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3BasicBlockInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3BlockInsertionSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3CCallValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3CCallValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3CheckValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3CheckValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Common.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Common.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Const32Value.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Const32Value.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Const64Value.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Const64Value.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ConstDoubleValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ConstDoubleValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ConstFloatValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ConstFloatValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ConstPtrValue.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3EliminateDeadCode.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3EliminateDeadCode.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ExtractValue.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ExtractValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3FenceValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3FenceValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3FixSSA.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Generate.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3LowerMacros.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3LowerMacrosAfterOptimizations.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3LowerToAir.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3MemoryValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3MemoryValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3MoveConstants.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3NativeTraits.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Opcode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Opcode.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3OptimizeAssociativeExpressionTrees.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3OptimizeAssociativeExpressionTrees.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3PatchpointSpecial.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3PatchpointValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3PatchpointValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3PhiChildren.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Procedure.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Procedure.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ProcedureInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3PureCSE.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3PureCSE.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ReduceLoopStrength.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ReduceLoopStrength.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ReduceStrength.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3SlotBaseValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3SlotBaseValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3StackmapSpecial.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3StackmapSpecial.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3StackmapValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3StackmapValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3SwitchValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3SwitchValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Type.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Type.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3TypeMap.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3UpsilonValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3UpsilonValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3UseCounts.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Validate.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Value.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Value.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ValueInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ValueKey.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ValueKey.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ValueRep.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3ValueRep.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3VariableValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3VariableValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3WasmAddressValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3WasmAddressValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3Width.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirAllocateRegistersByGraphColoring.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirArg.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirArg.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirCCallingConvention.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirCode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirDisassembler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirGenerate.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirHandleCalleeSaves.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirHandleCalleeSaves.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirLowerMacros.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/AirOpcode.opcodes
! modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/air/testair.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_1.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_2.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_3.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_4.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_5.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_6.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_7.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/testb3_8.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bindings/ScriptFunctionCall.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bindings/ScriptValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/ArrayPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/AsyncFromSyncIteratorPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/AsyncGeneratorPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/BuiltinExecutables.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/BuiltinExecutables.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/BuiltinNames.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/BuiltinNames.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/GlobalOperations.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/MapPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/ModuleLoader.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/PromiseConstructor.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/PromiseOperations.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/PromisePrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/RegExpPrototype.js
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/RegExpStringIteratorPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/SetPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/StringPrototype.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/TypedArrayPrototype.js
= modules/javafx.web/src/main/native/Source/JavaScriptCore/builtins/WebAssembly.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/AccessCase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/AccessCaseSnippetParams.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/AccessCaseSnippetParams.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/AdaptiveInferredPropertyValueWatchpointBase.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArrayAllocationProfile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArrayAllocationProfile.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArrayProfile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArrayProfile.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ByValInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeBasicBlock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeConventions.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeDumper.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeDumper.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeIntrinsicRegistry.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeIntrinsicRegistry.h
- modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeList.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeList.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeRewriter.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeRewriter.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/BytecodeUseDef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CallLinkInfo.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CallLinkInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CallLinkStatus.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CallLinkStatus.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CallVariant.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CallVariant.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeBlock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeBlockInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeBlockJettisoningWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeBlockWithJITType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeOrigin.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/CodeOrigin.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/DFGExitProfile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/DataFormat.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/DeferredCompilationCallback.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/DeferredSourceDump.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/DeferredSourceDump.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/EvalCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ExecutableToCodeBlockEdge.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ExecutionCounter.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ExecutionCounter.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ExitFlag.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ExitingJITType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Fits.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/FunctionCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GetByIdMetadata.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GetByIdStatus.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GetByIdStatus.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GetByIdVariant.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GetByIdVariant.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GetterSetterAccessCase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/GlobalCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ICStatusMap.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ICStatusUtils.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InByIdStatus.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InByIdStatus.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InByIdVariant.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InByIdVariant.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InlineCallFrame.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InlineCallFrame.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InstanceOfAccessCase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InstanceOfStatus.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InstanceOfVariant.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Instruction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InstructionStream.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/IntrinsicGetterAccessCase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/JumpTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/LLIntCallLinkInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/LazyOperandValueProfile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/LazyOperandValueProfile.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/MetadataTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/MetadataTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ModuleNamespaceAccessCase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ModuleProgramCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ObjectAllocationProfile.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ObjectPropertyCondition.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ObjectPropertyCondition.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Opcode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Opcode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/OpcodeSize.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Operands.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PolyProtoAccessChain.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PolyProtoAccessChain.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PolymorphicAccess.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PreciseJumpTargetsInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ProgramCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PropertyCondition.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PropertyCondition.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ProxyableAccessCase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PutByIdStatus.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PutByIdStatus.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PutByIdVariant.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/PutByIdVariant.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/RecordedStatuses.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/RecordedStatuses.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/SpeculatedType.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/SpeculatedType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/StructureSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/StructureSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/StructureStubInfo.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/StructureStubInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/TypeLocation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedEvalCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedFunctionCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedModuleProgramCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/UnlinkedProgramCodeBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ValueProfile.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ValueRecovery.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/VirtualRegister.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Watchpoint.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/Watchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/config.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/debugger/Breakpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/debugger/Debugger.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/debugger/Debugger.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/debugger/DebuggerParseData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/debugger/DebuggerParseData.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/debugger/DebuggerScope.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAbstractInterpreter.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAbstractValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAbstractValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGAdjacencyList.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGArgumentsUtilities.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGArrayMode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGBasicBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCFAPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCSEPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCapabilities.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCapabilities.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGClobberize.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGClobbersExitState.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCommon.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGCommonData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGDesiredIdentifiers.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGDesiredWatchpoints.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGDesiredWatchpoints.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGDisassembler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGDoesGC.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGDriver.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGFlowIndexing.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGFlowMap.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGForAllKills.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGFrozenValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGGenerationInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGGraph.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGGraph.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGInPlaceAbstractState.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGIntegerCheckCombiningPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGJITCode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGJITCode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGJITCompiler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGJITCompiler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGJITFinalizer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGLICMPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGLazyJSValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGLiveCatchVariablePreservationPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGLivenessAnalysisPhase.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMaximalFlushInsertionPhase.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMaximalFlushInsertionPhase.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMayExit.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMinifiedID.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMinifiedIDInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGMinifiedNode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGNode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGNode.h
- modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGNodeAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGNodeType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRAvailabilityAnalysisPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRAvailabilityAnalysisPhase.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSREntry.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSREntrypointCreationPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRExit.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRExit.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRExitBase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOSRExitPreparation.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOperations.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGOperations.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPhantomInsertionPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPhase.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPlan.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPlan.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPreciseLocalClobberize.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPredictionPropagationPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPureValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGPureValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGRegisteredStructureSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSSAConversionPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSafeToExecute.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGStoreBarrierClusteringPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGStructureAbstractValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGThunks.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGThunks.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGTierUpCheckInjectionPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGTypeCheckHoistingPhase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGUseKind.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGValidate.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGValueRepReductionPhase.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGValueRepReductionPhase.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGValueSource.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGVariableAccessData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGVariableAccessData.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGVariableEvent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGVariableEventStream.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGWorklist.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGWorklist.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/testdfg.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/disassembler/ARM64/A64DOpcode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/disassembler/ARM64/A64DOpcode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/disassembler/Disassembler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/domjit/DOMJITSignature.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/dynbench.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLAbbreviatedTypes.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLAbstractHeap.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLAbstractHeapRepository.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLAbstractHeapRepository.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLCapabilities.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLCompile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLExitValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLExitValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLFail.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLJITCode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLJITFinalizer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLLink.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLOSREntry.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLOperations.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLOutput.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLState.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLThunks.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/ftl/FTLThunks.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/generator/Argument.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/generator/DSL.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/generator/Metadata.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/generator/Opcode.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/generator/Section.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/AlignedMemoryAllocator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/AlignedMemoryAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/BlockDirectory.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/CellContainer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/CellContainerInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/CompleteSubspace.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/CompleteSubspace.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/ConservativeRoots.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/FastMallocAlignedMemoryAllocator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/FastMallocAlignedMemoryAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/FreeList.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCActivityCallback.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCAssertions.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCIncomingRefCounted.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCIncomingRefCountedInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCIncomingRefCountedSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCIncomingRefCountedSetInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GCSegmentedArray.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GigacageAlignedMemoryAllocator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/GigacageAlignedMemoryAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HandleSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HandleSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/Heap.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/Heap.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapAnalyzer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapCell.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapCellInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapProfiler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapProfiler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapSnapshot.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapSnapshot.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapSnapshotBuilder.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/HeapSnapshotBuilder.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/IsoAlignedMemoryAllocator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/IsoAlignedMemoryAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/IsoCellSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/IsoSubspace.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/IsoSubspace.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/IsoSubspacePerVM.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/JITStubRoutineSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/JITStubRoutineSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/LargeAllocation.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/LargeAllocation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/LocalAllocator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/LocalAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/LocalAllocatorInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MachineStackMarker.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkedBlock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkedBlock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkedBlockInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkedSpace.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkedSpace.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkingConstraintSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkingConstraintSolver.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/MarkingConstraintSolver.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/PackedCellPtr.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/SlotVisitor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/SlotVisitor.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/SlotVisitorInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/StopIfNecessaryTimer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/StopIfNecessaryTimer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/Strong.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/WeakBlock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/heap/WeakSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/AsyncStackTrace.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ConsoleMessage.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ConsoleMessage.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ContentSearchUtilities.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScript.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScript.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScriptBase.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScriptHost.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScriptManager.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScriptManager.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScriptModule.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InjectedScriptSource.js
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InspectorBackendDispatcher.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InspectorBackendDispatcher.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/InspectorBackendDispatcherCompatibility.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSGlobalObjectConsoleClient.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSGlobalObjectConsoleClient.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSGlobalObjectInspectorController.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSGlobalObjectInspectorController.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSInjectedScriptHost.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSInjectedScriptHost.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSInjectedScriptHostPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSJavaScriptCallFrame.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/JSJavaScriptCallFramePrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ScriptArguments.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ScriptArguments.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ScriptCallStackFactory.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ScriptDebugListener.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ScriptDebugServer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/ScriptDebugServer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorAuditAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorAuditAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorHeapAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorHeapAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorRuntimeAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorRuntimeAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorScriptProfilerAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorScriptProfilerAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorTargetAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/InspectorTargetAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/JSGlobalObjectAuditAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/JSGlobalObjectAuditAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/JSGlobalObjectDebuggerAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/JSGlobalObjectDebuggerAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/JSGlobalObjectRuntimeAgent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/agents/JSGlobalObjectRuntimeAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Audit.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/CPUProfiler.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/CSS.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Canvas.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Console.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/DOM.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Debugger.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Memory.json
- modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Page.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Recording.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Runtime.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/ScriptProfiler.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/protocol/Timeline.json
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/remote/RemoteControllableTarget.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/remote/RemoteInspector.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/remote/RemoteInspector.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/remote/RemoteInspectorConstants.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/scripts/codegen/cpp_generator_templates.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/scripts/codegen/generate_objc_header.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/scripts/codegen/generator.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/scripts/codegen/objc_generator_templates.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/inspector/scripts/generate-inspector-protocol-bindings.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/CLoopStack.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/CallFrame.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/CallFrame.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/CallFrameInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/FrameTracers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/Interpreter.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/StackVisitor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/interpreter/StackVisitor.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/AssemblyHelpers.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/AssemblyHelpers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/BinarySwitch.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/BinarySwitch.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/CCallHelpers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/CachedRecovery.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/CallFrameShuffleData.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/CallFrameShuffler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ExecutableAllocator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ExecutableAllocator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/GPRInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ICStats.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ICStats.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/IntrinsicEmitter.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JIT.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JIT.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITArithmetic.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITCall.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITCall32_64.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITCode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITCode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITDisassembler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITDivGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITExceptions.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITExceptions.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITInlineCacheGenerator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITMathIC.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITOpcodes.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITOpcodes32_64.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITOperations.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITOperations.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITPropertyAccess.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITThunks.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITThunks.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITToDFGDeferredCompilationCallback.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JITWorklist.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/JSInterfaceJIT.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/PCToCodeOriginMap.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/PCToCodeOriginMap.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/RegisterSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/RegisterSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/Repatch.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/Repatch.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/SnippetOperand.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/SpecializedThunkJIT.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/SpillRegistersMode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ThunkGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ThunkGenerators.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/ThunkGenerators.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/jsc.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntData.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntEntrypoint.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntEntrypoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntOfflineAsmConfig.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntSlowPaths.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntThunks.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntThunks.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm
! modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/arm.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/arm64.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/asm.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/ast.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/backends.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/cloop.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/instructions.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/mips.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/registers.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/x86.rb
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ASTBuilder.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/Lexer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/Lexer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ModuleAnalyzer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ModuleAnalyzer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/NodeConstructors.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/Nodes.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/Nodes.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/Parser.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/Parser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ParserArena.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ParserError.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ParserModes.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ParserTokens.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/ResultType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/SourceCode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/SourceCodeKey.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/SourceProvider.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/SyntaxChecker.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/UnlinkedSourceCode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/VariableEnvironment.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/parser/VariableEnvironment.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerBytecode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerBytecodeSequence.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerBytecodes.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerCompilation.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerCompilation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerCompiledBytecode.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerEvent.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerOSRExit.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerOSRExit.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerOSRExitSite.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerOriginStack.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerOriginStack.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/profiler/ProfilerUID.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AbstractModuleRecord.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AbstractModuleRecord.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBuffer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBuffer.h
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpointSet.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpointSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBufferView.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayBufferView.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayConstructor.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayIteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ArrayPrototype.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncFromSyncIteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncFunctionConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncFunctionPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncGeneratorFunctionConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncGeneratorFunctionPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncGeneratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AsyncIteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/AtomicsObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BasicBlockLocation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BigIntConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BigIntPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BooleanConstructor.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BundlePath.mm
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Butterfly.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ButterflyInlines.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BytecodeCacheError.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/BytecodeCacheError.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CachePayload.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CachePayload.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CacheUpdate.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CacheUpdate.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CachedBytecode.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CachedBytecode.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CachedTypes.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CachedTypes.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CagedBarrierPtr.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CatchScope.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ClassInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ClonedArguments.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CodeCache.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CodeCache.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CodeSpecializationKind.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CommonIdentifiers.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CommonIdentifiers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CommonSlowPaths.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/CommonSlowPaths.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Completion.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Completion.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ConfigFile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ConsoleClient.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ConsoleObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ConsoleTypes.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ConstructData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DataView.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DataView.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DateConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DateConversion.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DatePrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DirectArguments.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DirectArguments.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DirectEvalExecutable.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DoublePredictionFuzzerAgent.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/DoublePredictionFuzzerAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Error.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Error.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ErrorConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ErrorInstance.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ErrorInstance.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ErrorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ErrorType.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/EvalExecutable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/EvalExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Exception.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Exception.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ExceptionHelpers.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ExceptionHelpers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ExceptionScope.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionExecutable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionExecutableDump.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionExecutableInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionPrototype.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionRareData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FunctionRareData.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FuzzerAgent.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/FuzzerAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GeneratorFunctionConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GeneratorFunctionPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GeneratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GenericArguments.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GenericArgumentsInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GenericTypedArrayView.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GenericTypedArrayViewInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GetterSetter.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GlobalExecutable.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/GlobalExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/HashMapImpl.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Identifier.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Identifier.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IdentifierInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IndexingType.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IndirectEvalExecutable.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/InferredValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/InferredValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/InferredValueInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/InitializeThreading.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/InternalFunction.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/InternalFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlCollator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlCollator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlCollatorConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlCollatorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlDateTimeFormat.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlDateTimeFormat.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlDateTimeFormatConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlNumberFormat.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlNumberFormat.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlNumberFormatConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlPluralRules.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlPluralRulesConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IntlPluralRulesPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/IteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArray.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArray.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArrayBufferConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArrayBufferPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArrayBufferPrototype.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArrayBufferView.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArrayBufferView.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSArrayInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSAsyncFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSAsyncGeneratorFunction.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSAsyncGeneratorFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSBigInt.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSBigInt.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCJSValue.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCJSValue.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCJSValueInlines.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCPtrTag.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCPtrTag.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCast.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCell.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCell.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCellInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSDataViewPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSDateMath.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSFixedArray.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSFunction.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSFunctionInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGeneratorFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGenericTypedArrayView.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructorInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGlobalObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGlobalObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSGlobalObjectInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSImmutableButterfly.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSImmutableButterfly.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSLexicalEnvironment.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSLexicalEnvironment.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSLock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSLock.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSMicrotask.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSModuleEnvironment.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSModuleLoader.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSModuleLoader.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSModuleNamespaceObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSModuleRecord.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSONObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSObjectInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSPromiseConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSPromisePrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSPropertyNameEnumerator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSPropertyNameEnumerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSRunLoopTimer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSRunLoopTimer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSSegmentedVariableObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSSegmentedVariableObject.h
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSSegmentedVariableObjectHeapCellType.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSSegmentedVariableObjectHeapCellType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSString.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSString.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSStringInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSStringJoiner.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSSymbolTableObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSSymbolTableObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSTemplateObjectDescriptor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSTemplateObjectDescriptor.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSTypeInfo.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSTypedArrayViewConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSTypedArrayViewPrototype.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSWeakObjectRef.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSWeakObjectRef.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/LazyClassStructure.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/LazyProperty.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/LazyPropertyInlines.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/LeafExecutable.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/LeafExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/LiteralParser.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Lookup.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/MapConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/MapIteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/MapPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/MatchResult.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/MathCommon.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/MathObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ModuleProgramExecutable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ModuleProgramExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NativeErrorConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NullGetterFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NullSetterFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NumberConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NumberPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NumericStrings.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ObjectConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ObjectPropertyChangeAdaptiveWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ObjectPrototype.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ObjectToStringAdaptiveStructureWatchpoint.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Operations.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Options.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Options.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ProgramExecutable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ProgramExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PromiseDeferredTimer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PromiseDeferredTimer.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PropertyMapHashTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PropertyName.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PropertyNameArray.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PropertySlot.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/PropertyTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ProxyConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ProxyObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ProxyObject.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ReflectObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExp.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExp.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpCache.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpCache.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpCachedResult.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpCachedResult.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpGlobalData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpKey.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpMatchesArray.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpMatchesArray.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpPrototype.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpStringIteratorPrototype.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RegExpStringIteratorPrototype.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RuntimeType.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/RuntimeType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SamplingProfiler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SamplingProfiler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ScopedArgumentsTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ScopedArgumentsTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ScriptExecutable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ScriptExecutable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SetConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SetIteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SetPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SmallStrings.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SparseArrayValueMap.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StackFrame.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StackFrame.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StrictEvalActivation.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StrictEvalActivation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringIteratorPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringObject.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringObject.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringPrototypeInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StringRecursionChecker.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Structure.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Structure.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureCache.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureCache.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureChain.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureChain.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureIDTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureRareData.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/StructureRareData.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Symbol.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Symbol.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SymbolConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SymbolPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SymbolTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SymbolTable.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SymbolTableInlines.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/SymbolTableOrScopeDepth.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/TestRunnerUtils.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ThrowScope.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/ThrowScope.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/TypeProfiler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/TypeProfiler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/TypeSet.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/TypeSet.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/VM.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/VM.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/VMTraps.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/VMTraps.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/Watchdog.h
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WatchdogMac.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WatchdogNone.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakMapConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakMapImpl.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakMapImplInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakMapPrototype.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakObjectRefConstructor.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakObjectRefConstructor.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakObjectRefPrototype.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakObjectRefPrototype.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakSetConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/WeakSetPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/shell/CMakeLists.txt
- modules/javafx.web/src/main/native/Source/JavaScriptCore/shell/PlatformJSCOnly.cmake
! modules/javafx.web/src/main/native/Source/JavaScriptCore/testRegExp.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/CodeProfile.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/FunctionOverrides.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/FunctionOverrides.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/HeapVerifier.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/JSDollarVM.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/SigillCrashAnalyzer.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/VMInspector.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/tools/VMInspector.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmAirIRGenerator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmB3IRGenerator.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmBBQPlan.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmBBQPlan.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmBBQPlanInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmBinding.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCallee.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCallee.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCalleeRegistry.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCalleeRegistry.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCallingConvention.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCapabilities.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCodeBlock.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCodeBlock.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCompilationMode.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmCompilationMode.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmContext.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmContext.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmContextInlines.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmExceptionType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmFormat.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmFunctionParser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmIndexOrName.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmInstance.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmInstance.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmLimits.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmMemory.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmMemory.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmMemoryInformation.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmMemoryInformation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmModuleInformation.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmModuleParser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmNameSectionParser.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOMGForOSREntryPlan.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOMGForOSREntryPlan.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOMGPlan.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOMGPlan.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOSREntryData.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOperations.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmOperations.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmParser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmSectionParser.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmSectionParser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmSignature.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmSignature.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmStreamingParser.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmStreamingParser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmThunks.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmThunks.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmTierUpCount.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmTierUpCount.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmValidate.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/WasmWorklist.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/generateWasmOpsHeader.py
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSToWasm.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSToWasmICCallee.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSToWasmICCallee.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssembly.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssembly.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyCompileError.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyHelpers.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyLinkError.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyRuntimeError.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyRuntimeError.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WasmToJS.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WasmToJS.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyCompileErrorConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyFunction.h
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyFunctionHeapCellType.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyFunctionHeapCellType.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyInstanceConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyInstancePrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyLinkErrorConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyMemoryConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyMemoryPrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyModuleConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyPrototype.cpp
- modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyPrototype.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyRuntimeErrorConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyTableConstructor.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyTablePrototype.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyToJSCallee.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyToJSCallee.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyWrapperFunction.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/js/WebAssemblyWrapperFunction.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/wasm/wasm.json
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/RegularExpression.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrFlags.cpp
+ modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrFlags.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrInterpreter.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrInterpreter.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrJIT.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrJIT.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrParser.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrPattern.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrPattern.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrSyntaxChecker.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrUnicodeProperties.cpp
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/YarrUnicodeProperties.h
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/create_regex_tables
! modules/javafx.web/src/main/native/Source/JavaScriptCore/yarr/generateYarrUnicodePropertyTables.py
! modules/javafx.web/src/main/native/Source/WTF/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/WTF/Scripts/generate-unified-source-bundles.rb
! modules/javafx.web/src/main/native/Source/WTF/benchmarks/HashSetDFGReplay.cpp
! modules/javafx.web/src/main/native/Source/WTF/benchmarks/LockFairnessTest.cpp
! modules/javafx.web/src/main/native/Source/WTF/benchmarks/LockSpeedTest.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/AggregateLogger.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Assertions.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/Assertions.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Atomics.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/AutodrainedPool.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Bag.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/BitVector.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/BitVector.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Bitmap.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/BlockPtr.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/BloomFilter.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Box.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/BumpPointerAllocator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/WTF/wtf/CPUTime.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CagedPtr.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CagedUniquePtr.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CheckedArithmetic.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CheckedBoolean.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CommaPrinter.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CompactPointerTuple.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CompilationThread.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/CompilationThread.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Compiler.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CompletionHandler.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ConcurrentBuffer.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ConcurrentPtrHashSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ConcurrentVector.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Condition.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CountingLock.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CrossThreadCopier.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CrossThreadQueue.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CrossThreadTask.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CrossThreadTaskHandler.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/CrossThreadTaskHandler.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/CryptographicallyRandomNumber.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/DataMutex.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/DateMath.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/DateMath.h
- modules/javafx.web/src/main/native/Source/WTF/wtf/DeprecatedOptional.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Deque.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Dominators.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/DoublyLinkedList.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/DumbPtrTraits.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/DumbValueTraits.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Expected.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/FastBitVector.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/FastMalloc.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/FeatureDefines.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/FileMetadata.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/FilePrintStream.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/FileSystem.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/FileSystem.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ForbidHeapAllocation.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Forward.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Function.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Gigacage.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/Gigacage.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/GraphNodeWorklist.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/GregorianDateTime.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/HashMap.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/HashSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/HashTable.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/HashTraits.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Hasher.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/HexNumber.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Indenter.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IndexMap.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IndexSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IndexSparseSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IndexedContainerIterator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Insertion.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IsoMalloc.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IsoMallocInlines.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IteratorAdaptors.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/IteratorRange.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/JSONValues.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/KeyValuePair.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ListHashSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Liveness.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Locker.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/LocklessBag.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Logger.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/Logger.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/LoggerHelper.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/LoggingHashID.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MD5.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MachSendRight.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MainThread.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/MainThread.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/MainThreadData.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Markable.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MathExtras.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MediaTime.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/MediaTime.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MemoryFootprint.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MemoryPressureHandler.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/MemoryPressureHandler.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MessageQueue.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MetaAllocator.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/MetaAllocator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/MonotonicTime.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/NaturalLoops.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/NeverDestroyed.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/NoLock.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Noncopyable.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/Nonmovable.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/OSAllocator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ObjectIdentifier.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/OptionSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Optional.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/OrderMaker.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/Packed.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/PackedIntVector.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/PageBlock.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ParallelJobsGeneric.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/ParallelJobsOpenMP.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ParkingLot.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Platform.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformJSCOnly.cmake
! modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformJava.cmake
! modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformPlayStation.cmake
! modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformRegisters.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/PointerPreparations.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/PrintStream.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/PriorityQueue.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/PtrTag.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/PtrTag.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RandomDevice.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Range.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RangeSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RecursableLambda.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RedBlackTree.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/RefCounted.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/RefCounted.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RefCountedLeakCounter.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/ResourceUsage.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RetainPtr.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RunLoop.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/RunLoop.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/RunLoopTimer.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SHA1.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Seconds.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SegmentedVector.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SentinelLinkedList.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SetForScope.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SingleRootGraph.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SinglyLinkedList.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SizeLimits.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/SmallPtrSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SpanningTree.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Spectrum.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StackShot.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StackShotProfiler.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StackStats.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StackTrace.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StdLibExtras.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/StreamBuffer.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SynchronizedFixedQueue.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/SystemTracing.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/TaggedArrayStoragePtr.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ThreadGroup.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ThreadSafeRefCounted.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ThreadSpecific.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Threading.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/Threading.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/ThreadingPrimitives.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/TimeWithDynamicClockType.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/TimingScope.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/TimingScope.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/TinyLRUCache.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/TinyPtrSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/URL.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/URLHash.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/URLHelpers.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/URLHelpers.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/URLParser.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/URLParser.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/UUID.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/UnalignedAccess.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Unexpected.h
- modules/javafx.web/src/main/native/Source/WTF/wtf/UniStdExtras.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/UniStdExtras.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/UniqueRef.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/VMTags.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Variant.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/Vector.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/VectorTraits.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/WTFAssertions.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/WTFSemaphore.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/WallTime.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/WeakHashSet.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/WeakPtr.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/WeakRandom.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/WordLock.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/CPUTimeCocoa.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/FileSystemCocoa.mm
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/MainThreadCocoa.mm
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/MemoryFootprintCocoa.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/NSURLExtras.mm
+ modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/ResourceUsageCocoa.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/SoftLinking.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/bignum-dtoa.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/bignum-dtoa.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/bignum.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/bignum.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/cached-powers.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/cached-powers.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/diy-fp.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/diy-fp.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/double-conversion.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/double-conversion.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/fast-dtoa.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/fast-dtoa.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/fixed-dtoa.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/fixed-dtoa.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/strtod.cc
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/strtod.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/dtoa/utils.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/fuchsia/CPUTimeFuchsia.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/generic/MainThreadGeneric.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/linux/CurrentProcessMemoryStatus.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/linux/MemoryPressureHandlerLinux.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/mac/AppKitCompatibilityDeclarations.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/persistence/PersistentCoders.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/persistence/PersistentCoders.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/posix/FileSystemPOSIX.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/posix/ThreadingPOSIX.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/spi/darwin/SandboxSPI.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/spi/darwin/XPCSPI.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/spi/darwin/dyldSPI.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/ASCIILiteral.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomString.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomString.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomStringHash.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomStringImpl.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomStringImpl.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomStringTable.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomStringTable.h
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicString.cpp
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicString.h
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicStringHash.h
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicStringImpl.cpp
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicStringImpl.h
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicStringTable.cpp
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/AtomicStringTable.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/CString.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/ExternalStringImpl.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/LineBreakIteratorPoolICU.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/NullTextBreakIterator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/OrdinalNumber.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringBuffer.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringBuilder.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringBuilder.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringCommon.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringConcatenate.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringConcatenateNumbers.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringHash.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringHasher.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringImpl.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringImpl.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringOperators.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringView.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/StringView.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/SymbolImpl.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/SymbolRegistry.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/TextBreakIterator.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/TextBreakIterator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/TextPosition.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/TextStream.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/ValueToString.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/WTFString.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/WTFString.h
+ modules/javafx.web/src/main/native/Source/WTF/wtf/text/cf/AtomStringImplCF.cpp
- modules/javafx.web/src/main/native/Source/WTF/wtf/text/cf/AtomicStringImplCF.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/cf/TextBreakIteratorCF.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/cocoa/TextBreakIteratorInternalICUCocoa.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/icu/TextBreakIteratorICU.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/icu/UTextProviderLatin1.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/text/win/WCharStringExtras.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/threads/BinarySemaphore.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/Collator.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/UTF8Conversion.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/UTF8Conversion.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/unix/CPUTimeUnix.cpp
+ modules/javafx.web/src/main/native/Source/WTF/wtf/unix/UniStdExtrasUnix.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/CPUTimeWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/FileSystemWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/GDIObject.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/LanguageWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/MainThreadWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/PathWalker.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/PathWalker.h
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/ThreadSpecificWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/ThreadingWin.cpp
! modules/javafx.web/src/main/native/Source/WTF/wtf/win/Win32Handle.h
! modules/javafx.web/src/main/native/Source/WebCore/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/WebCore/DerivedSources-input.xcfilelist
! modules/javafx.web/src/main/native/Source/WebCore/DerivedSources-output.xcfilelist
! modules/javafx.web/src/main/native/Source/WebCore/DerivedSources.make
+ modules/javafx.web/src/main/native/Source/WebCore/Headers.cmake
! modules/javafx.web/src/main/native/Source/WebCore/Modules/airplay/WebKitPlaybackTargetAvailabilityEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/airplay/WebKitPlaybackTargetAvailabilityEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayPayment.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayPaymentAuthorizedEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayPaymentAuthorizedEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayPaymentMethod.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayPaymentMethodSelectedEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayPaymentMethodSelectedEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayRequestBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayRequestBase.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePaySession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePaySession.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePaySession.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePaySessionPaymentRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayShippingContactSelectedEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayShippingContactSelectedEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayShippingMethodSelectedEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayShippingMethodSelectedEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayValidateMerchantEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/ApplePayValidateMerchantEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentCoordinator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentCoordinator.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentCoordinatorClient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentCoordinatorClient.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentRequestValidator.mm
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentSession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/PaymentSession.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/paymentrequest/ApplePayPaymentHandler.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/applicationmanifest/ApplicationManifestParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/beacon/NavigatorBeacon.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/CacheStorageConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/CacheStorageConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMCache.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMCacheEngine.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMCacheEngine.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMCacheStorage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMCacheStorage.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/DOMWindowCaches.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/WorkerCacheStorageConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/WorkerCacheStorageConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/cache/WorkerGlobalScopeCaches.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/credentialmanagement/CredentialsContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/credentialmanagement/NavigatorCredentials.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/CDM.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/CDM.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/InitDataRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/InitDataRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeyMessageEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeyMessageEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeySession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeySession.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeyStatusMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeyStatusMap.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/MediaKeys.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDM.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDM.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDMPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDMPrivateClearKey.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDMSessionClearKey.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDMSessionClearKey.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeyMessageEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeyMessageEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeyNeededEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeyNeededEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeySession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeySession.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/DOMFileSystem.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/FileSystemDirectoryEntry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/FileSystemDirectoryReader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/FileSystemDirectoryReader.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/FileSystemEntry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/FileSystemEntry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi/FileSystemFileEntry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchBody.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchBody.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchBodyConsumer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchBodyOwner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchBodyOwner.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchHeaders.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchResponse.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch/FetchResponse.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/gamepad/GamepadEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/gamepad/GamepadEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/gamepad/GamepadManager.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/gamepad/NavigatorGamepad.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Coordinates.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Coordinates.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Coordinates.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeoNotifier.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeoNotifier.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Geolocation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Geolocation.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Geolocation.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationClient.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationController.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationCoordinates.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationCoordinates.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationCoordinates.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationPosition.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationPosition.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationPositionData.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationPositionError.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/GeolocationPositionError.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Geoposition.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/Geoposition.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/NavigatorGeolocation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/NavigatorGeolocation.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/PositionCallback.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/PositionCallback.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/PositionError.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/PositionError.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/PositionErrorCallback.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/PositionErrorCallback.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation/ios/GeolocationPositionDataIOS.mm
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/DOMWindowIndexedDatabase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/DOMWindowIndexedDatabase.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBCursor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBCursor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBCursorWithValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBCursorWithValue.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBDatabase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBDatabase.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBFactory.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBGetAllResult.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBGetAllResult.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBGetResult.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBGetResult.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBIndex.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBIndex.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBKey.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBKeyData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBKeyData.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBKeyRange.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBKeyRange.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBObjectStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBObjectStore.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBOpenDBRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBOpenDBRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBRequestCompletionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBRequestCompletionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBTransaction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBTransaction.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBValue.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBVersionChangeEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/IDBVersionChangeEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/WorkerGlobalScopeIndexedDatabase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client/TransactionOperation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client/TransactionOperation.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IDBBackingStore.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IDBSerializationContext.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IDBSerializationContext.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IDBServer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IDBServer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IndexValueEntry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IndexValueStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/IndexValueStore.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryIndex.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryIndexCursor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryObjectStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryObjectStore.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/MemoryObjectStoreCursor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/SQLiteIDBTransaction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBDatabaseInfo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBDatabaseInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBError.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBError.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBGetAllRecordsData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBIterateCursorData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBObjectStoreInfo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBRequestData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBRequestData.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBResultData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBResultData.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBTransactionInfo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/IDBTransactionInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/InProcessIDBServer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared/InProcessIDBServer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/AudioConfiguration.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilities.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilities.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilitiesDecodingInfo.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilitiesEncodingInfo.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaDecodingConfiguration.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaEncodingConfiguration.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/NavigatorMediaCapabilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/VideoConfiguration.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacontrols/MediaControlsHost.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacontrols/MediaControlsHost.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder/BlobEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder/BlobEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder/MediaRecorder.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder/MediaRecorderErrorEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder/MediaRecorderErrorEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasession/MediaRemoteControls.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasession/MediaRemoteControls.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasession/WebMediaSessionManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/MediaSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/MediaSource.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/MediaSourceRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/MediaSourceRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/SourceBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/SourceBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/SourceBufferList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource/SourceBufferList.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/CanvasCaptureMediaStreamTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/CanvasCaptureMediaStreamTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDeviceInfo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDeviceInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDeviceInfo.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDevices.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDevices.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDevicesEnumerationRequest.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDevicesEnumerationRequest.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDevicesRequest.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaDevicesRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStream.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStream.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStream.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStreamRegistry.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStreamRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStreamTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStreamTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStreamTrackEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/MediaStreamTrackEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/NavigatorMediaDevices.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/NavigatorMediaDevices.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/OverconstrainedErrorEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/PeerConnectionBackend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/PeerConnectionBackend.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDTMFSender.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDTMFSender.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDTMFSender.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDTMFToneChangeEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDTMFToneChangeEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDTMFToneChangeEvent.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDataChannel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDataChannel.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDataChannelEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCDataChannelEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCIceCandidate.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCIceCandidate.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCIceTransport.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCIceTransport.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCPeerConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCPeerConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCPeerConnection.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCPeerConnectionIceEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCPeerConnectionIceEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCPeerConnectionInternals.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpReceiver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpReceiver.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpSender.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpSender.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpSender.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpSenderBackend.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpTransceiver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCRtpTransceiver.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCSessionDescription.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCSessionDescription.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCTrackEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/RTCTrackEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/UserMediaClient.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/UserMediaController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/UserMediaController.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/UserMediaRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/UserMediaRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCDataChannelHandler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCPeerConnectionBackend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCRtpReceiverBackend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCRtpSenderBackend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCRtpSenderBackend.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCRtpTransceiverBackend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCUtils.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/modern-media-controls/controls/ios-inline-media-controls.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/modern-media-controls/controls/media-document.css
! modules/javafx.web/src/main/native/Source/WebCore/Modules/modern-media-controls/media/media-controller.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/modern-media-controls/media/media-document-controller.js
- modules/javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtils.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtils.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtils.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtilsClient.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/notifications/Notification.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/notifications/Notification.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/notifications/NotificationController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/MerchantValidationEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/MerchantValidationEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentHandler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentHandler.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentMethodChangeEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentMethodChangeEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentRequest.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentRequestUpdateEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentRequestUpdateEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest/PaymentResponse.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/plugins/QuickTimePluginReplacement.mm
! modules/javafx.web/src/main/native/Source/WebCore/Modules/plugins/YouTubePluginReplacement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/quota/DOMWindowQuota.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/quota/NavigatorStorageQuota.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/quota/WorkerNavigatorStorageQuota.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/DOMWindowSpeechSynthesis.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/SpeechSynthesis.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/SpeechSynthesis.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/SpeechSynthesisEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/SpeechSynthesisEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/SpeechSynthesisUtterance.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/speech/SpeechSynthesisUtterance.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/ReadableByteStreamInternals.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/ReadableStream.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/ReadableStreamBYOBReader.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/ReadableStreamDefaultReader.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/ReadableStreamInternals.js
- modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/WebGPUBindGroupLayoutDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/streams/WritableStream.js
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AnalyserNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AnalyserNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AsyncAudioDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AsyncAudioDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBasicInspectorNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBasicInspectorNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBasicProcessorNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBasicProcessorNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioContext.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioContext.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioDestinationNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioDestinationNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioNode.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioParam.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioParam.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioScheduledSourceNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/AudioScheduledSourceNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/BiquadFilterNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/BiquadFilterNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/BiquadProcessor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ChannelMergerNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ChannelMergerNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ChannelSplitterNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ChannelSplitterNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ConvolverNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ConvolverNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DefaultAudioDestinationNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DefaultAudioDestinationNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DelayNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DelayNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DelayProcessor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DynamicsCompressorNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/DynamicsCompressorNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/GainNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/GainNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/MediaElementAudioSourceNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/MediaElementAudioSourceNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/MediaStreamAudioDestinationNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/MediaStreamAudioDestinationNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/MediaStreamAudioSourceNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/MediaStreamAudioSourceNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/OfflineAudioContext.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/OfflineAudioDestinationNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/OfflineAudioDestinationNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/OscillatorNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/OscillatorNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/PannerNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/PannerNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/PeriodicWave.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/RealtimeAnalyser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ScriptProcessorNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/ScriptProcessorNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/WaveShaperDSPKernel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/WaveShaperNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/WaveShaperNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio/WaveShaperProcessor.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AttestationConveyancePreference.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AttestationConveyancePreference.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AuthenticationExtensionsClientInputs.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AuthenticationExtensionsClientInputs.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AuthenticatorCoordinator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AuthenticatorCoordinator.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AuthenticatorCoordinatorClient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/AuthenticatorCoordinatorClient.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredential.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredential.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredential.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredentialCreationOptions.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredentialCreationOptions.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredentialData.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredentialRequestOptions.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/PublicKeyCredentialRequestOptions.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/WebAuthenticationConstants.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/WebAuthenticationUtils.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/WebAuthenticationUtils.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/apdu/ApduCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/apdu/ApduCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/apdu/ApduResponse.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/apdu/ApduResponse.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/DeviceResponseConverter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/DeviceResponseConverter.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/FidoConstants.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/FidoHidMessage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/FidoHidMessage.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/FidoHidPacket.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/U2fCommandConstructor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/U2fCommandConstructor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/U2fResponseConverter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido/U2fResponseConverter.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/ChangeVersionData.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DOMWindowWebDatabase.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/Database.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/Database.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseContext.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseManager.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseThread.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseTracker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/DatabaseTracker.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/OriginLock.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLError.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLError.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLResultSetRowList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLStatement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLStatement.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLTransaction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase/SQLTransaction.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webdriver/NavigatorWebDriver.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/DOMWindowWebGPU.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/DOMWindowWebGPU.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/DOMWindowWebGPU.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBindGroupLayoutBinding.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBindGroupLayoutBinding.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBindGroupLayoutDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBindGroupLayoutDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBlendDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBufferDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUBufferUsage.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUCanvasContext.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUCanvasContext.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUCanvasContext.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUColor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUColorStateDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUColorWriteBits.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUCompareFunction.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUDepthStencilStateDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUErrorFilter.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUExtent3D.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPULoadOp.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUOrigin3D.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUOrigin3D.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUOutOfMemoryError.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPURequestAdapterOptions.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUSamplerDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUShaderStageBit.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUShaderStageBit.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUStoreOp.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUTextureDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUTextureDimension.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUTextureFormat.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUTextureUsage.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUValidationError.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUVertexAttributeDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUVertexBufferDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/GPUVertexInputDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/NavigatorGPU.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/NavigatorGPU.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/NavigatorGPU.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAddressEscapeMode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAddressSpace.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLArrayReferenceType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLArrayType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAssignmentExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBaseFunctionAttribute.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBaseSemantic.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBlock.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBooleanLiteral.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBreak.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBuiltInSemantic.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCommaExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLConstantExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLContinue.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLDefaultDelete.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLDereferenceExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLDoWhileLoop.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLDotExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLEffectfulExpressionStatement.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLEntryPointType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLEnumerationDefinition.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLEnumerationMember.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLEnumerationMemberLiteral.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLExpression.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFallthrough.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFloatLiteral.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFloatLiteralType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFloatLiteralType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFunctionDefinition.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLGlobalVariableReference.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIndexExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteral.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteral.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteralType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteralType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLLogicalExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLLogicalNotExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLMakeArrayReferenceExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLMakePointerExpression.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNameSpace.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNamedType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNativeFunctionDeclaration.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNativeTypeDeclaration.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNode.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNullLiteral.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNullLiteralType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNumThreadsFunctionAttribute.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLPointerType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLQualifier.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReadModifyWriteExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReferenceType.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReplaceWith.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLResolvableType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLResourceSemantic.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLResourceSemantic.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReturn.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLSpecializationConstantSemantic.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLSpecializationConstantSemantic.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStageInOutSemantic.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStageInOutSemantic.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatementList.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStructureDefinition.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLSwitchCase.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLSwitchStatement.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTernaryExpression.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTrap.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLType.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTypeArgument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTypeArgument.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTypeDefinition.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTypeReference.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTypeReference.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnnamedTypeHash.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteral.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteral.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteralType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteralType.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLValue.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclarationsStatement.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableReference.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLWhileLoop.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLMangledNames.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLMetalCodeGenerator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLMetalCodeGenerator.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLNativeFunctionWriter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLNativeFunctionWriter.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLNativeTypeWriter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLVertexBufferIndexCalculator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLVertexBufferIndexCalculator.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLCheckDuplicateFunctions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLCheckDuplicateFunctions.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLCheckTextureReferences.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLCheckTextureReferences.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLCodeLocation.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLError.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLFunctionStageChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLFunctionStageChecker.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLGatherEntryPointItems.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLGatherEntryPointItems.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLInferTypes.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLInferTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLIntrinsics.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLIntrinsics.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLiteralTypeChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameContext.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParsingMode.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPipelineDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPrepare.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPrepare.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLProgram.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPropertyResolver.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPruneUnreachableStandardLibraryFunctions.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPruneUnreachableStandardLibraryFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursionChecker.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLResolveOverloadImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLResolveOverloadImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLResolvingType.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLScopedSetAdder.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSemanticMatcher.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSemanticMatcher.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibraryFunctionMap.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPU.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPU.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPU.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUAdapter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUAdapter.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUAdapter.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroup.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroup.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupBinding.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupBinding.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupDescriptor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupDescriptor.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupLayout.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupLayout.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupLayoutBinding.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupLayoutBinding.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBindGroupLayoutDescriptor.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBuffer.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBufferBinding.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBufferBinding.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBufferDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBufferDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBufferUsage.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUBufferUsage.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUColor.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUColor.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUCommandBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUCommandBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUCommandBuffer.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUCommandEncoder.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUCommandEncoder.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUCommandEncoder.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePassEncoder.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePassEncoder.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePassEncoder.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePipeline.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePipeline.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePipeline.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePipelineDescriptor.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePipelineDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUComputePipelineDescriptor.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUDevice.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUDevice.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUDevice.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUDeviceErrorScopes.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUDeviceErrorScopes.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUDeviceErrorScopes.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUIndexFormat.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUIndexFormat.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUInputStateDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUInputStateDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUInputStepMode.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUInputStepMode.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineDescriptorBase.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineLayout.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineLayout.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineLayout.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineLayoutDescriptor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineLayoutDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineLayoutDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineStageDescriptor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineStageDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUPipelineStageDescriptor.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUProgrammablePassEncoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUProgrammablePassEncoder.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUProgrammablePassEncoder.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUQueue.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUQueue.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassColorAttachmentDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassColorAttachmentDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassDescriptor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassDescriptor.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassEncoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassEncoder.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPassEncoder.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPipeline.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPipeline.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPipeline.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPipelineDescriptor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPipelineDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderPipelineDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderingContext.cpp
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderingContext.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPURenderingContext.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSampler.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSampler.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSampler.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUShaderModule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUShaderModule.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUShaderModule.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUShaderModuleDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUShaderStageBit.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUShaderStageBit.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSwapChain.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSwapChain.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSwapChain.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSwapChainDescriptor.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUSwapChainDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUTexture.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUTexture.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUTexture.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUTextureView.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUTextureView.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUTextureView.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUVertexAttributeDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUVertexAttributeDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUVertexFormat.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUVertexFormat.idl
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUVertexInputDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WebGPUVertexInputDescriptor.idl
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WorkerNavigatorGPU.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WorkerNavigatorGPU.h
+ modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/WorkerNavigatorGPU.idl
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/CloseEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/ThreadableWebSocketChannel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/ThreadableWebSocketChannel.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/ThreadableWebSocketChannelClientWrapper.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocket.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocket.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketChannel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketChannel.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketChannelClient.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketDeflateFramer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketDeflater.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketExtensionDispatcher.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketExtensionParser.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketFrame.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketHandshake.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WebSocketHandshake.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/NavigatorWebVR.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VRDisplay.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VRDisplay.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VRDisplayEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VRDisplayEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VREyeParameters.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VRFrameData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/Modules/webvr/VRPose.cpp
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/CMakeLists.txt
+ modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/Gunzip.h
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/LogMacros.h
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/SessionID.cpp
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/SessionID.h
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/crypto/openssl/CryptoDigestOpenSSL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/crypto/tasn1/Utilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/crypto/tasn1/Utilities.h
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/system/ClockGeneric.cpp
! modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/win/LoggingWin.cpp
! modules/javafx.web/src/main/native/Source/WebCore/PlatformJava.cmake
! modules/javafx.web/src/main/native/Source/WebCore/PlatformPlayStation.cmake
+ modules/javafx.web/src/main/native/Source/WebCore/Resources/AttachmentPlaceholder.png
+ modules/javafx.web/src/main/native/Source/WebCore/Resources/AttachmentPlaceholder at 2x.png
+ modules/javafx.web/src/main/native/Source/WebCore/Resources/ContentFilterBlockedPage.html
- modules/javafx.web/src/main/native/Source/WebCore/Resources/DictationPhraseWithAlternativesDot.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/DictationPhraseWithAlternativesDot at 2x.png
+ modules/javafx.web/src/main/native/Source/WebCore/Resources/ListButtonArrow.png
+ modules/javafx.web/src/main/native/Source/WebCore/Resources/ListButtonArrow at 2x.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/SpellingDot.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/SpellingDot at 2x.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/SpellingDot at 3x.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/decrementArrow.tiff
- modules/javafx.web/src/main/native/Source/WebCore/Resources/hScrollControl_left.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/hScrollControl_middle.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/hScrollControl_right.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/incrementArrow.tiff
- modules/javafx.web/src/main/native/Source/WebCore/Resources/inputSpeech.tiff
- modules/javafx.web/src/main/native/Source/WebCore/Resources/markedLeft.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/markedMiddle.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/markedRight.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/missingImage.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/missingImage.tiff
! modules/javafx.web/src/main/native/Source/WebCore/Resources/missingImage at 2x.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/missingImage at 3x.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/moveCursor.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/northEastSouthWestResizeCursor.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/northSouthResizeCursor.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/northWestSouthEastResizeCursor.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/nullPlugin.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/nullPlugin at 2x.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/panIcon.png
! modules/javafx.web/src/main/native/Source/WebCore/Resources/textAreaResizeCorner.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/textAreaResizeCorner.tiff
! modules/javafx.web/src/main/native/Source/WebCore/Resources/textAreaResizeCorner at 2x.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/urlIcon.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/vScrollControl_bottom.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/vScrollControl_middle.png
- modules/javafx.web/src/main/native/Source/WebCore/Resources/vScrollControl_top.png
! modules/javafx.web/src/main/native/Source/WebCore/Scripts/SettingsTemplates/Settings.cpp.erb
! modules/javafx.web/src/main/native/Source/WebCore/Scripts/check-xcfilelists.sh
! modules/javafx.web/src/main/native/Source/WebCore/Sources.txt
! modules/javafx.web/src/main/native/Source/WebCore/SourcesCocoa.txt
! modules/javafx.web/src/main/native/Source/WebCore/SourcesGTK.txt
! modules/javafx.web/src/main/native/Source/WebCore/SourcesPlatformJava.txt
! modules/javafx.web/src/main/native/Source/WebCore/SourcesWPE.txt
- modules/javafx.web/src/main/native/Source/WebCore/WebCore.vcxproj/QTMovieWin/QTMovieWinPreLink.cmd
! modules/javafx.web/src/main/native/Source/WebCore/WebCoreMacros.cmake
! modules/javafx.web/src/main/native/Source/WebCore/WebCorePrefix.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AXObjectCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AXObjectCache.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityARIAGrid.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityARIAGridRow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityAttachment.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityAttachment.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityImageMapLink.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityImageMapLink.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityListBoxOption.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityMediaControls.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityMediaControls.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityMediaObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityMenuListOption.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityNodeObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityNodeObject.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityObject.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityObjectInterface.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityProgressIndicator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityProgressIndicator.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityRenderObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityRenderObject.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilitySVGElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilitySVGElement.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityScrollView.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityScrollView.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityScrollbar.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilitySlider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilitySlider.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityTable.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityTableCell.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityTableColumn.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityTableHeaderContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibilityTableRow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibleSetValueEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibleSetValueEvent.h
- modules/javafx.web/src/main/native/Source/WebCore/accessibility/AccessibleSetValueEvent.idl
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/AriaAttributes.idl
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/AccessibilityObjectAtk.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessible.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessible.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleHyperlink.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleHyperlink.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceAction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceAction.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceComponent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceComponent.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceEditableText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceEditableText.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceHyperlinkImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceHyperlinkImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceHypertext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceHypertext.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceImage.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceSelection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceSelection.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceTable.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceTable.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceTableCell.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceTableCell.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceText.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleInterfaceValue.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleUtil.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/atk/WebKitAccessibleUtil.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree/AXIsolatedTree.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree/AXIsolatedTree.h
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree/AXIsolatedTreeNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree/AXIsolatedTreeNode.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/AnimationPlaybackEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/AnimationPlaybackEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/AnimationTimeline.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/AnimationTimeline.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/CSSAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/CSSAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/CSSTransition.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/CSSTransition.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/DeclarativeAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/DeclarativeAnimation.h
- modules/javafx.web/src/main/native/Source/WebCore/animation/DocumentAnimationScheduler.cpp
- modules/javafx.web/src/main/native/Source/WebCore/animation/DocumentAnimationScheduler.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/DocumentTimeline.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/DocumentTimeline.h
! modules/javafx.web/src/main/native/Source/WebCore/animation/KeyframeEffect.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/WebAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/animation/WebAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/IDLTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CachedScriptFetcher.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CachedScriptFetcher.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CallTracer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CallTracer.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CallTracerTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CommonVM.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/CommonVM.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/DOMGCOutputConstraint.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/DOMGCOutputConstraint.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/DOMPromiseProxy.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/GCController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/GCController.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/IDBBindingUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/IDBBindingUtilities.h
+ modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSAudioNodeCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCSSRuleListCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCallbackData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCanvasRenderingContext2DCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCustomElementInterface.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCustomElementInterface.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCustomElementRegistryCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSCustomXPathNSResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMBindingSecurity.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMBuiltinConstructor.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMConvertNumbers.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMConvertRecord.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMConvertStrings.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMConvertStrings.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMConvertVariadic.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMConvertWebGL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMExceptionHandling.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMGlobalObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMGlobalObject.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMPromiseDeferred.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMWindowBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMWindowCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMWindowProperties.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDOMWrapper.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDeprecatedCSSOMValueCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSDocumentCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSEventCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSEventListener.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSEventListener.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSEventTargetCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSExecStateInstrumentation.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSExtendableMessageEventCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSHTMLElementCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSHistoryCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSIDBCursorWithValueCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSIDBRequestCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSImageDataCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSLazyEventListener.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSLazyEventListener.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSLocationCustom.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSMediaCapabilitiesCustom.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSNavigatorCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSNodeListCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSPerformanceObserverCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSPluginElementFunctions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSRemoteDOMWindowCustom.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSResizeObserverEntryCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSSVGPathSegCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSValueInWrappedObject.h
- modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSWebMetalRenderPassAttachmentDescriptorCustom.cpp
- modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSWebMetalRenderingContextCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSWindowProxy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSWorkerGlobalScopeBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/JSWorkerNavigatorCustom.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/ReadableStreamDefaultController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/ScriptCachedFrameData.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/ScriptController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/ScriptController.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/ScriptModuleLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/ScriptWrappable.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/SerializedScriptValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/SerializedScriptValue.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/WebCoreBuiltinNames.h
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/WebCoreJSClientData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/WindowProxy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/js/WorkerScriptController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/CodeGenerator.pm
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/IDLAttributes.json
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/IDLParser.pm
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/generate-bindings-all.pl
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/generate-bindings.pl
! modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/preprocess-idls.pl
- modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/test/GObject/WebKitDOMTestGenerateIsReachable.symbols
- modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/test/GObject/WebKitDOMTestMediaQueryListListener.symbols
- modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/test/GObject/WebKitDOMTestNamedConstructor.symbols
- modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/test/GObject/WebKitDOMTestNode.symbols
- modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/test/GObject/WebKitDOMTestOverloadedConstructors.symbols
- modules/javafx.web/src/main/native/Source/WebCore/bindings/scripts/test/GObject/WebKitDOMreadonly.symbols
! modules/javafx.web/src/main/native/Source/WebCore/bridge/NP_jsobject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/c/c_class.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/c/c_instance.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/c/c_utility.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/jni/jsc/JavaInstanceJSC.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/jsc/BridgeJSC.h
! modules/javafx.web/src/main/native/Source/WebCore/bridge/runtime_array.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/runtime_object.cpp
! modules/javafx.web/src/main/native/Source/WebCore/bridge/runtime_object.h
! modules/javafx.web/src/main/native/Source/WebCore/config.h
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/CombinedURLFilters.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionActions.h
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionCompiler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionRule.h
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionsBackend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentExtensionsBackend.h
+ modules/javafx.web/src/main/native/Source/WebCore/contentextensions/ContentRuleListResults.h
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/DFABytecodeCompiler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/DFACombiner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/NFAToDFA.cpp
! modules/javafx.web/src/main/native/Source/WebCore/contentextensions/URLFilterParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/crypto/CommonCryptoUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/crypto/SubtleCrypto.cpp
! modules/javafx.web/src/main/native/Source/WebCore/crypto/gcrypt/CryptoAlgorithmHMACGCrypt.cpp
! modules/javafx.web/src/main/native/Source/WebCore/crypto/gcrypt/GCryptUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/crypto/gcrypt/GCryptUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/crypto/keys/CryptoKeyEC.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSBasicShapes.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSCalculationValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSComputedStyleDeclaration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSComputedStyleDeclaration.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSCrossfadeValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSCursorImageValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSCustomIdentValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSCustomIdentValue.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSCustomPropertyValue.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSDefaultStyleSheets.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFilterImageValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFace.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFace.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFaceRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFaceSet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFaceSet.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFaceSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFaceSource.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontFaceSrcValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontSelector.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontSelector.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSFontVariationValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSGradientValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSGridAutoRepeatValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSGridAutoRepeatValue.h
+ modules/javafx.web/src/main/native/Source/WebCore/css/CSSGridIntegerRepeatValue.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/css/CSSGridIntegerRepeatValue.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSGroupingRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSImageGeneratorValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSImageValue.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSKeyframeRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSKeyframesRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSKeyframesRule.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSMarkup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSMediaRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSNamespaceRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSNamespaceRule.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSPageRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSPrimitiveValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSPrimitiveValue.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSPrimitiveValueMappings.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSProperties.json
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSPropertySourceData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSPropertySourceData.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSSelector.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSSelector.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSStyleDeclaration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSStyleDeclaration.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSStyleRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSStyleSheet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSStyleSheet.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSTimingFunctionValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSValue.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSValueKeywords.in
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSValuePool.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSValuePool.h
! modules/javafx.web/src/main/native/Source/WebCore/css/CSSVariableData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/DOMCSSPaintWorklet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/DOMCSSRegisterCustomProperty.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/DOMMatrix.h
! modules/javafx.web/src/main/native/Source/WebCore/css/DOMMatrixReadOnly.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/DOMMatrixReadOnly.h
- modules/javafx.web/src/main/native/Source/WebCore/css/DashboardRegion.h
! modules/javafx.web/src/main/native/Source/WebCore/css/DocumentRuleSets.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/DocumentRuleSets.h
! modules/javafx.web/src/main/native/Source/WebCore/css/ElementRuleCollector.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/FontFace.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/FontFace.h
! modules/javafx.web/src/main/native/Source/WebCore/css/FontFace.idl
! modules/javafx.web/src/main/native/Source/WebCore/css/FontFaceSet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/FontFaceSet.h
! modules/javafx.web/src/main/native/Source/WebCore/css/FontVariantBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/LengthFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaFeatureNames.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaFeatureNames.h
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaList.h
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaQueryEvaluator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaQueryExpression.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaQueryExpression.h
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaQueryMatcher.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/MediaQueryMatcher.h
! modules/javafx.web/src/main/native/Source/WebCore/css/PageRuleCollector.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/PropertySetCSSStyleDeclaration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/PropertySetCSSStyleDeclaration.h
! modules/javafx.web/src/main/native/Source/WebCore/css/RuleFeature.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/RuleFeature.h
! modules/javafx.web/src/main/native/Source/WebCore/css/RuleSet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/RuleSet.h
! modules/javafx.web/src/main/native/Source/WebCore/css/SVGCSSComputedStyleDeclaration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/SelectorChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/SelectorChecker.h
! modules/javafx.web/src/main/native/Source/WebCore/css/SelectorCheckerTestFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/css/SelectorFilter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/SelectorPseudoClassAndCompatibilityElementMap.in
! modules/javafx.web/src/main/native/Source/WebCore/css/SelectorPseudoTypeMap.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleBuilderConverter.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleBuilderCustom.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleColor.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleMedia.idl
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleProperties.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleProperties.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleResolver.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleRule.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleRule.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleSheetContents.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleSheetContents.h
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleSheetList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/StyleSheetList.h
! modules/javafx.web/src/main/native/Source/WebCore/css/ViewportStyleResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/ViewportStyleResolver.h
! modules/javafx.web/src/main/native/Source/WebCore/css/WebKitCSSMatrix.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/WebKitCSSMatrix.h
! modules/javafx.web/src/main/native/Source/WebCore/css/html.css
! modules/javafx.web/src/main/native/Source/WebCore/css/makeSelectorPseudoClassAndCompatibilityElementMap.py
! modules/javafx.web/src/main/native/Source/WebCore/css/makeSelectorPseudoElementsMap.py
! modules/javafx.web/src/main/native/Source/WebCore/css/makeprop.pl
! modules/javafx.web/src/main/native/Source/WebCore/css/makevalues.pl
! modules/javafx.web/src/main/native/Source/WebCore/css/mathml.css
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSDeferredParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSDeferredParser.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParser.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserContext.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserFastPaths.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserFastPaths.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserSelector.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserSelector.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSParserToken.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSSelectorParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSSelectorParser.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSTokenizer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSTokenizer.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSVariableParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSVariableParser.h
! modules/javafx.web/src/main/native/Source/WebCore/css/parser/SizesAttributeParser.h
! modules/javafx.web/src/main/native/Source/WebCore/css/typedom/StylePropertyMap.h
+ modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSImageValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSImageValue.h
+ modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSNumericValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSNumericValue.h
+ modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSStyleValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSStyleValue.h
+ modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSUnitValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSUnitValue.h
+ modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSUnparsedValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/css/typedom/TypedOMCSSUnparsedValue.h
! modules/javafx.web/src/main/native/Source/WebCore/cssjit/SelectorCompiler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/cssjit/StackAllocator.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/AbortController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/AbortController.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/AbortSignal.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/AbortSignal.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/AllDescendantsCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/AllDescendantsCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/AnimationEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/AnimationEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Attr.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Attr.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Attribute.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/BeforeLoadEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ChildNodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ChildNodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ClassCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ClassCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ClipboardEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ClipboardEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/CompositionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/CompositionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ConstantPropertyMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ConstantPropertyMap.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ContainerNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ContainerNode.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/CustomElementReactionQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/CustomElementReactionQueue.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/CustomElementRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/CustomElementRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/CustomEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/CustomEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMImplementation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMImplementation.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DOMPasteAccess.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMPoint.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMPointReadOnly.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMPointReadOnly.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMQuad.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMQuad.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMRect.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DOMRectReadOnly.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMRectReadOnly.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DOMRectReadOnly.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/DataTransfer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DataTransfer.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DataTransferItem.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DataTransferItemList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DataTransferItemList.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DataTransferMac.mm
! modules/javafx.web/src/main/native/Source/WebCore/dom/DatasetDOMStringMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DatasetDOMStringMap.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceMotionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceMotionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceMotionEvent.idl
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationAndMotionAccessController.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationAndMotionAccessController.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationEvent.idl
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationOrMotionEvent.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationOrMotionEvent.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationOrMotionEvent.idl
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationOrMotionPermissionState.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DeviceOrientationOrMotionPermissionState.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/Document.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Document.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Document.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentEventQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentFragment.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentFragment.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentFullscreen.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentFullscreen.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentMarker.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentMarkerController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentMarkerController.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentParser.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentStorageAccess.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentStorageAccess.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/DocumentStorageAccess.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/Element.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Element.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Element.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/ElementData.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/ElementIdentifier.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ElementRareData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ElementRareData.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ErrorEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ErrorEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Event.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Event.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventListener.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventListenerMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventListenerMap.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventNames.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventNames.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventNames.in
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventPath.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventSender.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventTarget.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventTarget.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventTarget.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/EventTargetFactory.in
! modules/javafx.web/src/main/native/Source/WebCore/dom/ExtensionStyleSheets.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/FocusEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/FocusEvent.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/FullscreenManager.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/dom/FullscreenManager.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/GenericEventQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/GenericEventQueue.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/GlobalEventHandlers.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/HashChangeEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/IdTargetObserver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/IdTargetObserver.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/IdTargetObserverRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/IdTargetObserverRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/InlineClassicScript.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/InlineStyleSheetOwner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/InlineStyleSheetOwner.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/InputEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/InputEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/KeyboardEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/KeyboardEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/LiveNodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/LiveNodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/LoadableClassicScript.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/LoadableClassicScript.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/LoadableModuleScript.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/LoadableModuleScript.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/LoadableScript.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MessageChannel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MessageEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MessageEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MessagePort.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MessagePort.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Microtasks.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Microtasks.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseEvent.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseEventInit.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseEventInit.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseRelatedEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MouseRelatedEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationObserver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationObserverInterestGroup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationObserverRegistration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationObserverRegistration.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationRecord.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/MutationRecord.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/NameNodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/NameNodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/NamedNodeMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/NamedNodeMap.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/NavigatorMaxTouchPoints.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/Node.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Node.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/NodeIterator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/NodeIterator.h
+ modules/javafx.web/src/main/native/Source/WebCore/dom/NodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/NodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/NodeRareData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/NodeRareData.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/NonElementParentNode.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/OverflowEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/OverflowEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/PageTransitionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/PageTransitionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/PointerEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/PointerEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/PointerEvent.idl
- modules/javafx.web/src/main/native/Source/WebCore/dom/PointerID.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/PopStateEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/PopStateEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Position.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ProgressEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ProgressEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/PromiseRejectionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/PromiseRejectionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/QualifiedName.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/QualifiedName.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/RadioButtonGroups.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/RadioButtonGroups.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Range.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/Range.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/RangeBoundaryPoint.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/RequestAnimationFrameCallback.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptDisallowedScope.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptElement.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptElementCachedScriptFetcher.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptExecutionContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptedAnimationController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ScriptedAnimationController.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/SecurityPolicyViolationEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/SelectorQuery.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/SelectorQuery.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ShadowRoot.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ShadowRoot.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/SimulatedClick.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/SlotAssignment.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/SlotAssignment.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/SpaceSplitString.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/SpaceSplitString.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/SpectreGadget.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/SpectreGadget.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/StaticNodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/StaticNodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/StaticRange.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/StaticRange.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/StaticRange.idl
! modules/javafx.web/src/main/native/Source/WebCore/dom/StyledElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/StyledElement.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TagCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TagCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/Text.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TextDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TextDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TextEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TextEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TouchEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TouchEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TransitionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TransitionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TreeScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TreeScope.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TreeScopeOrderedMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TreeScopeOrderedMap.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/TreeWalker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/TreeWalker.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/UIEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/UIEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/UIEventWithKeyState.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/UserGestureIndicator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/UserGestureIndicator.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/ViewportArguments.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/ViewportArguments.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/VisitedLinkState.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/WebKitAnimationEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/WebKitAnimationEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/WebKitTransitionEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/WebKitTransitionEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/WheelEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/WheelEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/XMLDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/make_names.pl
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannel.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannelProvider.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannelProviderImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannelProviderImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannelRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/dom/messageports/MessagePortChannelRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/domjit/DOMJITHelpers.h
! modules/javafx.web/src/main/native/Source/WebCore/domjit/DOMJITIDLConvert.h
! modules/javafx.web/src/main/native/Source/WebCore/domjit/DOMJITIDLType.h
! modules/javafx.web/src/main/native/Source/WebCore/domjit/DOMJITIDLTypeFilter.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/ApplyBlockElementCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/ApplyBlockElementCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/BreakBlockquoteCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/ChangeListTypeCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/ChangeListTypeCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/CompositeEditCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/CompositeEditCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/DeleteSelectionCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/DeleteSelectionCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/DictionaryPopupInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditAction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditAction.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/Editing.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/Editing.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditingBehavior.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditingStyle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditingStyle.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/Editor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/Editor.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/EditorCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/FontAttributes.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/FrameSelection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/FrameSelection.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/InsertEditableImageCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/InsertTextCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/MarkupAccumulator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/MarkupAccumulator.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/ReplaceRangeWithTextCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/ReplaceSelectionCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/ReplaceSelectionCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/SelectionRectGatherer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/SetNodeAttributeCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/SetNodeAttributeCommand.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/SpellingCorrectionCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/SplitElementCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/TextCheckingHelper.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/TextCheckingHelper.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/TextGranularity.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/TextIterator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/TextIterator.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/TypingCommand.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/VisibleSelection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/VisibleUnits.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/VisibleUnits.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/WebContentReader.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/WebCorePasteboardFileReader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/WebCorePasteboardFileReader.h
! modules/javafx.web/src/main/native/Source/WebCore/editing/atk/FrameSelectionAtk.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/markup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/editing/markup.h
! modules/javafx.web/src/main/native/Source/WebCore/features.json
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/AsyncFileStream.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/Blob.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/Blob.h
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/Blob.idl
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/File.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/File.h
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/File.idl
+ modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileList.h
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileReader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileReader.h
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileReaderLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileReaderLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/ThreadableBlobRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/fileapi/ThreadableBlobRegistry.h
- modules/javafx.web/src/main/native/Source/WebCore/history/BackForwardList.cpp
- modules/javafx.web/src/main/native/Source/WebCore/history/BackForwardList.h
! modules/javafx.web/src/main/native/Source/WebCore/history/CachedFrame.cpp
! modules/javafx.web/src/main/native/Source/WebCore/history/CachedPage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/history/PageCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/Autocapitalize.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/Autocapitalize.h
! modules/javafx.web/src/main/native/Source/WebCore/html/Autofill.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/Autofill.h
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseCheckableInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseCheckableInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseChooserOnlyDateAndTimeInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseChooserOnlyDateAndTimeInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseClickableWithKeyInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseClickableWithKeyInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/BaseTextInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ButtonInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ButtonInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/CachedHTMLCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/CanvasBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/CheckboxInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/CheckboxInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/ColorInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ColorInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/DOMFormData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/DOMFormData.h
! modules/javafx.web/src/main/native/Source/WebCore/html/DOMTokenList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/DOMTokenList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/DOMURL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/DateInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/DateInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/DateTimeInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/DateTimeInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/DateTimeLocalInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/DateTimeLocalInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/EmailInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/EmailInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/FTPDirectoryDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/FTPDirectoryDocument.h
+ modules/javafx.web/src/main/native/Source/WebCore/html/FeaturePolicy.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/html/FeaturePolicy.h
! modules/javafx.web/src/main/native/Source/WebCore/html/FileInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/FileInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/FileListCreator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/FileListCreator.h
! modules/javafx.web/src/main/native/Source/WebCore/html/FormAssociatedElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/FormAssociatedElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/FormController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/FormController.h
! modules/javafx.web/src/main/native/Source/WebCore/html/GenericCachedHTMLCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/GenericCachedHTMLCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAllCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAllCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAnchorElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAnchorElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAppletElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAppletElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAreaElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAreaElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAttachmentElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAttachmentElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAttributeNames.in
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAudioElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAudioElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLAudioElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLBRElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLBRElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLBaseElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLBaseElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLBodyElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLBodyElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLButtonElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLButtonElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLCanvasElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLCanvasElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLCanvasElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDetailsElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDetailsElement.h
+ modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDialogElement.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDialogElement.h
+ modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDialogElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDivElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDivElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLEmbedElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLEmbedElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFieldSetElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFieldSetElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFontElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFontElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFormControlElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFormControlElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFormControlsCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFormControlsCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFormElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFormElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameElementBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameElementBase.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameOwnerElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameOwnerElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameSetElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLFrameSetElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLHRElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLHRElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLHtmlElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLIFrameElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLIFrameElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLIFrameElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLImageElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLImageElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLImageElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLImageLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLImageLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLInputElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLInputElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLKeygenElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLKeygenElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLKeygenElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLIElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLIElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLabelElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLabelElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLinkElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLinkElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLLinkElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMapElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMapElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMarqueeElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMarqueeElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMediaElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMediaElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMenuElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMenuElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMetaElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMetaElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMeterElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLMeterElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLNameCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLNameCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOListElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOListElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLObjectElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLObjectElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLObjectElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOptGroupElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOptGroupElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOptionElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOptionElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOptionsCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOptionsCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOutputElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLOutputElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLParagraphElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLParagraphElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPictureElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPlugInElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPlugInElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPlugInImageElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPlugInImageElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPreElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLPreElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLProgressElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLProgressElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLScriptElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLScriptElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLScriptElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSelectElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSelectElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSlotElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSlotElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSourceElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSourceElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLStyleElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLStyleElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLSummaryElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableCaptionElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableCaptionElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableCellElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableCellElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableColElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableColElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTablePartElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTablePartElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableRowElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableRowsCollection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTableRowsCollection.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTagNames.in
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTextAreaElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTextAreaElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTextFormControlElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTextFormControlElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTrackElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLTrackElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLUListElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLUListElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLVideoElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HTMLVideoElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/HiddenInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/HiddenInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/ImageBitmap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ImageBitmap.h
! modules/javafx.web/src/main/native/Source/WebCore/html/ImageData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ImageDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ImageInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ImageInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/InputMode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/InputMode.h
! modules/javafx.web/src/main/native/Source/WebCore/html/InputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/InputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/InputTypeNames.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/InputTypeNames.h
! modules/javafx.web/src/main/native/Source/WebCore/html/LabelsNodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/LabelsNodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaController.h
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaElementSession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaElementSession.h
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaEncryptedEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/MediaEncryptedEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/html/MonthInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/MonthInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/NumberInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/NumberInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/OffscreenCanvas.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/OffscreenCanvas.h
! modules/javafx.web/src/main/native/Source/WebCore/html/PasswordInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/PasswordInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/PluginDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/PluginDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/html/PublicURLManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/PublicURLManager.h
! modules/javafx.web/src/main/native/Source/WebCore/html/RadioInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/RadioInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/RadioNodeList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/RadioNodeList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/RangeInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/RangeInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/ResetInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/ResetInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/SearchInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/SearchInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/SubmitInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/SubmitInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/TelephoneInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/TelephoneInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/TextDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/TextDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/html/TextFieldInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/TextFieldInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/TextInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/TextInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/TimeInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/TimeInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/URLInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/URLInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/URLRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/html/URLUtils.h
! modules/javafx.web/src/main/native/Source/WebCore/html/ValidationMessage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/WeekInputType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/WeekInputType.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasGradient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasGradient.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasRenderingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasRenderingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasRenderingContext2D.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/CanvasRenderingContext2DBase.h
+ modules/javafx.web/src/main/native/Source/WebCore/html/canvas/GPUBasedCanvasRenderingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/GPUBasedCanvasRenderingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/ImageBitmapRenderingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/ImageBitmapRenderingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/OESVertexArrayObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/OESVertexArrayObject.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/OffscreenCanvasRenderingContext2D.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/OffscreenCanvasRenderingContext2D.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/PaintRenderingContext2D.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/PaintRenderingContext2D.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/Path2D.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/PlaceholderRenderingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/PlaceholderRenderingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGL2RenderingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGL2RenderingContext.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLActiveInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLCompressedTextureASTC.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLCompressedTextureATC.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLCompressedTexturePVRTC.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLCompressedTextureS3TC.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLContextAttributes.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLContextEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLContextEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLContextGroup.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLContextObject.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLDebugRendererInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLDebugShaders.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLDepthTexture.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLDrawBuffers.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLExtension.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLFramebuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLFramebuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLLoseContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLObject.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLProgram.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLProgram.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLQuery.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLRenderbuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLRenderingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLRenderingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLRenderingContextBase.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLSampler.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLShader.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLShaderPrecisionFormat.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLSharedObject.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLSync.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLTexture.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLTransformFeedback.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLUniformLocation.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLVertexArrayObjectBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLVertexArrayObjectBase.h
! modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalBuffer.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalBuffer.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalBuffer.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalCommandBuffer.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalCommandBuffer.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalCommandBuffer.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalCommandQueue.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalCommandQueue.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalCommandQueue.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalComputeCommandEncoder.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalComputeCommandEncoder.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalComputeCommandEncoder.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalComputePipelineState.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalComputePipelineState.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalComputePipelineState.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDepthStencilDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDepthStencilDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDepthStencilDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDepthStencilState.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDepthStencilState.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDepthStencilState.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDrawable.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDrawable.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalDrawable.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalEnums.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalEnums.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalEnums.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalFunction.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalFunction.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalFunction.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalLibrary.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalLibrary.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalLibrary.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderCommandEncoder.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderCommandEncoder.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderCommandEncoder.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassAttachmentDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassAttachmentDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassAttachmentDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassColorAttachmentDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassColorAttachmentDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassColorAttachmentDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassDepthAttachmentDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassDepthAttachmentDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassDepthAttachmentDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPassDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineColorAttachmentDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineColorAttachmentDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineColorAttachmentDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineDescriptor.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineState.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineState.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderPipelineState.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderingContext.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderingContext.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalRenderingContext.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalSize.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalSize.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalTexture.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalTexture.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalTexture.idl
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalTextureDescriptor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalTextureDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/html/canvas/WebMetalTextureDescriptor.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/AtomicHTMLToken.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/CSSPreloadScanner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLConstructionSite.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLConstructionSite.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLDocumentParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLEntityParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLFormattingElementList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLFormattingElementList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLMetaCharsetParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLParserIdioms.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLParserIdioms.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLParserOptions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLParserOptions.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLPreloadScanner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLResourcePreloader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLResourcePreloader.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLScriptRunner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLScriptRunner.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLSrcsetParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLSrcsetParser.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLStackItem.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLToken.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLTokenizer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLTokenizer.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLTreeBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLTreeBuilder.h
! modules/javafx.web/src/main/native/Source/WebCore/html/parser/XSSAuditor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/DataListButtonElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/DetailsMarkerControl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/MediaControlElementTypes.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/MediaControlElementTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/MediaControlElements.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/MediaControlElements.h
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/MediaControls.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/ProgressShadowElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/SliderThumbElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/SliderThumbElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/SpinButtonElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/TextControlInnerElements.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/shadow/YouTubeEmbedShadowElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/AudioTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/AudioTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/AudioTrackList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/AudioTrackList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/BufferedLineReader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/DataCue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/DataCue.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandDataTextTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandDataTextTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandGenericTextTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandGenericTextTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandTextTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandTextTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandWebVTTTextTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/InbandWebVTTTextTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/LoadableTextTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/LoadableTextTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackCue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackCue.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackCueGeneric.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackCueGeneric.h
+ modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackCueGeneric.idl
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TextTrackList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TrackBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TrackBase.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TrackEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TrackEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TrackListBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/TrackListBase.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VTTCue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VTTCue.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VTTRegion.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VTTRegion.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VideoTrack.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VideoTrack.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VideoTrackList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/VideoTrackList.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/WebVTTElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/WebVTTElement.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/WebVTTParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/html/track/WebVTTParser.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/WebVTTToken.h
! modules/javafx.web/src/main/native/Source/WebCore/html/track/WebVTTTokenizer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/CommandLineAPIHost.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/CommandLineAPIHost.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/CommandLineAPIHost.idl
! modules/javafx.web/src/main/native/Source/WebCore/inspector/CommandLineAPIModuleSource.js
! modules/javafx.web/src/main/native/Source/WebCore/inspector/DOMEditor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/DOMPatchSupport.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorAuditDOMObject.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorAuditResourcesObject.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorAuditResourcesObject.h
+ modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorAuditResourcesObject.idl
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorCanvas.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorCanvas.h
- modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorClient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorClient.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorController.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorDatabaseResource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorDatabaseResource.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorFrontendClient.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorFrontendClientLocal.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorFrontendClientLocal.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorFrontendHost.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorFrontendHost.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorFrontendHost.idl
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorHistory.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorInstrumentation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorInstrumentation.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorNodeFinder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorNodeFinder.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorOverlay.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorOverlay.h
- modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorOverlayPage.css
- modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorOverlayPage.html
- modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorOverlayPage.js
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InspectorStyleSheet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InstrumentingAgents.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/InstrumentingAgents.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/NetworkResourcesData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/RecordingSwizzleTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/WebInjectedScriptHost.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/WebInjectedScriptManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/WebInjectedScriptManager.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/WorkerInspectorController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorApplicationCacheAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorApplicationCacheAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorCPUProfilerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorCPUProfilerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorCSSAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorCSSAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorCanvasAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorCanvasAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDOMAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDOMAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDOMDebuggerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDOMDebuggerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDOMStorageAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDOMStorageAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDatabaseAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorDatabaseAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorIndexedDBAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorIndexedDBAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorLayerTreeAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorLayerTreeAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorMemoryAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorMemoryAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorNetworkAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorPageAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorPageAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorTimelineAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorTimelineAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorWorkerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/InspectorWorkerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/WebConsoleAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/WebConsoleAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/WebDebuggerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/WebDebuggerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/WebHeapAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/WebHeapAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageAuditAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageAuditAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageConsoleAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageConsoleAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageDebuggerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageDebuggerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageHeapAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageHeapAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageNetworkAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageNetworkAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageRuntimeAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page/PageRuntimeAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/ServiceWorkerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/ServiceWorkerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerAuditAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerAuditAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerConsoleAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerConsoleAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerDebuggerAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerDebuggerAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerNetworkAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerNetworkAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerRuntimeAgent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker/WorkerRuntimeAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/FormattingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/FormattingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/FormattingContextGeometry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/FormattingContextQuirks.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/FormattingState.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/LayoutPhase.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/LayoutPhase.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/LayoutState.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/LayoutState.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/LayoutUnits.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/Verification.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/blockformatting/BlockFormattingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/blockformatting/BlockFormattingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/blockformatting/BlockFormattingContextGeometry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/blockformatting/BlockMarginCollapse.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/displaytree/DisplayBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/displaytree/DisplayBox.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/displaytree/DisplayRect.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/displaytree/DisplayRun.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatAvoider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatAvoider.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatBox.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatingState.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/floats/FloatingState.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineFormattingContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineFormattingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineFormattingContextLineLayout.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineFormattingContextQuirks.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineFormattingState.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineItem.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineLine.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineLine.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineLineBox.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineLineBreaker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineLineBreaker.h
- modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineRun.h
- modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineRunProvider.cpp
- modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineRunProvider.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineTextItem.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/InlineTextItem.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/text/TextUtil.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/inlineformatting/text/TextUtil.h
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutBlockContainer.cpp
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutBlockContainer.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutBox.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutContainer.h
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutInlineBox.cpp
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutInlineBox.h
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutInlineContainer.cpp
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutInlineContainer.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutIterator.h
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutLineBreakBox.cpp
- modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutLineBreakBox.h
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutReplaced.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutTreeBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree/LayoutTreeBuilder.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableFormattingContext.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableFormattingContext.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableFormattingContextGeometry.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableFormattingState.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableFormattingState.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableGrid.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableGrid.h
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableInvalidation.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/layout/tableformatting/TableInvalidation.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/AdClickAttribution.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/AdClickAttribution.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/ApplicationManifestLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ContentFilter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ContentFilter.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/CookieJar.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/CookieJar.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/CrossOriginAccessControl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/CrossOriginAccessControl.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/CrossOriginPreflightResultCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/CrossOriginPreflightResultCache.h
+ modules/javafx.web/src/main/native/Source/WebCore/loader/CustomHeaderFields.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/loader/CustomHeaderFields.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/DocumentLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/DocumentLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/DocumentThreadableLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/DocumentWriter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/DocumentWriter.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/EmptyClients.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/EmptyClients.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/EmptyFrameLoaderClient.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/FetchOptions.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/FormSubmission.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoadRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoadRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoaderClient.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoaderStateMachine.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/FrameLoaderTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/HistoryController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ImageLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ImageLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/LinkHeader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/LinkHeader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/LinkLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/LinkLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/LoadTiming.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/LoaderStrategy.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/MediaResourceLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/MediaResourceLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/NavigationAction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/NavigationAction.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/NavigationDisabler.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/NavigationScheduler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/NavigationScheduler.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/NetscapePlugInStreamLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/NetscapePlugInStreamLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/PingLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/PingLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/PolicyChecker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ProgressTracker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceCryptographicDigest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceCryptographicDigest.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadInfo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadNotifier.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadObserver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadObserver.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadStatistics.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoadStatistics.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceTimingInformation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ResourceTimingInformation.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/SinkDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/SinkDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/SubframeLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/SubframeLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/SubresourceLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/SubresourceLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/TextResourceDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/TextTrackLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/ThreadableLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/WorkerThreadableLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/ApplicationCacheGroup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/ApplicationCacheGroup.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/ApplicationCacheHost.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/ApplicationCacheHost.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/ApplicationCacheStorage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/DOMApplicationCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/DOMApplicationCache.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/appcache/DOMApplicationCache.idl
! modules/javafx.web/src/main/native/Source/WebCore/loader/archive/mhtml/MHTMLArchive.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/archive/mhtml/MHTMLParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedFont.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedFont.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedImage.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedRawResource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResource.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequestInitiators.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequestInitiators.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedSVGDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedSVGDocumentReference.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedSVGFont.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedSVGFont.h
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/KeepaliveRequestTracker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/cache/MemoryCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/icon/IconLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/loader/soup/ResourceLoaderSoup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mapfile-macosx
! modules/javafx.web/src/main/native/Source/WebCore/mapfile-vers
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLAnnotationElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLAnnotationElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLFractionElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLFractionElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLMathElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLMathElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLMencloseElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLMencloseElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLOperatorDictionary.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLOperatorDictionary.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLOperatorElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLOperatorElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLPaddedElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLPaddedElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLPresentationElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLPresentationElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLScriptsElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLScriptsElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLSelectElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLSelectElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLSpaceElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLSpaceElement.h
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLTokenElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLUnderOverElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/mathml/MathMLUnderOverElement.h
! modules/javafx.web/src/main/native/Source/WebCore/page/AbstractDOMWindow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/AbstractDOMWindow.h
! modules/javafx.web/src/main/native/Source/WebCore/page/AutoscrollController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/BarProp.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/BarProp.h
! modules/javafx.web/src/main/native/Source/WebCore/page/BarProp.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/CacheStorageProvider.h
! modules/javafx.web/src/main/native/Source/WebCore/page/CaptionUserPreferences.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Chrome.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Chrome.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ChromeClient.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ClientOrigin.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ContextMenuClient.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ContextMenuController.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/CrossSiteNavigationDataTransfer.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMSelection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMSelection.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMTimer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMTimer.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindowExtension.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindowExtension.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindowProperty.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindowProperty.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DebugPageOverlays.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DeviceController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DeviceController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DiagnosticLoggingClient.h
! modules/javafx.web/src/main/native/Source/WebCore/page/DragController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/DragController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/EditorClient.h
! modules/javafx.web/src/main/native/Source/WebCore/page/EventHandler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/EventHandler.h
! modules/javafx.web/src/main/native/Source/WebCore/page/EventSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/EventSource.h
! modules/javafx.web/src/main/native/Source/WebCore/page/FocusController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/FocusController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Frame.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Frame.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/FrameIdentifier.h
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameSnapshotting.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameSnapshotting.h
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameTree.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameTree.h
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameView.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameView.h
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameViewLayoutContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/FrameViewLayoutContext.h
! modules/javafx.web/src/main/native/Source/WebCore/page/GlobalFrameIdentifier.h
! modules/javafx.web/src/main/native/Source/WebCore/page/History.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/History.h
! modules/javafx.web/src/main/native/Source/WebCore/page/History.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/IntersectionObserver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Location.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Location.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Location.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/MediaProducer.h
! modules/javafx.web/src/main/native/Source/WebCore/page/MemoryRelease.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/MemoryRelease.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Navigator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Navigator.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Navigator.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/NavigatorBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/NavigatorBase.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Page.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Page.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PageConfiguration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PageConfiguration.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PageConsoleClient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PageConsoleClient.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PageGroup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PageGroup.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/PageIdentifier.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PageOverlayController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PageOverlayController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Performance.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Performance.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceEntry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceEntry.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceMonitor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceNavigation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceNavigation.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceResourceTiming.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceResourceTiming.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceTiming.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/PerformanceUserTiming.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PointerCaptureController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PointerCaptureController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PointerLockController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PointerLockController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PrewarmInformation.h
! modules/javafx.web/src/main/native/Source/WebCore/page/PrintContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/PrintContext.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ProcessWarming.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Quirks.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Quirks.h
! modules/javafx.web/src/main/native/Source/WebCore/page/RemoteDOMWindow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/RemoteDOMWindow.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/RenderingUpdateScheduler.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/RenderingUpdateScheduler.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObservation.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObservation.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserver.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserver.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserver.idl
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserverCallback.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserverCallback.idl
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserverEntry.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/ResizeObserverEntry.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/ResourceUsageData.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ResourceUsageOverlay.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ResourceUsageThread.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/ResourceUsageThread.h
! modules/javafx.web/src/main/native/Source/WebCore/page/RuntimeEnabledFeatures.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/RuntimeEnabledFeatures.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Screen.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Screen.h
! modules/javafx.web/src/main/native/Source/WebCore/page/Screen.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/SecurityOrigin.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/SecurityOrigin.h
! modules/javafx.web/src/main/native/Source/WebCore/page/SecurityPolicy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/Settings.yaml
! modules/javafx.web/src/main/native/Source/WebCore/page/SettingsBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/SettingsBase.h
! modules/javafx.web/src/main/native/Source/WebCore/page/SettingsDefaultValues.h
! modules/javafx.web/src/main/native/Source/WebCore/page/SocketProvider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/SocketProvider.h
! modules/javafx.web/src/main/native/Source/WebCore/page/SpatialNavigation.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/SpeechSynthesisClient.h
! modules/javafx.web/src/main/native/Source/WebCore/page/SuspendableTimer.h
! modules/javafx.web/src/main/native/Source/WebCore/page/TextIndicator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UndoItem.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UndoItem.h
! modules/javafx.web/src/main/native/Source/WebCore/page/UndoManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UserContentController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UserContentProvider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UserContentProvider.h
! modules/javafx.web/src/main/native/Source/WebCore/page/UserMessageHandlerDescriptor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UserMessageHandlerDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/page/UserMessageHandlerDescriptorTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/page/UserMessageHandlersNamespace.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/UserMessageHandlersNamespace.h
! modules/javafx.web/src/main/native/Source/WebCore/page/ViewportConfiguration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/ViewportConfiguration.h
! modules/javafx.web/src/main/native/Source/WebCore/page/VisitedLinkStore.h
! modules/javafx.web/src/main/native/Source/WebCore/page/VisualViewport.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/VisualViewport.h
! modules/javafx.web/src/main/native/Source/WebCore/page/VisualViewport.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/WheelEventDeltaFilter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/WindowEventHandlers.idl
! modules/javafx.web/src/main/native/Source/WebCore/page/WindowFeatures.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/WindowFeatures.h
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/AnimationBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/AnimationBase.h
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/CSSAnimationController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/CSSAnimationController.h
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/CSSAnimationControllerPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/CSSPropertyAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/CompositeAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/CompositeAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/ImplicitAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/ImplicitAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/KeyframeAnimation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/animation/KeyframeAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/page/csp/ContentSecurityPolicy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/csp/ContentSecurityPolicy.h
! modules/javafx.web/src/main/native/Source/WebCore/page/csp/ContentSecurityPolicyDirective.h
! modules/javafx.web/src/main/native/Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.h
! modules/javafx.web/src/main/native/Source/WebCore/page/linux/ResourceUsageOverlayLinux.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/linux/ResourceUsageThreadLinux.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/AxisScrollSnapOffsets.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollSnapOffsetsInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingConstraints.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingConstraints.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingCoordinator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingCoordinator.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingMomentumCalculator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingMomentumCalculator.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateFixedNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateFixedNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateFrameHostingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateFrameHostingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateNode.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateOverflowScrollingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateOverflowScrollingNode.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStatePositionedNode.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStatePositionedNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateStickyNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateTree.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingStateTree.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTree.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTree.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeFrameHostingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeFrameHostingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeNode.h
+ modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ScrollingTreeScrollingNodeDelegate.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ThreadedScrollingTree.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/ThreadedScrollingTree.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeFixedNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeFixedNode.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeFrameScrollingNodeNicosia.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeFrameScrollingNodeNicosia.h
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeNicosia.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeStickyNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/page/scrolling/nicosia/ScrollingTreeStickyNode.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/CPUMonitor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Cairo.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/ColorData.gperf
! modules/javafx.web/src/main/native/Source/WebCore/platform/ContentFilterUnblockHandler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ContextMenuItem.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Cookie.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/CountedUserActivity.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Curl.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/DateTimeChooser.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Decimal.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/DragImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/DragImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/EventTrackingRegions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/EventTrackingRegions.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/FileMonitor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/FreeType.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/GStreamer.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/GenericTaskQueue.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/HolePunch.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/HostWindow.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ImageDecoders.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/LayoutUnit.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Length.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Length.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/LocalizedStrings.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/LocalizedStrings.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Logging.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Logging.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/MIMETypeRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/MainThreadSharedTimer.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/MediaCapabilitiesDecodingInfo.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/MediaCapabilitiesEncodingInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/MediaDescription.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/MediaSample.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Pasteboard.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PasteboardItemInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PasteboardStrategy.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PasteboardWriterData.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformKeyboardEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformMouseEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformPasteboard.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformScreen.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformSpeechSynthesisUtterance.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformSpeechSynthesizer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformWheelEvent.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/PointerID.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ReferrerPolicy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/ReferrerPolicy.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/RegistrableDomain.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/RemoteCommandListener.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/RuntimeApplicationChecks.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScreenProperties.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollAnimator.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollAnimatorNone.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollAnimatorSmooth.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollAnimatorSmooth.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollView.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollView.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollableArea.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollableArea.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Scrollbar.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Scrollbar.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ScrollbarThemeComposite.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/SearchPopupMenu.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/SharedBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/SharedStringHash.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/SharedStringHash.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/SourcesGLib.txt
! modules/javafx.web/src/main/native/Source/WebCore/platform/SourcesSoup.txt
! modules/javafx.web/src/main/native/Source/WebCore/platform/SuddenTermination.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/TextureMapper.cmake
! modules/javafx.web/src/main/native/Source/WebCore/platform/Theme.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Theme.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/ThreadGlobalData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Timer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Timer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/TouchAction.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/UserAgent.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/UserAgentQuirks.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/WebGLStateTracker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/WebGLStateTracker.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/Widget.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/Widget.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/animation/AnimationUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/animation/TimingFunction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioBus.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioBus.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioChannel.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioFIFO.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioPullFIFO.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioResampler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioResampler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioResamplerKernel.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioSession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/AudioSession.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/Biquad.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/Cone.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DenormalDisabler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DirectConvolver.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/Distance.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DownSampler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DynamicsCompressor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DynamicsCompressor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DynamicsCompressorKernel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/DynamicsCompressorKernel.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/EqualPowerPanner.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/FFTConvolver.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/FFTFrame.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/HRTFDatabase.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/HRTFDatabaseLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/HRTFElevation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/HRTFElevation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/HRTFKernel.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/HRTFPanner.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/MultiChannelResampler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/MultiChannelResampler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/Panner.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/PlatformAudioData.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/PlatformMediaSession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/PlatformMediaSession.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/PlatformMediaSessionManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/PlatformMediaSessionManager.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/Reverb.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/Reverb.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ReverbAccumulationBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ReverbConvolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ReverbConvolver.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ReverbConvolverStage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ReverbConvolverStage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ReverbInputBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/SincResampler.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/SincResampler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/UpSampler.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/audio/ZeroPole.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/KeyedDecoderCF.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/KeyedDecoderCF.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/KeyedEncoderCF.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/KeyedEncoderCF.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/MainThreadSharedTimerCF.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/MediaAccessibilitySoftLink.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/MediaAccessibilitySoftLink.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/RunLoopObserver.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/cf/RunLoopObserver.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia/CDMInstance.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia/CDMInstanceSession.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia/CDMPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia/clearkey/CDMClearKey.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia/clearkey/CDMClearKey.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/generic/KeyedDecoderGeneric.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/generic/KeyedDecoderGeneric.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/generic/KeyedEncoderGeneric.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/generic/KeyedEncoderGeneric.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/generic/ScrollAnimatorGeneric.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/geoclue/GeolocationProviderGeoclue.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/geoclue/GeolocationProviderGeoclue.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/geoclue/GeolocationProviderGeoclueClient.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ANGLEWebKitBridge.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/BitmapImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/BitmapImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Color.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Color.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ColorUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ColorUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ComplexTextController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/CrossfadeGeneratedImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/CrossfadeGeneratedImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/CustomPaintImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/CustomPaintImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/DisplayRefreshMonitor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/DisplayRefreshMonitorManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/DisplayRefreshMonitorManager.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ExtendedColor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FloatPoint.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FloatPoint3D.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FloatPolygon.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Font.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Font.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCache.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCascade.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCascade.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCascadeDescription.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCascadeDescription.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontCascadeFonts.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontDescription.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontDescription.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontFamilySpecificationNull.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontGenericFamilies.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontGenericFamilies.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontPlatformData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontPlatformData.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontSelector.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FontTaggedSettings.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/FourCC.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GLContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GLContext.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GeneratedImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GlyphBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GlyphMetricsMap.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GradientImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GradientImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContext.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContext.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContext3D.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContext3DAttributes.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContext3DManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContext3DPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContextImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsContextImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/GraphicsLayerClient.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/HEVCUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Image.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Image.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageBackingStore.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageFrame.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageFrameCache.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageOrientation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageOrientation.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImagePaintingOptions.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/InbandTextTrackPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/IntSize.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/IntSize.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/LayoutPoint.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/LayoutRect.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/LayoutSize.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/LegacyCDMSession.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/MediaPlayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/MediaPlayer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/MediaPlayerEnums.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/MediaPlayerPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/NamedImageGeneratedImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/NamedImageGeneratedImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/NativeImage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/OpenGLShims.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/PathUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Pattern.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/PlatformDisplay.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/PlatformDisplay.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Region.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/Region.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/RemoteVideoSample.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/RoundedRect.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/RoundedRect.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ShadowBlur.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ShadowBlur.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/SourceBufferPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/SourceBufferPrivateClient.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/TabSize.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/TextRun.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/TextRun.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/TextTrackRepresentation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/TiledBacking.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/TrackPrivateBase.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/VelocityData.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/VelocityData.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/WidthIterator.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/ImageRotationSessionVT.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/ImageRotationSessionVT.mm
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/ImageTransferSessionVT.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/ImageTransferSessionVT.mm
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/TextureCacheCV.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/TextureCacheCV.mm
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/VideoTextureCopierCV.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cv/VideoTextureCopierCV.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists/DisplayListItems.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists/DisplayListItems.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists/DisplayListReplayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/egl/GLContextEGL.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/egl/GLContextEGLLibWPE.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/FEBlend.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/FEComposite.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/FilterOperation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/SourceAlpha.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/SourceAlpha.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/SourceGraphic.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/SourceGraphic.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/freetype/FontCacheFreeType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/freetype/FontPlatformDataFreeType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroup.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroupAllocator.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroupBinding.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroupDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroupLayout.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroupLayoutBinding.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBindGroupLayoutDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBlendDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBufferBinding.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBufferDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUBufferUsage.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUColorStateDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUColorWriteBits.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUCommandBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUCompareFunction.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUComputePassEncoder.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUComputePipeline.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUComputePipelineDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUDevice.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUDevice.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUError.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUError.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUErrorFilter.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUErrorScopes.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUErrorScopes.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUExtent3D.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUInputStateDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPULimits.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPULoadOp.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUObjectBase.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUOutOfMemoryError.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUPipelineDescriptorBase.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUPipelineLayout.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUPipelineLayout.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUPipelineLayoutDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUPipelineStageDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUProgrammablePassEncoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUProgrammablePassEncoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUQueue.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPURenderPassColorAttachmentDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPURenderPassDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPURenderPassEncoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPURenderPipeline.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPURenderPipelineDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPURequestAdapterOptions.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUSampler.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUSamplerDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUShaderModule.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUStoreOp.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUSwapChain.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUSwapChainDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUTexture.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUTextureDescriptor.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUTextureDimension.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUTextureFormat.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUTextureUsage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUUtils.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUValidationError.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUValidationError.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUVertexAttributeDescriptor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUVertexBufferDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/GPUVertexInputDescriptor.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/gpu/Texture.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/holepunch/MediaPlayerPrivateHolePunch.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/holepunch/MediaPlayerPrivateHolePunch.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOOriginalFormatBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOProtectionSchemeInfoBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOProtectionSchemeInfoBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOProtectionSystemSpecificHeaderBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOProtectionSystemSpecificHeaderBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOSchemeInformationBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOSchemeInformationBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOSchemeTypeBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOTrackEncryptionBox.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOVTTCue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso/ISOVTTCue.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/BufferImageJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/BufferImageJava.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/FontCacheJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/FontCustomPlatformData.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/FontPlatformDataJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/ImageBufferJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/ImageDecoderJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/PathJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/NicosiaAnimation.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/NicosiaAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/NicosiaPaintingOperation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/NicosiaPlatformLayer.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/NicosiaSceneIntegration.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/NicosiaSceneIntegration.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaBackingStoreTextureMapperImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaBackingStoreTextureMapperImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaCompositionLayerTextureMapperImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaCompositionLayerTextureMapperImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaContentLayerTextureMapperImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaContentLayerTextureMapperImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaGC3DLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaGC3DLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaImageBackingTextureMapperImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia/texmap/NicosiaImageBackingTextureMapperImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/Extensions3DOpenGL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/Extensions3DOpenGLCommon.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/Extensions3DOpenGLCommon.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/Extensions3DOpenGLES.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGLES.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opengl/TemporaryOpenGLSetting.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opentype/OpenTypeUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/BitmapTexture.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/BitmapTextureGL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/GraphicsContext3DTextureMapper.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperAnimation.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperAnimation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperGC3DPlatformLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperGC3DPlatformLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperGLHeaders.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerBuffer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerBuffer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerProxy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/coordinated/Tile.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap/coordinated/TiledBackingStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/AffineTransform.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/AffineTransform.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/TransformOperations.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/TransformState.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/TransformState.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms/TransformationMatrix.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/wayland/PlatformDisplayWayland.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/ScalableImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/ScalableImageDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/ScalableImageDecoderFrame.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/bmp/BMPImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/bmp/BMPImageDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/bmp/BMPImageReader.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/gif/GIFImageReader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/gif/GIFImageReader.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/ico/ICOImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/ico/ICOImageDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/jpeg2000/JPEG2000ImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/image-decoders/webp/WEBPImageDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/DragImageJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/LocalizedStringsJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/PasteboardJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/RenderThemeJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/TextBreakIteratorJava.cpp
= modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp
= modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/WidgetJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/libwpe/PasteboardLibWPE.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/libwpe/PlatformKeyboardEventLibWPE.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities/AudioConfiguration.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities/MediaEngineConfigurationFactory.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities/MediaEngineConfigurationFactory.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities/VideoConfiguration.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediarecorder/MediaRecorderPrivateAVFImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediarecorder/MediaRecorderPrivateAVFImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/AudioTrackPrivateMediaStream.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/CaptureDeviceManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/CaptureDeviceManager.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaConstraints.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaConstraints.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaStreamPrivate.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaStreamPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaStreamRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RTCDTMFSenderBackend.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RTCDTMFSenderHandler.h
- modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RTCDTMFSenderHandlerClient.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeIncomingAudioSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeIncomingAudioSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeIncomingVideoSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeIncomingVideoSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceCapabilities.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceCenter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceCenter.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceFactory.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceSettings.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceSettings.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeMediaSourceSupportedConstraints.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeOutgoingAudioSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeOutgoingAudioSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeOutgoingVideoSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeOutgoingVideoSource.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeVideoCaptureSource.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeVideoCaptureSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeVideoSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/RealtimeVideoSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/VideoPreset.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/VideoTrackPrivateMediaStream.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/GStreamerVideoDecoderFactory.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/GStreamerVideoDecoderFactory.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/GStreamerVideoEncoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/GStreamerVideoEncoderFactory.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/GStreamerVideoEncoderFactory.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCDTMFSenderBackend.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCDTMFSenderBackend.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCProvider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCProvider.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCProviderCocoa.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCProviderCocoa.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCProviderGStreamer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/GeolocationClientMock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/GeolocationClientMock.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MediaEngineConfigurationFactoryMock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MediaEngineConfigurationFactoryMock.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MediaPlaybackTargetPickerMock.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MockRealtimeAudioSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MockRealtimeAudioSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MockRealtimeMediaSourceCenter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MockRealtimeMediaSourceCenter.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MockRealtimeVideoSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/MockRealtimeVideoSource.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/PlatformSpeechSynthesizerMock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/RTCDataChannelHandlerMock.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/RTCNotifiersMock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource/MockBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource/MockTracks.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/BlobRegistry.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/BlobRegistryImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/BlobRegistryImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/BlobResourceHandle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/CacheValidation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/CacheValidation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/CookieRequestHeaderFieldProxy.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/CredentialStorage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/CredentialStorage.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/DNSResolveQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/DataURLDecoder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/DataURLDecoder.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/FormData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/FormData.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/HTTPHeaderMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/HTTPHeaderMap.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/HTTPParsers.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/HTTPParsers.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/MIMEHeader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/NetworkStateNotifier.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/NetworkStorageSession.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/NetworkStorageSession.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ParsedContentType.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ParsedContentType.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceErrorBase.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceHandle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceHandle.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceRequestBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceRequestBase.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceResponseBase.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/SocketStreamHandle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/SocketStreamHandle.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/SocketStreamHandleImpl.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/StoredCredentialsPolicy.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/NetworkStorageSessionJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/playstation/UserAgentPlayStation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/soup/PublicSuffixSoup.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/soup/URLSoup.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteDatabase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteDatabase.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteDatabaseTracker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteDatabaseTracker.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteFileSystem.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteFileSystem.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/sql/SQLiteStatement.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/BidiResolver.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/Hyphenation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/Hyphenation.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/LocaleICU.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/LocaleNone.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/PlatformLocale.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/SegmentedString.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecICU.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecICU.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecLatin1.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecReplacement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecUTF16.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecUTF8.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextCodecUserDefined.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextEncoding.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/TextEncodingRegistry.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/text/hyphen/HyphenationLibHyphen.cpp
- modules/javafx.web/src/main/native/Source/WebCore/platform/text/icu/UTextProvider.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/vr/openvr/VRPlatformDisplayOpenVR.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/vr/openvr/VRPlatformManagerOpenVR.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/vr/openvr/VRPlatformManagerOpenVR.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/BString.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/BString.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/BitmapInfo.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/BitmapInfo.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/COMPtr.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ClipboardUtilitiesWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ClipboardUtilitiesWin.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/CursorWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DefWndProcWindowClass.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DefWndProcWindowClass.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DelayLoadedModulesEnumerator.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DelayLoadedModulesEnumerator.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DragDataWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DragImageCGWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DragImageCairoWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DragImageDirect2D.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/DragImageWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/EventLoopWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/GDIObjectCounter.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/GDIObjectCounter.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/GDIUtilities.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/GDIUtilities.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/HWndDC.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ImportedFunctionsEnumerator.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ImportedFunctionsEnumerator.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ImportedModulesEnumerator.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ImportedModulesEnumerator.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ImportedModulesEnumeratorBase.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/KeyEventWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/LocalizedStringsWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/LoggingWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/MIMETypeRegistryWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/MainThreadSharedTimerWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PEImage.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PEImage.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PasteboardWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PlatformMouseEventWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PlatformScreenWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PopupMenuWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/PopupMenuWin.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/SSLKeyGeneratorWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ScrollbarThemeWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/ScrollbarThemeWin.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/SearchPopupMenuDB.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/SearchPopupMenuDB.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/SearchPopupMenuWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/SearchPopupMenuWin.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/SharedBufferWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/StructuredExceptionHandlerSuppressor.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/StructuredExceptionHandlerSuppressor.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/TemporaryLinkStubs.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/UserAgentWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WCDataObject.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WCDataObject.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WebCoreBundleWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WebCoreBundleWin.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WebCoreInstanceHandle.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WebCoreInstanceHandle.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WebCoreTextRenderer.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WebCoreTextRenderer.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WheelEventWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WidgetWin.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WindowMessageBroadcaster.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WindowMessageBroadcaster.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WindowMessageListener.h
+ modules/javafx.web/src/main/native/Source/WebCore/platform/win/WindowsTouch.h
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMMimeTypeArray.cpp
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMMimeTypeArray.h
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMMimeTypeArray.idl
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMPlugin.cpp
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMPlugin.h
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMPluginArray.cpp
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMPluginArray.h
! modules/javafx.web/src/main/native/Source/WebCore/plugins/DOMPluginArray.idl
! modules/javafx.web/src/main/native/Source/WebCore/plugins/PluginData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/BorderEdge.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/BreakLines.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/CSSFilter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/ClipRect.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/ClipRect.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/ComplexLineLayout.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/ComplexLineLayout.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/CounterNode.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/CounterNode.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/EllipsisBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/EllipsisBox.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/EventRegion.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/EventRegion.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/FixedTableLayout.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/FloatingObjects.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/Grid.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/Grid.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/GridBaselineAlignment.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/GridBaselineAlignment.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/GridLayoutFunctions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/GridLayoutFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/GridTrackSizingAlgorithm.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/HitTestRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/HitTestResult.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/HitTestResult.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/ImageQualityController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/ImageQualityController.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/InlineBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/InlineElementBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/InlineFlowBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/InlineFlowBox.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/InlineIterator.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/InlineTextBox.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/LayerAncestorClippingStack.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/LayerAncestorClippingStack.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/LayerOverlapMap.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/LayerOverlapMap.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/PaintFrequencyTracker.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/PaintInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/PaintPhase.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBlock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBlock.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBlockFlow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBlockFlow.h
- modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBlockLineLayout.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBox.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBoxModelObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderBoxModelObject.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderButton.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderButton.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderCounter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderCounter.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderElement.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderEmbeddedObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderEmbeddedObject.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderFlexibleBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderFragmentContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderFragmentedFlow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderFullScreen.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderGeometryMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderGrid.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderIFrame.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderImage.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderInline.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderInline.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerBacking.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerBacking.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerCompositor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerCompositor.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerFilters.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerModelObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLayerModelObject.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderLineBreak.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderListBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderListBox.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderListMarker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMarquee.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMenuList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMultiColumnFlow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMultiColumnFlow.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMultiColumnSet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMultiColumnSet.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderMultiColumnSpannerPlaceholder.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderObject.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderObject.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderReplaced.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderRubyBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderRubyBase.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderRubyText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderRubyText.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderScrollbar.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderScrollbar.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderSearchField.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderSearchField.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderSnapshottedPlugIn.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTable.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTable.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTableCell.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTableSection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTableSection.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTextControlMultiLine.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTextControlSingleLine.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTextControlSingleLine.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTheme.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTheme.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeCocoa.mm
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeGtk.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeGtk.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeIOS.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeIOS.mm
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeMac.mm
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeWin.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeWin.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTreeAsText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderTreeAsText.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderVTTCue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderVideo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderView.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderView.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderWidget.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RootInlineBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/RootInlineBox.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/ScrollAlignment.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SelectionRangeData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SelectionRangeData.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayout.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutFunctions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutPagination.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutTextFragmentIterator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutTextFragmentIterator.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextAutoSizing.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextDecorationPainter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextDecorationPainter.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextPaintStyle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextPaintStyle.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextPainter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/TextPainter.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/line/BreakingContext.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/line/LineBreaker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/line/LineBreaker.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/line/LineInlineHeaders.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/line/LineLayoutInterfaceTextBoxes.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/line/LineLayoutInterfaceTextBoxes.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/line/LineWidth.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/MathOperator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/MathOperator.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLBlock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLBlock.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLFraction.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLFraction.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLMath.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLMenclose.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLPadded.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLRoot.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLRow.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLScripts.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLSpace.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLToken.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes/BoxShape.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes/RasterShape.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes/RasterShape.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes/Shape.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes/ShapeOutsideInfo.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes/ShapeOutsideInfo.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/BasicShapes.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/BasicShapes.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/CollapsedBorderValue.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/ContentData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/ContentData.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/CounterContent.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/CounterDirectives.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/FillLayer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/FillLayer.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/KeyframeList.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/NinePieceImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/NinePieceImage.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/RenderStyle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/RenderStyle.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/RenderStyleConstants.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/SVGRenderStyleDefs.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/ShadowData.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleColorScheme.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleCustomPropertyData.h
- modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleDashboardRegion.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleRareInheritedData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleRareInheritedData.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleRareNonInheritedData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleRareNonInheritedData.h
- modules/javafx.web/src/main/native/Source/WebCore/rendering/style/StyleSupportedColorSchemes.h
+ modules/javafx.web/src/main/native/Source/WebCore/rendering/style/TextSizeAdjustment.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/TextSizeAdjustment.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/style/WillChangeData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGBlock.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGBlock.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGInline.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGInlineText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGRect.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceContainer.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceFilter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceFilter.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceGradient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceMasker.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourcePattern.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGShape.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGText.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGInlineTextBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGPathData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGPathData.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGRenderSupport.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGRenderTreeAsText.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGRenderTreeAsText.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGResources.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGResourcesCache.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGTextLayoutAttributesBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/SVGTextMetricsBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilder.h
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilderContinuation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilderFirstLetter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilderInline.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilderList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeBuilderSVG.cpp
! modules/javafx.web/src/main/native/Source/WebCore/rendering/updating/RenderTreeUpdater.cpp
! modules/javafx.web/src/main/native/Source/WebCore/replay/UserInputBridge.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/Storage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/storage/Storage.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/Storage.idl
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageArea.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageMap.cpp
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageMap.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageNamespace.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageNamespaceProvider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageNamespaceProvider.h
+ modules/javafx.web/src/main/native/Source/WebCore/storage/StorageQuotaManager.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/storage/StorageQuotaManager.h
+ modules/javafx.web/src/main/native/Source/WebCore/storage/StorageQuotaUser.h
! modules/javafx.web/src/main/native/Source/WebCore/storage/StorageType.h
! modules/javafx.web/src/main/native/Source/WebCore/style/AttributeChangeInvalidation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/AttributeChangeInvalidation.h
! modules/javafx.web/src/main/native/Source/WebCore/style/ClassChangeInvalidation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/IdChangeInvalidation.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/IdChangeInvalidation.h
! modules/javafx.web/src/main/native/Source/WebCore/style/InlineTextBoxStyle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/InlineTextBoxStyle.h
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleInvalidationFunctions.h
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleInvalidator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/StylePendingResources.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleRelations.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleResolveForDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleSharingResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/style/StyleTreeResolver.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAltGlyphElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAltGlyphElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAngle.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAngleValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateColorElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateColorElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateElementBase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateElementBase.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateMotionElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateMotionElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateTransformElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimateTransformElement.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedAngle.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedAngle.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedBoolean.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedColor.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedColor.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedEnumeration.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedEnumeration.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedInteger.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedInteger.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedIntegerOptionalInteger.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedIntegerOptionalInteger.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedLength.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedLength.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedLengthList.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedLengthList.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedNumber.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedNumber.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedNumberList.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedNumberList.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedNumberOptionalNumber.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedNumberOptionalNumber.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedPath.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedPath.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedPointList.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedPointList.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedPreserveAspectRatio.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedPreserveAspectRatio.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedRect.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedRect.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedString.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedString.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedTransformList.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedTransformList.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedType.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedTypeAnimator.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatedTypeAnimator.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimationElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimationElement.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGAnimatorFactory.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGCircleElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGCircleElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGClipPathElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGClipPathElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGComponentTransferFunctionElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGComponentTransferFunctionElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGCursorElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGCursorElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGDefsElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGDocument.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGDocument.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGDocumentExtensions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGDocumentExtensions.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGEllipseElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGEllipseElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGExternalResourcesRequired.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGExternalResourcesRequired.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEBlendElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEBlendElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEColorMatrixElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEColorMatrixElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEComponentTransferElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEComponentTransferElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFECompositeElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFECompositeElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEConvolveMatrixElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEConvolveMatrixElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEDiffuseLightingElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEDiffuseLightingElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEDisplacementMapElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEDisplacementMapElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEDropShadowElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEDropShadowElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEFloodElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEFloodElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEGaussianBlurElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEGaussianBlurElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEImageElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEImageElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFELightElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFELightElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEMergeElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEMergeElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEMergeNodeElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEMergeNodeElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEMorphologyElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEMorphologyElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEOffsetElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFEOffsetElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFESpecularLightingElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFESpecularLightingElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFETileElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFETileElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFETurbulenceElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFETurbulenceElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFilterElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFilterElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFilterPrimitiveStandardAttributes.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFilterPrimitiveStandardAttributes.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFitToViewBox.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFitToViewBox.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFontElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFontFaceElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFontFaceElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFontFaceUriElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGFontFaceUriElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGForeignObjectElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGForeignObjectElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGeometryElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGeometryElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGlyphRefElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGlyphRefElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGradientElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGradientElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGraphicsElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGGraphicsElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGImageElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGImageElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGImageLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGImageLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLangSpace.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLangSpace.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLength.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLengthList.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLengthList.idl
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLengthListValues.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLengthListValues.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLineElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLineElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLinearGradientElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGLinearGradientElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMPathElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMPathElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMarkerElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMarkerElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMarkerTypes.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMaskElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMaskElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMatrix.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMatrix.idl
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGMatrixValue.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGNumber.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGNumberList.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGNumberList.idl
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGNumberListValues.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGNumberListValues.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGParserUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGParserUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathByteStream.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSeg.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegArc.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegArcAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegArcRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegClosePath.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoCubic.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoCubicAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoCubicRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoCubicSmooth.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoCubicSmoothAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoCubicSmoothRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoQuadratic.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoQuadraticAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoQuadraticRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoQuadraticSmoothAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegCurvetoQuadraticSmoothRel.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegImpl.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoHorizontal.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoHorizontalAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoHorizontalRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoVertical.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoVerticalAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegLinetoVerticalRel.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegList.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegList.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegList.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegListBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegListBuilder.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegListSource.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegListSource.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegListValues.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegListValues.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegMovetoAbs.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegMovetoRel.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegValue.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathSegWithContext.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathStringBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathUtilities.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPathUtilities.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPatternElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPatternElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPoint.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPoint.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPointList.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPointList.idl
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPointListValues.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPointListValues.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPolyElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPolyElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGPreserveAspectRatio.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGRadialGradientElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGRadialGradientElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGRect.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGRectElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGRectElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSVGElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSVGElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSVGElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGScriptElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGScriptElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSetElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStopElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStopElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStringList.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStringList.idl
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStringListValues.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStringListValues.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStyleElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGStyleElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSwitchElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSymbolElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGSymbolElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTRefElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTRefElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTests.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTests.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTests.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextContentElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextContentElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextPathElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextPathElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextPositioningElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTextPositioningElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGToOTFFontConversion.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGToOTFFontConversion.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransform.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransform.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransform.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformDistance.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformList.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformList.idl
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformListValues.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformListValues.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformValue.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformable.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGTransformable.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGURIReference.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGURIReference.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGUseElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGUseElement.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/SVGValue.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGViewElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGViewElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGViewElement.idl
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGViewSpec.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGViewSpec.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGZoomAndPan.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGZoomAndPan.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/SVGZoomAndPanType.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/animation/SMILTimeContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/animation/SMILTimeContainer.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/animation/SVGSMILElement.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/animation/SVGSMILElement.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/SVGImage.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/SVGImage.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/SVGImageForContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/SVGImageForContainer.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/filters/SVGFEImage.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/filters/SVGFilterBuilder.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/filters/SVGFilterBuilder.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedDecoratedProperty.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedEnumerationPropertyTearOff.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedListPropertyTearOff.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPathSegListPropertyTearOff.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPathSegListPropertyTearOff.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPrimitiveProperty.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedProperty.cpp
! modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedProperty.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyAccessor.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyAccessorImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyAnimator.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyAnimatorImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyDescription.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyList.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyPairAccessor.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyPairAccessorImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyPairAnimator.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyPairAnimatorImpl.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyTearOff.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyType.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedStaticPropertyTearOff.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedTransformListPropertyTearOff.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedValueProperty.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationAdditiveFunction.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationAdditiveListFunction.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationAdditiveListFunctionImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationAdditiveValueFunction.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationAdditiveValueFunctionImpl.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationAdditiveValueFunctionImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationDiscreteFunction.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationDiscreteFunctionImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimationFunction.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttribute.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeAccessor.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeAnimator.cpp
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeAnimator.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeOwnerProxy.cpp
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeOwnerProxy.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeOwnerProxyImpl.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAttributeRegistry.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGDecoratedEnumeration.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGDecoratedPrimitive.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGDecoratedProperty.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGList.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGListProperty.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGListPropertyTearOff.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGMatrixTearOff.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGMemberAccessor.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPointerMemberAccessor.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPrimitiveList.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPrimitivePropertyAnimator.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPrimitivePropertyAnimatorImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGProperty.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyAccessor.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyAccessorImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyAnimator.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyAnimatorFactory.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyList.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyOwner.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyOwnerRegistry.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyRegistry.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyTearOff.h
! modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGPropertyTraits.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGSharedPrimitiveProperty.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGStaticListPropertyTearOff.h
- modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGStaticPropertyTearOff.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGValueProperty.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGValuePropertyAnimator.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGValuePropertyAnimatorImpl.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGValuePropertyList.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGValuePropertyListAnimator.h
+ modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGValuePropertyListAnimatorImpl.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/InternalSettings.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/InternalSettings.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/InternalSettings.idl
! modules/javafx.web/src/main/native/Source/WebCore/testing/Internals.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/Internals.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/Internals.idl
! modules/javafx.web/src/main/native/Source/WebCore/testing/LegacyMockCDM.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/LegacyMockCDM.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockCDMFactory.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockCDMFactory.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockContentFilter.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockGamepadProvider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockLibWebRTCPeerConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockLibWebRTCPeerConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockPaymentCoordinator.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockPaymentCoordinator.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/MockPaymentCoordinator.idl
! modules/javafx.web/src/main/native/Source/WebCore/testing/ServiceWorkerInternals.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/ServiceWorkerInternals.h
! modules/javafx.web/src/main/native/Source/WebCore/testing/ServiceWorkerInternals.idl
! modules/javafx.web/src/main/native/Source/WebCore/testing/js/WebCoreTestSupport.cpp
! modules/javafx.web/src/main/native/Source/WebCore/testing/js/WebCoreTestSupport.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/AbstractWorker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/AbstractWorker.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/DedicatedWorkerGlobalScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/DedicatedWorkerGlobalScope.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/Worker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/Worker.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerConsoleClient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerConsoleClient.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerEventQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerEventQueue.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerGlobalScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerGlobalScope.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerMessagingProxy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerRunLoop.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerScriptLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerScriptLoader.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerThread.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/WorkerThread.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ExtendableEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ExtendableEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ExtendableMessageEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ExtendableMessageEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/FetchEvent.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/FetchEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/SWClientConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/SWClientConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorker.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerClientData.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerClientQueryOptions.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerClients.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerClients.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerContainer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerContainer.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerContainer.idl
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerContextData.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerGlobalScope.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerJob.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerJob.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerJobClient.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerJobData.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerProvider.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerRegistration.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerRegistration.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/ServiceWorkerRegistrationKey.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/context/SWContextManager.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/context/SWContextManager.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/context/ServiceWorkerFetch.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/context/ServiceWorkerInspectorProxy.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/context/ServiceWorkerThread.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/RegistrationDatabase.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/RegistrationDatabase.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/RegistrationStore.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/RegistrationStore.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServer.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServerJobQueue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServerToContextConnection.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServerToContextConnection.h
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServerWorker.cpp
! modules/javafx.web/src/main/native/Source/WebCore/workers/service/server/SWServerWorker.h
! modules/javafx.web/src/main/native/Source/WebCore/worklets/PaintWorkletGlobalScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/worklets/PaintWorkletGlobalScope.h
! modules/javafx.web/src/main/native/Source/WebCore/worklets/Worklet.cpp
! modules/javafx.web/src/main/native/Source/WebCore/worklets/Worklet.h
! modules/javafx.web/src/main/native/Source/WebCore/worklets/WorkletConsoleClient.cpp
! modules/javafx.web/src/main/native/Source/WebCore/worklets/WorkletConsoleClient.h
! modules/javafx.web/src/main/native/Source/WebCore/worklets/WorkletGlobalScope.cpp
! modules/javafx.web/src/main/native/Source/WebCore/worklets/WorkletGlobalScope.h
! modules/javafx.web/src/main/native/Source/WebCore/worklets/WorkletScriptController.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/DOMParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/DOMParser.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/DOMParser.idl
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLErrors.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequest.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequest.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequestEventTarget.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequestProgressEvent.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequestProgressEventThrottle.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequestProgressEventThrottle.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequestUpload.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLHttpRequestUpload.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XMLTreeViewer.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathExpression.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathFunctions.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathPredicate.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathStep.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathStep.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/XPathValue.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XSLStyleSheetLibxslt.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XSLTProcessor.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/XSLTProcessorLibxslt.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/parser/CharacterReferenceParserInlines.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/parser/XMLDocumentParser.cpp
! modules/javafx.web/src/main/native/Source/WebCore/xml/parser/XMLDocumentParser.h
! modules/javafx.web/src/main/native/Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/WebKitLegacy/PlatformJava.cmake
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageAreaImpl.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageAreaImpl.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageAreaSync.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageAreaSync.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageNamespaceImpl.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageNamespaceImpl.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageSyncManager.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageTracker.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/WebDatabaseProvider.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/WebDatabaseProvider.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/WebStorageNamespaceProvider.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/WebStorageNamespaceProvider.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/WebCoreSupport/NetworkStorageSessionMap.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/WebCoreSupport/WebResourceLoadScheduler.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/WebCoreSupport/WebResourceLoadScheduler.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaDOMWindow.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaDocument.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaHTMLElement.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/ChromeClientJava.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/ChromeClientJava.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/EditorClientJava.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/EditorClientJava.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/PageCacheJava.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/PlatformStrategiesJava.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/SearchPopupMenuJava.cpp
+ modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/SearchPopupMenuJava.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/VisitedLinkStoreJava.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/VisitedLinkStoreJava.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/WebPage.cpp
! modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/WebPage.h
! modules/javafx.web/src/main/native/Source/WebKitLegacy/mac/Configurations/Version.xcconfig
! modules/javafx.web/src/main/native/Source/bmalloc/CMakeLists.txt
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Algorithm.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/AllIsoHeaps.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/AllIsoHeaps.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Allocator.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/AvailableMemory.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/BCompiler.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/BExport.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/BPlatform.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/BVMTags.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Cache.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/CryptoRandom.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Deallocator.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/DebugHeap.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/DebugHeap.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Environment.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Environment.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/FreeList.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Gigacage.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Gigacage.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Heap.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Heap.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoAllocator.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoAllocatorInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoDeallocator.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoDeallocatorInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoDirectory.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoDirectoryInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoHeap.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoHeapImpl.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoHeapImpl.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoHeapImplInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoHeapInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoPage.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoPage.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoPageInlines.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedConfig.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedHeap.cpp
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedHeap.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedHeapInlines.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedPage.cpp
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedPage.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoSharedPageInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoTLS.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoTLS.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoTLSEntry.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoTLSInlines.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoTLSLayout.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/IsoTLSLayout.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/LargeMap.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/LargeRange.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/PerThread.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/PerThread.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/ProcessCheck.mm
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Scavenger.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Scavenger.h
- modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/SmallAllocator.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/SmallPage.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/StaticPerProcess.h
+ modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/StdLibExtras.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/VMAllocate.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/VMHeap.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/VMHeap.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/Zone.h
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/bmalloc.cpp
! modules/javafx.web/src/main/native/Source/bmalloc/bmalloc/darwin/MemoryStatusSPI.h
- modules/javafx.web/src/main/native/Source/bmalloc/test/testbmalloc.cpp
! modules/javafx.web/src/main/native/Source/cmake/FindGLIB.cmake
! modules/javafx.web/src/main/native/Source/cmake/FindGTK3.cmake
! modules/javafx.web/src/main/native/Source/cmake/GStreamerChecks.cmake
! modules/javafx.web/src/main/native/Source/cmake/GtkDoc.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsCommon.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsGTK.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsJSCOnly.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsJava.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsMSVC.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsMac.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsPlayStation.cmake
! modules/javafx.web/src/main/native/Source/cmake/OptionsWin.cmake
! modules/javafx.web/src/main/native/Source/cmake/WebKitCompilerFlags.cmake
! modules/javafx.web/src/main/native/Source/cmake/WebKitFS.cmake
! modules/javafx.web/src/main/native/Source/cmake/WebKitFeatures.cmake
! modules/javafx.web/src/main/native/Source/cmake/WebKitMacros.cmake
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/AccessibilityController.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/AccessibilityTextMarker.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/AccessibilityUIElement.cpp
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/AccessibilityUIElement.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/CMakeLists.txt
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/DumpRenderTreePrefix.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/GCController.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/Scripts/check-xcfilelists.sh
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestNetscapePlugIn/ForwardingHeaders/WebKit/npapi.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestNetscapePlugIn/ForwardingHeaders/WebKit/npfunctions.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestNetscapePlugIn/ForwardingHeaders/WebKit/npruntime.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestNetscapePlugIn/main.cpp
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestOptions.cpp
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestOptions.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestRunner.cpp
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/TestRunner.h
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/java/DumpRenderTree.cpp
! modules/javafx.web/src/main/native/Tools/DumpRenderTree/java/TestRunnerJava.cpp
! modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
! modules/javafx.web/src/main/native/Tools/Scripts/build-webkit
! modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm
! modules/javafx.web/src/main/native/Tools/Scripts/webkitperl/FeatureList.pm
! modules/javafx.web/src/main/native/Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
! modules/javafx.web/src/main/native/Tools/TestRunnerShared/UIScriptContext/UIScriptContext.h
! modules/javafx.web/src/main/native/Tools/TestRunnerShared/UIScriptContext/UIScriptController.cpp
! modules/javafx.web/src/main/native/Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
! modules/javafx.web/src/main/native/Tools/TestRunnerShared/spi/CoreGraphicsTestSPI.h
! modules/javafx.web/src/main/native/Tools/TestRunnerShared/spi/PencilKitTestSPI.h

From rlichten at openjdk.java.net  Fri Jan 24 06:25:27 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Fri, 24 Jan 2020 06:25:27 GMT
Subject: [Rev 01] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <7o-JcZfwu4Oxcsgsw62n8ml1rc-Sd0DrYHuYnFDgSng=.cc3a5528-dd9b-42fb-bd27-cae32c6fe189@github.com>

> Test simulates a single mouse-released event.
> Fix simply guards against the null case.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 30290116: 8237372: NullPointerException in TabPaneSkin.stopDrag

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/89/files
  - new: https://git.openjdk.java.net/jfx/pull/89/files/923a63b2..30290116

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

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

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

From rlichten at openjdk.java.net  Fri Jan 24 06:25:41 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Fri, 24 Jan 2020 06:25:41 GMT
Subject: [Rev 01] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <WScZ8yNafusZ-Vo_Ch-YcrQwBE8iL3w2-RMbXHinaAM=.c4f9f50f-123a-4292-9077-368ee8c0135f@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <WScZ8yNafusZ-Vo_Ch-YcrQwBE8iL3w2-RMbXHinaAM=.c4f9f50f-123a-4292-9077-368ee8c0135f@github.com>
Message-ID: <m3WDOIJNzwMGWhqbstD_mbJ4C0mqsqAxHTKCp2cvgPk=.c6672c12-ad2e-47b6-9084-cc2d6b9b1ba2@github.com>

On Wed, 22 Jan 2020 08:01:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 2216:
> 
>> 2215:         // Animate tab header being dragged to its final position.
>> 2216:         if (dragTabHeader != null) {
>> 2217:             dragHeaderSourceX = dragTabHeader.getLayoutX();
> 
> This is a situation when reorder was not started.
> So a check as `else if (dragState == DragState.REORDER)` seems more correct instead of `null` check. With this `else if` the `return;` on line 2213 can be removed.

You're right, this makes the method cleaner and easier to understand. I've adapted the PR.

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

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

From jpereda at openjdk.java.net  Fri Jan 24 11:38:01 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 24 Jan 2020 11:38:01 GMT
Subject: RFR: 8237770: Error creating fragment phong shader on iOS
Message-ID: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>

This PR defines a pre-processor in the phong frag files to avoid inline declaration of #extension when several frags are combined that leads to the error:

syntax error: #extension must always be before any non-preprocessor tokens

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

Commits:
 - 14ccbe6a: Define pre-processor in frag files to avoid inline declaration of #extension when several frags are combined

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

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

From Rony.Flatscher at wu.ac.at  Fri Jan 24 12:27:07 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Fri, 24 Jan 2020 13:27:07 +0100
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <AM0PR07MB6372F3BA13060B97A8E4FACBE80F0@AM0PR07MB6372.eurprd07.prod.outlook.com>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
 <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
 <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
 <AM0PR07MB6372F3BA13060B97A8E4FACBE80F0@AM0PR07MB6372.eurprd07.prod.outlook.com>
Message-ID: <1ad0b1d5-7256-2dce-d8ed-55129adf4308@wu.ac.at>

On 23.01.2020 18:09, Anthony Vanelverdinghe wrote:
> On 22/01/2020 18:52, Rony G. Flatscher wrote:
... cut ...
>> Maybe one more question: there would be an optimization possible by compiling scripts for script
>> engines that have the javax.script.Compilable interface implemented and use the compiled version
>> to execute/evaluate the scripts (may be helpful for event handler code e.g. for onMouseMove event
>> handlers). Can the fix include such an optimization or should there be a separate discussion/RFE
>> for it beforehand? (Adding this would be trivial in the context of the fix, however the bug
>> description would not hint at such an optimization.)
> In my opinion, this should be filed as a separate issue, since it's unrelated to the current issue
> and is an enhancement, rather than a bug.

Thank you very much Anthony, will do.

---rony


From ghb at openjdk.java.net  Fri Jan 24 14:38:09 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Fri, 24 Jan 2020 14:38:09 GMT
Subject: [Rev 03] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <gxjfTxOHYj7IX9ul8ajYzrgqwOJPsbV7P0TCNP8Im1M=.e30cf9ea-a130-441e-838b-08fdf5853cf7@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>
 <gxjfTxOHYj7IX9ul8ajYzrgqwOJPsbV7P0TCNP8Im1M=.e30cf9ea-a130-441e-838b-08fdf5853cf7@github.com>
Message-ID: <PUvRbpTKvX-aqvuuQSxL93jxsmvStokAL9DE4Cavk18=.77c85751-1fca-4e3e-9b7d-db8cfdcefffc@github.com>

On Fri, 17 Jan 2020 23:18:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.
> 
> Looks good to me.
> 
> @guruhb can you re-review this when you get a chance?

+1, Looks good to me.

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

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

From ghb at openjdk.java.net  Fri Jan 24 14:41:12 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Fri, 24 Jan 2020 14:41:12 GMT
Subject: [Rev 03] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>
Message-ID: <_nOWgErBulVi_rXbXY_AWwe9e0cYkIMcUzPl9H9OBj8=.22b4b525-5abd-491c-97c4-7580a4842b00@github.com>

On Fri, 24 Jan 2020 14:41:11 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> As documented in JDK-8236912, WebView did not check whether the idMap really contained a mapping for the given button, making it prone to errors, when things are extended (as has happened here).
>> 
>> The fix consists of two test cases that show the problem in unfixed WebViews and a fix which works analogously to the check whether the given event type is mapped.
> 
> Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by ghb (Reviewer).

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

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

From kcr at openjdk.java.net  Fri Jan 24 14:42:19 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 24 Jan 2020 14:42:19 GMT
Subject: [Rev 03] RFR: 8236912: NullPointerException when clicking in
 WebView with Button 4 or Button 5
In-Reply-To: <_nOWgErBulVi_rXbXY_AWwe9e0cYkIMcUzPl9H9OBj8=.22b4b525-5abd-491c-97c4-7580a4842b00@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
 <dS_rZDZRyOgMiF5fu-a20x4p3lxA_l9HgrkBYW6bo9Y=.8f0a4309-159a-4a03-9776-8ae70d0f0b73@github.com>
 <_nOWgErBulVi_rXbXY_AWwe9e0cYkIMcUzPl9H9OBj8=.22b4b525-5abd-491c-97c4-7580a4842b00@github.com>
Message-ID: <uR_6Mc7G0MUfmyl4ug8XQbAY2yHW_Ogw_td2xwzs-Ps=.18a6996e-bf5d-4e48-b7d0-cd34d8611dd4@github.com>

On Fri, 24 Jan 2020 14:41:00 GMT, Guru Hb <ghb at openjdk.org> wrote:

>> Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.
> 
> Marked as reviewed by ghb (Reviewer).

@effad you can integrate this when ready. I will sponsor it.

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

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

From kevin.rushforth at oracle.com  Fri Jan 24 14:57:33 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 24 Jan 2020 06:57:33 -0800
Subject: Indicating minimum number of reviewers for a PR [was: Skara - bot
 sending can-be-integrated message prematurely?]
In-Reply-To: <CA+0ynh_eDa_xyGnGP-0yLYcU=ttw-kGKmHVOjGMOc41wP7J-_g@mail.gmail.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
 <5DF98923.4070409@oracle.com>
 <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>
 <a4405c66-542b-f2b0-7a1a-800300f59bab@oracle.com>
 <CD81E1E3-B95F-4931-ADAC-3B3D07531726@oracle.com>
 <72e4e84c-873e-6857-cf4a-5c71638d1fa3@oracle.com>
 <CA+0ynh_eDa_xyGnGP-0yLYcU=ttw-kGKmHVOjGMOc41wP7J-_g@mail.gmail.com>
Message-ID: <cde73ead-862c-d389-710c-0b33f01ff6be@oracle.com>

The Skara team has implemented SKARA-217 [1] to allow for increasing the 
number of reviewers before it will mark a PR as ready for integration.

Starting from now, any "R"eviewer (that is, someone with a Reviewer role 
in the OpenJFX Project) can indicate that a PR needs 2 reviewers (or 
perhaps even 3 in some cases if one of the reviewers desires additional 
eyes on a risky PR), can issue this command in the PR:

/reviewers 2

I'll do that now for the ones that we've already identified as needing 
multiple reviewers.

Thanks to Nir Lisker for suggesting the Skara improvement, and to the 
Skara team for implementing it. Let me know if there are any questions.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/SKARA-217




On 1/8/2020 10:19 AM, Nir Lisker wrote:
> I forgot to mention that I filed these:
>
> https://bugs.openjdk.java.net/browse/SKARA-218
> https://bugs.openjdk.java.net/browse/SKARA-217
>
> They weren't triaged, so maybe the Skara team needs to be notified.
>
> On Thu, Dec 19, 2019 at 6:24 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     FYI, for anyone interested, the Skara team submitted the following
>     PR to modify the "ready for integration" message:
>
>     https://github.com/openjdk/skara/pull/343
>
>     We can file a follow-up RFE to have them consider adding
>     "/reviewers" and "/csr" commands.
>
>     -- Kevin
>
>
>     On 12/18/2019 7:17 PM, Phil Race wrote:
>>     It would have to allow anyone who has reviewer status to add that
>>     comment.
>>     Not just the author since if they knew we would have less need
>>     for it.
>>
>>     -Phil.
>>
>>     On Dec 18, 2019, at 11:31 AM, Kevin Rushforth
>>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>>     wrote:
>>
>>>     That's an interesting idea. It would, of course, need to
>>>     disallow reducing the number below the minimum specified in
>>>     .jcheck/conf (e.g., we wouldn't allow "/reviewers 0").
>>>
>>>     -- Kevin
>>>
>>>
>>>     On 12/18/2019 10:36 AM, Nir Lisker wrote:
>>>>
>>>>         The client libraries in the OpenJDK do as a default rule,
>>>>         excusing?simple fixes.
>>>>
>>>>
>>>>     Then maybe it would be helpful to have a "/reviewers n" command
>>>>     that will tell the bot how many reviewers are needed. It's less
>>>>     convoluted than the CSR tracking and basically replaces the
>>>>     comment a reviewer would make anyway to inform the PR author
>>>>     how many reviewers they should wait for. Extending the bot to
>>>>     look for n reviewers instead of the current 1 should not be far
>>>>     fetched.
>>>>
>>>>
>>>>
>>>>     On Wed, Dec 18, 2019 at 4:02 AM Philip Race
>>>>     <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>>>
>>>>
>>>>
>>>>         On 12/16/19, 4:14 PM, Nir Lisker wrote:
>>>>         > Do other projects also have multi-reviewers requirements?
>>>>
>>>>         The client libraries in the OpenJDK do as a default rule,
>>>>         excusing
>>>>         simple fixes.
>>>>
>>>>         >
>>>>         > I would think that at least for a CSR, which is
>>>>         OpenJDK-wide, a request
>>>>         > could be put in with the Skara to track it. A Reviewer
>>>>         (or Committer?)
>>>>         > could invoke a /csr command which will require the PR
>>>>         author to provide a
>>>>         > link to the CSR, and check that it was approved as part
>>>>         of the patch
>>>>         > approval process.
>>>>
>>>>         I think that if there is a CSR sub-task in JBS skara can
>>>>         key off whether
>>>>         that is approved.
>>>>         This does mean skara needs to probe JBS but SFAIK its doing
>>>>         that a
>>>>         hundred times
>>>>         a minute anyway.
>>>>
>>>>         -phil.
>>>>
>>>>         >
>>>>         > Not sure how complicated it would be to implement.
>>>>         >
>>>>         > - Nir
>>>>         >
>>>>         > On Mon, Dec 16, 2019 at 5:39 PM Kevin
>>>>         Rushforth<kevin.rushforth at oracle.com
>>>>         <mailto:kevin.rushforth at oracle.com>>
>>>>         > wrote:
>>>>         >
>>>>         >> That's a good question about whether we can ask for a
>>>>         slight rewording
>>>>         >> of the Skara bot message to indicate that there might be
>>>>         other things to
>>>>         >> check before "/integrate". I'll raise that question with
>>>>         the Skara team.
>>>>         >>
>>>>         >> As an aside, I noticed the other day that you typed
>>>>         "/integrate" after a
>>>>         >> single review, but in that case, there was no clear
>>>>         indication from Ajit
>>>>         >> (the first reviewer and the sponsor) that a second
>>>>         review was required,
>>>>         >> so I didn't comment on it.
>>>>         >>
>>>>         >> -- Kevin
>>>>         >>
>>>>         >>
>>>>         >> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>>>         >>> Kevin,
>>>>         >>>
>>>>         >>> thanks for the clarification :) My bad that I didn't
>>>>         re-read the
>>>>         >>> contrib.md. But then, who does? The lazy like myself do it
>>>>         >>> occasionally only (down to once and then forget about
>>>>         it<g>)
>>>>         >>>
>>>>         >>> Maybe the bot message can be improved? With some
>>>>         indication that its
>>>>         >>> (the bot's) knowledge about review requirements is
>>>>         limited, so would
>>>>         >>> require a careful check by the contributor before
>>>>         actually post the
>>>>         >>> /integrate comment? Actually, I think I goofed the
>>>>         other day, was
>>>>         >>> safed only by Ajit who waited for the 2nd review before
>>>>         his /sponsor.
>>>>         >>>
>>>>         >>> -- Jeanette
>>>>         >>>
>>>>         >>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com
>>>>         <mailto:kevin.rushforth at oracle.com>>:
>>>>         >>>
>>>>         >>>> I added a comment to the two PRs in question, but it
>>>>         bears discussion
>>>>         >>>> here.
>>>>         >>>>
>>>>         >>>> The Skara bot can't know whether all criteria have
>>>>         been met. It
>>>>         >>>> can't, for example, know whether there are outstanding
>>>>         comments from
>>>>         >>>> some reviewers that need to be addressed. Nor does it
>>>>         know which PRs
>>>>         >>>> need two reviewers (or sometimes a third if there is a
>>>>         specific
>>>>         >>>> person we would like to review it), which ones need a
>>>>         CSR, etc.
>>>>         >>>>
>>>>         >>>> So having it state authoritatively that the PR is
>>>>         ready to integrate
>>>>         >>>> is a bit misleading. This is documented in the Code
>>>>         Review section of
>>>>         >>>> the CONTRIBUTING [1] doc:
>>>>         >>>>
>>>>         >>>>> NOTE: while the Skara tooling will indicate that the
>>>>         PR is ready to
>>>>         >>>>> integrate once the first reviewer with a "Reviewer"
>>>>         role in the
>>>>         >>>>> project has approved it, this may or may not be
>>>>         sufficient depending
>>>>         >>>>> on the type of fix. For example, you must wait for a
>>>>         second approval
>>>>         >>>>> for enhancements or high-impact bug fixes.
>>>>         >>>> If anyone can think of a way to improve this and make
>>>>         it more clear,
>>>>         >>>> that would be helpful.
>>>>         >>>>
>>>>         >>>> -- Kevin
>>>>         >>>>
>>>>         >>>> [1]
>>>>         https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>>>         >>>>
>>>>         >>>>
>>>>         >>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>>>         >>>>> Looks like it assumes a pull request as properly
>>>>         reviewed as soon as
>>>>         >>>>> it gets a single approve - independent on how many
>>>>         reviewers are
>>>>         >>>>> required, see f.i.
>>>>         >>>>>
>>>>         >>>>>
>>>>         https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>>>         >>>>>
>>>>         https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>>>         >>>>>
>>>>         >>>>> -- Jeanette
>>>>         >>>>>
>>>>         >>>
>>>>         >>>
>>>>         >>
>>>>
>>>
>


From kcr at openjdk.java.net  Fri Jan 24 15:19:45 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 24 Jan 2020 15:19:45 GMT
Subject: RFR: 8237823: Mark TextTest.testTabSize as unstable
Message-ID: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>

Fix for [JDK-8237823](https://bugs.openjdk.java.net/browse/JDK-8237823).

The javafx.graphics unit test `TextTest.testTabSize` fails intermittently -- see [JDK-8236728](https://bugs.openjdk.java.net/browse/JDK-8236728).

This PR marks `TextTest.testTabSize` as unstable, meaning it will not be run by default. It will be run only when running gradle with the `-PUNSTABLE_TEST=true` flag.

As noted in the bug report, I see this about 20% of the time in our nightly and CI builds. Given that we are getting late in the cycle for openjfx14, we need to mark the test as unstable until a fix can be found.

NOTE: this is targeted to jfx14.

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

Commits:
 - bfca349c: 8237823: Mark TextTest.testTabSize as unstable

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

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

From kcr at openjdk.java.net  Fri Jan 24 15:19:56 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 24 Jan 2020 15:19:56 GMT
Subject: RFR: 8237823: Mark TextTest.testTabSize as unstable
In-Reply-To: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
References: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
Message-ID: <OyGk-SgPdYnAy5pXV3FO9tetoDpqIIRvtkYSz14HzMY=.29562dfd-aa1c-4e55-ba2e-a24b1e08aebb@github.com>

On Fri, 24 Jan 2020 15:12:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fix for [JDK-8237823](https://bugs.openjdk.java.net/browse/JDK-8237823).
> 
> The javafx.graphics unit test `TextTest.testTabSize` fails intermittently -- see [JDK-8236728](https://bugs.openjdk.java.net/browse/JDK-8236728).
> 
> This PR marks `TextTest.testTabSize` as unstable, meaning it will not be run by default. It will be run only when running gradle with the `-PUNSTABLE_TEST=true` flag.
> 
> As noted in the bug report, I see this about 20% of the time in our nightly and CI builds. Given that we are getting late in the cycle for openjfx14, we need to mark the test as unstable until a fix can be found.
> 
> NOTE: this is targeted to jfx14.

@prrace can you review this?

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

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

From Rony.Flatscher at wu.ac.at  Fri Jan 24 15:21:07 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Fri, 24 Jan 2020 16:21:07 +0100
Subject: "Internal review ID 9063426: "FXMLLoader: if script engines implement
 javax.script.Compilabel compile scripts"
Message-ID: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>

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  Fri Jan 24 15:26:03 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 24 Jan 2020 07:26:03 -0800
Subject: "Internal review ID 9063426: "FXMLLoader: if script engines
 implement javax.script.Compilabel compile scripts"
In-Reply-To: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>
References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>
Message-ID: <d237cbbe-f1fe-519b-e378-ad576a4944ff@oracle.com>

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  Fri Jan 24 15:43:27 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 24 Jan 2020 15:43:27 GMT
Subject: [Rev 01] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <7o-JcZfwu4Oxcsgsw62n8ml1rc-Sd0DrYHuYnFDgSng=.cc3a5528-dd9b-42fb-bd27-cae32c6fe189@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <7o-JcZfwu4Oxcsgsw62n8ml1rc-Sd0DrYHuYnFDgSng=.cc3a5528-dd9b-42fb-bd27-cae32c6fe189@github.com>
Message-ID: <3nnY_KhRNQv-ucgWGuye_6sael0yrNBAWCmHGoe7gjw=.dc00edec-f607-4a3a-8fa1-1b7065f5c0a8@github.com>

On Fri, 24 Jan 2020 15:43:25 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Test simulates a single mouse-released event.
>> Fix simply guards against the null case.
> 
> The pull request has been updated with 1 additional commit.

This is a simple enough change that 1 reviewer will suffice -- @arapte will review.

I did notice some unrelated changes that should be reverted.

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

> 1956:         }
> 1957:         @Override
> 1958:         protected void interpolate(double frac) {

This is unrelated to your change. Please revert it.

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

> 1973:         }
> 1974:         @Override
> 1975:         protected void interpolate(double frac) {

Please revert.

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

> 1993:     private ListChangeListener childListener = new ListChangeListener<Node>() {
> 1994:         @Override
> 1995:         public void onChanged(Change<? extends Node> change) {

Please revert.

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



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

From kevin.rushforth at oracle.com  Fri Jan 24 15:50:02 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 24 Jan 2020 07:50:02 -0800
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
 <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
 <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
Message-ID: <c6cf8770-eeb0-48cb-c5fb-acf55e716dbd@oracle.com>

Hi Rony,

This bug was transferred to the JDK project on 28-Nov-2019. I don't know 
why you didn't get an email at that time, but I will inquire of the team 
who processes incoming bugs.

Also, I'll keep an eye out for the RFE you filed today, and let you know 
when it is transferred in case there is still a problem with the 
notification.

-- Kevin


On 1/22/2020 9:52 AM, Rony G. Flatscher wrote:
> Hi Anthony,
>
> On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
>> Your issue has been converted into a JDK issue, with your testcase attached [1].
> Thank you *very* much for this information!
>
>> Normally you should?ve received an e-mail at the time of this conversion,
> Just searched all my e-mail folders and could not find it (looking for "FXMLLoader" in the subject
> of e-mails as the bug title contains that word) but could not find a matching e-mail for whatever
> reasons.
>
>> but you can check this yourself by using the internal review ID as in [2]. If you?d like to
>> contribute a fix, see [3].
>>
>>   
>>
>> Kind regards, Anthony
>>
>>   
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8234959
>> <https://bugs.openjdk.java.net/browse/JDK-8234959>
>>
>> [2] https://bugs.openjdk.java.net/browse/JI-9062887 <https://bugs.openjdk.java.net/browse/JI-9062887>
>>
>> [3] https://github.com/openjdk/jfx <https://github.com/openjdk/jfx>
>>
> Thank you also for these links (and I learned something new on how to check for it using the
> internal review id with your [2], thanks a lot for this hint as well)!
>
> Will go back and study all the necessary procedures (forgot a lot since reading them the last time)
> and will try to contribute the fix in the proper way but it may take me a little while (currently
> quite busy around here).
>
> ---
>
> Maybe one more question: there would be an optimization possible by compiling scripts for script
> engines that have the javax.script.Compilable interface implemented and use the compiled version to
> execute/evaluate the scripts (may be helpful for event handler code e.g. for onMouseMove event
> handlers). Can the fix include such an optimization or should there be a separate discussion/RFE for
> it beforehand? (Adding this would be trivial in the context of the fix, however the bug description
> would not hint at such an optimization.)
>
> ---rony
>
>


From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 24 15:56:12 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 24 Jan 2020 15:56:12 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
Message-ID: <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>

On Tue, 21 Jan 2020 21:53:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> 
>>> 
>>> Looks good to me.
>>> Below is just an observation about time taken by the API,
>>> Platform: Windows10, `maxTextureSize`: 4096
>>> For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()` takes ~100 ms, and each call to `setPixels()` takes ~30 ms.
>>> 
>>> Please wait for one more approval before integrating.
>> 
>> Do you have the same kind of measurements for similar uses cases without this patch? I'm expecting performances to remain the same for snapshots less than `maxTextureSize*maxTextureSize` in size, since there is no extra pixel copy in that case, and the rest of the code if globally unchanged.
>> 
>> Still there exists a window for performance regressions, which for instance on Windows 10 w/ the D3D rendering pipeline would be when one of the dimension of a snapshot is >4096  and <8192: in that case a snapshot would require up to 4 extra copy pixels steps with this patch.
>> This is due to the fact that the old code would accept to render in a texture of a size up to the non-clamped max texture size (8192 in D3D, 16384 in ES2), but because I couldn't find a clean way to access the non clamped maxTextureSize exposed by the render factory from the Scene class, I settled for Prsim.maxTextureSize, which is the clamped value (4096 by default).
>> I haven't dug deep enough in the code to understand precisely why the max texture size is clamped to 4096 by default, but assuming that it is for a good reason wouldn't that also apply in that case? Or is it always safe to use the non-clamped value in that particular case?
> 
> I haven't done any testing yet, but I have two comments on the patch:
> 
> 1. Using the clamped texture size as the upper limit is the right thing to do, but `Prism.maxTexture` isn't guaranteed to be that size. The `Prism.maxTexture` constant represents the value to clamp the texture size to. In the event that D3D or OpenGL were to report a maximum less than the value of `Prism.maxTexture` (unlikely, but maybe on some low-end embedded systems?), then that value is what should be used. The way to get the clamped texture size is to call [`ResourceFactory::getMaximumTextureSize`](https://github.com/openjdk/jfx/blob/jfx14/modules/javafx.graphics/src/main/java/com/sun/prism/ResourceFactory.java#L222), but you can't do that directly from the scene graph code.
> 
> 2. Allocating multiple `WritableImage` objects and using `PixelWriter::setPixels` to stitch them together will take more temporary memory, and is likely to be slower, than having the snapshot code write into a subimage of the larger allocated image directly.
> 
> Having said that, the current proposed solution is still better than the current behavior is almost all cases, although there could be a performance hit in the case of an 8K x 8K image, which will now be tiled. I want to do a more careful review and some testing. If any other users of snapshot have any comments or concerns, they would be welcome.
> 
> I think the best long-term solution might be to modify the [`QuantumToolkit::renderToImage`](https://github.com/openjdk/jfx/blob/jfx14/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java#L1490) method, although that would certainly be out of scope for JavaFX 14.

I've put together a small benchmark to measure the time it takes to snapshots into images of sizes varying from 1024*1024 to 8192*8192, by increment of 1024 in each dimension, which you can find here: https://github.com/fthevenet/snapshot-perf-meter/blob/master/src/main/java/eu/fthevenet/SnapshotPerfMeter.java

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 24 16:03:48 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 24 Jan 2020 16:03:48 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
Message-ID: <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>

On Fri, 24 Jan 2020 15:55:50 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I haven't done any testing yet, but I have two comments on the patch:
>> 
>> 1. Using the clamped texture size as the upper limit is the right thing to do, but `Prism.maxTexture` isn't guaranteed to be that size. The `Prism.maxTexture` constant represents the value to clamp the texture size to. In the event that D3D or OpenGL were to report a maximum less than the value of `Prism.maxTexture` (unlikely, but maybe on some low-end embedded systems?), then that value is what should be used. The way to get the clamped texture size is to call [`ResourceFactory::getMaximumTextureSize`](https://github.com/openjdk/jfx/blob/jfx14/modules/javafx.graphics/src/main/java/com/sun/prism/ResourceFactory.java#L222), but you can't do that directly from the scene graph code.
>> 
>> 2. Allocating multiple `WritableImage` objects and using `PixelWriter::setPixels` to stitch them together will take more temporary memory, and is likely to be slower, than having the snapshot code write into a subimage of the larger allocated image directly.
>> 
>> Having said that, the current proposed solution is still better than the current behavior is almost all cases, although there could be a performance hit in the case of an 8K x 8K image, which will now be tiled. I want to do a more careful review and some testing. If any other users of snapshot have any comments or concerns, they would be welcome.
>> 
>> I think the best long-term solution might be to modify the [`QuantumToolkit::renderToImage`](https://github.com/openjdk/jfx/blob/jfx14/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java#L1490) method, although that would certainly be out of scope for JavaFX 14.
> 
> I've put together a small benchmark to measure the time it takes to snapshots into images of sizes varying from 1024*1024 to 8192*8192, by increment of 1024 in each dimension, which you can find here: https://github.com/fthevenet/snapshot-perf-meter/blob/master/src/main/java/eu/fthevenet/SnapshotPerfMeter.java

Here are the results when running JavaFX 14-ea+7. 
The columns of the table correspond the width of the target snapshot, while the rows correspond to the height and the content of the cells is the average time* spent (in ms) in `Node::snapshot`
(*) each test is ran 10 times and the elapsed time is averaged after pruning outliers, using Grubbs' test.

|    | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
|---|---|---|---|---|---|---|---|---|
| 1024 | 6.304272 | 10.303935 | 15.052336 | 35.929304 | 23.860095 | 28.828812 | 35.315288 | 27.867205 |
| 2048 | 11.544367 | 21.156326 | 28.368750 | 28.887164 | 47.134738 | 54.354708 | 55.480251 | 56.722649 |
| 3072 | 15.503187 | 30.215269 | 41.304645 | 39.789648 | 82.255091 | 82.576379 | 96.618722 | 106.586547 |
| 4096 | 20.928336 | 38.768648 | 64.255423 | 52.608217 | 101.797347 | 132.516816 | 158.525192 | 166.872889 |
| 5120 | 28.693431 | 67.275306 | 68.090280 | 76.208412 | 133.974510 | 157.120373 | 182.329784 | 210.069066 |
| 6144 | 29.972591 | 54.751002 | 88.171906 | 104.489291 | 147.788597 | 185.185643 | 213.562819 | 228.643761 |
| 7168 | 33.668398 | 63.088490 | 98.756212 | 130.502678 | 196.367121 | 225.166481 | 239.328794 | 260.162501 |
| 8192 | 40.961901 | 87.067460 | 128.230351 | 178.127225 | 198.479068 | 225.806211 | 266.170239 | 325.967840 |

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

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

From nlisker at openjdk.java.net  Fri Jan 24 16:25:15 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 24 Jan 2020 16:25:15 GMT
Subject: [Integrated] RFR: 8236753: Animations do not play backwards after
 being stopped
In-Reply-To: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
References: <ArmrIuTEdbKEsZTQbwRU_ztXB6xV6gSHnnc6_bLmLdk=.70ce9f36-e8ac-4c90-b1ee-87a725be0982@github.com>
Message-ID: <ad6cd57f-4544-4b27-b69b-90722cfaf034@openjdk.org>

Changeset: 9ae37f1f
Author:    Nir Lisker <nlisker at openjdk.org>
Date:      2020-01-22 20:58:12 +0000
URL:       https://git.openjdk.java.net/jfx/commit/9ae37f1f

8236753: Animations do not play backwards after being stopped

Reviewed-by: kcr, arapte

! modules/javafx.graphics/src/main/java/javafx/animation/Animation.java
! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationTest.java
! modules/javafx.graphics/src/test/java/test/javafx/animation/SequentialTransitionPlayTest.java

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 24 16:26:50 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 24 Jan 2020 16:26:50 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
Message-ID: <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>

On Fri, 24 Jan 2020 16:03:39 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I've put together a small benchmark to measure the time it takes to snapshots into images of sizes varying from 1024*1024 to 8192*8192, by increment of 1024 in each dimension, which you can find here: https://github.com/fthevenet/snapshot-perf-meter/blob/master/src/main/java/eu/fthevenet/SnapshotPerfMeter.java
> 
> Here are the results when running JavaFX 14-ea+7. 
> The columns of the table correspond the width of the target snapshot, while the rows correspond to the height and the content of the cells is the average time* spent (in ms) in `Node::snapshot`
> (*) each test is ran 10 times and the elapsed time is averaged after pruning outliers, using Grubbs' test.
> 
> |    | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
> |---|---|---|---|---|---|---|---|---|
> | 1024 | 6.304272 | 10.303935 | 15.052336 | 35.929304 | 23.860095 | 28.828812 | 35.315288 | 27.867205 |
> | 2048 | 11.544367 | 21.156326 | 28.368750 | 28.887164 | 47.134738 | 54.354708 | 55.480251 | 56.722649 |
> | 3072 | 15.503187 | 30.215269 | 41.304645 | 39.789648 | 82.255091 | 82.576379 | 96.618722 | 106.586547 |
> | 4096 | 20.928336 | 38.768648 | 64.255423 | 52.608217 | 101.797347 | 132.516816 | 158.525192 | 166.872889 |
> | 5120 | 28.693431 | 67.275306 | 68.090280 | 76.208412 | 133.974510 | 157.120373 | 182.329784 | 210.069066 |
> | 6144 | 29.972591 | 54.751002 | 88.171906 | 104.489291 | 147.788597 | 185.185643 | 213.562819 | 228.643761 |
> | 7168 | 33.668398 | 63.088490 | 98.756212 | 130.502678 | 196.367121 | 225.166481 | 239.328794 | 260.162501 |
> | 8192 | 40.961901 | 87.067460 | 128.230351 | 178.127225 | 198.479068 | 225.806211 | 266.170239 | 325.967840 |

And here are the results with the change in this PR, on the same machine under Windows 10:

|    | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
|---|---|---|---|---|---|---|---|---|
| 1024 | 6.957774 | 10.461498 | 14.721024 | 19.279638 | 47.508266 | 56.585089 | 64.522117 | 53.448326 |
| 2048 | 10.990480 | 19.284461 | 28.235822 | 41.067555 | 92.818088 | 106.782334 | 120.907050 | 112.852554 |
| 3072 | 15.642648 | 28.502151 | 59.541998 | 55.663658 | 130.654226 | 149.805330 | 205.212356 | 169.002232 |
| 4096 | 19.882252 | 41.287722 | 59.493687 | 73.809264 | 169.212467 | 200.212097 | 247.934609 | 246.412543 |
| 5120 | 49.986204 | 97.986781 | 126.127089 | 167.274104 | 217.063815 | 276.812929 | 307.276073 | 366.800463 |
| 6144 | 66.546156 | 104.339809 | 150.171765 | 206.282107 | 272.486419 | 321.178983 | 365.822047 | 410.087087 |
| 7168 | 66.894654 | 119.510866 | 176.002883 | 248.937222 | 314.721516 | 380.834398 | 430.858648 | 482.499047 |
| 8192 | 67.040207 | 112.831977 | 161.852173 | 237.588749 | 319.667719 | 382.151556 | 437.810832 | 451.865266 |

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

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

From nlisker at openjdk.java.net  Fri Jan 24 16:34:38 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 24 Jan 2020 16:34:38 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
Message-ID: <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>

On Fri, 24 Jan 2020 16:26:38 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> Here are the results when running JavaFX 14-ea+7. 
>> The columns of the table correspond the width of the target snapshot, while the rows correspond to the height and the content of the cells is the average time* spent (in ms) in `Node::snapshot`
>> (*) each test is ran 10 times and the elapsed time is averaged after pruning outliers, using Grubbs' test.
>> 
>> |    | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
>> |---|---|---|---|---|---|---|---|---|
>> | 1024 | 6.304272 | 10.303935 | 15.052336 | 35.929304 | 23.860095 | 28.828812 | 35.315288 | 27.867205 |
>> | 2048 | 11.544367 | 21.156326 | 28.368750 | 28.887164 | 47.134738 | 54.354708 | 55.480251 | 56.722649 |
>> | 3072 | 15.503187 | 30.215269 | 41.304645 | 39.789648 | 82.255091 | 82.576379 | 96.618722 | 106.586547 |
>> | 4096 | 20.928336 | 38.768648 | 64.255423 | 52.608217 | 101.797347 | 132.516816 | 158.525192 | 166.872889 |
>> | 5120 | 28.693431 | 67.275306 | 68.090280 | 76.208412 | 133.974510 | 157.120373 | 182.329784 | 210.069066 |
>> | 6144 | 29.972591 | 54.751002 | 88.171906 | 104.489291 | 147.788597 | 185.185643 | 213.562819 | 228.643761 |
>> | 7168 | 33.668398 | 63.088490 | 98.756212 | 130.502678 | 196.367121 | 225.166481 | 239.328794 | 260.162501 |
>> | 8192 | 40.961901 | 87.067460 | 128.230351 | 178.127225 | 198.479068 | 225.806211 | 266.170239 | 325.967840 |
> 
> And here are the results with the change in this PR, on the same machine under Windows 10:
> 
> |    | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
> |---|---|---|---|---|---|---|---|---|
> | 1024 | 6.957774 | 10.461498 | 14.721024 | 19.279638 | 47.508266 | 56.585089 | 64.522117 | 53.448326 |
> | 2048 | 10.990480 | 19.284461 | 28.235822 | 41.067555 | 92.818088 | 106.782334 | 120.907050 | 112.852554 |
> | 3072 | 15.642648 | 28.502151 | 59.541998 | 55.663658 | 130.654226 | 149.805330 | 205.212356 | 169.002232 |
> | 4096 | 19.882252 | 41.287722 | 59.493687 | 73.809264 | 169.212467 | 200.212097 | 247.934609 | 246.412543 |
> | 5120 | 49.986204 | 97.986781 | 126.127089 | 167.274104 | 217.063815 | 276.812929 | 307.276073 | 366.800463 |
> | 6144 | 66.546156 | 104.339809 | 150.171765 | 206.282107 | 272.486419 | 321.178983 | 365.822047 | 410.087087 |
> | 7168 | 66.894654 | 119.510866 | 176.002883 | 248.937222 | 314.721516 | 380.834398 | 430.858648 | 482.499047 |
> | 8192 | 67.040207 | 112.831977 | 161.852173 | 237.588749 | 319.667719 | 382.151556 | 437.810832 | 451.865266 |

> Here are the results when running JavaFX 14-ea+7.
> The columns of the table correspond the width of the target snapshot, while the rows correspond to the height and the content of the cells is the average time* spent (in ms) in `Node::snapshot`
> (*) each test is ran 10 times and the elapsed time is averaged after pruning outliers, using Grubbs' test.
> 
> 1024	2048	3072	4096	5120	6144	7168	8192
> 1024	6.304272	10.303935	15.052336	35.929304	23.860095	28.828812	35.315288	27.867205
> 2048	11.544367	21.156326	28.368750	28.887164	47.134738	54.354708	55.480251	56.722649
> 3072	15.503187	30.215269	41.304645	39.789648	82.255091	82.576379	96.618722	106.586547
> 4096	20.928336	38.768648	64.255423	52.608217	101.797347	132.516816	158.525192	166.872889
> 5120	28.693431	67.275306	68.090280	76.208412	133.974510	157.120373	182.329784	210.069066
> 6144	29.972591	54.751002	88.171906	104.489291	147.788597	185.185643	213.562819	228.643761
> 7168	33.668398	63.088490	98.756212	130.502678	196.367121	225.166481	239.328794	260.162501
> 8192	40.961901	87.067460	128.230351	178.127225	198.479068	225.806211	266.170239	325.967840

Any idea why 4096x1024 and 1024x4096 are so different? Same for 8192x1024 and 1024x8192.

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

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

From prr at openjdk.java.net  Fri Jan 24 16:48:36 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Jan 2020 16:48:36 GMT
Subject: RFR: 8237823: Mark TextTest.testTabSize as unstable
In-Reply-To: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
References: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
Message-ID: <VO2_iK7xfavb0TwRRJ-TClG840ArOq2OESZIVe9e6gA=.08d9fb31-a24c-450d-9e02-69352849f561@github.com>

On Fri, 24 Jan 2020 15:12:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fix for [JDK-8237823](https://bugs.openjdk.java.net/browse/JDK-8237823).
> 
> The javafx.graphics unit test `TextTest.testTabSize` fails intermittently -- see [JDK-8236728](https://bugs.openjdk.java.net/browse/JDK-8236728).
> 
> This PR marks `TextTest.testTabSize` as unstable, meaning it will not be run by default. It will be run only when running gradle with the `-PUNSTABLE_TEST=true` flag.
> 
> As noted in the bug report, I see this about 20% of the time in our nightly and CI builds. Given that we are getting late in the cycle for openjfx14, we need to mark the test as unstable until a fix can be found.
> 
> NOTE: this is targeted to jfx14.

Marked as reviewed by prr (Reviewer).

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 24 16:56:03 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 24 Jan 2020 16:56:03 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
Message-ID: <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>

On Fri, 24 Jan 2020 16:34:29 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> And here are the results with the change in this PR, on the same machine under Windows 10:
>> 
>> |    | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
>> |---|---|---|---|---|---|---|---|---|
>> | 1024 | 6.957774 | 10.461498 | 14.721024 | 19.279638 | 47.508266 | 56.585089 | 64.522117 | 53.448326 |
>> | 2048 | 10.990480 | 19.284461 | 28.235822 | 41.067555 | 92.818088 | 106.782334 | 120.907050 | 112.852554 |
>> | 3072 | 15.642648 | 28.502151 | 59.541998 | 55.663658 | 130.654226 | 149.805330 | 205.212356 | 169.002232 |
>> | 4096 | 19.882252 | 41.287722 | 59.493687 | 73.809264 | 169.212467 | 200.212097 | 247.934609 | 246.412543 |
>> | 5120 | 49.986204 | 97.986781 | 126.127089 | 167.274104 | 217.063815 | 276.812929 | 307.276073 | 366.800463 |
>> | 6144 | 66.546156 | 104.339809 | 150.171765 | 206.282107 | 272.486419 | 321.178983 | 365.822047 | 410.087087 |
>> | 7168 | 66.894654 | 119.510866 | 176.002883 | 248.937222 | 314.721516 | 380.834398 | 430.858648 | 482.499047 |
>> | 8192 | 67.040207 | 112.831977 | 161.852173 | 237.588749 | 319.667719 | 382.151556 | 437.810832 | 451.865266 |
> 
>> Here are the results when running JavaFX 14-ea+7.
>> The columns of the table correspond the width of the target snapshot, while the rows correspond to the height and the content of the cells is the average time* spent (in ms) in `Node::snapshot`
>> (*) each test is ran 10 times and the elapsed time is averaged after pruning outliers, using Grubbs' test.
>> 
>> 1024	2048	3072	4096	5120	6144	7168	8192
>> 1024	6.304272	10.303935	15.052336	35.929304	23.860095	28.828812	35.315288	27.867205
>> 2048	11.544367	21.156326	28.368750	28.887164	47.134738	54.354708	55.480251	56.722649
>> 3072	15.503187	30.215269	41.304645	39.789648	82.255091	82.576379	96.618722	106.586547
>> 4096	20.928336	38.768648	64.255423	52.608217	101.797347	132.516816	158.525192	166.872889
>> 5120	28.693431	67.275306	68.090280	76.208412	133.974510	157.120373	182.329784	210.069066
>> 6144	29.972591	54.751002	88.171906	104.489291	147.788597	185.185643	213.562819	228.643761
>> 7168	33.668398	63.088490	98.756212	130.502678	196.367121	225.166481	239.328794	260.162501
>> 8192	40.961901	87.067460	128.230351	178.127225	198.479068	225.806211	266.170239	325.967840
> 
> Any idea why 4096x1024 and 1024x4096 are so different? Same for 8192x1024 and 1024x8192.

I don't, to be honest. 
The results for some dimensions  (not always the same) can vary pretty widely from one run to another, despite all my effort to repeat results and remove outliers.
Out of curiosity, I also tried to eliminate the GC as possible culprit by running it with epsilon, but it seems to make a significant difference.
I ran that test on a laptop with Integrated Intel graphics and no dedicated vram (Intel UHD Graphics 620), though, so this might be why. 
Maybe someone could try and run the bench on hardware with a discreet GPU?

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

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

From kcr at openjdk.java.net  Fri Jan 24 16:56:11 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 24 Jan 2020 16:56:11 GMT
Subject: [Integrated] RFR: 8237823: Mark TextTest.testTabSize as unstable
In-Reply-To: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
References: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
Message-ID: <93755ae2-7a24-4426-83fa-70d9efa2370f@openjdk.org>

Changeset: da99e248
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-24 16:54:57 +0000
URL:       https://git.openjdk.java.net/jfx/commit/da99e248

8237823: Mark TextTest.testTabSize as unstable

Reviewed-by: prr

! modules/javafx.graphics/src/test/java/test/javafx/scene/text/TextTest.java

From kcr at openjdk.java.net  Fri Jan 24 17:11:09 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 24 Jan 2020 17:11:09 GMT
Subject: [Integrated] RFR: 8237823: Mark TextTest.testTabSize as unstable
In-Reply-To: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
References: <2YFYF6skfuhSawaN1ibDB5xW5t-ymtuL-ijv61YWGvI=.5f11c454-dfac-4793-81b9-85ff7dd0cf5d@github.com>
Message-ID: <52a39037-dee6-48cd-b71a-00df00314472@openjdk.org>

Changeset: da99e248
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-24 16:54:57 +0000
URL:       https://git.openjdk.java.net/jfx/commit/da99e248

8237823: Mark TextTest.testTabSize as unstable

Reviewed-by: prr

! modules/javafx.graphics/src/test/java/test/javafx/scene/text/TextTest.java

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 24 17:16:33 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 24 Jan 2020 17:16:33 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
Message-ID: <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWXuUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>

On Fri, 24 Jan 2020 16:55:47 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>>> Here are the results when running JavaFX 14-ea+7.
>>> The columns of the table correspond the width of the target snapshot, while the rows correspond to the height and the content of the cells is the average time* spent (in ms) in `Node::snapshot`
>>> (*) each test is ran 10 times and the elapsed time is averaged after pruning outliers, using Grubbs' test.
>>> 
>>> 1024	2048	3072	4096	5120	6144	7168	8192
>>> 1024	6.304272	10.303935	15.052336	35.929304	23.860095	28.828812	35.315288	27.867205
>>> 2048	11.544367	21.156326	28.368750	28.887164	47.134738	54.354708	55.480251	56.722649
>>> 3072	15.503187	30.215269	41.304645	39.789648	82.255091	82.576379	96.618722	106.586547
>>> 4096	20.928336	38.768648	64.255423	52.608217	101.797347	132.516816	158.525192	166.872889
>>> 5120	28.693431	67.275306	68.090280	76.208412	133.974510	157.120373	182.329784	210.069066
>>> 6144	29.972591	54.751002	88.171906	104.489291	147.788597	185.185643	213.562819	228.643761
>>> 7168	33.668398	63.088490	98.756212	130.502678	196.367121	225.166481	239.328794	260.162501
>>> 8192	40.961901	87.067460	128.230351	178.127225	198.479068	225.806211	266.170239	325.967840
>> 
>> Any idea why 4096x1024 and 1024x4096 are so different? Same for 8192x1024 and 1024x8192.
> 
> I don't, to be honest. 
> The results for some dimensions  (not always the same) can vary pretty widely from one run to another, despite all my effort to repeat results and remove outliers.
> Out of curiosity, I also tried to eliminate the GC as possible culprit by running it with epsilon, but it seems to make a significant difference.
> I ran that test on a laptop with Integrated Intel graphics and no dedicated vram (Intel UHD Graphics 620), though, so this might be why. 
> Maybe someone could try and run the bench on hardware with a discreet GPU?

With regard to why the tiling version is significantly slower, though, I do have a pretty good idea; as Kevin hinted, the pixel copy into a temporary buffer before copying into the final image is where most the extra time is spent.
The reason why is is some much slower is a little bit of a pity, though; profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert` and the reason for this turns out that this is due to the fact that, under Windows and the D3D pipeline anyway, the `WriteableImage` used to collate the tiles and the tiles returned from the RTTexture have different pixel formats (IntARGB for the tile and byteBGRA for the `WriteableImage`).
So if we could use a `WriteableImage` with an IntARGB pixel format as the recipient for the snapshot (at least as long as no image was provided by the caller), I suspect that the copy would be much faster.
Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it and it desn't seems to me that there is a way to safely access the `PixelBuffer` from an image's reference alone.
I'm pretty new to this code base though (which is quite large; I haven't read it all quite yet... ;-), so hopefully there's a way to do that that has eluded me so far.

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

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

From prr at openjdk.java.net  Fri Jan 24 17:24:17 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Jan 2020 17:24:17 GMT
Subject: RFR: 8237782: Only read advances up to the minimum of the
 numHorMetrics =?UTF-8?B?b3LigKY=?=
Message-ID: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>

? the available font data.

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

Commits:
 - 059ec788: 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data.

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

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

From prr at openjdk.java.net  Fri Jan 24 21:11:16 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Jan 2020 21:11:16 GMT
Subject: RFR: 8237833: Check glyph size before adding to glyph texture cache
Message-ID: <fLtWIZGn9W-SHGPMd4XirEColcnfGRWA1q7XKV9M_Gk=.267b0073-a3ae-4eba-9a05-f02ed376ccdd@github.com>

Check if the glyph will fit before trying to cache it.

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

Commits:
 - fbfb2473: 8237833: Check glyph size before adding to glyph texture cache

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

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

From ed at kennard.net  Sat Jan 25 01:39:07 2020
From: ed at kennard.net (Ed Kennard)
Date: Sat, 25 Jan 2020 01:39:07 +0000
Subject: TableView slow vertical scrolling with 300+ columns
Message-ID: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>

Hi everyone,

I?m new to the list, so by way of a short introduction, I?ve been working with JavaFX for the last 4 years developing a commodities trading risk management system from the ground up for a software company I co-founded in London.  All our code is written in Scala, the functional style of which is essential for the mathematical heavy lifting needed on the backend, but which also lends itself really well to UI programming and working with JavaFX.  I?m enthusiastic about JavaFX and would love to make a contribution to the project.

At the center of our product is an extension of the TableView control that?s responsible for displaying all the output from our pivot reporting engine.  Depending on how the user configures the layout of their pivot reports, sometimes there are a legitimately large number of columns (300+).  When that happens, while the horizontal scrolling remains perfectly smooth, the vertical scrolling degrades to a somewhat juddery state and CPU usage spikes.

I found an issue raised about this in 2019 on the old JFX GitHub repo here?
https://github.com/javafxports/openjdk-jfx/issues/409

?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was ever submitted through the correct channels.  I can confirm that the test code included there by ?yososs? on 20th May 2019 perfectly illustrates the problem I?m experiencing.  The same person seems to have a fairly clear theory on what is causing the problem, too - see their follow-up comment on 12 Sept 2019.

So, my questions to the list are:


  1.  Has anyone seen this issue raised anywhere else?
  2.  If yes, has anyone taken a look into it yet, and possibly even found a fix?
  3.  If no to both of the above, shall I submit it through the correct channels then have a crack at fixing myself?  Or is the issue likely to be a much deeper and far-reaching one than I?m anticipating?

Many thanks

Ed

From nlisker at gmail.com  Sat Jan 25 10:10:15 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 25 Jan 2020 12:10:15 +0200
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
Message-ID: <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>

Hi Ed,

Try to search JBS [1] for this issue. If you don't find one, you can submit
it through bugs.java.com, though I suspect this is known.

I don't know the technicalities of VirtualFlow in TableView, so can't help
there.

- Nir

[1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx

On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net> wrote:

> Hi everyone,
>
> I?m new to the list, so by way of a short introduction, I?ve been working
> with JavaFX for the last 4 years developing a commodities trading risk
> management system from the ground up for a software company I co-founded in
> London.  All our code is written in Scala, the functional style of which is
> essential for the mathematical heavy lifting needed on the backend, but
> which also lends itself really well to UI programming and working with
> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
> contribution to the project.
>
> At the center of our product is an extension of the TableView control
> that?s responsible for displaying all the output from our pivot reporting
> engine.  Depending on how the user configures the layout of their pivot
> reports, sometimes there are a legitimately large number of columns
> (300+).  When that happens, while the horizontal scrolling remains
> perfectly smooth, the vertical scrolling degrades to a somewhat juddery
> state and CPU usage spikes.
>
> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
> https://github.com/javafxports/openjdk-jfx/issues/409
>
> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was
> ever submitted through the correct channels.  I can confirm that the test
> code included there by ?yososs? on 20th May 2019 perfectly illustrates the
> problem I?m experiencing.  The same person seems to have a fairly clear
> theory on what is causing the problem, too - see their follow-up comment on
> 12 Sept 2019.
>
> So, my questions to the list are:
>
>
>   1.  Has anyone seen this issue raised anywhere else?
>   2.  If yes, has anyone taken a look into it yet, and possibly even found
> a fix?
>   3.  If no to both of the above, shall I submit it through the correct
> channels then have a crack at fixing myself?  Or is the issue likely to be
> a much deeper and far-reaching one than I?m anticipating?
>
> Many thanks
>
> Ed
>

From Rony.Flatscher at wu.ac.at  Sat Jan 25 14:32:27 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Sat, 25 Jan 2020 15:32:27 +0100
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <c6cf8770-eeb0-48cb-c5fb-acf55e716dbd@oracle.com>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
 <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
 <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
 <c6cf8770-eeb0-48cb-c5fb-acf55e716dbd@oracle.com>
Message-ID: <174bd8e2-1d02-1b14-1164-63e978028585@wu.ac.at>

Hi Kevin,

On 24.01.2020 16:50, Kevin Rushforth wrote:
> This bug was transferred to the JDK project on 28-Nov-2019. I don't know why you didn't get an
> email at that time, but I will inquire of the team who processes incoming bugs.
>
> Also, I'll keep an eye out for the RFE you filed today, and let you know when it is transferred in
> case there is still a problem with the notification.

thank you very much!

---rony


>
> On 1/22/2020 9:52 AM, Rony G. Flatscher wrote:
>> Hi Anthony,
>>
>> On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
>>> Your issue has been converted into a JDK issue, with your testcase attached [1].
>> Thank you *very* much for this information!
>>
>>> Normally you should?ve received an e-mail at the time of this conversion,
>> Just searched all my e-mail folders and could not find it (looking for "FXMLLoader" in the subject
>> of e-mails as the bug title contains that word) but could not find a matching e-mail for whatever
>> reasons.
>>
>>> but you can check this yourself by using the internal review ID as in [2]. If you?d like to
>>> contribute a fix, see [3].
>>>
>>> ?
>>> Kind regards, Anthony
>>>
>>> ?
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234959
>>> <https://bugs.openjdk.java.net/browse/JDK-8234959>
>>>
>>> [2] https://bugs.openjdk.java.net/browse/JI-9062887
>>> <https://bugs.openjdk.java.net/browse/JI-9062887>
>>>
>>> [3] https://github.com/openjdk/jfx <https://github.com/openjdk/jfx>
>>>
>> Thank you also for these links (and I learned something new on how to check for it using the
>> internal review id with your [2], thanks a lot for this hint as well)!
>>
>> Will go back and study all the necessary procedures (forgot a lot since reading them the last time)
>> and will try to contribute the fix in the proper way but it may take me a little while (currently
>> quite busy around here).
>>
>> ---
>>
>> Maybe one more question: there would be an optimization possible by compiling scripts for script
>> engines that have the javax.script.Compilable interface implemented and use the compiled version to
>> execute/evaluate the scripts (may be helpful for event handler code e.g. for onMouseMove event
>> handlers). Can the fix include such an optimization or should there be a separate discussion/RFE for
>> it beforehand? (Adding this would be trivial in the context of the fix, however the bug description
>> would not hint at such an optimization.)
>>
>> ---rony


From Rony.Flatscher at wu.ac.at  Sat Jan 25 14:38:03 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Sat, 25 Jan 2020 15:38:03 +0100
Subject: "Internal review ID 9063426: "FXMLLoader: if script engines
 implement javax.script.Compilabel compile scripts"
In-Reply-To: <d237cbbe-f1fe-519b-e378-ad576a4944ff@oracle.com>
References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at>
 <d237cbbe-f1fe-519b-e378-ad576a4944ff@oracle.com>
Message-ID: <454e6744-6fed-9834-738d-91caad62b4bd@wu.ac.at>

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).
Sure, will do after creating an appropriate PR for adding the ARGV and FILENAME entries to the
engine scope bindings [1] (may take a little while).
> 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.

+1

---rony


[1] https://bugs.openjdk.java.net/browse/JDK-8234959

>
>
> 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 Jan 25 14:38:44 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 25 Jan 2020 06:38:44 -0800
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
Message-ID: <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>

I took a quick look and didn't see one that was close enough to this, so 
I think it's worth submitting a new bug report. The closest I found were 
JDK-8166956 [1] and JDK-8185887 [2].

I also would be interested to know whether others have run into this in 
their applications.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8166956
[2] https://bugs.openjdk.java.net/browse/JDK-8185887


On 1/25/2020 2:10 AM, Nir Lisker wrote:
> Hi Ed,
>
> Try to search JBS [1] for this issue. If you don't find one, you can submit
> it through bugs.java.com, though I suspect this is known.
>
> I don't know the technicalities of VirtualFlow in TableView, so can't help
> there.
>
> - Nir
>
> [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
>
> On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net> wrote:
>
>> Hi everyone,
>>
>> I?m new to the list, so by way of a short introduction, I?ve been working
>> with JavaFX for the last 4 years developing a commodities trading risk
>> management system from the ground up for a software company I co-founded in
>> London.  All our code is written in Scala, the functional style of which is
>> essential for the mathematical heavy lifting needed on the backend, but
>> which also lends itself really well to UI programming and working with
>> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
>> contribution to the project.
>>
>> At the center of our product is an extension of the TableView control
>> that?s responsible for displaying all the output from our pivot reporting
>> engine.  Depending on how the user configures the layout of their pivot
>> reports, sometimes there are a legitimately large number of columns
>> (300+).  When that happens, while the horizontal scrolling remains
>> perfectly smooth, the vertical scrolling degrades to a somewhat juddery
>> state and CPU usage spikes.
>>
>> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
>> https://github.com/javafxports/openjdk-jfx/issues/409
>>
>> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was
>> ever submitted through the correct channels.  I can confirm that the test
>> code included there by ?yososs? on 20th May 2019 perfectly illustrates the
>> problem I?m experiencing.  The same person seems to have a fairly clear
>> theory on what is causing the problem, too - see their follow-up comment on
>> 12 Sept 2019.
>>
>> So, my questions to the list are:
>>
>>
>>    1.  Has anyone seen this issue raised anywhere else?
>>    2.  If yes, has anyone taken a look into it yet, and possibly even found
>> a fix?
>>    3.  If no to both of the above, shall I submit it through the correct
>> channels then have a crack at fixing myself?  Or is the issue likely to be
>> a much deeper and far-reaching one than I?m anticipating?
>>
>> Many thanks
>>
>> Ed
>>


From martin.desruisseaux at geomatys.com  Sat Jan 25 14:51:36 2020
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Sat, 25 Jan 2020 15:51:36 +0100
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <mailman.59.1579953825.19399.openjfx-dev@openjdk.java.net>
References: <mailman.59.1579953825.19399.openjfx-dev@openjdk.java.net>
Message-ID: <9e0e0159-ae1b-18aa-6c55-57e31cd97c1d@geomatys.com>

Hello Ed

> At the center of our product is an extension of the TableView control that's responsible for displaying all the output from our pivot reporting engine.  Depending on how the user configures the layout of their pivot reports, sometimes there are a legitimately large number of columns (300+).  When that happens, while the horizontal scrolling remains perfectly smooth, the vertical scrolling degrades to a somewhat juddery state and CPU usage spikes.
>
> (?snip?)
> So, my questions to the list are:
>
>    1.  Has anyone seen this issue raised anywhere else?
>    2.  If yes, has anyone taken a look into it yet, and possibly even found a fix?
>    3.  If no to both of the above, shall I submit it through the correct channels then have a crack at fixing myself?  Or is the issue likely to be a much deeper and far-reaching one than I?m anticipating?

By coincidence I'm developing right now a GridView for displaying large 
grids (millions of rows and columns) using JavaFX VirtualFlow. It seems 
to work smoothly up to now. That GridView is specifically designed for 
rendering the sample values of large java.awt.image.RenderedImage using 
its tile management capacity (tiles loaded in background thread when 
first requested). It is not my goal to create a general purpose GridView 
at this time. However it should be possible to remove the 
RenderedImage-specific code and replace it by another model with not too 
much effort. The code is at [1].

About improving TableView for managing thousands of columns, I believe 
that one difficulty is that TableView depends extensively on 
TableColumn, which provides a lot of capability (resizing, sorting, 
reordering, hiding, etc.) at the cost of more complexity that may be 
difficult to optimize. By contrast, above-cited GridView has a lot of 
restrictions (all cells of the same size, no sorting, no reordering, 
etc.) for easier implementation.

 ??? Martin

[1] https://github.com/apache/sis/tree/geoapi-4.0/application/sis-javafx/src/main/java/org/apache/sis/gui/coverage


From ed at kennard.net  Sat Jan 25 15:34:32 2020
From: ed at kennard.net (Ed Kennard)
Date: Sat, 25 Jan 2020 15:34:32 +0000
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
 <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>
Message-ID: <33343544-49FD-404C-9F37-51A64F849897@kennard.net>

Hi Kevin, Nir,

I also dug out those two bug reports and agree neither are close enough.  However, it seems to be general consensus that in order to properly address the issue, TableView's virtualisation would need to be changed to support columns in addition to rows, and that the extra complexity through the rest of the control's features would not be a worthwhile trade-off.

So might it be better to submit a new feature request to develop a separate and leaner control entirely, geared much more towards viewing large datasets without all the bells and whistles of a TableView?




?On 25/01/2020, 15:39, "Kevin Rushforth" <kevin.rushforth at oracle.com> wrote:

    I took a quick look and didn't see one that was close enough to this, so 
    I think it's worth submitting a new bug report. The closest I found were 
    JDK-8166956 [1] and JDK-8185887 [2].
    
    I also would be interested to know whether others have run into this in 
    their applications.
    
    -- Kevin
    
    [1] https://bugs.openjdk.java.net/browse/JDK-8166956
    [2] https://bugs.openjdk.java.net/browse/JDK-8185887
    
    
    On 1/25/2020 2:10 AM, Nir Lisker wrote:
    > Hi Ed,
    >
    > Try to search JBS [1] for this issue. If you don't find one, you can submit
    > it through bugs.java.com, though I suspect this is known.
    >
    > I don't know the technicalities of VirtualFlow in TableView, so can't help
    > there.
    >
    > - Nir
    >
    > [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
    >
    > On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net> wrote:
    >
    >> Hi everyone,
    >>
    >> I?m new to the list, so by way of a short introduction, I?ve been working
    >> with JavaFX for the last 4 years developing a commodities trading risk
    >> management system from the ground up for a software company I co-founded in
    >> London.  All our code is written in Scala, the functional style of which is
    >> essential for the mathematical heavy lifting needed on the backend, but
    >> which also lends itself really well to UI programming and working with
    >> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
    >> contribution to the project.
    >>
    >> At the center of our product is an extension of the TableView control
    >> that?s responsible for displaying all the output from our pivot reporting
    >> engine.  Depending on how the user configures the layout of their pivot
    >> reports, sometimes there are a legitimately large number of columns
    >> (300+).  When that happens, while the horizontal scrolling remains
    >> perfectly smooth, the vertical scrolling degrades to a somewhat juddery
    >> state and CPU usage spikes.
    >>
    >> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
    >> https://github.com/javafxports/openjdk-jfx/issues/409
    >>
    >> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was
    >> ever submitted through the correct channels.  I can confirm that the test
    >> code included there by ?yososs? on 20th May 2019 perfectly illustrates the
    >> problem I?m experiencing.  The same person seems to have a fairly clear
    >> theory on what is causing the problem, too - see their follow-up comment on
    >> 12 Sept 2019.
    >>
    >> So, my questions to the list are:
    >>
    >>
    >>    1.  Has anyone seen this issue raised anywhere else?
    >>    2.  If yes, has anyone taken a look into it yet, and possibly even found
    >> a fix?
    >>    3.  If no to both of the above, shall I submit it through the correct
    >> channels then have a crack at fixing myself?  Or is the issue likely to be
    >> a much deeper and far-reaching one than I?m anticipating?
    >>
    >> Many thanks
    >>
    >> Ed
    >>
    


From nlisker at gmail.com  Sat Jan 25 15:39:46 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 25 Jan 2020 17:39:46 +0200
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <33343544-49FD-404C-9F37-51A64F849897@kennard.net>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
 <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>
 <33343544-49FD-404C-9F37-51A64F849897@kennard.net>
Message-ID: <CA+0ynh-UfmYTrqd0VTsPhKY5t8ANEvxbr3zUO5r0VZxKbfxMsA@mail.gmail.com>

>
> So might it be better to submit a new feature request to develop a
> separate and leaner control entirely, geared much more towards viewing
> large datasets without all the bells and whistles of a TableView?
>

 Doesn't ControlsFX have that already, or some other 3rd party library?

On Sat, Jan 25, 2020 at 5:34 PM Ed Kennard <ed at kennard.net> wrote:

> Hi Kevin, Nir,
>
> I also dug out those two bug reports and agree neither are close enough.
> However, it seems to be general consensus that in order to properly address
> the issue, TableView's virtualisation would need to be changed to support
> columns in addition to rows, and that the extra complexity through the rest
> of the control's features would not be a worthwhile trade-off.
>
> So might it be better to submit a new feature request to develop a
> separate and leaner control entirely, geared much more towards viewing
> large datasets without all the bells and whistles of a TableView?
>
>
>
>
> ?On 25/01/2020, 15:39, "Kevin Rushforth" <kevin.rushforth at oracle.com>
> wrote:
>
>     I took a quick look and didn't see one that was close enough to this,
> so
>     I think it's worth submitting a new bug report. The closest I found
> were
>     JDK-8166956 [1] and JDK-8185887 [2].
>
>     I also would be interested to know whether others have run into this
> in
>     their applications.
>
>     -- Kevin
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8166956
>     [2] https://bugs.openjdk.java.net/browse/JDK-8185887
>
>
>     On 1/25/2020 2:10 AM, Nir Lisker wrote:
>     > Hi Ed,
>     >
>     > Try to search JBS [1] for this issue. If you don't find one, you can
> submit
>     > it through bugs.java.com, though I suspect this is known.
>     >
>     > I don't know the technicalities of VirtualFlow in TableView, so
> can't help
>     > there.
>     >
>     > - Nir
>     >
>     > [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
>     >
>     > On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net> wrote:
>     >
>     >> Hi everyone,
>     >>
>     >> I?m new to the list, so by way of a short introduction, I?ve been
> working
>     >> with JavaFX for the last 4 years developing a commodities trading
> risk
>     >> management system from the ground up for a software company I
> co-founded in
>     >> London.  All our code is written in Scala, the functional style of
> which is
>     >> essential for the mathematical heavy lifting needed on the backend,
> but
>     >> which also lends itself really well to UI programming and working
> with
>     >> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
>     >> contribution to the project.
>     >>
>     >> At the center of our product is an extension of the TableView
> control
>     >> that?s responsible for displaying all the output from our pivot
> reporting
>     >> engine.  Depending on how the user configures the layout of their
> pivot
>     >> reports, sometimes there are a legitimately large number of columns
>     >> (300+).  When that happens, while the horizontal scrolling remains
>     >> perfectly smooth, the vertical scrolling degrades to a somewhat
> juddery
>     >> state and CPU usage spikes.
>     >>
>     >> I found an issue raised about this in 2019 on the old JFX GitHub
> repo here?
>     >> https://github.com/javafxports/openjdk-jfx/issues/409
>     >>
>     >> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it
> was
>     >> ever submitted through the correct channels.  I can confirm that
> the test
>     >> code included there by ?yososs? on 20th May 2019 perfectly
> illustrates the
>     >> problem I?m experiencing.  The same person seems to have a fairly
> clear
>     >> theory on what is causing the problem, too - see their follow-up
> comment on
>     >> 12 Sept 2019.
>     >>
>     >> So, my questions to the list are:
>     >>
>     >>
>     >>    1.  Has anyone seen this issue raised anywhere else?
>     >>    2.  If yes, has anyone taken a look into it yet, and possibly
> even found
>     >> a fix?
>     >>    3.  If no to both of the above, shall I submit it through the
> correct
>     >> channels then have a crack at fixing myself?  Or is the issue
> likely to be
>     >> a much deeper and far-reaching one than I?m anticipating?
>     >>
>     >> Many thanks
>     >>
>     >> Ed
>     >>
>
>
>

From ed at kennard.net  Sat Jan 25 15:56:12 2020
From: ed at kennard.net (Ed Kennard)
Date: Sat, 25 Jan 2020 15:56:12 +0000
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <9e0e0159-ae1b-18aa-6c55-57e31cd97c1d@geomatys.com>
References: <mailman.59.1579953825.19399.openjfx-dev@openjdk.java.net>
 <9e0e0159-ae1b-18aa-6c55-57e31cd97c1d@geomatys.com>
Message-ID: <1E78CB1B-4FF9-4CFE-9717-5C785E9DECBA@kennard.net>

Hi Martin,

Big thank you for your message, and for sharing your code.  I took a look and it could definitely be a great starting point for me.  The content we need to display is very simple, every cell just needs to display text, occasionally with an expand/collapse button on the left.  So I think the only two features we rely on from TableView I'd need to add support for are varying cell widths, and nested column headers, both of which I imagine will require a lot of patience, but I'm definitely going to spend some time looking into it and will let you know how it goes.

Ed




?On 25/01/2020, 15:52, "Martin Desruisseaux" <martin.desruisseaux at geomatys.com> wrote:

    Hello Ed
    
    > At the center of our product is an extension of the TableView control that's responsible for displaying all the output from our pivot reporting engine.  Depending on how the user configures the layout of their pivot reports, sometimes there are a legitimately large number of columns (300+).  When that happens, while the horizontal scrolling remains perfectly smooth, the vertical scrolling degrades to a somewhat juddery state and CPU usage spikes.
    >
    > (?snip?)
    > So, my questions to the list are:
    >
    >    1.  Has anyone seen this issue raised anywhere else?
    >    2.  If yes, has anyone taken a look into it yet, and possibly even found a fix?
    >    3.  If no to both of the above, shall I submit it through the correct channels then have a crack at fixing myself?  Or is the issue likely to be a much deeper and far-reaching one than I?m anticipating?
    
    By coincidence I'm developing right now a GridView for displaying large 
    grids (millions of rows and columns) using JavaFX VirtualFlow. It seems 
    to work smoothly up to now. That GridView is specifically designed for 
    rendering the sample values of large java.awt.image.RenderedImage using 
    its tile management capacity (tiles loaded in background thread when 
    first requested). It is not my goal to create a general purpose GridView 
    at this time. However it should be possible to remove the 
    RenderedImage-specific code and replace it by another model with not too 
    much effort. The code is at [1].
    
    About improving TableView for managing thousands of columns, I believe 
    that one difficulty is that TableView depends extensively on 
    TableColumn, which provides a lot of capability (resizing, sorting, 
    reordering, hiding, etc.) at the cost of more complexity that may be 
    difficult to optimize. By contrast, above-cited GridView has a lot of 
    restrictions (all cells of the same size, no sorting, no reordering, 
    etc.) for easier implementation.
    
         Martin
    
    [1] https://github.com/apache/sis/tree/geoapi-4.0/application/sis-javafx/src/main/java/org/apache/sis/gui/coverage
    


From ed at kennard.net  Sat Jan 25 16:10:17 2020
From: ed at kennard.net (Ed Kennard)
Date: Sat, 25 Jan 2020 16:10:17 +0000
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <CA+0ynh-UfmYTrqd0VTsPhKY5t8ANEvxbr3zUO5r0VZxKbfxMsA@mail.gmail.com>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
 <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>
 <33343544-49FD-404C-9F37-51A64F849897@kennard.net>
 <CA+0ynh-UfmYTrqd0VTsPhKY5t8ANEvxbr3zUO5r0VZxKbfxMsA@mail.gmail.com>
Message-ID: <8CD8B4B0-D9D5-4D42-BB54-AEBAF52340D9@kennard.net>

I did previously look at the ControlsFX SpreadsheetView, but it wasn?t a good match, at least at that time.  Off the top of my head, I?m not sure it supports nested column headers, which is essential for our purposes. Furthermore, in my travels around the internet on this subject I?ve seen comments suggesting it has its own performance issues, too.  I will revisit it though, just to be sure.

Beyond that, I haven?t seen any other 3rd party libraries along these lines


From: Nir Lisker <nlisker at gmail.com>
Date: Saturday, 25 January 2020 at 16:40
To: Ed Kennard <ed at kennard.net>
Cc: Kevin Rushforth <kevin.rushforth at oracle.com>, "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
Subject: Re: TableView slow vertical scrolling with 300+ columns

So might it be better to submit a new feature request to develop a separate and leaner control entirely, geared much more towards viewing large datasets without all the bells and whistles of a TableView?

 Doesn't ControlsFX have that already, or some other 3rd party library?

On Sat, Jan 25, 2020 at 5:34 PM Ed Kennard <ed at kennard.net<mailto:ed at kennard.net>> wrote:
Hi Kevin, Nir,

I also dug out those two bug reports and agree neither are close enough.  However, it seems to be general consensus that in order to properly address the issue, TableView's virtualisation would need to be changed to support columns in addition to rows, and that the extra complexity through the rest of the control's features would not be a worthwhile trade-off.

So might it be better to submit a new feature request to develop a separate and leaner control entirely, geared much more towards viewing large datasets without all the bells and whistles of a TableView?




On 25/01/2020, 15:39, "Kevin Rushforth" <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>> wrote:

    I took a quick look and didn't see one that was close enough to this, so
    I think it's worth submitting a new bug report. The closest I found were
    JDK-8166956 [1] and JDK-8185887 [2].

    I also would be interested to know whether others have run into this in
    their applications.

    -- Kevin

    [1] https://bugs.openjdk.java.net/browse/JDK-8166956
    [2] https://bugs.openjdk.java.net/browse/JDK-8185887


    On 1/25/2020 2:10 AM, Nir Lisker wrote:
    > Hi Ed,
    >
    > Try to search JBS [1] for this issue. If you don't find one, you can submit
    > it through bugs.java.com<http://bugs.java.com>, though I suspect this is known.
    >
    > I don't know the technicalities of VirtualFlow in TableView, so can't help
    > there.
    >
    > - Nir
    >
    > [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
    >
    > On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net<mailto:ed at kennard.net>> wrote:
    >
    >> Hi everyone,
    >>
    >> I?m new to the list, so by way of a short introduction, I?ve been working
    >> with JavaFX for the last 4 years developing a commodities trading risk
    >> management system from the ground up for a software company I co-founded in
    >> London.  All our code is written in Scala, the functional style of which is
    >> essential for the mathematical heavy lifting needed on the backend, but
    >> which also lends itself really well to UI programming and working with
    >> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
    >> contribution to the project.
    >>
    >> At the center of our product is an extension of the TableView control
    >> that?s responsible for displaying all the output from our pivot reporting
    >> engine.  Depending on how the user configures the layout of their pivot
    >> reports, sometimes there are a legitimately large number of columns
    >> (300+).  When that happens, while the horizontal scrolling remains
    >> perfectly smooth, the vertical scrolling degrades to a somewhat juddery
    >> state and CPU usage spikes.
    >>
    >> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
    >> https://github.com/javafxports/openjdk-jfx/issues/409
    >>
    >> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was
    >> ever submitted through the correct channels.  I can confirm that the test
    >> code included there by ?yososs? on 20th May 2019 perfectly illustrates the
    >> problem I?m experiencing.  The same person seems to have a fairly clear
    >> theory on what is causing the problem, too - see their follow-up comment on
    >> 12 Sept 2019.
    >>
    >> So, my questions to the list are:
    >>
    >>
    >>    1.  Has anyone seen this issue raised anywhere else?
    >>    2.  If yes, has anyone taken a look into it yet, and possibly even found
    >> a fix?
    >>    3.  If no to both of the above, shall I submit it through the correct
    >> channels then have a crack at fixing myself?  Or is the issue likely to be
    >> a much deeper and far-reaching one than I?m anticipating?
    >>
    >> Many thanks
    >>
    >> Ed
    >>


From nlisker at openjdk.java.net  Sat Jan 25 19:55:44 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 25 Jan 2020 19:55:44 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWXuUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
Message-ID: <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>

On Fri, 24 Jan 2020 17:16:13 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I don't, to be honest. 
>> The results for some dimensions  (not always the same) can vary pretty widely from one run to another, despite all my effort to repeat results and remove outliers.
>> Out of curiosity, I also tried to eliminate the GC as possible culprit by running it with epsilon, but it seems to make no significant difference.
>> I ran that test on a laptop with Integrated Intel graphics and no dedicated vram (Intel UHD Graphics 620), though, so this might be why. 
>> Maybe someone could try and run the bench on hardware with a discreet GPU?
> 
> With regard as to why the tiling version is significantly slower, though, I do have a pretty good idea; as Kevin hinted, the pixel copy into a temporary buffer before copying into the final image is where most the extra time is spent.
> The reason why it is so much slower is a little bit of a pity, though; profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`. As it turns out, the reason for this is that, under Windows and the D3D pipeline anyway, the `WriteableImage` used to collate the tiles and the tiles returned from the RTTexture have different pixel formats (IntARGB for the tile and byteBGRA for the `WriteableImage`).
> So if we could use a `WriteableImage` with an IntARGB pixel format as the recipient for the snapshot (at least as long as no image was provided by the caller), I suspect that the copy would be much faster.
> Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it and it desn't seems to me that there is a way to safely access the `PixelBuffer` from an image's reference alone.
> I'm pretty new to this code base though (which is quite large; I haven't read it all quite yet... ;-), so hopefully there's a way to do that that has simply eluded me so far.

> profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`

This is a bit naive, but what if you parallelize the code there? I didn't test that this produces the correct result, but you can try to replace the loops with this:
IntStream.range(0, h).parallel().forEach(y -> {    
    IntStream.range(0, w).parallel().forEach(x -> {
        int pixel = srcarr[srcoff++];              
        dstarr[dstoff++] = (byte) (pixel      );   
        dstarr[dstoff++] = (byte) (pixel >>  8);   
        dstarr[dstoff++] = (byte) (pixel >> 16);   
        dstarr[dstoff++] = (byte) (pixel >> 24);   
    });                                            
    srcoff += srcscanints;                         
    dstoff += dstscanbytes;                        
});

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

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

From nlisker at openjdk.java.net  Sat Jan 25 20:25:10 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 25 Jan 2020 20:25:10 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
Message-ID: <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>

On Sat, 25 Jan 2020 19:55:23 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> With regard as to why the tiling version is significantly slower, though, I do have a pretty good idea; as Kevin hinted, the pixel copy into a temporary buffer before copying into the final image is where most the extra time is spent.
>> The reason why it is so much slower is a little bit of a pity, though; profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`. As it turns out, the reason for this is that, under Windows and the D3D pipeline anyway, the `WriteableImage` used to collate the tiles and the tiles returned from the RTTexture have different pixel formats (IntARGB for the tile and byteBGRA for the `WriteableImage`).
>> So if we could use a `WriteableImage` with an IntARGB pixel format as the recipient for the snapshot (at least as long as no image was provided by the caller), I suspect that the copy would be much faster.
>> Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it and it desn't seems to me that there is a way to safely access the `PixelBuffer` from an image's reference alone.
>> I'm pretty new to this code base though (which is quite large; I haven't read it all quite yet... ;-), so hopefully there's a way to do that that has simply eluded me so far.
> 
>> profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`
> 
> This is a bit naive, but what if you parallelize the code there? I didn't test that this produces the correct result, but you can try to replace the loops with this:
> IntStream.range(0, h).parallel().forEach(y -> {    
>     IntStream.range(0, w).parallel().forEach(x -> {
>         int pixel = srcarr[srcoff++];              
>         dstarr[dstoff++] = (byte) (pixel      );   
>         dstarr[dstoff++] = (byte) (pixel >>  8);   
>         dstarr[dstoff++] = (byte) (pixel >> 16);   
>         dstarr[dstoff++] = (byte) (pixel >> 24);   
>     });                                            
>     srcoff += srcscanints;                         
>     dstoff += dstscanbytes;                        
> });

> the `WriteableImage` used to collate the tiles and the tiles returned from the `RTTexture` have different pixel formats (`IntARGB` for the tile and `byteBGRA` for the `WriteableImage`).

Where did you see these?

> Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it...

You can update it with `PixelBuffer#updateBuffer`. I think that you will want to pass the stitched tile as the dirty region.

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

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

From martin.desruisseaux at geomatys.com  Sat Jan 25 23:43:58 2020
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Sun, 26 Jan 2020 00:43:58 +0100
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <mailman.4122.1579983919.14600.openjfx-dev@openjdk.java.net>
References: <mailman.4122.1579983919.14600.openjfx-dev@openjdk.java.net>
Message-ID: <9aa53579-d766-9d3b-caeb-bfacd8ce15c4@geomatys.com>

> Doesn't ControlsFX have that already, or some other 3rd party library?
>
Yes ControlsFX has a GridView class. But it is based on Skin in 
"com.sun.javafx" packages (replaced by "javafx.scene.control.skin" 
packages since JavaFX 9). I have not tested if it would still work with 
JavaFX more recent than version 8.

 ??? Martin



From github.com+7450507+fthevenet at openjdk.java.net  Sun Jan 26 11:40:20 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Sun, 26 Jan 2020 11:40:20 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
Message-ID: <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>

On Sat, 25 Jan 2020 20:24:54 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>>> profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`
>> 
>> This is a bit naive, but what if you parallelize the code there? I didn't test that this produces the correct result, but you can try to replace the loops with this:
>> IntStream.range(0, h).parallel().forEach(y -> {    
>>     IntStream.range(0, w).parallel().forEach(x -> {
>>         int pixel = srcarr[srcoff++];              
>>         dstarr[dstoff++] = (byte) (pixel      );   
>>         dstarr[dstoff++] = (byte) (pixel >>  8);   
>>         dstarr[dstoff++] = (byte) (pixel >> 16);   
>>         dstarr[dstoff++] = (byte) (pixel >> 24);   
>>     });                                            
>>     srcoff += srcscanints;                         
>>     dstoff += dstscanbytes;                        
>> });
> 
>> the `WriteableImage` used to collate the tiles and the tiles returned from the `RTTexture` have different pixel formats (`IntARGB` for the tile and `byteBGRA` for the `WriteableImage`).
> 
> Where did you see these?
> 
>> Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it...
> 
> You can update it with `PixelBuffer#updateBuffer`. I think that you will want to pass the stitched tile as the dirty region.

> 
> 
> > the `WriteableImage` used to collate the tiles and the tiles returned from the `RTTexture` have different pixel formats (`IntARGB` for the tile and `byteBGRA` for the `WriteableImage`).
> 
> Where did you see these?

Simply by watching the value of  `tile.getPixelReader().getPixelFormat()` and `wimg.getPixelWriter().getPixelFormat()` before doing the copy at https://github.com/openjdk/jfx/blob/4bc4417356ebd639567d315257a6bbe11344d9c2/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L1315
> 
> > Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it...
> 
> You can update it with `PixelBuffer#updateBuffer`. I think that you will want to pass the stitched tile as the dirty region.

Thanks. I'll look into it.

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Sun Jan 26 11:58:36 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Sun, 26 Jan 2020 11:58:36 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
 <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
Message-ID: <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>

On Sun, 26 Jan 2020 11:40:06 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>>> the `WriteableImage` used to collate the tiles and the tiles returned from the `RTTexture` have different pixel formats (`IntARGB` for the tile and `byteBGRA` for the `WriteableImage`).
>> 
>> Where did you see these?
>> 
>>> Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it...
>> 
>> You can update it with `PixelBuffer#updateBuffer`. I think that you will want to pass the stitched tile as the dirty region.
> 
>> 
>> 
>> > the `WriteableImage` used to collate the tiles and the tiles returned from the `RTTexture` have different pixel formats (`IntARGB` for the tile and `byteBGRA` for the `WriteableImage`).
>> 
>> Where did you see these?
> 
> Simply by watching the value of  `tile.getPixelReader().getPixelFormat()` and `wimg.getPixelWriter().getPixelFormat()` before doing the copy at https://github.com/openjdk/jfx/blob/4bc4417356ebd639567d315257a6bbe11344d9c2/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L1315
>> 
>> > Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it...
>> 
>> You can update it with `PixelBuffer#updateBuffer`. I think that you will want to pass the stitched tile as the dirty region.
> 
> Thanks. I'll look into it.

> 
> 
> > profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`
> 
> This is a bit naive, but what if you parallelize the code there? I didn't test that this produces the correct result, but you can try to replace the loops with this:
> 
> ```
> IntStream.range(0, h).parallel().forEach(y -> {    
>     IntStream.range(0, w).parallel().forEach(x -> {
>         int pixel = srcarr[srcoff++];              
>         dstarr[dstoff++] = (byte) (pixel      );   
>         dstarr[dstoff++] = (byte) (pixel >>  8);   
>         dstarr[dstoff++] = (byte) (pixel >> 16);   
>         dstarr[dstoff++] = (byte) (pixel >> 24);   
>     });                                            
>     srcoff += srcscanints;                         
>     dstoff += dstscanbytes;                        
> });                                                
> ```

I don't think this works as it is, as all threads race to increment `srcoff` and `dstoff`.

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

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

From jonathan at jonathangiles.net  Sun Jan 26 21:47:50 2020
From: jonathan at jonathangiles.net (Jonathan Giles)
Date: Mon, 27 Jan 2020 10:47:50 +1300
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <8CD8B4B0-D9D5-4D42-BB54-AEBAF52340D9@kennard.net>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
 <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>
 <33343544-49FD-404C-9F37-51A64F849897@kennard.net>
 <CA+0ynh-UfmYTrqd0VTsPhKY5t8ANEvxbr3zUO5r0VZxKbfxMsA@mail.gmail.com>
 <8CD8B4B0-D9D5-4D42-BB54-AEBAF52340D9@kennard.net>
Message-ID: <CAMzdD4129KpDT8s4gL7ADBLk-MEiMzCnk=N+PxDTFHbCqDhwsg@mail.gmail.com>

It's been a wee while since I built TableView, but from memory there is
code in there that virtualises the columns, such that those that are
scrolled out of view are not being included in the scenegraph needlessly.
>From memory, to achieve this all you needed to do was set a fixed row
height on the TableView, using this API:
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableView.html#fixedCellSizeProperty

I'm sure it will won't be a silver bullet, but from my recollection it did
massively help for these scenarios where there were many columns, most of
which were not in the viewable area.

-- Jonathan

On Sun, Jan 26, 2020 at 5:11 AM Ed Kennard <ed at kennard.net> wrote:

> I did previously look at the ControlsFX SpreadsheetView, but it wasn?t a
> good match, at least at that time.  Off the top of my head, I?m not sure it
> supports nested column headers, which is essential for our purposes.
> Furthermore, in my travels around the internet on this subject I?ve seen
> comments suggesting it has its own performance issues, too.  I will revisit
> it though, just to be sure.
>
> Beyond that, I haven?t seen any other 3rd party libraries along these lines
>
>
> From: Nir Lisker <nlisker at gmail.com>
> Date: Saturday, 25 January 2020 at 16:40
> To: Ed Kennard <ed at kennard.net>
> Cc: Kevin Rushforth <kevin.rushforth at oracle.com>, "
> openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
> Subject: Re: TableView slow vertical scrolling with 300+ columns
>
> So might it be better to submit a new feature request to develop a
> separate and leaner control entirely, geared much more towards viewing
> large datasets without all the bells and whistles of a TableView?
>
>  Doesn't ControlsFX have that already, or some other 3rd party library?
>
> On Sat, Jan 25, 2020 at 5:34 PM Ed Kennard <ed at kennard.net<mailto:
> ed at kennard.net>> wrote:
> Hi Kevin, Nir,
>
> I also dug out those two bug reports and agree neither are close enough.
> However, it seems to be general consensus that in order to properly address
> the issue, TableView's virtualisation would need to be changed to support
> columns in addition to rows, and that the extra complexity through the rest
> of the control's features would not be a worthwhile trade-off.
>
> So might it be better to submit a new feature request to develop a
> separate and leaner control entirely, geared much more towards viewing
> large datasets without all the bells and whistles of a TableView?
>
>
>
>
> On 25/01/2020, 15:39, "Kevin Rushforth" <kevin.rushforth at oracle.com
> <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     I took a quick look and didn't see one that was close enough to this,
> so
>     I think it's worth submitting a new bug report. The closest I found
> were
>     JDK-8166956 [1] and JDK-8185887 [2].
>
>     I also would be interested to know whether others have run into this in
>     their applications.
>
>     -- Kevin
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8166956
>     [2] https://bugs.openjdk.java.net/browse/JDK-8185887
>
>
>     On 1/25/2020 2:10 AM, Nir Lisker wrote:
>     > Hi Ed,
>     >
>     > Try to search JBS [1] for this issue. If you don't find one, you can
> submit
>     > it through bugs.java.com<http://bugs.java.com>, though I suspect
> this is known.
>     >
>     > I don't know the technicalities of VirtualFlow in TableView, so
> can't help
>     > there.
>     >
>     > - Nir
>     >
>     > [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
>     >
>     > On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net<mailto:
> ed at kennard.net>> wrote:
>     >
>     >> Hi everyone,
>     >>
>     >> I?m new to the list, so by way of a short introduction, I?ve been
> working
>     >> with JavaFX for the last 4 years developing a commodities trading
> risk
>     >> management system from the ground up for a software company I
> co-founded in
>     >> London.  All our code is written in Scala, the functional style of
> which is
>     >> essential for the mathematical heavy lifting needed on the backend,
> but
>     >> which also lends itself really well to UI programming and working
> with
>     >> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
>     >> contribution to the project.
>     >>
>     >> At the center of our product is an extension of the TableView
> control
>     >> that?s responsible for displaying all the output from our pivot
> reporting
>     >> engine.  Depending on how the user configures the layout of their
> pivot
>     >> reports, sometimes there are a legitimately large number of columns
>     >> (300+).  When that happens, while the horizontal scrolling remains
>     >> perfectly smooth, the vertical scrolling degrades to a somewhat
> juddery
>     >> state and CPU usage spikes.
>     >>
>     >> I found an issue raised about this in 2019 on the old JFX GitHub
> repo here?
>     >> https://github.com/javafxports/openjdk-jfx/issues/409
>     >>
>     >> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it
> was
>     >> ever submitted through the correct channels.  I can confirm that
> the test
>     >> code included there by ?yososs? on 20th May 2019 perfectly
> illustrates the
>     >> problem I?m experiencing.  The same person seems to have a fairly
> clear
>     >> theory on what is causing the problem, too - see their follow-up
> comment on
>     >> 12 Sept 2019.
>     >>
>     >> So, my questions to the list are:
>     >>
>     >>
>     >>    1.  Has anyone seen this issue raised anywhere else?
>     >>    2.  If yes, has anyone taken a look into it yet, and possibly
> even found
>     >> a fix?
>     >>    3.  If no to both of the above, shall I submit it through the
> correct
>     >> channels then have a crack at fixing myself?  Or is the issue
> likely to be
>     >> a much deeper and far-reaching one than I?m anticipating?
>     >>
>     >> Many thanks
>     >>
>     >> Ed
>     >>
>
>

From rlichten at openjdk.java.net  Mon Jan 27 06:41:06 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Mon, 27 Jan 2020 06:41:06 GMT
Subject: [Rev 02] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <YqjyVCvXrww4xkNlAd7sZR7PX100_P5c-C1Z6LVbxQk=.28df1da6-bd49-4a22-9414-f371af1119bc@github.com>

> Test simulates a single mouse-released event.
> Fix simply guards against the null case.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - a54a5306: 8237372: NullPointerException in TabPaneSkin.stopDrag

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/89/files
  - new: https://git.openjdk.java.net/jfx/pull/89/files/30290116..a54a5306

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

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

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

From rlichten at openjdk.java.net  Mon Jan 27 06:41:27 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Mon, 27 Jan 2020 06:41:27 GMT
Subject: [Rev 01] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <3nnY_KhRNQv-ucgWGuye_6sael0yrNBAWCmHGoe7gjw=.dc00edec-f607-4a3a-8fa1-1b7065f5c0a8@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <7o-JcZfwu4Oxcsgsw62n8ml1rc-Sd0DrYHuYnFDgSng=.cc3a5528-dd9b-42fb-bd27-cae32c6fe189@github.com>
 <3nnY_KhRNQv-ucgWGuye_6sael0yrNBAWCmHGoe7gjw=.dc00edec-f607-4a3a-8fa1-1b7065f5c0a8@github.com>
Message-ID: <hBcprEYiuVD27NimqqgVfkzLwdkqn7JwvPQy7SEJgi0=.3aa3cd76-bb44-41e4-aebf-5df3cbfc5f3e@github.com>

On Fri, 24 Jan 2020 15:41:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1994:
> 
>> 1993:     private ListChangeListener childListener = new ListChangeListener<Node>() {
>> 1994:         @Override
>> 1995:         public void onChanged(Change<? extends Node> change) {
> 
> Please revert.

Reverted the Overrides-Annotations inserted by eclipse.

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

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

From it at kwinan.de  Mon Jan 27 07:32:48 2020
From: it at kwinan.de (it at kwinan.de)
Date: Mon, 27 Jan 2020 08:32:48 +0100
Subject: Canvas -> globalAlpha for custom / round clips
Message-ID: <1580110368591.17700.168816@webmail9>

Hello everybody

Maybe I'm making a mistake, but it seems to me that graphicContext.restore() for globalAlpha doesn't work if clipping is used that was not constructed via rect(...).

Java: openjdk 11.0.6 2020-01-14
JavaFX: 13
OS: Windows 10 Pro

Code:

package foo.bar;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.canvas.Canvas;
import javafx.scene.canvas.GraphicsContext;
import javafx.scene.layout.Pane;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.stage.Stage;

public class Main extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
final double width = 1000;
final double height = 600;

final Canvas canvas = new Canvas(width, height);

final Pane root = new StackPane();
root.setStyle("-fx-background-color: bisque;");
root.getChildren().add(canvas);

defaultRectangleClip(100, 100, 200, 200, canvas.getGraphicsContext2D());
customRectangleClip(400, 100, 200, 200, canvas.getGraphicsContext2D());
ovalClip(700, 100, 200, canvas.getGraphicsContext2D());

final Scene scene = new Scene(root);
primaryStage.setScene(scene);
primaryStage.setMaxWidth(width);
primaryStage.setMaxHeight(height);
primaryStage.show();
}

private void defaultRectangleClip(double x, double y, double width, double height, final GraphicsContext graphicsContext) {
// no problem
graphicsContext.save();
graphicsContext.beginPath();
graphicsContext.rect(x, y, width, height);
graphicsContext.closePath();
graphicsContext.clip();
graphicsContext.setGlobalAlpha(0.1);
graphicsContext.setFill(Color.RED);
graphicsContext.fillRect(x, y, width * 2, height * 2);
graphicsContext.restore();
}

private void customRectangleClip(double x, double y, double width, double height, final GraphicsContext graphicsContext) {
graphicsContext.save();
graphicsContext.beginPath();
graphicsContext.moveTo(x, y);
graphicsContext.lineTo(x + width, y);
graphicsContext.lineTo(x + width, y + height);
graphicsContext.lineTo(x, y + height);
graphicsContext.closePath();
graphicsContext.clip();
graphicsContext.setGlobalAlpha(0.4); // Comment out this line to see the difference.
graphicsContext.setFill(Color.GREEN);
graphicsContext.fillRect(x, y, width * 2, height * 2);
graphicsContext.restore();
}

private void ovalClip(double x, double y, double radii, final GraphicsContext graphicsContext) {
graphicsContext.save();
graphicsContext.beginPath();
graphicsContext.arc(x, y, radii, radii, 0, 360);
graphicsContext.closePath();
graphicsContext.clip();
graphicsContext.setGlobalAlpha(1.0); // Doesn't work -> Should be 1.0 per default?
graphicsContext.setFill(Color.CORNFLOWERBLUE);
graphicsContext.fillRect(x, y, radii * 4, radii * 4);
graphicsContext.restore();
}
}



Best regards
Michael





From kevin.rushforth at oracle.com  Mon Jan 27 13:09:14 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 27 Jan 2020 05:09:14 -0800
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
 <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
 <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>
Message-ID: <b68fb310-c554-fd63-b979-b08f60d55a29@oracle.com>

As a reminder, the RDP2 date for JavaFX 14 is Monday, February 3, at 
23:59 Pacific time. This is the deadline for all P3-P4 bugs for JavaFX 
14. Please allow sufficient time for your review to complete ahead of 
that deadline.

During RDP2 P1-P2 bugs can be fixed for JavaFX 14 with approval, as was 
done in previous releases. Doc-only bugs and test-only bugs of any 
priority may still be fixed during RDP2.

-- Kevin


On 12/16/2019 11:34 AM, Kevin Rushforth wrote:
> ...
>
> To address this, we are delaying RDP1 by three days. The new RDP1 date 
> is:
>
> Thursday, Jan 9, 23:59 PST
>
> The dates for RDP2, code freeze, and GA are unchanged.
>
> ...
>
> On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
>> ...
>>
>> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>>> Here is the proposed schedule for JavaFX 14.
>>>
>>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>>> RDP2: Feb 3, 2020
>>> Freeze: Feb 24, 2020
>>> GA: March 10, 2020
>>>
>>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is 
>>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>>
>>> Please let Johan or me know if you have any questions.
>>>
>>> -- Kevin
>>>
>>
>


From kcr at openjdk.java.net  Mon Jan 27 13:44:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 27 Jan 2020 13:44:15 GMT
Subject: [Integrated] RFR: 8236912: Preventing NPE when clicking WebView
 with forward/back mouse buttons
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <1d6fe9d8-df77-40b4-a7f9-e0d182c3f6bf@openjdk.org>

Changeset: aa6f3a4e
Author:    Robert Lichtenberger <rlichten at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-27 13:43:47 +0000
URL:       https://git.openjdk.java.net/jfx/commit/aa6f3a4e

8236912: NullPointerException when clicking in WebView with Button 4 or Button 5

Reviewed-by: ghb, kcr

! modules/javafx.web/src/main/java/javafx/scene/web/WebView.java
! modules/javafx.web/src/test/java/test/javafx/scene/web/WebViewTest.java

From kcr at openjdk.java.net  Mon Jan 27 13:47:57 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 27 Jan 2020 13:47:57 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
 <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
 <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>
Message-ID: <3PvgtFCD9kQOb_g9yptrkQOh3wjACCLdiCGmXFM7NX4=.dc098e56-e182-4a1a-9453-ce4e44381fc8@github.com>

On Sun, 26 Jan 2020 11:58:27 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>>> 
>>> 
>>> > the `WriteableImage` used to collate the tiles and the tiles returned from the `RTTexture` have different pixel formats (`IntARGB` for the tile and `byteBGRA` for the `WriteableImage`).
>>> 
>>> Where did you see these?
>> 
>> Simply by watching the value of  `tile.getPixelReader().getPixelFormat()` and `wimg.getPixelWriter().getPixelFormat()` before doing the copy at https://github.com/openjdk/jfx/blob/4bc4417356ebd639567d315257a6bbe11344d9c2/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L1315
>>> 
>>> > Unfortunately it seems the only way to choose the pixel format for a `WritableImage` is to initialize it with a `PixelBuffer`, but then one can no longer use a `PixelWriter` to update it...
>>> 
>>> You can update it with `PixelBuffer#updateBuffer`. I think that you will want to pass the stitched tile as the dirty region.
>> 
>> Thanks. I'll look into it.
> 
>> 
>> 
>> > profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`
>> 
>> This is a bit naive, but what if you parallelize the code there? I didn't test that this produces the correct result, but you can try to replace the loops with this:
>> 
>> ```
>> IntStream.range(0, h).parallel().forEach(y -> {    
>>     IntStream.range(0, w).parallel().forEach(x -> {
>>         int pixel = srcarr[srcoff++];              
>>         dstarr[dstoff++] = (byte) (pixel      );   
>>         dstarr[dstoff++] = (byte) (pixel >>  8);   
>>         dstarr[dstoff++] = (byte) (pixel >> 16);   
>>         dstarr[dstoff++] = (byte) (pixel >> 24);   
>>     });                                            
>>     srcoff += srcscanints;                         
>>     dstoff += dstscanbytes;                        
>> });                                                
>> ```
> 
> I don't think this works as it is, as all threads race to increment `srcoff` and `dstoff`.

I would be very cautious of using multi-threading here. In any case, I think that the issues around absolute performance could be handled separately.

Having said that, given my review comments, along with the concerns over performance regressions for those cases that will now be tiled, but formerly weren't, I no longer think this is a good candidate for openjfx14. This PR should be retargeted to the `master` branch for openjfx15.

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

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

From ed at kennard.net  Mon Jan 27 14:22:32 2020
From: ed at kennard.net (Ed Kennard)
Date: Mon, 27 Jan 2020 14:22:32 +0000
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <CAMzdD4129KpDT8s4gL7ADBLk-MEiMzCnk=N+PxDTFHbCqDhwsg@mail.gmail.com>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <CA+0ynh-FiEjR1kxq1s=PRVRKN77D4nNNfJ0_d4V3_v80kO8dPA@mail.gmail.com>
 <efc71d5f-9fb0-872d-4bad-f577a5a29e40@oracle.com>
 <33343544-49FD-404C-9F37-51A64F849897@kennard.net>
 <CA+0ynh-UfmYTrqd0VTsPhKY5t8ANEvxbr3zUO5r0VZxKbfxMsA@mail.gmail.com>
 <8CD8B4B0-D9D5-4D42-BB54-AEBAF52340D9@kennard.net>
 <CAMzdD4129KpDT8s4gL7ADBLk-MEiMzCnk=N+PxDTFHbCqDhwsg@mail.gmail.com>
Message-ID: <AABD534F-67F0-4B29-8D14-D376C19E0544@kennard.net>

Hi Jonathan,

Thanks for jumping into the discussion.

I?ve tested setting a value for fixedCellSize?

Against Java 8, there is indeed a _major_ improvement in vertical scrolling performance, but there are some issues that come with that.  Performance of horizontal scrolling suffers, becoming similarly juddery to how the vertical scrolling was, although not quite as bad.  Also, when scrolling horizontally, the left-most 1, 2 or 3 columns are rendered incorrectly, seemingly with their values not being set.  This issue gets worse the further you scroll to the right, so if the horizontal scroll bar is all the way to the left then there?s no issue, but if it?s all the way to the right, in my sample table with 382 columns, 3.5 columns are rendered blank on the left side of the table.

Against Java 11 LTS, setting fixedCellSize no longer has any positive impact on the vertical scrolling, but it does still bring all of the negative effects to the horizontal scrolling.

Out of the above, I?m not sure what is valuable to formally submit as bugs/changes, versus what not.  If someone could give me guidance on that, happy to prepare test code focusing on the useful stuff.

Thanks

Ed



From: Jonathan Giles <jonathan at jonathangiles.net>
Date: Sunday, 26 January 2020 at 22:48
To: Ed Kennard <ed at kennard.net>
Cc: Nir Lisker <nlisker at gmail.com>, "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
Subject: Re: TableView slow vertical scrolling with 300+ columns

It's been a wee while since I built TableView, but from memory there is code in there that virtualises the columns, such that those that are scrolled out of view are not being included in the scenegraph needlessly. From memory, to achieve this all you needed to do was set a fixed row height on the TableView, using this API: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableView.html#fixedCellSizeProperty

I'm sure it will won't be a silver bullet, but from my recollection it did massively help for these scenarios where there were many columns, most of which were not in the viewable area.

-- Jonathan

On Sun, Jan 26, 2020 at 5:11 AM Ed Kennard <ed at kennard.net<mailto:ed at kennard.net>> wrote:
I did previously look at the ControlsFX SpreadsheetView, but it wasn?t a good match, at least at that time.  Off the top of my head, I?m not sure it supports nested column headers, which is essential for our purposes. Furthermore, in my travels around the internet on this subject I?ve seen comments suggesting it has its own performance issues, too.  I will revisit it though, just to be sure.

Beyond that, I haven?t seen any other 3rd party libraries along these lines


From: Nir Lisker <nlisker at gmail.com<mailto:nlisker at gmail.com>>
Date: Saturday, 25 January 2020 at 16:40
To: Ed Kennard <ed at kennard.net<mailto:ed at kennard.net>>
Cc: Kevin Rushforth <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>>, "openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net>" <openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net>>
Subject: Re: TableView slow vertical scrolling with 300+ columns

So might it be better to submit a new feature request to develop a separate and leaner control entirely, geared much more towards viewing large datasets without all the bells and whistles of a TableView?

 Doesn't ControlsFX have that already, or some other 3rd party library?

On Sat, Jan 25, 2020 at 5:34 PM Ed Kennard <ed at kennard.net<mailto:ed at kennard.net><mailto:ed at kennard.net<mailto:ed at kennard.net>>> wrote:
Hi Kevin, Nir,

I also dug out those two bug reports and agree neither are close enough.  However, it seems to be general consensus that in order to properly address the issue, TableView's virtualisation would need to be changed to support columns in addition to rows, and that the extra complexity through the rest of the control's features would not be a worthwhile trade-off.

So might it be better to submit a new feature request to develop a separate and leaner control entirely, geared much more towards viewing large datasets without all the bells and whistles of a TableView?




On 25/01/2020, 15:39, "Kevin Rushforth" <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>>> wrote:

    I took a quick look and didn't see one that was close enough to this, so
    I think it's worth submitting a new bug report. The closest I found were
    JDK-8166956 [1] and JDK-8185887 [2].

    I also would be interested to know whether others have run into this in
    their applications.

    -- Kevin

    [1] https://bugs.openjdk.java.net/browse/JDK-8166956
    [2] https://bugs.openjdk.java.net/browse/JDK-8185887


    On 1/25/2020 2:10 AM, Nir Lisker wrote:
    > Hi Ed,
    >
    > Try to search JBS [1] for this issue. If you don't find one, you can submit
    > it through bugs.java.com<http://bugs.java.com><http://bugs.java.com>, though I suspect this is known.
    >
    > I don't know the technicalities of VirtualFlow in TableView, so can't help
    > there.
    >
    > - Nir
    >
    > [1] https://bugs.openjdk.java.net/issues/?jql=component %3D javafx
    >
    > On Sat, Jan 25, 2020 at 3:39 AM Ed Kennard <ed at kennard.net<mailto:ed at kennard.net><mailto:ed at kennard.net<mailto:ed at kennard.net>>> wrote:
    >
    >> Hi everyone,
    >>
    >> I?m new to the list, so by way of a short introduction, I?ve been working
    >> with JavaFX for the last 4 years developing a commodities trading risk
    >> management system from the ground up for a software company I co-founded in
    >> London.  All our code is written in Scala, the functional style of which is
    >> essential for the mathematical heavy lifting needed on the backend, but
    >> which also lends itself really well to UI programming and working with
    >> JavaFX.  I?m enthusiastic about JavaFX and would love to make a
    >> contribution to the project.
    >>
    >> At the center of our product is an extension of the TableView control
    >> that?s responsible for displaying all the output from our pivot reporting
    >> engine.  Depending on how the user configures the layout of their pivot
    >> reports, sometimes there are a legitimately large number of columns
    >> (300+).  When that happens, while the horizontal scrolling remains
    >> perfectly smooth, the vertical scrolling degrades to a somewhat juddery
    >> state and CPU usage spikes.
    >>
    >> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
    >> https://github.com/javafxports/openjdk-jfx/issues/409
    >>
    >> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was
    >> ever submitted through the correct channels.  I can confirm that the test
    >> code included there by ?yososs? on 20th May 2019 perfectly illustrates the
    >> problem I?m experiencing.  The same person seems to have a fairly clear
    >> theory on what is causing the problem, too - see their follow-up comment on
    >> 12 Sept 2019.
    >>
    >> So, my questions to the list are:
    >>
    >>
    >>    1.  Has anyone seen this issue raised anywhere else?
    >>    2.  If yes, has anyone taken a look into it yet, and possibly even found
    >> a fix?
    >>    3.  If no to both of the above, shall I submit it through the correct
    >> channels then have a crack at fixing myself?  Or is the issue likely to be
    >> a much deeper and far-reaching one than I?m anticipating?
    >>
    >> Many thanks
    >>
    >> Ed
    >>

From clemens.kadura at katla.de.com  Mon Jan 27 14:43:30 2020
From: clemens.kadura at katla.de.com (Clemens Kadura)
Date: Mon, 27 Jan 2020 15:43:30 +0100
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
Message-ID: <b5d41168-5dae-0211-3c85-b1d07e52e9a8@katla.de.com>

Hello Ed, hello all,

It is also the first time that I become active in this mailing list, 
although I'm already monitoring this list for half a year to get 
familiar with your conventions.
I am co-founder of a software and consulting company in Germany. We 
develop a system (JACAMAR) that combines a serverless no-sql database 
engine with a customizable user interface for do-it-yourself non-IT 
expert end users. We started with an Eclipse based user interface, 
switched in 2015 to a self developed UI and unfortunately found out only 
very late that JavaFX did just the same with, I guess, a lot more 
resources than we have. So we switched another time to JavaFX and are 
about to launch our next version. By going this way, we have gained a 
lot of insights in the field of user interfaces.

To come to your question:
Yes we also experienced issues of poor performance on scrolling virtual 
tables with a lot of columns.
The reason is in the nature of the VirtualFlow, which is the base of 
TableView: It has a "virtual" direction and a "static" direction. By 
default the vertical direction is the virtual one. That means the 
vertical scrollbar works with a value p between 0 and 1. Depending on 
how quick you scroll, only those lines are calculated and rendered, 
which will become visible in the the viewport for a given p. This gives 
good performance for tables with huge amount of lines.
The problem is now the horizontal direction. Since this dimension is 
static, TableRowSkin calculates and renders all TableCells of each 
TableRow independent of its actual visibility in the view port. (see 
TableRowSkinBase line 519ff.)
This works well for TableRows with relatively low number of columns. And 
knowing that, it is obvious, why the horizontal scrolling works so quick 
in your application, because all cells are already prepared and just 
need to be moved in X to become visible.
There are 2 opportunities how to attack that issue:
1.) If you don't have many lines, you could just change the vertical 
property to false (see VirtualFlow line 745). We did it only in a test 
case so far, so we don't have a lot of experience about that.
2.) is a tradeoff between vertical and horizontal performance. A code 
change would be required in TableRowSkinBase to restrict the actual 
creation of TableCells for one line to only those cells that will become 
visible for a particular scroll pulse. That way only 10-20 cells are 
affected for each line and not 300 any longer. If you now scroll 
horizontally, all new cells that become visible, must be additionally 
calculated and rendered at that point in time. Unless you have a 50-inch 
screen, there shouldn't be so many cells, so the loss of performance in 
horizontal direction should be manageable.

At the moment I am still very occupied with our system launch, but I 
intend to participate soon in the community and give back a little bit 
of what we received from using JavaFX for free in our applications up to 
now.

Greetings
Clemens


Am 25.01.2020 um 02:39 schrieb Ed Kennard:
> Hi everyone,
>
> I?m new to the list, so by way of a short introduction, I?ve been working with JavaFX for the last 4 years developing a commodities trading risk management system from the ground up for a software company I co-founded in London.  All our code is written in Scala, the functional style of which is essential for the mathematical heavy lifting needed on the backend, but which also lends itself really well to UI programming and working with JavaFX.  I?m enthusiastic about JavaFX and would love to make a contribution to the project.
>
> At the center of our product is an extension of the TableView control that?s responsible for displaying all the output from our pivot reporting engine.  Depending on how the user configures the layout of their pivot reports, sometimes there are a legitimately large number of columns (300+).  When that happens, while the horizontal scrolling remains perfectly smooth, the vertical scrolling degrades to a somewhat juddery state and CPU usage spikes.
>
> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
> https://github.com/javafxports/openjdk-jfx/issues/409
>
> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was ever submitted through the correct channels.  I can confirm that the test code included there by ?yososs? on 20th May 2019 perfectly illustrates the problem I?m experiencing.  The same person seems to have a fairly clear theory on what is causing the problem, too - see their follow-up comment on 12 Sept 2019.
>
> So, my questions to the list are:
>
>
>    1.  Has anyone seen this issue raised anywhere else?
>    2.  If yes, has anyone taken a look into it yet, and possibly even found a fix?
>    3.  If no to both of the above, shall I submit it through the correct channels then have a crack at fixing myself?  Or is the issue likely to be a much deeper and far-reaching one than I?m anticipating?
>
> Many thanks
>
> Ed

-- 
Mit freundlichen Gr??en / Kind Regards

Clemens Kadura
Development Leader
Co-founder

*JACAMAR - agiles Datenmanagement im Team
Weitere Informationen auf www.jacamar.de <https://www.jacamar.de> *



Katla GmbH
Immermannstr. 28
39108 Magdeburg
Tel: +49 391-50558353
Fax: +49 391-50549735
www.katla-gmbh.de

Vertretungsberechtigter Gesch?ftsf?hrer: Dr. J?rg Czekalla
Firmensitz: Magdeburg, Amtsgericht Stendal, HRB 19672
Verantwortlich i.S.d.MDStV: Katla GmbH


From kcr at openjdk.java.net  Mon Jan 27 15:30:36 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 27 Jan 2020 15:30:36 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <3PvgtFCD9kQOb_g9yptrkQOh3wjACCLdiCGmXFM7NX4=.dc098e56-e182-4a1a-9453-ce4e44381fc8@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
 <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
 <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>
 <3PvgtFCD9kQOb_g9yptrkQOh3wjACCLdiCGmXFM7NX4=.dc098e56-e182-4a1a-9453-ce4e44381fc8@github.com>
Message-ID: <VNk6ODle4XSeACeINFqlGs1Mc_9y842ofxrB2GhACFU=.9735d3fb-369f-40ff-ba6f-fcae901fc75c@github.com>

On Mon, 27 Jan 2020 13:47:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> 
>>> 
>>> > profiling a run of the benchmark shows that a lot of time is spent into `IntTo4ByteSameConverter::doConvert`
>>> 
>>> This is a bit naive, but what if you parallelize the code there? I didn't test that this produces the correct result, but you can try to replace the loops with this:
>>> 
>>> ```
>>> IntStream.range(0, h).parallel().forEach(y -> {    
>>>     IntStream.range(0, w).parallel().forEach(x -> {
>>>         int pixel = srcarr[srcoff++];              
>>>         dstarr[dstoff++] = (byte) (pixel      );   
>>>         dstarr[dstoff++] = (byte) (pixel >>  8);   
>>>         dstarr[dstoff++] = (byte) (pixel >> 16);   
>>>         dstarr[dstoff++] = (byte) (pixel >> 24);   
>>>     });                                            
>>>     srcoff += srcscanints;                         
>>>     dstoff += dstscanbytes;                        
>>> });                                                
>>> ```
>> 
>> I don't think this works as it is, as all threads race to increment `srcoff` and `dstoff`.
> 
> I would be very cautious of using multi-threading here. In any case, I think that the issues around absolute performance could be handled separately.
> 
> Having said that, given my review comments, along with the concerns over performance regressions for those cases that will now be tiled, but formerly weren't, I no longer think this is a good candidate for openjfx14. This PR should be retargeted to the `master` branch for openjfx15.

I thought of one possibility that might be worth looking into for a short term fix (i.e., could still go into openjfx14). Rather than relying on `PrismSettings.maxTextureSize` you could instead try to render the entire image (as is done today) in a try / catch block, and only fall back to tiling if there is an exception. That way there would be no concern over any possible performance regression, since the only time we would use tiling would be in the case where it fials today.

What do you think?

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

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

From fkirmaier at openjdk.java.net  Mon Jan 27 15:34:46 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Mon, 27 Jan 2020 15:34:46 GMT
Subject: [Rev 02] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
Message-ID: <3lORrAdqsiYTgm-krGh1rAt1RNk-6Hp32XbCLpr-zKU=.a3c07cfa-0c05-4f39-8032-b98fbf25b5b7@github.com>

> Hi everyone,
> 
> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
> 
> The fix itself is quite straight forward.
> It basically just removed the listener which causes the leak.
> 
> The unit-test for the fix is a bit more complicated.
> 
> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
> It could also simplify many of the already existing unit tests.
> It makes testing for memory-leaks readably and reliable. 
> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
> It only contains a single class.
> 
> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 768f70c7: JDK-8236259

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/71/files
  - new: https://git.openjdk.java.net/jfx/pull/71/files/e9ea4d8e..768f70c7

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

  Stats: 30 lines in 3 files changed: 0 ins; 29 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/71.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/71/head:pull/71

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

From fkirmaier at openjdk.java.net  Mon Jan 27 15:34:47 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Mon, 27 Jan 2020 15:34:47 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <OHR6_mbjOrYOmmJO53Q84ND9MsZvobdX7Di0EDeqS7E=.d86ff800-fe6c-4f50-9409-018620e1ef3c@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
 <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
 <iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyO
 Qx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com>
 <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com>
 <xFY1R-O53_xFrJnVfvJdRFvMSTo7e3XxP02zZjGFvvM=.78597514-fb80-454b-a7ce-4e336e7bcc1f@github.com>
 <OHR6_mbjOrYOmmJO53Q84ND9MsZvobdX7Di0EDeqS7E=.d86ff800-fe6c-4f50-9409-018620e1ef3c@github.com>
Message-ID: <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com>

On Mon, 6 Jan 2020 23:05:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I agree. Static analysis tools are quite limited in this regard, and are in now way a substitute for regression testing.
>> 
>> So the question is how best to test fixes for memory leaks at runtime. Our current approach can be best characterized as "ad hoc", and is not all that robust (although works well enough in most cases and is still much better than doing no testing at all). I would welcome discussion of a more robust approach for testing, but it should be decoupled from this bug fix, and discussed as a separate JBS Enhancement request.
> 
> The use of static analysis tools to catch certain types of problems is orthogonal to a regression test to validate a bug fix of a specific memory leak.
> 
> @FlorianKirmaier as mentioned previously, please file a new JBS Enhancement to propose adding a test utility for memory leak test. You can then start a discussion on the openjfx-dev mailing list.
> 
> As for fixing this memory leak, I recommend one of the following two approaches:
> 1. Modify the PR without relying on any new utilities (meaning you would create yet-another adhoc test for memory leaks).
> 2. Close this PR, wait for memory leak test utility to be integrated, and then resubmit the PR for this leak using that utility.
> 
> Obviously, approach 1 would get the fix in faster. You could then modify the test to use the new utility as part of implementing the utility.

A little bit late ...
I have now removed unit-test and it's dependency.
I will add a ticket about adding them again.

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

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

From mike at plan99.net  Mon Jan 27 15:59:45 2020
From: mike at plan99.net (Mike Hearn)
Date: Mon, 27 Jan 2020 07:59:45 -0800
Subject: Explanation of different scaling factors anywhere?
Message-ID: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>

Hello,

A feature I often miss when using non-web GUIs is support for browser style
zooming. In JavaFX it is quite easy to specify all font sizes in terms of
"ems", relative sizes ("largest") or percentages and then adjust the base
font size on a root node inside key handlers. This works OK but doesn't do
much for images or other controls, and of course most JavaFX GUI code
specifies sizes in terms of pixels.

There are various scaling factors applied to pixel sizes. There is the
per-node scaling transform, but this doesn't affect layout so isn't
comparable to what browsers do. There's a per-screen DPI, there's a
"platform scale", there's a "render scale" and then there's a "ui scale".
These seem related to hidpi/retina support and are all internal (for the
purposes of this question I'm happy to modify JavaFX itself).

Render scale seems to affect resolution without affecting positions or
layout, so that's not quite what I want. UI scale sounds promising but
isn't documented and I couldn't quite figure it out by reading the code,
though I could just fiddle with it and see what happens.

It feels like someone probably explored this before now. Is there a way to
effectively expand the size of every node without altering the size of the
containing viewport, to get browser-style layout affecting  zoom?  If not,
has anyone explored the complexity of the modifications required?

thanks,
-mike

From David.Grieve at microsoft.com  Mon Jan 27 16:29:04 2020
From: David.Grieve at microsoft.com (David Grieve)
Date: Mon, 27 Jan 2020 16:29:04 +0000
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>
References: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>
Message-ID: <BN8PR21MB1281D717E89FD664B8FA6DED9B0B0@BN8PR21MB1281.namprd21.prod.outlook.com>

Wouldn't this just be a scale transform? 

> -----Original Message-----
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev at openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
> 
> Hello,
> 
> A feature I often miss when using non-web GUIs is support for browser style
> zooming. In JavaFX it is quite easy to specify all font sizes in terms of "ems",
> relative sizes ("largest") or percentages and then adjust the base font size on a
> root node inside key handlers. This works OK but doesn't do much for images
> or other controls, and of course most JavaFX GUI code specifies sizes in terms
> of pixels.
> 
> There are various scaling factors applied to pixel sizes. There is the per-node
> scaling transform, but this doesn't affect layout so isn't comparable to what
> browsers do. There's a per-screen DPI, there's a "platform scale", there's a
> "render scale" and then there's a "ui scale".
> These seem related to hidpi/retina support and are all internal (for the
> purposes of this question I'm happy to modify JavaFX itself).
> 
> Render scale seems to affect resolution without affecting positions or layout,
> so that's not quite what I want. UI scale sounds promising but isn't
> documented and I couldn't quite figure it out by reading the code, though I
> could just fiddle with it and see what happens.
> 
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting  zoom?  If not, has
> anyone explored the complexity of the modifications required?
> 
> thanks,
> -mike

From github.com+7450507+fthevenet at openjdk.java.net  Mon Jan 27 18:45:28 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Mon, 27 Jan 2020 18:45:28 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <VNk6ODle4XSeACeINFqlGs1Mc_9y842ofxrB2GhACFU=.9735d3fb-369f-40ff-ba6f-fcae901fc75c@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
 <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
 <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>
 <3PvgtFCD9kQOb_g9yptrkQOh3wjACCLdiCGmXFM7NX4=.dc098e56-e182-4a1a-9453-ce4e44381fc8@github.com>
 <VNk6ODle4XSeACeINFqlGs1Mc_9y842ofxrB2GhACFU=.9735d3fb-369f-40ff-ba6f-fcae901fc75c@github.com>
Message-ID: <bsVolqKIkyt5o8YrZzx5AiV3rNguKXbjl7CDPuTVtLg=.0bc62a61-ff21-4b06-8fca-6f53f9bb5117@github.com>

On Mon, 27 Jan 2020 15:30:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I would be very cautious of using multi-threading here. In any case, I think that the issues around absolute performance could be handled separately.
>> 
>> Having said that, given my review comments, along with the concerns over performance regressions for those cases that will now be tiled, but formerly weren't, I no longer think this is a good candidate for openjfx14. This PR should be retargeted to the `master` branch for openjfx15.
> 
> I thought of one possibility that might be worth looking into for a short term fix (i.e., could still go into openjfx14). Rather than relying on `PrismSettings.maxTextureSize` you could instead try to render the entire image (as is done today) in a try / catch block, and only fall back to tiling if there is an exception. That way there would be no concern over any possible performance regression, since the only time we would use tiling would be in the case where it fials today.
> 
> What do you think?

I have tested using a recipient WritableImage with an IntARGB pixel format (so that is aligned with that of the tile), that I construct by supplying a PixelBuffer, and as expected that performance of the tiled code is much more in line with that of the non-tiled version. One overhead left is the allocation of the extra buffer, but it is far less significant.
The problem with this approach is that the "best" pixel format (as in similar to that of RRT) isn't the same depending on the rendering pipeline (e.g. d3d is intARGB while es2 is byteBGRA) so that would require adding a fair amount of code to determine the best possible scenario depending on all the constraints (keeping in mind the caller can also provide its own WritableImage...) that in turn would need thorough testing. 
All in all, I agree the risk of regression is probably too great for this to make it into openjfx14 with so little time left.

Instead, I will prototype Kevin's proposal to only use tiling when it would fail with the current code and use  what I've learned here to propose a more robust fix targeted at openjfx15

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

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

From pedro.duquevieira at gmail.com  Mon Jan 27 23:02:53 2020
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 27 Jan 2020 23:02:53 +0000
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
Message-ID: <CAAEud6bCFQvZy2-5Tr7MbCsypoKmgR_-AJS4_JE2y9=2Cg1yew@mail.gmail.com>

Hi,

AFAIK, -fx-padding values are also affected as long as they're also defined
in em.

I agree, would also be nice for other things to scale automatically,
depending on the font size defined in root. I don't think other properties
besides -fx-padding also scale.

One thing that would be nice to have to be able to do responsive design as
we can do on the web, would be to have things like media queries (css rules
that only apply on specified screen sizes), being able to specify layout
through CSS, other properties responding to changes in font size in the
root when defined in em.

Cheers,

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From tbee at tbee.org  Tue Jan 28 06:42:31 2020
From: tbee at tbee.org (Tom Eugelink)
Date: Tue, 28 Jan 2020 07:42:31 +0100
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <CAAEud6bCFQvZy2-5Tr7MbCsypoKmgR_-AJS4_JE2y9=2Cg1yew@mail.gmail.com>
References: <CAAEud6bCFQvZy2-5Tr7MbCsypoKmgR_-AJS4_JE2y9=2Cg1yew@mail.gmail.com>
Message-ID: <76e42689-1b6d-e812-4cf2-4a776b70e86d@tbee.org>

ResponsivePane is an attempt to do something in that way, but I chose a slightly different approach where the system automatically switches between different layouts and CSS files depending on the window's size. It has a common area (reusable nodes) and then specific layouts per size.
https://tbeernot.wordpress.com/2016/12/11/responsivepane/
https://github.com/JFXtras/jfxtras/blob/9.0/jfxtras-common/src/main/java/jfxtras/scene/layout/responsivepane/ResponsivePane.java

It worked very well, I used it to transition between desktop, tablet en phone screens. Except problems with higher screen DPI's, which I was not able to solve because the DPI info JavaFX gave me was inaccurate.



On 28-1-2020 00:02, Pedro Duque Vieira wrote:
> Hi,
>
> AFAIK, -fx-padding values are also affected as long as they're also defined
> in em.
>
> I agree, would also be nice for other things to scale automatically,
> depending on the font size defined in root. I don't think other properties
> besides -fx-padding also scale.
>
> One thing that would be nice to have to be able to do responsive design as
> we can do on the web, would be to have things like media queries (css rules
> that only apply on specified screen sizes), being able to specify layout
> through CSS, other properties responding to changes in font size in the
> root when defined in em.
>
> Cheers,
>


From aghaisas at openjdk.java.net  Tue Jan 28 09:03:53 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 28 Jan 2020 09:03:53 GMT
Subject: [Rev 02] RFR: 8232824: Removing TabPane with strong referenced
 content causes memory leak from weak one
In-Reply-To: <EZipNaeszEZaxzDogVu1z6kHV-7Id0ey5Tmbm7TerQs=.3c1da96f-d789-4a28-8d59-70ea025e84c8@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
 <EZipNaeszEZaxzDogVu1z6kHV-7Id0ey5Tmbm7TerQs=.3c1da96f-d789-4a28-8d59-70ea025e84c8@github.com>
Message-ID: <ttxAvhH0iETl8uSAgKlqW4wmHS_EWWn9emukbzr2ipI=.16a11adb-d20b-43b2-82cd-25dd8d243c1b@github.com>

On Tue, 28 Jan 2020 09:03:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> This PR is a fix for [JDK-8232824](https://bugs.openjdk.java.net/browse/JDK-8232824)
>> This issue is regression of [JDK-8187074](https://bugs.openjdk.java.net/browse/JDK-8187074).
>> 
>> Issue.
>> - `Parent.viewOrderChildren` is a list of children sorted according to view order.
>> - `Parent.viewOrderChildren` is cleared and computed in `Parent.computeViewOrderChildren()` which is called from `Parent.doUpdatePeer()` when a `pulse `is received.
>> 
>> - Below is the scenario mentioned in this issue,
>> 1. `TabPane` is created with few `tabs`.
>> 2. For each tab,  a `TabHeaderSkin` is created with `setViewOrder(1)` and is added to `TabHeaderArea.headersRegion`
>> 3. All these `TabHeaderSkin`s are added to `Parent.viewOrderChildren` on `pulse`.
>> 4. When the `TabPane` is removed from scene, then on the next pulse the method `Parent.doUpdatePeer()` does not get called for `TabHeaderArea.headersRegion`, because it is not part for scenegraph anymore.
>> So `Parent.computeViewOrderChildren()` does not get called and the `Parent.viewOrderChildren` does not get cleared, which causes the leak.
>> 
>> Fix:
>> Clear the `Parent.viewOrderChildren` list when marking `DirtyBits.PARENT_CHILDREN_VIEW_ORDER` as dirty.
>> `Parent.viewOrderChildren` will be computed on next `pulse`.
>> This will maintain lazy computation of `Parent.viewOrderChildren`. 
>> 
>> Added a system test, fails without fix and passes with. No failures in existing tests.
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by aghaisas (Reviewer).

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

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

From aghaisas at openjdk.java.net  Tue Jan 28 09:08:47 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 28 Jan 2020 09:08:47 GMT
Subject: [Rev 01] RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <8GTA0ist_AM_kquybyA5mj-dq6FPH5fO-vYXb1Ir-Xc=.57c7a535-c6e6-4745-8781-81be60dd212a@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
 <8GTA0ist_AM_kquybyA5mj-dq6FPH5fO-vYXb1Ir-Xc=.57c7a535-c6e6-4745-8781-81be60dd212a@github.com>
Message-ID: <RkjTKgs2JBGq0C1WkUdSbaAXzS-nSHFnpsduXjaau5w=.4462a776-34c0-429c-a224-e51114fb3330@github.com>

On Tue, 28 Jan 2020 09:08:35 GMT, Dean Wookey <dwookey at openjdk.org> wrote:

>> Everything passes with the fix and 5 of the new tests fail without the fix.
>> 
>> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
>> movingBranchToDifferentBranchGetsNewCssVariableTest
>> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
>> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
>> movingNodeToDifferentBranchGetsNewFontStyleTest
>> 
>> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
>> 
>> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab
> 
> The pull request has been updated with 1 additional commit.

modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Minor : As this is a new file being added, there should be just one 2020 (The year in which file has been introduced)

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

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

From dwookey at openjdk.java.net  Tue Jan 28 09:29:43 2020
From: dwookey at openjdk.java.net (Dean Wookey)
Date: Tue, 28 Jan 2020 09:29:43 GMT
Subject: [Rev 02] RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
Message-ID: <3ZPNIAjoZIvU3Q8tg5owogKh4-NCUNCbV9i1smDRegk=.ad26d542-45d8-4a34-b5b8-287d58d3c0f1@github.com>

> Everything passes with the fix and 5 of the new tests fail without the fix.
> 
> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
> movingBranchToDifferentBranchGetsNewCssVariableTest
> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
> movingNodeToDifferentBranchGetsNewFontStyleTest
> 
> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
> 
> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab

The pull request has been updated with 1 additional commit.

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

Added commits:
 - c7e60b9e: 8237469: Removed extra year in copyright header

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/87/files
  - new: https://git.openjdk.java.net/jfx/pull/87/files/782f55e3..c7e60b9e

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

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

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

From aghaisas at openjdk.java.net  Tue Jan 28 09:47:34 2020
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 28 Jan 2020 09:47:34 GMT
Subject: [Rev 02] RFR: 8237469: CssStyleHelper reuse check fixed
In-Reply-To: <3ZPNIAjoZIvU3Q8tg5owogKh4-NCUNCbV9i1smDRegk=.ad26d542-45d8-4a34-b5b8-287d58d3c0f1@github.com>
References: <EbQUqINBMkyMGLA0yPiQAxExhwhNbN_VrwqAbXYxA0s=.d4ac1b9c-f85d-4a9a-9fc3-ed046fdf8c69@github.com>
 <3ZPNIAjoZIvU3Q8tg5owogKh4-NCUNCbV9i1smDRegk=.ad26d542-45d8-4a34-b5b8-287d58d3c0f1@github.com>
Message-ID: <f_gEfsbRBtOo3e8_p55pGJIqzqjigwxB25_Awjvj1Ps=.09f62dff-ae2f-452c-b8c0-58173164c597@github.com>

On Tue, 28 Jan 2020 09:47:33 GMT, Dean Wookey <dwookey at openjdk.org> wrote:

>> Everything passes with the fix and 5 of the new tests fail without the fix.
>> 
>> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
>> movingBranchToDifferentBranchGetsNewCssVariableTest
>> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
>> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
>> movingNodeToDifferentBranchGetsNewFontStyleTest
>> 
>> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is?
>> 
>> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by aghaisas (Reviewer).

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

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

From danny.a.gonzalez at gmail.com  Tue Jan 28 09:50:15 2020
From: danny.a.gonzalez at gmail.com (Danny Gonzalez)
Date: Tue, 28 Jan 2020 09:50:15 +0000
Subject: How to build standalone openJFX modules for uploading to a local
 maven repository
Message-ID: <078F2BB3-4A70-49F3-90ED-9FA9A613D06B@gmail.com>


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

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

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

Is this documented anywhere?

Thanks for your help

Danny


From ghb at openjdk.java.net  Tue Jan 28 09:55:33 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Tue, 28 Jan 2020 09:55:33 GMT
Subject: RFR: 8237944: webview native cl "-m32" unknown option for windows
 32-bit build
Message-ID: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>

cl : Command line warning D9002 : ignoring unknown option '-m32'

post fix for "https://trac.webkit.org/changeset/242724/webkit" makes use of cross compiling 32 bit JSC in a 64 bit and its holds good only for Linux. 
'-m32' flag is gcc specifc and on windows cl.exe (visual studio) doesn't recognize this flag.

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

Commits:
 - 0d9ca899: 8237944: webview native cl "-m32" unknown option for windows 32-bit build

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

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

From fkirmaier at openjdk.java.net  Tue Jan 28 10:32:55 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 28 Jan 2020 10:32:55 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
Message-ID: <WdMTma_1dGW9clo7awbCWNPWhCBPVX_-Fj-xb-VA3D8=.b162760b-e35f-4a0b-a2a7-0b2b89b8144d@github.com>

On Thu, 19 Dec 2019 15:10:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 1929:
> 
>> 1928:      */
>> 1929:     public List<Node> test_getRemoved() {
>> 1930:         return removed;
> 
> This is not an acceptable change. We do not add public API to support tests. Take a look at the Shim classes for an example of how to handle this.

Done

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

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

From fkirmaier at openjdk.java.net  Tue Jan 28 10:32:57 2020
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Tue, 28 Jan 2020 10:32:57 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
Message-ID: <4tzEp8fIAzpgokuzkuHu33--xdoEPJeRFvoxooLH3vc=.94004355-f480-4af6-8b51-1cc9a922021b@github.com>

On Thu, 19 Dec 2019 15:09:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> build.gradle line 2514:
> 
>> 2513:         compile project(':graphics')
>> 2514:         testCompile "de.sandec:JMemoryBuddy:0.1.3"
>> 2515:     }
> 
> This is a new third-party dependency, which would need legal approval. You need to remove this.

Done

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

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

From tom.schindl at bestsolution.at  Tue Jan 28 11:09:04 2020
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 28 Jan 2020 12:09:04 +0100
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <BN8PR21MB1281D717E89FD664B8FA6DED9B0B0@BN8PR21MB1281.namprd21.prod.outlook.com>
References: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>
 <BN8PR21MB1281D717E89FD664B8FA6DED9B0B0@BN8PR21MB1281.namprd21.prod.outlook.com>
Message-ID: <d21c307a-67e2-6e28-9867-ea2b21d13f3e@bestsolution.at>

I think that can not work because layouts don't take the scale factor
into account nor does stuff like ScrollView but i could be wrong.

Tom

On 27.01.20 17:29, David Grieve wrote:
> Wouldn't this just be a scale transform? 
> 
>> -----Original Message-----
>> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
>> Mike Hearn
>> Sent: Monday, January 27, 2020 11:00 AM
>> To: openjfx-dev at openjdk.java.net
>> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>>
>> Hello,
>>
>> A feature I often miss when using non-web GUIs is support for browser style
>> zooming. In JavaFX it is quite easy to specify all font sizes in terms of "ems",
>> relative sizes ("largest") or percentages and then adjust the base font size on a
>> root node inside key handlers. This works OK but doesn't do much for images
>> or other controls, and of course most JavaFX GUI code specifies sizes in terms
>> of pixels.
>>
>> There are various scaling factors applied to pixel sizes. There is the per-node
>> scaling transform, but this doesn't affect layout so isn't comparable to what
>> browsers do. There's a per-screen DPI, there's a "platform scale", there's a
>> "render scale" and then there's a "ui scale".
>> These seem related to hidpi/retina support and are all internal (for the
>> purposes of this question I'm happy to modify JavaFX itself).
>>
>> Render scale seems to affect resolution without affecting positions or layout,
>> so that's not quite what I want. UI scale sounds promising but isn't
>> documented and I couldn't quite figure it out by reading the code, though I
>> could just fiddle with it and see what happens.
>>
>> It feels like someone probably explored this before now. Is there a way to
>> effectively expand the size of every node without altering the size of the
>> containing viewport, to get browser-style layout affecting  zoom?  If not, has
>> anyone explored the complexity of the modifications required?
>>
>> thanks,
>> -mike

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From pedro.duquevieira at gmail.com  Tue Jan 28 11:12:36 2020
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 28 Jan 2020 11:12:36 +0000
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
Message-ID: <CAAEud6Y16kZGC_oX4xiLrvLD0p35e8w4Z3eL+dZEdAE8oYHScQ@mail.gmail.com>

Interesting, Tom.

I didn't know about this blog post and control.

Cheers,

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From tbee at tbee.org  Tue Jan 28 11:44:58 2020
From: tbee at tbee.org (Tom Eugelink)
Date: Tue, 28 Jan 2020 12:44:58 +0100
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <CAAEud6Y16kZGC_oX4xiLrvLD0p35e8w4Z3eL+dZEdAE8oYHScQ@mail.gmail.com>
References: <CAAEud6Y16kZGC_oX4xiLrvLD0p35e8w4Z3eL+dZEdAE8oYHScQ@mail.gmail.com>
Message-ID: <a80a520f-f83c-74d6-db09-9fc167023767@tbee.org>

One can't keep taps on everything. :-) It was part of the "One application to rule them all" talk I had on the JavaOne 2017.
Just tested it, but it's still doing its thing in my time registration app.

Desktop layout:

Phone layout:

This is on my desktop when I resize the window.

I'll stop spamming this list now.

Tom


On 28-1-2020 12:12, Pedro Duque Vieira wrote:
> Interesting, Tom.
>
> I didn't know about this blog post and control.
>
> Cheers,
>


From ed at kennard.net  Tue Jan 28 11:49:03 2020
From: ed at kennard.net (Ed Kennard)
Date: Tue, 28 Jan 2020 11:49:03 +0000
Subject: Release roadmap for 2 already-merged TableView PRs 
Message-ID: <8EAB2D1E-24EE-45DD-AEE3-0B07FBAAD328@kennard.net>

Hi everyone,

In Java 9 there were some issues introduced into the TableView code which significantly reduced the extensibility of the skinning.  These issues were blocking ones for us, in terms of migrating from 8 to 11, since we rely heavily on what was originally exposed, a good example being the resizeColumnToFitContent method, originally a protected method in TableViewSkin but moved to the static TableSkinUtils.

I?ve found in the more recent history 2 separate commits by Samir Hadzic which I believe completely solve this for us:

[1] 8207942: Add new protected VirtualFlow methods for subclassing (exposes reorderingProperty, fixed for Java 12)
[2] 8207957: TableSkinUtils should not contain actual code implementation (exposes resizeColumnToFitContent again, fixed for Java 14)

This is excellent news, thanks guys!

It looks like the first opportunity to benefit from both changes is to wait for the upcoming Java 14 pre-release Feb 6th - is that on schedule, and please could I try that out?  Then am I correct in thinking it will be officially published at AdpotOpenJDK on March 17th?

Thanks

Ed

[1] https://bugs.openjdk.java.net/browse/JDK-8207942
[2] https://bugs.openjdk.java.net/browse/JDK-8207957



From arapte at openjdk.java.net  Tue Jan 28 12:37:13 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 28 Jan 2020 12:37:13 GMT
Subject: [Integrated] RFR: 8232824: Removing TabPane with strong
 referenced content causes memory leak from weak one
In-Reply-To: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
Message-ID: <902bfa54-3d5c-4ca2-8903-3c5d8dd3a1e5@openjdk.org>

Changeset: 79fc0d0d
Author:    Ambarish Rapte <arapte at openjdk.org>
Date:      2020-01-28 12:35:52 +0000
URL:       https://git.openjdk.java.net/jfx/commit/79fc0d0d

8232824: Removing TabPane with strong referenced content causes memory leak from weak one

Reviewed-by: kcr, aghaisas

! modules/javafx.graphics/src/main/java/javafx/scene/Parent.java
+ tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java
+ tests/system/src/test/java/test/javafx/scene/shape/ShapeViewOrderLeakTest.java

From arapte at openjdk.java.net  Tue Jan 28 12:39:21 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 28 Jan 2020 12:39:21 GMT
Subject: [Rev 02] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <YqjyVCvXrww4xkNlAd7sZR7PX100_P5c-C1Z6LVbxQk=.28df1da6-bd49-4a22-9414-f371af1119bc@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <YqjyVCvXrww4xkNlAd7sZR7PX100_P5c-C1Z6LVbxQk=.28df1da6-bd49-4a22-9414-f371af1119bc@github.com>
Message-ID: <MknjxAXMUnB5b6ynfSk-PpxmFxpwrizrv5xu3xLcwJQ=.695bfb18-00c8-45e7-b2b3-8454aee525cd@github.com>

On Tue, 28 Jan 2020 12:39:20 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Test simulates a single mouse-released event.
>> Fix simply guards against the null case.
> 
> The pull request has been updated with 1 additional commit.

Fix looks good, suggested minor changes in test.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java line 484:

> 483: 
> 484: 
> 485:     @Test public void setRotateGraphicAndSeeValueIsReflectedInModel() {

Please remove the additional empty line from here.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java line 57:

> 56: import javafx.scene.input.KeyEvent;
> 57: import javafx.scene.input.MouseButton;
> 58: import javafx.scene.input.MouseEvent;

This import it not used, please remove.

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

Changes requested by arapte (Reviewer).

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

From ed at kennard.net  Tue Jan 28 12:54:21 2020
From: ed at kennard.net (Ed Kennard)
Date: Tue, 28 Jan 2020 12:54:21 +0000
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <b5d41168-5dae-0211-3c85-b1d07e52e9a8@katla.de.com>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <b5d41168-5dae-0211-3c85-b1d07e52e9a8@katla.de.com>
Message-ID: <B147754E-F614-449A-8C31-83D4624D5D46@kennard.net>

Hi Clemens,

Thanks very much for your message, it definitely helped me crystalize the root of the issue beyond my previous understanding, and also gave me some additional options on how to work around it :)

Ed






?On 27/01/2020, 15:45, "openjfx-dev on behalf of Clemens Kadura" <openjfx-dev-bounces at openjdk.java.net on behalf of clemens.kadura at katla.de.com> wrote:

    Hello Ed, hello all,
    
    It is also the first time that I become active in this mailing list, 
    although I'm already monitoring this list for half a year to get 
    familiar with your conventions.
    I am co-founder of a software and consulting company in Germany. We 
    develop a system (JACAMAR) that combines a serverless no-sql database 
    engine with a customizable user interface for do-it-yourself non-IT 
    expert end users. We started with an Eclipse based user interface, 
    switched in 2015 to a self developed UI and unfortunately found out only 
    very late that JavaFX did just the same with, I guess, a lot more 
    resources than we have. So we switched another time to JavaFX and are 
    about to launch our next version. By going this way, we have gained a 
    lot of insights in the field of user interfaces.
    
    To come to your question:
    Yes we also experienced issues of poor performance on scrolling virtual 
    tables with a lot of columns.
    The reason is in the nature of the VirtualFlow, which is the base of 
    TableView: It has a "virtual" direction and a "static" direction. By 
    default the vertical direction is the virtual one. That means the 
    vertical scrollbar works with a value p between 0 and 1. Depending on 
    how quick you scroll, only those lines are calculated and rendered, 
    which will become visible in the the viewport for a given p. This gives 
    good performance for tables with huge amount of lines.
    The problem is now the horizontal direction. Since this dimension is 
    static, TableRowSkin calculates and renders all TableCells of each 
    TableRow independent of its actual visibility in the view port. (see 
    TableRowSkinBase line 519ff.)
    This works well for TableRows with relatively low number of columns. And 
    knowing that, it is obvious, why the horizontal scrolling works so quick 
    in your application, because all cells are already prepared and just 
    need to be moved in X to become visible.
    There are 2 opportunities how to attack that issue:
    1.) If you don't have many lines, you could just change the vertical 
    property to false (see VirtualFlow line 745). We did it only in a test 
    case so far, so we don't have a lot of experience about that.
    2.) is a tradeoff between vertical and horizontal performance. A code 
    change would be required in TableRowSkinBase to restrict the actual 
    creation of TableCells for one line to only those cells that will become 
    visible for a particular scroll pulse. That way only 10-20 cells are 
    affected for each line and not 300 any longer. If you now scroll 
    horizontally, all new cells that become visible, must be additionally 
    calculated and rendered at that point in time. Unless you have a 50-inch 
    screen, there shouldn't be so many cells, so the loss of performance in 
    horizontal direction should be manageable.
    
    At the moment I am still very occupied with our system launch, but I 
    intend to participate soon in the community and give back a little bit 
    of what we received from using JavaFX for free in our applications up to 
    now.
    
    Greetings
    Clemens
    
    
    Am 25.01.2020 um 02:39 schrieb Ed Kennard:
    > Hi everyone,
    >
    > I?m new to the list, so by way of a short introduction, I?ve been working with JavaFX for the last 4 years developing a commodities trading risk management system from the ground up for a software company I co-founded in London.  All our code is written in Scala, the functional style of which is essential for the mathematical heavy lifting needed on the backend, but which also lends itself really well to UI programming and working with JavaFX.  I?m enthusiastic about JavaFX and would love to make a contribution to the project.
    >
    > At the center of our product is an extension of the TableView control that?s responsible for displaying all the output from our pivot reporting engine.  Depending on how the user configures the layout of their pivot reports, sometimes there are a legitimately large number of columns (300+).  When that happens, while the horizontal scrolling remains perfectly smooth, the vertical scrolling degrades to a somewhat juddery state and CPU usage spikes.
    >
    > I found an issue raised about this in 2019 on the old JFX GitHub repo here?
    > https://github.com/javafxports/openjdk-jfx/issues/409
    >
    > ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was ever submitted through the correct channels.  I can confirm that the test code included there by ?yososs? on 20th May 2019 perfectly illustrates the problem I?m experiencing.  The same person seems to have a fairly clear theory on what is causing the problem, too - see their follow-up comment on 12 Sept 2019.
    >
    > So, my questions to the list are:
    >
    >
    >    1.  Has anyone seen this issue raised anywhere else?
    >    2.  If yes, has anyone taken a look into it yet, and possibly even found a fix?
    >    3.  If no to both of the above, shall I submit it through the correct channels then have a crack at fixing myself?  Or is the issue likely to be a much deeper and far-reaching one than I?m anticipating?
    >
    > Many thanks
    >
    > Ed
    
    -- 
    Mit freundlichen Gr??en / Kind Regards
    
    Clemens Kadura
    Development Leader
    Co-founder
    
    *JACAMAR - agiles Datenmanagement im Team
    Weitere Informationen auf www.jacamar.de <https://www.jacamar.de> *
    
    
    
    Katla GmbH
    Immermannstr. 28
    39108 Magdeburg
    Tel: +49 391-50558353
    Fax: +49 391-50549735
    www.katla-gmbh.de
    
    Vertretungsberechtigter Gesch?ftsf?hrer: Dr. J?rg Czekalla
    Firmensitz: Magdeburg, Amtsgericht Stendal, HRB 19672
    Verantwortlich i.S.d.MDStV: Katla GmbH
    


From kevin.rushforth at oracle.com  Tue Jan 28 12:57:05 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 28 Jan 2020 04:57:05 -0800
Subject: Release roadmap for 2 already-merged TableView PRs
In-Reply-To: <8EAB2D1E-24EE-45DD-AEE3-0B07FBAAD328@kennard.net>
References: <8EAB2D1E-24EE-45DD-AEE3-0B07FBAAD328@kennard.net>
Message-ID: <d5d708a0-318f-9225-6844-ddd92e6fc99b@oracle.com>

JavaFX is unbundled (i.e., shipped separately from the JDK) since JDK 
11. Early access builds of JavaFX 14 have been available for quite some 
time [1]. The GA release is scheduled for Tuesday, March 10 [2].

Hope this helps.

-- Kevin

[1] https://gluonhq.com/products/javafx/#ea
[2] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024799.html

On 1/28/2020 3:49 AM, Ed Kennard wrote:
> Hi everyone,
>
> In Java 9 there were some issues introduced into the TableView code which significantly reduced the extensibility of the skinning.  These issues were blocking ones for us, in terms of migrating from 8 to 11, since we rely heavily on what was originally exposed, a good example being the resizeColumnToFitContent method, originally a protected method in TableViewSkin but moved to the static TableSkinUtils.
>
> I?ve found in the more recent history 2 separate commits by Samir Hadzic which I believe completely solve this for us:
>
> [1] 8207942: Add new protected VirtualFlow methods for subclassing (exposes reorderingProperty, fixed for Java 12)
> [2] 8207957: TableSkinUtils should not contain actual code implementation (exposes resizeColumnToFitContent again, fixed for Java 14)
>
> This is excellent news, thanks guys!
>
> It looks like the first opportunity to benefit from both changes is to wait for the upcoming Java 14 pre-release Feb 6th - is that on schedule, and please could I try that out?  Then am I correct in thinking it will be officially published at AdpotOpenJDK on March 17th?
>
> Thanks
>
> Ed
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8207942
> [2] https://bugs.openjdk.java.net/browse/JDK-8207957
>
>


From mp at jugs.org  Tue Jan 28 12:57:22 2020
From: mp at jugs.org (Michael Paus)
Date: Tue, 28 Jan 2020 13:57:22 +0100
Subject: Release roadmap for 2 already-merged TableView PRs
In-Reply-To: <8EAB2D1E-24EE-45DD-AEE3-0B07FBAAD328@kennard.net>
References: <8EAB2D1E-24EE-45DD-AEE3-0B07FBAAD328@kennard.net>
Message-ID: <89153c9b-d093-0c7f-81a6-df747aaffe8c@jugs.org>

Am 28.01.20 um 12:49 schrieb Ed Kennard:
> It looks like the first opportunity to benefit from both changes is to wait for the upcoming Java 14 pre-release Feb 6th - is that on schedule, and please could I try that out?  Then am I correct in thinking it will be officially published at AdpotOpenJDK on March 17th?

Why don't you try that out right now? The pre-releases for OpenJFX 14 
and 15 are available
here <https://gluonhq.com/products/javafx/> and also via Maven/Gradle.

As this is all JFX you do not even need anything beyond JDK 11 although 
the pre-releases
for that are also available here <http://jdk.java.net/14/> and 
<http://jdk.java.net/15/>.

Michael

From ed at kennard.net  Tue Jan 28 13:00:30 2020
From: ed at kennard.net (Ed Kennard)
Date: Tue, 28 Jan 2020 13:00:30 +0000
Subject: Release roadmap for 2 already-merged TableView PRs
In-Reply-To: <89153c9b-d093-0c7f-81a6-df747aaffe8c@jugs.org>
References: <8EAB2D1E-24EE-45DD-AEE3-0B07FBAAD328@kennard.net>
 <89153c9b-d093-0c7f-81a6-df747aaffe8c@jugs.org>
Message-ID: <67C9F297-37E0-4C9B-AB10-0CDBE43D16DD@kennard.net>

Michael, Kevin,

Great, will try out right away!

Thanks!

Ed



?On 28/01/2020, 13:58, "openjfx-dev on behalf of Michael Paus" <openjfx-dev-bounces at openjdk.java.net on behalf of mp at jugs.org> wrote:

    Am 28.01.20 um 12:49 schrieb Ed Kennard:
    > It looks like the first opportunity to benefit from both changes is to wait for the upcoming Java 14 pre-release Feb 6th - is that on schedule, and please could I try that out?  Then am I correct in thinking it will be officially published at AdpotOpenJDK on March 17th?
    
    Why don't you try that out right now? The pre-releases for OpenJFX 14 
    and 15 are available
    here <https://gluonhq.com/products/javafx/> and also via Maven/Gradle.
    
    As this is all JFX you do not even need anything beyond JDK 11 although 
    the pre-releases
    for that are also available here <http://jdk.java.net/14/> and 
    <http://jdk.java.net/15/>.
    
    Michael
    


From danny.a.gonzalez at gmail.com  Tue Jan 28 13:11:58 2020
From: danny.a.gonzalez at gmail.com (Danny Gonzalez)
Date: Tue, 28 Jan 2020 13:11:58 +0000
Subject: TableView slow vertical scrolling with 300+ columns
In-Reply-To: <B147754E-F614-449A-8C31-83D4624D5D46@kennard.net>
References: <952B9340-A64F-4B79-AD19-21E6886836A8@kennard.net>
 <b5d41168-5dae-0211-3c85-b1d07e52e9a8@katla.de.com>
 <B147754E-F614-449A-8C31-83D4624D5D46@kennard.net>
Message-ID: <8B04545D-4B10-4DB0-8D69-B4FCE5EB4F81@gmail.com>

Hi Clemens,

I am also experiencing the TableView slow vertical scrolling issue with large number of columns.

Did you manage to work around this issue with a code change in TableRowSkinBase as you mentioned in your bullet point 2 and if so could you share what you did?

Thanks

Danny

> On 28 Jan 2020, at 12:54, Ed Kennard <ed at kennard.net> wrote:
> 
> Hi Clemens,
> 
> Thanks very much for your message, it definitely helped me crystalize the root of the issue beyond my previous understanding, and also gave me some additional options on how to work around it :)
> 
> Ed
> 
> 
> 
> 
> 
> 
> ?On 27/01/2020, 15:45, "openjfx-dev on behalf of Clemens Kadura" <openjfx-dev-bounces at openjdk.java.net on behalf of clemens.kadura at katla.de.com> wrote:
> 
>    Hello Ed, hello all,
> 
>    It is also the first time that I become active in this mailing list, 
>    although I'm already monitoring this list for half a year to get 
>    familiar with your conventions.
>    I am co-founder of a software and consulting company in Germany. We 
>    develop a system (JACAMAR) that combines a serverless no-sql database 
>    engine with a customizable user interface for do-it-yourself non-IT 
>    expert end users. We started with an Eclipse based user interface, 
>    switched in 2015 to a self developed UI and unfortunately found out only 
>    very late that JavaFX did just the same with, I guess, a lot more 
>    resources than we have. So we switched another time to JavaFX and are 
>    about to launch our next version. By going this way, we have gained a 
>    lot of insights in the field of user interfaces.
> 
>    To come to your question:
>    Yes we also experienced issues of poor performance on scrolling virtual 
>    tables with a lot of columns.
>    The reason is in the nature of the VirtualFlow, which is the base of 
>    TableView: It has a "virtual" direction and a "static" direction. By 
>    default the vertical direction is the virtual one. That means the 
>    vertical scrollbar works with a value p between 0 and 1. Depending on 
>    how quick you scroll, only those lines are calculated and rendered, 
>    which will become visible in the the viewport for a given p. This gives 
>    good performance for tables with huge amount of lines.
>    The problem is now the horizontal direction. Since this dimension is 
>    static, TableRowSkin calculates and renders all TableCells of each 
>    TableRow independent of its actual visibility in the view port. (see 
>    TableRowSkinBase line 519ff.)
>    This works well for TableRows with relatively low number of columns. And 
>    knowing that, it is obvious, why the horizontal scrolling works so quick 
>    in your application, because all cells are already prepared and just 
>    need to be moved in X to become visible.
>    There are 2 opportunities how to attack that issue:
>    1.) If you don't have many lines, you could just change the vertical 
>    property to false (see VirtualFlow line 745). We did it only in a test 
>    case so far, so we don't have a lot of experience about that.
>    2.) is a tradeoff between vertical and horizontal performance. A code 
>    change would be required in TableRowSkinBase to restrict the actual 
>    creation of TableCells for one line to only those cells that will become 
>    visible for a particular scroll pulse. That way only 10-20 cells are 
>    affected for each line and not 300 any longer. If you now scroll 
>    horizontally, all new cells that become visible, must be additionally 
>    calculated and rendered at that point in time. Unless you have a 50-inch 
>    screen, there shouldn't be so many cells, so the loss of performance in 
>    horizontal direction should be manageable.
> 
>    At the moment I am still very occupied with our system launch, but I 
>    intend to participate soon in the community and give back a little bit 
>    of what we received from using JavaFX for free in our applications up to 
>    now.
> 
>    Greetings
>    Clemens
> 
> 
>    Am 25.01.2020 um 02:39 schrieb Ed Kennard:
>> Hi everyone,
>> 
>> I?m new to the list, so by way of a short introduction, I?ve been working with JavaFX for the last 4 years developing a commodities trading risk management system from the ground up for a software company I co-founded in London.  All our code is written in Scala, the functional style of which is essential for the mathematical heavy lifting needed on the backend, but which also lends itself really well to UI programming and working with JavaFX.  I?m enthusiastic about JavaFX and would love to make a contribution to the project.
>> 
>> At the center of our product is an extension of the TableView control that?s responsible for displaying all the output from our pivot reporting engine.  Depending on how the user configures the layout of their pivot reports, sometimes there are a legitimately large number of columns (300+).  When that happens, while the horizontal scrolling remains perfectly smooth, the vertical scrolling degrades to a somewhat juddery state and CPU usage spikes.
>> 
>> I found an issue raised about this in 2019 on the old JFX GitHub repo here?
>> https://github.com/javafxports/openjdk-jfx/issues/409
>> 
>> ?but I?m not sure whether, per Kevin?s suggestion at the bottom, it was ever submitted through the correct channels.  I can confirm that the test code included there by ?yososs? on 20th May 2019 perfectly illustrates the problem I?m experiencing.  The same person seems to have a fairly clear theory on what is causing the problem, too - see their follow-up comment on 12 Sept 2019.
>> 
>> So, my questions to the list are:
>> 
>> 
>>   1.  Has anyone seen this issue raised anywhere else?
>>   2.  If yes, has anyone taken a look into it yet, and possibly even found a fix?
>>   3.  If no to both of the above, shall I submit it through the correct channels then have a crack at fixing myself?  Or is the issue likely to be a much deeper and far-reaching one than I?m anticipating?
>> 
>> Many thanks
>> 
>> Ed
> 
>    -- 
>    Mit freundlichen Gr??en / Kind Regards
> 
>    Clemens Kadura
>    Development Leader
>    Co-founder
> 
>    *JACAMAR - agiles Datenmanagement im Team
>    Weitere Informationen auf www.jacamar.de <https://www.jacamar.de> *
> 
> 
> 
>    Katla GmbH
>    Immermannstr. 28
>    39108 Magdeburg
>    Tel: +49 391-50558353
>    Fax: +49 391-50549735
>    www.katla-gmbh.de
> 
>    Vertretungsberechtigter Gesch?ftsf?hrer: Dr. J?rg Czekalla
>    Firmensitz: Magdeburg, Amtsgericht Stendal, HRB 19672
>    Verantwortlich i.S.d.MDStV: Katla GmbH
> 
> 


From tsayao at openjdk.java.net  Tue Jan 28 17:48:05 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 28 Jan 2020 17:48:05 GMT
Subject: RFR: WIP: 8236651: Simplify and update glass gtk backend
In-Reply-To: <DQhahySKkmtA9PENyqEI6bpVxfJGjQHr9eEcOc0cHP8=.83ebd7d3-5f6f-4da7-a610-2678223446c4@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
 <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
 <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>
 <RTNlL4YgDTkU1J2hxEldvHgLAHAYTBNcAR4OdIGS9vI=.b219fd7a-1f0a-4bcb-9d31-8b2b8b18bc15@github.com>
 <DQhahySKkmtA9PENyqEI6bpVxfJGjQHr9eEcOc0cHP8=.83ebd7d3-5f6f-4da7-a610-2678223446c4@github.com>
Message-ID: <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com>

On Tue, 14 Jan 2020 11:30:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> I understand. Will do that when the code works 100%. I have submitted the PR to avoid duplicated efforts and let people test it (if anyone is willing).
> 
> Sizing and positioning completed and fairly tested.
> 
> Will look into mouse grabbing.

To anyone willing to test this, here is a binary test-release for linux:

https://github.com/tsayao/jfx/releases/tag/test-glass-gtk

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Tue Jan 28 18:03:49 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Tue, 28 Jan 2020 18:03:49 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>

> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
> 
> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
> Other than that, the logic used to do the actual snapshot is unchanged.
> 
> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

The pull request has been updated with 1 additional commit.

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

Added commits:
 - fce986e9: Only attempt tiling on exception

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/68/files
  - new: https://git.openjdk.java.net/jfx/pull/68/files/8966936f..fce986e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/68/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/68/webrev.03-04

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Tue Jan 28 18:03:50 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Tue, 28 Jan 2020 18:03:50 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <bsVolqKIkyt5o8YrZzx5AiV3rNguKXbjl7CDPuTVtLg=.0bc62a61-ff21-4b06-8fca-6f53f9bb5117@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
 <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
 <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>
 <3PvgtFCD9kQOb_g9yptrkQOh3wjACCLdiCGmXFM7NX4=.dc098e56-e182-4a1a-9453-ce4e44381fc8@github.com>
 <VNk6ODle4XSeACeINFqlGs1Mc_9y842ofxrB2GhACFU=.9735d3fb-369f-40ff-ba6f-fcae901fc75c@github.com>
 <bsVolqKIkyt5o8YrZzx5AiV3rNguKXbjl7CDPuTVtLg=.0bc62a61-ff21-4b06-8fca-6f53f9bb5117@github.com>
Message-ID: <yViEjB7_7f1uBUPnp7Mvw5yINoV0mZzXbtgIy9YCyko=.61e950a2-6b82-44c6-a008-ea49082f149e@github.com>

On Mon, 27 Jan 2020 18:45:17 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I thought of one possibility that might be worth looking into for a short term fix (i.e., could still go into openjfx14). Rather than relying on `PrismSettings.maxTextureSize` you could instead try to render the entire image (as is done today) in a try / catch block, and only fall back to tiling if there is an exception. That way there would be no concern over any possible performance regression, since the only time we would use tiling would be in the case where it fials today.
>> 
>> What do you think?
> 
> I have tested using a recipient WritableImage with an IntARGB pixel format (so that is aligned with that of the tile), that I construct by supplying a PixelBuffer, and as expected that performance of the tiled code is much more in line with that of the non-tiled version. One overhead left is the allocation of the extra buffer, but it is far less significant.
> The problem with this approach is that the "best" pixel format (as in similar to that of RRT) isn't the same depending on the rendering pipeline (e.g. d3d is intARGB while es2 is byteBGRA) so that would require adding a fair amount of code to determine the best possible scenario depending on all the constraints (keeping in mind the caller can also provide its own WritableImage...) that in turn would need thorough testing. 
> All in all, I agree the risk of regression is probably too great for this to make it into openjfx14 with so little time left.
> 
> Instead, I will prototype Kevin's proposal to only use tiling when it would fail with the current code and use  what I've learned here to propose a more robust fix targeted at openjfx15

I've made the change suggested by Kevin, and it works as expected. 
It is not very elegant but it does provide relief with regard to the core issue while avoiding risks of performance regressions.

Now with regard to a follow-up PR targeted at the next release, I assume a new issue needs first be filed into the JBS first; should I just file a new bug via https://bugreport.java.com/bugreport (I don't have access to https://bugs.openjdk.java.net)?

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

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

From rlichten at openjdk.java.net  Tue Jan 28 18:05:17 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 28 Jan 2020 18:05:17 GMT
Subject: [Rev 03] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <CztBUm9tKKdbgVxtQaTcimyHjU5cGWCyHsP4Wy9_MnU=.d473e15b-5830-459f-b361-f8f9693a1f80@github.com>

> Test simulates a single mouse-released event.
> Fix simply guards against the null case.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 39a61821: 8237372: NullPointerException in TabPaneSkin.stopDrag

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/89/files
  - new: https://git.openjdk.java.net/jfx/pull/89/files/a54a5306..39a61821

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

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

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

From arapte at openjdk.java.net  Tue Jan 28 18:05:17 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 28 Jan 2020 18:05:17 GMT
Subject: [Rev 03] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <CztBUm9tKKdbgVxtQaTcimyHjU5cGWCyHsP4Wy9_MnU=.d473e15b-5830-459f-b361-f8f9693a1f80@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <CztBUm9tKKdbgVxtQaTcimyHjU5cGWCyHsP4Wy9_MnU=.d473e15b-5830-459f-b361-f8f9693a1f80@github.com>
Message-ID: <3Ddp9nFzE6SHyz_2uLqgJH4sHuwztRq0_xMjCJqT1Bk=.5ddae7e0-3d4b-40f1-93d4-39d87e2ed846@github.com>

On Tue, 28 Jan 2020 18:04:54 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Test simulates a single mouse-released event.
>> Fix simply guards against the null case.
> 
> The pull request has been updated with 1 additional commit.

The fix looks good to me. 
Verified that the new test fails before and passes after fix and observed no test failures.

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

Marked as reviewed by arapte (Reviewer).

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

From rlichten at openjdk.java.net  Tue Jan 28 18:05:19 2020
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Tue, 28 Jan 2020 18:05:19 GMT
Subject: [Rev 02] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <MknjxAXMUnB5b6ynfSk-PpxmFxpwrizrv5xu3xLcwJQ=.695bfb18-00c8-45e7-b2b3-8454aee525cd@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <YqjyVCvXrww4xkNlAd7sZR7PX100_P5c-C1Z6LVbxQk=.28df1da6-bd49-4a22-9414-f371af1119bc@github.com>
 <MknjxAXMUnB5b6ynfSk-PpxmFxpwrizrv5xu3xLcwJQ=.695bfb18-00c8-45e7-b2b3-8454aee525cd@github.com>
Message-ID: <B6BKU2vjPGCu5kQXYG3YqRcMz9vTtsv1zeTf8PpqzNQ=.e47fdd6f-7215-443f-b962-ad8ee7862bd9@github.com>

On Tue, 28 Jan 2020 12:38:32 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java line 57:
> 
>> 56: import javafx.scene.input.KeyEvent;
>> 57: import javafx.scene.input.MouseButton;
>> 58: import javafx.scene.input.MouseEvent;
> 
> This import it not used, please remove.

Removed import and extra empty line.

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

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

From kcr at openjdk.java.net  Tue Jan 28 18:15:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 28 Jan 2020 18:15:55 GMT
Subject: [Rev 03] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <3Ddp9nFzE6SHyz_2uLqgJH4sHuwztRq0_xMjCJqT1Bk=.5ddae7e0-3d4b-40f1-93d4-39d87e2ed846@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
 <CztBUm9tKKdbgVxtQaTcimyHjU5cGWCyHsP4Wy9_MnU=.d473e15b-5830-459f-b361-f8f9693a1f80@github.com>
 <3Ddp9nFzE6SHyz_2uLqgJH4sHuwztRq0_xMjCJqT1Bk=.5ddae7e0-3d4b-40f1-93d4-39d87e2ed846@github.com>
Message-ID: <jDTQ9xL0r06spwt7WyFHdTPI21UcYdI2YySzwAHstoc=.62aa14e9-3ba1-4eb9-be73-f2be6f0314dc@github.com>

On Tue, 28 Jan 2020 16:04:59 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix looks good to me. 
> Verified that the new test fails before and passes after fix and observed no test failures.

I don't have any additional comment, so this is good to go with 1 reviewer. @arapte can sponsor this.

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

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

From kcr at openjdk.java.net  Tue Jan 28 18:26:30 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 28 Jan 2020 18:26:30 GMT
Subject: [Rev 03] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <yViEjB7_7f1uBUPnp7Mvw5yINoV0mZzXbtgIy9YCyko=.61e950a2-6b82-44c6-a008-ea49082f149e@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <rU0xBm0_Ytjsf5Vyyetpl75qCco15vp55eUMOYWhrnw=.3a37bcfc-016f-4f66-9979-12e81ef28292@github.com>
 <d95V5EXUNwn0QkEsdYTsm8dEeArK-XvCZGLNTfFAh6A=.abbdf70a-ce6a-442d-838a-ae0ccb82b794@github.com>
 <WXGr55khZQqNvYXuDcVGuB_2rnsmRRCq6luDhr_x870=.4493e13f-c8e3-417c-9971-f7746dd83285@github.com>
 <HYZEo8mv99liSjaQGva75QtQ0XsJc9CRNQUnMFkhIYI=.0c6b5344-4932-44e0-a2dd-7f7fcc4fe778@github.com>
 <zP90cYZlMjyljq9bd3mg5bvfGlU6iTJUkByyBIpje90=.59c66b4a-7c7d-4305-9492-6af8debbc5fa@github.com>
 <X-zyEooD6igCJccdUaHD8sOcSESvRfJFGG8zm0lycAM=.25d7ee99-7c95-4404-87cd-97bb3d173bfb@github.com>
 <vLzV6hM9dFF2qqKCM9AYDbsfqVHSEvoZ8Lh0uDgtVGE=.be3dd28d-955e-4f17-a4cc-f6501c7f9650@github.com>
 <upPBUXGVSnqVPhDUADiaAv7csp01w5Xy5CnTqWD_IP4=.da09b01e-20b0-49f6-9b60-7ae2905008b3@github.com>
 <eX8l-hyoRSs2C1CL62MiwKlCk5dhalnXm3UjLGXRROQ=.3a0c4cbf-20a0-44a6-a8c1-7c2ca1df3e85@github.com>
 <xpIFk2dlQKwUuhCRtpc7S-rerHo2VLEWJWX
 uUJb9ssA=.cb98b555-2a3e-4a55-a19d-2a1ab2058b42@github.com>
 <cwdjW3XwDEk5nHhYi_Mox5_9o49A6oOFNZ8TDXLVs8U=.46da4a90-38ac-46b2-bf0f-c0b204b33cb3@github.com>
 <qnw93UBRtCWZZlYcqgfZGNIwnLVgySOSn54FOKzHm2k=.dc58ac31-f056-4046-b999-9c272445631c@github.com>
 <BspKw3IeXLdwVHREU95hZohqQ-d24I7ewQWdvRBeMP8=.6d672e13-1a6b-4846-a425-8eb1f9ec9266@github.com>
 <WV01atbO6EyXEWaOS7aYrsaCzpWXA1RLLRAxQcHj2CQ=.c0463e3a-29cd-42b1-99ec-c971c9a07af7@github.com>
 <3PvgtFCD9kQOb_g9yptrkQOh3wjACCLdiCGmXFM7NX4=.dc098e56-e182-4a1a-9453-ce4e44381fc8@github.com>
 <VNk6ODle4XSeACeINFqlGs1Mc_9y842ofxrB2GhACFU=.9735d3fb-369f-40ff-ba6f-fcae901fc75c@github.com>
 <bsVolqKIkyt5o8YrZzx5AiV3rNguKXbjl7CDPuTVtLg=.0bc62a61-ff21-4b06-8fca-6f53f9bb5117@github.com>
 <yViEjB7_7f1uBUPnp7Mvw5yINoV0mZzXbtgIy9YCyko=.61e950a2-6b82-44c6-a008-ea49082f149e@github.com>
Message-ID: <7UMT-xXoryCw05E8PsR2MBRkmnbZ6DODxagpfNyZjEA=.4972f89e-498e-4247-a64f-31deb465d9a6@github.com>

On Tue, 28 Jan 2020 16:00:35 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> I have tested using a recipient WritableImage with an IntARGB pixel format (so that is aligned with that of the tile), that I construct by supplying a PixelBuffer, and as expected that performance of the tiled code is much more in line with that of the non-tiled version. One overhead left is the allocation of the extra buffer, but it is far less significant.
>> The problem with this approach is that the "best" pixel format (as in similar to that of RRT) isn't the same depending on the rendering pipeline (e.g. d3d is intARGB while es2 is byteBGRA) so that would require adding a fair amount of code to determine the best possible scenario depending on all the constraints (keeping in mind the caller can also provide its own WritableImage...) that in turn would need thorough testing. 
>> All in all, I agree the risk of regression is probably too great for this to make it into openjfx14 with so little time left.
>> 
>> Instead, I will prototype Kevin's proposal to only use tiling when it would fail with the current code and use  what I've learned here to propose a more robust fix targeted at openjfx15
> 
> I've made the change suggested by Kevin, and it works as expected. 
> It is not very elegant but it does provide relief with regard to the core issue while avoiding risks of performance regressions.
> 
> Now with regard to a follow-up PR targeted at the next release, I assume a new issue needs first be filed into the JBS first; should I just file a new bug via https://bugreport.java.com/bugreport (I don't have access to https://bugs.openjdk.java.net)?

The change looks like what I would expect, so I'll finish my review in the next day or so. @arapte will need to re-review it as well.

Yes, we will need a new JBS bug ID for the follow-on.

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

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

From kcr at openjdk.java.net  Tue Jan 28 18:29:51 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 28 Jan 2020 18:29:51 GMT
Subject: RFR: 8236839: System menubar removed when other menubars are
 created or modified
In-Reply-To: <cP9_OUZg9rBR6W0b7rE7UwQaDP4efCHMw8xyHpHhzYU=.5d48d378-84be-4229-95db-a571616199f6@github.com>
References: <bE6bjH8iA9f5DKqF2VRBu1vIbNqAFaOXRb1fqdSN5dk=.d84dd6ae-1776-4326-88b8-cb8156980159@github.com>
 <qbwB15jqT5v9i6b7ZA52YTN9j0WXPbRJUdP0IZCR0qw=.24dd98b1-2ee5-4707-975b-4b194a137f68@github.com>
 <cP9_OUZg9rBR6W0b7rE7UwQaDP4efCHMw8xyHpHhzYU=.5d48d378-84be-4229-95db-a571616199f6@github.com>
Message-ID: <OyBEcA9iQVFRUTa-jpB3LXJvob3rgj97XFehm8u8cE4=.17449506-60c8-4bf2-b90c-f7cdf4a3526b@github.com>

On Tue, 14 Jan 2020 20:30:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I just realised that I did not make the commit with the same email address that I used on the OCA (but both addresses are linked to my GitHub account).
>> Will this be a problem?
>> Should I redo the commit with the correct email address and do a force push to my branch?
> 
> No, it's not a problem. The commit email address doesn't matter as long as your OCA can be validated.

@aghaisas can be the second reviewer.

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

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

From nlisker at openjdk.java.net  Tue Jan 28 19:30:51 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 28 Jan 2020 19:30:51 GMT
Subject: RFR: 8237975: Non-embedded Animations do not play backwards after
 being paused
Message-ID: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>

[8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.

This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.

A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.

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

Commits:
 - 54ee486d: Remove unused import
 - 355d04f0: Added concept test
 - 60a57f9a: Finalize fix
 - d8de2ea5: cont.
 - 4d34544d: Initial commit

Changes: https://git.openjdk.java.net/jfx/pull/98/files
 Webrev: https://webrevs.openjdk.java.net/jfx/98/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8237975
  Stats: 26 lines in 5 files changed: 17 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/98.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/98/head:pull/98

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

From nlisker at openjdk.java.net  Tue Jan 28 19:31:03 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 28 Jan 2020 19:31:03 GMT
Subject: RFR: 8237975: Non-embedded Animations do not play backwards after
 being paused
In-Reply-To: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
Message-ID: <o6Nd5lt79Xqmite84Z2xjGcxRN1iySxg0YKLoRvp9NE=.1b0e7b73-3e37-4ae1-a706-000d1528de6e@github.com>

On Tue, 28 Jan 2020 19:19:57 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
> 
> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
> 
> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.

> ?? Welcome back nlisker! A progress list of the required criteria for merging this PR into `master` will be added to the body of your pull request (refresh this page to view it).

Maybe the Skara team would like to change the message to apply to the correct branch - `jfx14` and not `master`.

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

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

From kcr at openjdk.java.net  Tue Jan 28 19:58:18 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 28 Jan 2020 19:58:18 GMT
Subject: RFR: 8237975: Non-embedded Animations do not play backwards after
 being paused
In-Reply-To: <o6Nd5lt79Xqmite84Z2xjGcxRN1iySxg0YKLoRvp9NE=.1b0e7b73-3e37-4ae1-a706-000d1528de6e@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
 <o6Nd5lt79Xqmite84Z2xjGcxRN1iySxg0YKLoRvp9NE=.1b0e7b73-3e37-4ae1-a706-000d1528de6e@github.com>
Message-ID: <JH83-gZE4rE660ukU9IykxABd1FBPd4mgr3HCzY196Y=.c948921e-ac61-4113-932c-08fe53408506@github.com>

On Tue, 28 Jan 2020 19:22:53 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
>> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
>> 
>> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
>> 
>> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.
> 
>> ?? Welcome back nlisker! A progress list of the required criteria for merging this PR into `master` will be added to the body of your pull request (refresh this page to view it).
> 
> Maybe the Skara team would like to change the message to apply to the correct branch - `jfx14` and not `master`.

> Maybe the Skara team would like to change the message to apply to the correct branch - `jfx14` and not `master`.

I filed https://bugs.openjdk.java.net/browse/SKARA-249 to track this.

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

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

From jvos at openjdk.java.net  Tue Jan 28 20:21:41 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 28 Jan 2020 20:21:41 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
Message-ID: <0BH858IWJsLOOpoGrTx6hwiuNYGgwwUGF2qjiY0qflU=.d28b7be3-d210-44d2-92b4-4c9e7b82276a@github.com>

On Wed, 11 Dec 2019 15:41:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.
> 
> The change is,
> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.
> 
> Verification:
> Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
> 2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
> Expected Behavior: 
> a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
> b. No OOM should occur with this change or without this change.

I did some more tests, and it looks good. 
There might be a merge conflict, as the date for JPiscesRenderer was modified.

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

Marked as reviewed by jvos (Reviewer).

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

From jvos at openjdk.java.net  Tue Jan 28 21:03:10 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 28 Jan 2020 21:03:10 GMT
Subject: RFR: 8237944: webview native cl "-m32" unknown option for windows
 32-bit build
In-Reply-To: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
Message-ID: <Px5PwGfy6HoF8ZjutWouSmBzJT0gS8kxKZBrNObHltE=.4e2df139-c230-4c6f-a0c8-89f4db12aa4c@github.com>

On Tue, 28 Jan 2020 09:50:27 GMT, Guru Hb <ghb at openjdk.org> wrote:

> cl : Command line warning D9002 : ignoring unknown option '-m32'
> 
> post fix for "https://trac.webkit.org/changeset/242724/webkit" makes use of cross compiling 32 bit JSC in a 64 bit and its holds good only for Linux. 
> '-m32' flag is gcc specifc and on windows cl.exe (visual studio) doesn't recognize this flag.

the -m32 option seems to be ignored by the compiler:
cl : Command line warning D9002 : ignoring unknown option '-m32'

However, I agree it is better to conditionally remove it.

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

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

From kcr at openjdk.java.net  Tue Jan 28 21:53:38 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 28 Jan 2020 21:53:38 GMT
Subject: RFR: 8237944: webview native cl "-m32" unknown option for windows
 32-bit build
In-Reply-To: <Px5PwGfy6HoF8ZjutWouSmBzJT0gS8kxKZBrNObHltE=.4e2df139-c230-4c6f-a0c8-89f4db12aa4c@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
 <Px5PwGfy6HoF8ZjutWouSmBzJT0gS8kxKZBrNObHltE=.4e2df139-c230-4c6f-a0c8-89f4db12aa4c@github.com>
Message-ID: <upSgo7aL6wlofpkiftVkIicJSGkvPtcSzNk_vBrz2tM=.498c9f76-ac69-4873-ad07-7285687921ad@github.com>

On Tue, 28 Jan 2020 21:03:01 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> cl : Command line warning D9002 : ignoring unknown option '-m32'
>> 
>> post fix for "https://trac.webkit.org/changeset/242724/webkit" makes use of cross compiling 32 bit JSC in a 64 bit and its holds good only for Linux. 
>> '-m32' flag is gcc specifc and on windows cl.exe (visual studio) doesn't recognize this flag.
> 
> the -m32 option seems to be ignored by the compiler:
> cl : Command line warning D9002 : ignoring unknown option '-m32'
> 
> However, I agree it is better to conditionally remove it.

Agreed. It's a good cleanup fix. I'll do a quick test and then review it.

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

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

From kcr at openjdk.java.net  Wed Jan 29 00:01:38 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 00:01:38 GMT
Subject: RFR: 8237944: webview native cl "-m32" unknown option for windows
 32-bit build
In-Reply-To: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
Message-ID: <1mRc_16FbhojBz5iEiNwIX87PicxFz5_61_ojPH3uFE=.c7ae1ca9-6127-4507-a2d7-4f6de97b1707@github.com>

On Tue, 28 Jan 2020 09:50:27 GMT, Guru Hb <ghb at openjdk.org> wrote:

> cl : Command line warning D9002 : ignoring unknown option '-m32'
> 
> post fix for "https://trac.webkit.org/changeset/242724/webkit" makes use of cross compiling 32 bit JSC in a 64 bit and its holds good only for Linux. 
> '-m32' flag is gcc specifc and on windows cl.exe (visual studio) doesn't recognize this flag.

All my testing looks good. I added one comment for you to take a look at.

modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm line 2300:

> 2299: 
> 2300:     if (architecture() eq "x86_64" && shouldBuild32Bit() && (isJava() && !isCygwin())) {
> 2301:         # CMAKE_LIBRARY_ARCHITECTURE is needed to get the right .pc

This will work, since all we build is the Java platform, but I'm not sure that the `isJava()` test is quite right. It suggests that the logic should be skipped for other platforms (i.e., that the entire test and body of the if block is Java platform-specific), which it isn't. I think this should be:

    ... && !(isJava() && isCygwin())

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



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

From arapte at openjdk.java.net  Wed Jan 29 05:00:05 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 29 Jan 2020 05:00:05 GMT
Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method
 from PiscesRenderer and AbstractSurface
In-Reply-To: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
Message-ID: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com>

> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.
> 
> The change is,
> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.
> 
> Verification:
> Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
> 2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
> Expected Behavior: 
> a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
> b. No OOM should occur with this change or without this change.

The pull request has been updated with a new target base due to a merge or a rebase.

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

Commits:
 - 0591e41f: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface

Changes: https://git.openjdk.java.net/jfx/pull/66/files
 Webrev: https://webrevs.openjdk.java.net/jfx/66/webrev.01
  Stats: 110 lines in 5 files changed: 40 ins; 52 del; 18 mod
  Patch: https://git.openjdk.java.net/jfx/pull/66.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/66/head:pull/66

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

From arapte at openjdk.java.net  Wed Jan 29 06:26:13 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 29 Jan 2020 06:26:13 GMT
Subject: [Integrated] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <eb76f941-4098-4940-b7e2-93e10bffb314@openjdk.org>

Changeset: 5a0e71b8
Author:    Robert Lichtenberger <rlichten at openjdk.org>
Committer: Ambarish Rapte <arapte at openjdk.org>
Date:      2020-01-29 06:25:21 +0000
URL:       https://git.openjdk.java.net/jfx/commit/5a0e71b8

8237372: NullPointerException in TabPaneSkin.stopDrag

Reviewed-by: arapte

! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java
! modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java

From ghb at openjdk.java.net  Wed Jan 29 11:12:13 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Wed, 29 Jan 2020 11:12:13 GMT
Subject: [Rev 01] RFR: 8237944: webview native cl "-m32" unknown option
 for windows 32-bit build
In-Reply-To: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
Message-ID: <YZIvXzwJjZF7SuD0OWhkl3X48VkSl7C7-EZ1Y-_lx0g=.ca2a6438-a932-4a19-ba07-0d29b664db6a@github.com>

> cl : Command line warning D9002 : ignoring unknown option '-m32'
> 
> post fix for "https://trac.webkit.org/changeset/242724/webkit" makes use of cross compiling 32 bit JSC in a 64 bit and its holds good only for Linux. 
> '-m32' flag is gcc specifc and on windows cl.exe (visual studio) doesn't recognize this flag.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - bbb6201b: inforporated review comments

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/97/files
  - new: https://git.openjdk.java.net/jfx/pull/97/files/0d9ca899..bbb6201b

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

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

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

From ghb at openjdk.java.net  Wed Jan 29 11:12:27 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Wed, 29 Jan 2020 11:12:27 GMT
Subject: [Rev 01] RFR: 8237944: webview native cl "-m32" unknown option
 for windows 32-bit build
In-Reply-To: <1mRc_16FbhojBz5iEiNwIX87PicxFz5_61_ojPH3uFE=.c7ae1ca9-6127-4507-a2d7-4f6de97b1707@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
 <1mRc_16FbhojBz5iEiNwIX87PicxFz5_61_ojPH3uFE=.c7ae1ca9-6127-4507-a2d7-4f6de97b1707@github.com>
Message-ID: <HJmw472MEWdQiIZ6jLRymkI9enqL2O-KZhrTKxHIZ8E=.c20777ef-b7aa-44f3-acf8-a969e427e229@github.com>

On Tue, 28 Jan 2020 23:42:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm line 2300:
> 
>> 2299: 
>> 2300:     if (architecture() eq "x86_64" && shouldBuild32Bit() && (isJava() && !isCygwin())) {
>> 2301:         # CMAKE_LIBRARY_ARCHITECTURE is needed to get the right .pc
> 
> This will work, since all we build is the Java platform, but I'm not sure that the `isJava()` test is quite right. It suggests that the logic should be skipped for other platforms (i.e., that the entire test and body of the if block is Java platform-specific), which it isn't. I think this should be:
> 
>     ... && !(isJava() && isCygwin())

You are correct, Current fix will block for all the other platform, Done the changes as suggested.

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

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

From ghb at openjdk.java.net  Wed Jan 29 11:34:04 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Wed, 29 Jan 2020 11:34:04 GMT
Subject: RFR: 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled
 flag in DumpRenderTree
Message-ID: <x-64yZsh7HwBDQAmrHnyGTu9DGMxx93qYfada1Evtv0=.1cc47b51-bd1b-4b4b-aa60-27a5aa4436a9@github.com>

AnimationBase and WebAnimation are two different abstract animation API provider. By default KeyFrameAnimation (which is a sub class of AnimationBase) is used for controlling and rendering the CSS animation. 
Enabling "WebAnimationsCSSIntegrationEnabled" overrides the CSSAnimationController to use WebAnimation which is not used in our port (JAVA) and we are using KeyFrameAnimation.

Test : need to run DRT test harness with this fix for "LayoutTests/animations".

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

Commits:
 - c473f6e2: 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree

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

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

From tsayao at openjdk.java.net  Wed Jan 29 12:05:20 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 29 Jan 2020 12:05:20 GMT
Subject: [Rev 15] RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <8mbLmg15Sw7qPdwfrXLzLIXTkF9WpDTgb-yTUikgnis=.6b4adbff-7134-4ffe-a43c-07097650ec51@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to understand and maintain;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing (for gtk3);
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code;
> - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491;
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> ![image](https://user-images.githubusercontent.com/30704286/73351421-b5f7b600-426d-11ea-9510-ee3b5bc81de7.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 0c982d60: Fix Initial Size

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/694641f6..0c982d60

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.15
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.14-15

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

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

From tsayao at openjdk.java.net  Wed Jan 29 12:16:59 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 29 Jan 2020 12:16:59 GMT
Subject: RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
 <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com>
 <EgIbbSCS2DvK4NoysEtaSH9sNfCnfJdoUxwlXWNMLlk=.54342d68-7bf4-4eb4-a2dd-ff279361392b@github.com>
 <YaJautwQTgaNviG5oL-89vI8zF5JUn-iqx7eA0yp2YM=.181d3764-b925-4017-9c6c-3c83344ca6b0@github.com>
 <RTNlL4YgDTkU1J2hxEldvHgLAHAYTBNcAR4OdIGS9vI=.b219fd7a-1f0a-4bcb-9d31-8b2b8b18bc15@github.com>
 <DQhahySKkmtA9PENyqEI6bpVxfJGjQHr9eEcOc0cHP8=.83ebd7d3-5f6f-4da7-a610-2678223446c4@github.com>
 <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com>
Message-ID: <odnwFmYa__6lMJqrGw5AlMUTcDNj7t-QAzhTP1YJ31E=.396e9cad-d54e-491f-a752-1268130109ef@github.com>

On Tue, 28 Jan 2020 16:59:27 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Sizing and positioning completed and fairly tested.
>> 
>> Will look into mouse grabbing.
> 
> To anyone willing to test this, here is a binary test-release for linux:
> 
> https://github.com/tsayao/jfx/releases/tag/test-glass-gtk

It's ready for an initial look.

If anyone has issues with Linux, I will fix it.

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

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

From kevin.rushforth at oracle.com  Wed Jan 29 12:24:08 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 29 Jan 2020 04:24:08 -0800
Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying
 filename to script engine, not supplying event object as argument to script
In-Reply-To: <174bd8e2-1d02-1b14-1164-63e978028585@wu.ac.at>
References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at>
 <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at>
 <d348944d-a27a-b052-467f-711785de2fa1@jugs.org>
 <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com>
 <ff6c8070-a9fa-32b1-a864-94d83b4b351f@wu.ac.at>
 <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com>
 <fb110562-302a-ad4e-a92b-855ac693bd92@wu.ac.at>
 <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at>
 <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com>
 <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at>
 <f9997bba-1572-fd13-66fd-230c08923863@wu.ac.at>
 <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at>
 <ca3b0a19-3ab4-663c-e7cc-cab3808e5d9d@wu.ac.at>
 <AM0PR07MB63726854D6A60E0A24ED9BD2E80C0@AM0PR07MB6372.eurprd07.prod.outlook.com>
 <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at>
 <c6cf8770-eeb0-48cb-c5fb-acf55e716dbd@oracle.com>
 <174bd8e2-1d02-1b14-1164-63e978028585@wu.ac.at>
Message-ID: <6ed49ec2-223c-200b-91aa-b85b8e07431a@oracle.com>

Hi Rony,

The RFE you filed is now available here:

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

-- Kevin


On 1/25/2020 6:32 AM, Rony G. Flatscher wrote:
> Hi Kevin,
>
> On 24.01.2020 16:50, Kevin Rushforth wrote:
>> This bug was transferred to the JDK project on 28-Nov-2019. I don't know why you didn't get an
>> email at that time, but I will inquire of the team who processes incoming bugs.
>>
>> Also, I'll keep an eye out for the RFE you filed today, and let you know when it is transferred in
>> case there is still a problem with the notification.
> thank you very much!
>
> ---rony
>
>
>> On 1/22/2020 9:52 AM, Rony G. Flatscher wrote:
>>> Hi Anthony,
>>>
>>> On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
>>>> Your issue has been converted into a JDK issue, with your testcase attached [1].
>>> Thank you *very* much for this information!
>>>
>>>> Normally you should?ve received an e-mail at the time of this conversion,
>>> Just searched all my e-mail folders and could not find it (looking for "FXMLLoader" in the subject
>>> of e-mails as the bug title contains that word) but could not find a matching e-mail for whatever
>>> reasons.
>>>
>>>> but you can check this yourself by using the internal review ID as in [2]. If you?d like to
>>>> contribute a fix, see [3].
>>>>
>>>>   
>>>> Kind regards, Anthony
>>>>
>>>>   
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234959
>>>> <https://bugs.openjdk.java.net/browse/JDK-8234959>
>>>>
>>>> [2] https://bugs.openjdk.java.net/browse/JI-9062887
>>>> <https://bugs.openjdk.java.net/browse/JI-9062887>
>>>>
>>>> [3] https://github.com/openjdk/jfx <https://github.com/openjdk/jfx>
>>>>
>>> Thank you also for these links (and I learned something new on how to check for it using the
>>> internal review id with your [2], thanks a lot for this hint as well)!
>>>
>>> Will go back and study all the necessary procedures (forgot a lot since reading them the last time)
>>> and will try to contribute the fix in the proper way but it may take me a little while (currently
>>> quite busy around here).
>>>
>>> ---
>>>
>>> Maybe one more question: there would be an optimization possible by compiling scripts for script
>>> engines that have the javax.script.Compilable interface implemented and use the compiled version to
>>> execute/evaluate the scripts (may be helpful for event handler code e.g. for onMouseMove event
>>> handlers). Can the fix include such an optimization or should there be a separate discussion/RFE for
>>> it beforehand? (Adding this would be trivial in the context of the fix, however the bug description
>>> would not hint at such an optimization.)
>>>
>>> ---rony


From kcr at openjdk.java.net  Wed Jan 29 12:58:00 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 12:58:00 GMT
Subject: [Rev 01] RFR: 8237944: webview native cl "-m32" unknown option
 for windows 32-bit build
In-Reply-To: <YZIvXzwJjZF7SuD0OWhkl3X48VkSl7C7-EZ1Y-_lx0g=.ca2a6438-a932-4a19-ba07-0d29b664db6a@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
 <YZIvXzwJjZF7SuD0OWhkl3X48VkSl7C7-EZ1Y-_lx0g=.ca2a6438-a932-4a19-ba07-0d29b664db6a@github.com>
Message-ID: <65dwSJk845x28C1G22a0UOWOS0Q6aukdc2YC4xQak9M=.1be4ca90-1abc-42d5-a42d-c60eec747072@github.com>

On Wed, 29 Jan 2020 12:58:00 GMT, Guru Hb <ghb at openjdk.org> wrote:

>> cl : Command line warning D9002 : ignoring unknown option '-m32'
>> 
>> post fix for "https://trac.webkit.org/changeset/242724/webkit" makes use of cross compiling 32 bit JSC in a 64 bit and its holds good only for Linux. 
>> '-m32' flag is gcc specifc and on windows cl.exe (visual studio) doesn't recognize this flag.
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.java.net  Wed Jan 29 13:03:16 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 13:03:16 GMT
Subject: [Integrated] RFR: 8236912: Preventing NPE when clicking WebView
 with forward/back mouse buttons
In-Reply-To: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
References: <q6pSRNmyAS60L6zVZKxKnGtYVRhsIyfXztOy5G0bRzA=.40f4888c-e070-4edb-8102-02872912ad0d@github.com>
Message-ID: <2a31d43f-8885-4ebc-82b6-d2851d90c292@openjdk.org>

Changeset: aa6f3a4e
Author:    Robert Lichtenberger <rlichten at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-27 13:43:47 +0000
URL:       https://git.openjdk.java.net/jfx/commit/aa6f3a4e

8236912: NullPointerException when clicking in WebView with Button 4 or Button 5

Reviewed-by: ghb, kcr

! modules/javafx.web/src/main/java/javafx/scene/web/WebView.java
! modules/javafx.web/src/test/java/test/javafx/scene/web/WebViewTest.java

From arapte at openjdk.java.net  Wed Jan 29 13:03:20 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 29 Jan 2020 13:03:20 GMT
Subject: [Integrated] RFR: 8232824: Removing TabPane with strong
 referenced content causes memory leak from weak one
In-Reply-To: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
References: <QxDNIvNsWxdTLooVR7GM84DzDEZXv197orhluMGr4Mg=.848fe972-2e98-4668-ae42-a54a5dca7641@github.com>
Message-ID: <70f54b91-7a6e-4e9e-9a18-1320a9db054d@openjdk.org>

Changeset: 79fc0d0d
Author:    Ambarish Rapte <arapte at openjdk.org>
Date:      2020-01-28 12:35:52 +0000
URL:       https://git.openjdk.java.net/jfx/commit/79fc0d0d

8232824: Removing TabPane with strong referenced content causes memory leak from weak one

Reviewed-by: kcr, aghaisas

! modules/javafx.graphics/src/main/java/javafx/scene/Parent.java
+ tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java
+ tests/system/src/test/java/test/javafx/scene/shape/ShapeViewOrderLeakTest.java

From arapte at openjdk.java.net  Wed Jan 29 13:03:25 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 29 Jan 2020 13:03:25 GMT
Subject: [Integrated] RFR: 8237372: NullPointerException in
 TabPaneSkin.stopDrag
In-Reply-To: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
References: <HEqbPt-RGZGmbkGX4SX09bgnK-ZkeNExz6AWYVsoeG8=.d963cd18-83b8-4b34-8efe-d5536e5ee511@github.com>
Message-ID: <8fce7ce6-875a-4150-ac3f-015a8d9d3f5e@openjdk.org>

Changeset: 5a0e71b8
Author:    Robert Lichtenberger <rlichten at openjdk.org>
Committer: Ambarish Rapte <arapte at openjdk.org>
Date:      2020-01-29 06:25:21 +0000
URL:       https://git.openjdk.java.net/jfx/commit/5a0e71b8

8237372: NullPointerException in TabPaneSkin.stopDrag

Reviewed-by: arapte

! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java
! modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java

From arapte at openjdk.java.net  Wed Jan 29 13:59:33 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 29 Jan 2020 13:59:33 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
Message-ID: <ASRVEEGW1h3vnFBP4AfJCcbdCbTZ4RCFr8KGS4d7gNg=.828697a4-0a2d-4de5-b680-73169328708c@github.com>

On Wed, 29 Jan 2020 13:59:32 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 1 additional commit.

I need to re-review the updated PR.

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

Changes requested by arapte (Reviewer).

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

From ghb at openjdk.java.net  Wed Jan 29 15:37:01 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Wed, 29 Jan 2020 15:37:01 GMT
Subject: [Rev 01] RFR: 8237944: webview native cl "-m32" unknown option
 for windows 32-bit build
In-Reply-To: <65dwSJk845x28C1G22a0UOWOS0Q6aukdc2YC4xQak9M=.1be4ca90-1abc-42d5-a42d-c60eec747072@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
 <YZIvXzwJjZF7SuD0OWhkl3X48VkSl7C7-EZ1Y-_lx0g=.ca2a6438-a932-4a19-ba07-0d29b664db6a@github.com>
 <65dwSJk845x28C1G22a0UOWOS0Q6aukdc2YC4xQak9M=.1be4ca90-1abc-42d5-a42d-c60eec747072@github.com>
Message-ID: <0qs2P4MB966ffrrY4YPBACMDPo0wT4P2SxAwdVW3roM=.801906c9-d00a-4511-80a9-2592470495ff@github.com>

On Wed, 29 Jan 2020 12:57:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Marked as reviewed by kcr (Lead).

> the -m32 option seems to be ignored by the compiler:
> cl : Command line warning D9002 : ignoring unknown option '-m32'
> 
> However, I agree it is better to conditionally remove it.
"-m32" required for compiling other ports of webkit (WebkitGTK, WPE) and for our platform I haven't tested this feature (i.e cross compiling on a 64 bit Linux).

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

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

From kcr at openjdk.java.net  Wed Jan 29 15:43:10 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 15:43:10 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <ASRVEEGW1h3vnFBP4AfJCcbdCbTZ4RCFr8KGS4d7gNg=.828697a4-0a2d-4de5-b680-73169328708c@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
 <ASRVEEGW1h3vnFBP4AfJCcbdCbTZ4RCFr8KGS4d7gNg=.828697a4-0a2d-4de5-b680-73169328708c@github.com>
Message-ID: <Akj47rTxl0XrqTNoDzmQFjZY4YWmMqQ5tjIpNiriG1Q=.7e4796cd-2093-4d60-9154-de3733e1c250@github.com>

On Wed, 29 Jan 2020 13:59:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> I need to re-review the updated PR.

The code changes look good to me. As long as you are willing to address the follow-on issues for openjfx15, I'll approve this PR for openjfx14, once I run my last test.

I did a fair bit of testing of the functionality, which reinforces the decision to only try tiling as a fallback when an exception occurs, since there could otherwise be functional regressions in addition to performance regressions.

With the latest update to the PR, any case that works today will continue to behave exactly as it does today. The worst that will happen is that the tiling might produce very slightly different results for interpolated colors, or possibly fail with a different exception (e.g., if a 4K x 4K texture is still too big for some hypothetical device, or if the user passes in a `WritableImage` created with a `PixelBuffer` (see below)).

I added a verbose println to snapshot to validate my testing:

1. Snapshot with image size = 5k x 5k (should still fit on Windows D3D with no tiling)
2. Snapshot with image size = 20k x 3k (should tile in X)
3. Snapshot with image size = 3K x 20k (should tile in Y)
4. Snapshot with image size = 20K x 20k (should tile in both X and Y)

RESULT: All of the above work as expected

5. Modify the jfx runtime to force tiling, set the tile size to 128 bytes, and run various tests (e.g., a stress test of tiling)
RESULT: Everything looks visually correct, but four of the tests in `test.robot.test3d.Snapshot3DTest` fail with a color mismatch [can be addressed in a follow-up bug]

6. Pass in a `WritableImage` created with a `PixelBuffer` object (NIO buffer)
RESULT: It works without tiling and throws an exception with tiling [can be addressed in a follow-up bug]

7. Pass in a larger than needed `WritableImage` (e.g., using a viewport that is large enough to cause tiling, but smaller than the passed in image) into snapshot when using tiling. Is the entire image cleared?
RESULT: I still need to run this test, but even if it doesn't work correctly when tiling, it wouldn't be a regression, and could be addressed in a follow-up bug.

Issues to file for follow-on bug(s):
1. Improve performance of tiled snapshot rendering
    * As part of this, we need to get max texture size from the toolkit
    * Consider moving the tiled rendering into `QuantumRenderer` thread
    * Reuse a single temporary buffer rather than creating a new one for each tile
2. Passing in a `WritableImage` created with a `PixelBuffer` object (NIO buffer) fails if tiling is needed. I'll file this one.
3. Pixel accuracy issues with tiled image; this can be seen in `Snapshot3DTest` by instrumenting the code to force tiling with a tile size of 128. It looks OK visually, but fails the color comparison test. I'll file this one.
4. Presuming that the above test 7 produces incorrect results, file a follow-up bug to fix it.

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

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

From kcr at openjdk.java.net  Wed Jan 29 16:32:40 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 16:32:40 GMT
Subject: RFR: 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled
 flag in DumpRenderTree
In-Reply-To: <x-64yZsh7HwBDQAmrHnyGTu9DGMxx93qYfada1Evtv0=.1cc47b51-bd1b-4b4b-aa60-27a5aa4436a9@github.com>
References: <x-64yZsh7HwBDQAmrHnyGTu9DGMxx93qYfada1Evtv0=.1cc47b51-bd1b-4b4b-aa60-27a5aa4436a9@github.com>
Message-ID: <RGNhX-DQ6BSYh8_V7XDJOvhfjR9yPvol_bQNENFOW6g=.d2d3c871-bc31-4f9d-be07-b0102c4c0775@github.com>

On Wed, 29 Jan 2020 11:29:10 GMT, Guru Hb <ghb at openjdk.org> wrote:

> AnimationBase and WebAnimation are two different abstract animation API provider. By default KeyFrameAnimation (which is a sub class of AnimationBase) is used for controlling and rendering the CSS animation. 
> Enabling "WebAnimationsCSSIntegrationEnabled" overrides the CSSAnimationController to use WebAnimation which is not used in our port (JAVA) and we are using KeyFrameAnimation.
> 
> Test : need to run DRT test harness with this fix for "LayoutTests/animations".

Marked as reviewed by kcr (Lead).

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

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

From nlisker at openjdk.java.net  Wed Jan 29 16:33:31 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 29 Jan 2020 16:33:31 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <Akj47rTxl0XrqTNoDzmQFjZY4YWmMqQ5tjIpNiriG1Q=.7e4796cd-2093-4d60-9154-de3733e1c250@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
 <ASRVEEGW1h3vnFBP4AfJCcbdCbTZ4RCFr8KGS4d7gNg=.828697a4-0a2d-4de5-b680-73169328708c@github.com>
 <Akj47rTxl0XrqTNoDzmQFjZY4YWmMqQ5tjIpNiriG1Q=.7e4796cd-2093-4d60-9154-de3733e1c250@github.com>
Message-ID: <Kt-agWsuAL9a7yHiHIo2E4nBSg2GwINh5POd3R8V8cI=.2c4d9ee7-0bbf-44ec-993d-326a0e6b20e6@github.com>

On Wed, 29 Jan 2020 15:42:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I need to re-review the updated PR.
> 
> The code changes look good to me. As long as you are willing to address the follow-on issues for openjfx15, I'll approve this PR for openjfx14, once I run my last test.
> 
> I did a fair bit of testing of the functionality, which reinforces the decision to only try tiling as a fallback when an exception occurs, since there could otherwise be functional regressions in addition to performance regressions.
> 
> With the latest update to the PR, any case that works today will continue to behave exactly as it does today. The worst that will happen is that the tiling might produce very slightly different results for interpolated colors, or possibly fail with a different exception (e.g., if a 4K x 4K texture is still too big for some hypothetical device, or if the user passes in a `WritableImage` created with a `PixelBuffer` (see below)).
> 
> I added a verbose println to snapshot to validate my testing:
> 
> 1. Snapshot with image size = 5k x 5k (should still fit on Windows D3D with no tiling)
> 2. Snapshot with image size = 20k x 3k (should tile in X)
> 3. Snapshot with image size = 3K x 20k (should tile in Y)
> 4. Snapshot with image size = 20K x 20k (should tile in both X and Y)
> 
> RESULT: All of the above work as expected
> 
> 5. Modify the jfx runtime to force tiling, set the tile size to 128 bytes, and run various tests (e.g., a stress test of tiling)
> RESULT: Everything looks visually correct, but four of the tests in `test.robot.test3d.Snapshot3DTest` fail with a color mismatch [can be addressed in a follow-up bug]
> 
> 6. Pass in a `WritableImage` created with a `PixelBuffer` object (NIO buffer)
> RESULT: It works without tiling and throws an exception with tiling [can be addressed in a follow-up bug]
> 
> 7. Pass in a larger than needed `WritableImage` (e.g., using a viewport that is large enough to cause tiling, but smaller than the passed in image) into snapshot when using tiling. Is the entire image cleared?
> RESULT: I still need to run this test, but even if it doesn't work correctly when tiling, it wouldn't be a regression, and could be addressed in a follow-up bug.
> 
> Issues to file for follow-on bug(s):
> 1. Improve performance of tiled snapshot rendering
>     * As part of this, we need to get max texture size from the toolkit
>     * Consider moving the tiled rendering into `QuantumRenderer` thread
>     * Reuse a single temporary buffer rather than creating a new one for each tile
> 2. Passing in a `WritableImage` created with a `PixelBuffer` object (NIO buffer) fails if tiling is needed. I'll file this one.
> 3. Pixel accuracy issues with tiled image; this can be seen in `Snapshot3DTest` by instrumenting the code to force tiling with a tile size of 128. It looks OK visually, but fails the color comparison test. I'll file this one.
> 4. Presuming that the above test 7 produces incorrect results, file a follow-up bug to fix it.

> Improve performance of tiled snapshot rendering

I'll have a closer look at improving `IntTo4ByteSameConverter::doConvert`.

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

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

From kcr at openjdk.java.net  Wed Jan 29 16:37:40 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 16:37:40 GMT
Subject: RFR: 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled
 flag in DumpRenderTree
In-Reply-To: <RGNhX-DQ6BSYh8_V7XDJOvhfjR9yPvol_bQNENFOW6g=.d2d3c871-bc31-4f9d-be07-b0102c4c0775@github.com>
References: <x-64yZsh7HwBDQAmrHnyGTu9DGMxx93qYfada1Evtv0=.1cc47b51-bd1b-4b4b-aa60-27a5aa4436a9@github.com>
 <RGNhX-DQ6BSYh8_V7XDJOvhfjR9yPvol_bQNENFOW6g=.d2d3c871-bc31-4f9d-be07-b0102c4c0775@github.com>
Message-ID: <-SfKmye0pK6kJ2wqpasKM6lfUmo2EY2RvQC_1C7V5f0=.fb50dcfb-0c3c-4b3b-a5df-26fbf76e0ab3@github.com>

On Wed, 29 Jan 2020 16:32:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> AnimationBase and WebAnimation are two different abstract animation API provider. By default KeyFrameAnimation (which is a sub class of AnimationBase) is used for controlling and rendering the CSS animation. 
>> Enabling "WebAnimationsCSSIntegrationEnabled" overrides the CSSAnimationController to use WebAnimation which is not used in our port (JAVA) and we are using KeyFrameAnimation.
>> 
>> Test : need to run DRT test harness with this fix for "LayoutTests/animations".
> 
> Marked as reviewed by kcr (Lead).

This fix only affects the test framework, so a single reviewer is fine.

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

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

From ghb at openjdk.java.net  Wed Jan 29 16:45:31 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Wed, 29 Jan 2020 16:45:31 GMT
Subject: [Integrated] RFR: 8237003: Remove hardcoded
 WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree
In-Reply-To: <x-64yZsh7HwBDQAmrHnyGTu9DGMxx93qYfada1Evtv0=.1cc47b51-bd1b-4b4b-aa60-27a5aa4436a9@github.com>
References: <x-64yZsh7HwBDQAmrHnyGTu9DGMxx93qYfada1Evtv0=.1cc47b51-bd1b-4b4b-aa60-27a5aa4436a9@github.com>
Message-ID: <c47a524d-f48f-4ff6-b2f5-3bab10a25d57@openjdk.org>

Changeset: b96bc52b
Author:    Guru Hb <ghb at openjdk.org>
Date:      2020-01-29 16:44:56 +0000
URL:       https://git.openjdk.java.net/jfx/commit/b96bc52b

8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree

Reviewed-by: kcr

! modules/javafx.web/src/main/java/com/sun/javafx/webkit/drt/DumpRenderTree.java

From github.com+7450507+fthevenet at openjdk.java.net  Wed Jan 29 17:49:36 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Wed, 29 Jan 2020 17:49:36 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <Kt-agWsuAL9a7yHiHIo2E4nBSg2GwINh5POd3R8V8cI=.2c4d9ee7-0bbf-44ec-993d-326a0e6b20e6@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
 <ASRVEEGW1h3vnFBP4AfJCcbdCbTZ4RCFr8KGS4d7gNg=.828697a4-0a2d-4de5-b680-73169328708c@github.com>
 <Akj47rTxl0XrqTNoDzmQFjZY4YWmMqQ5tjIpNiriG1Q=.7e4796cd-2093-4d60-9154-de3733e1c250@github.com>
 <Kt-agWsuAL9a7yHiHIo2E4nBSg2GwINh5POd3R8V8cI=.2c4d9ee7-0bbf-44ec-993d-326a0e6b20e6@github.com>
Message-ID: <myhEFLyYR7XrBJ7YUzXNIl3o0VqTdzMWQcYOZJUY-KY=.c4fde464-492a-41a7-be3a-548115b2766f@github.com>

On Wed, 29 Jan 2020 16:33:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The code changes look good to me. As long as you are willing to address the follow-on issues for openjfx15, I'll approve this PR for openjfx14, once I run my last test.
>> 
>> I did a fair bit of testing of the functionality, which reinforces the decision to only try tiling as a fallback when an exception occurs, since there could otherwise be functional regressions in addition to performance regressions.
>> 
>> With the latest update to the PR, any case that works today will continue to behave exactly as it does today. The worst that will happen is that the tiling might produce very slightly different results for interpolated colors, or possibly fail with a different exception (e.g., if a 4K x 4K texture is still too big for some hypothetical device, or if the user passes in a `WritableImage` created with a `PixelBuffer` (see below)).
>> 
>> I added a verbose println to snapshot to validate my testing:
>> 
>> 1. Snapshot with image size = 5k x 5k (should still fit on Windows D3D with no tiling)
>> 2. Snapshot with image size = 20k x 3k (should tile in X)
>> 3. Snapshot with image size = 3K x 20k (should tile in Y)
>> 4. Snapshot with image size = 20K x 20k (should tile in both X and Y)
>> 
>> RESULT: All of the above work as expected
>> 
>> 5. Modify the jfx runtime to force tiling, set the tile size to 128 bytes, and run various tests (e.g., a stress test of tiling)
>> RESULT: Everything looks visually correct, but four of the tests in `test.robot.test3d.Snapshot3DTest` fail with a color mismatch [can be addressed in a follow-up bug]
>> 
>> 6. Pass in a `WritableImage` created with a `PixelBuffer` object (NIO buffer)
>> RESULT: It works without tiling and throws an exception with tiling [can be addressed in a follow-up bug]
>> 
>> 7. Pass in a larger than needed `WritableImage` (e.g., using a viewport that is large enough to cause tiling, but smaller than the passed in image) into snapshot when using tiling. Is the entire image cleared?
>> RESULT: I still need to run this test, but even if it doesn't work correctly when tiling, it wouldn't be a regression, and could be addressed in a follow-up bug.
>> 
>> Issues to file for follow-on bug(s):
>> 1. Improve performance of tiled snapshot rendering
>>     * As part of this, we need to get max texture size from the toolkit
>>     * Consider moving the tiled rendering into `QuantumRenderer` thread
>>     * Reuse a single temporary buffer rather than creating a new one for each tile
>> 2. Passing in a `WritableImage` created with a `PixelBuffer` object (NIO buffer) fails if tiling is needed. I'll file this one.
>> 3. Pixel accuracy issues with tiled image; this can be seen in `Snapshot3DTest` by instrumenting the code to force tiling with a tile size of 128. It looks OK visually, but fails the color comparison test. I'll file this one.
>> 4. Presuming that the above test 7 produces incorrect results, file a follow-up bug to fix it.
> 
>> Improve performance of tiled snapshot rendering
> 
> I'll have a closer look at improving `IntTo4ByteSameConverter::doConvert`.

Yes, I'm fine with working further on this and the related issues for openjfx15, and I have fairly good idea on how to approach it.

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

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

From tsayao at openjdk.java.net  Wed Jan 29 18:33:30 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 29 Jan 2020 18:33:30 GMT
Subject: [Rev 16] RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <E99LTSs2UL2Qw2bpfsc2lcUTBw9lpQqq-LQPQAW9yrM=.98fe656e-4831-4337-9e49-760d49aad0bd@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to understand and maintain;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing (for gtk3);
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code;
> - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491;
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Updated on 2020-01-29:
> ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 058a0992: Revert "Fix Initial Size"

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/0c982d60..058a0992

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.16
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.15-16

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

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

From tsayao at openjdk.java.net  Wed Jan 29 19:07:30 2020
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 29 Jan 2020 19:07:30 GMT
Subject: [Rev 17] RFR: 8236651: Simplify and update glass gtk backend
In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com>
Message-ID: <7pAm39WXpnEIFMQi2IlDJ7cyIv6m45uP1SUV40V1eEU=.3fd2d78e-791c-4a6c-b90e-511daf7cc4ae@github.com>

> This proposed change does the following:
> 
> - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to understand and maintain;
> - Replaces (pointer and focus) grabbing with a gtk approach;
> - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity;
> - Simplified cursor changing (for gtk3);
> - Reduced the use of gtk/gdk deprecated functions;
> - Removes Applet/Web Start code;
> - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491;
> 
> In general it reduces code size and complexity and hands more work to gtk.
> 
> Updated on 2020-01-29:
> ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png)

The pull request has been updated with 1 additional commit.

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

Added commits:
 - e829b8e9: Better fix for initial size

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/058a0992..e829b8e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.17
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.16-17

  Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

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

From kcr at openjdk.java.net  Wed Jan 29 19:10:22 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 19:10:22 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
Message-ID: <xz_dBiVKMFFNTuhGNX32dCHDE1Tm8sd7J2UCllJKCa0=.cec22ebb-d593-4dec-a09c-1137a9a963f5@github.com>

On Wed, 29 Jan 2020 19:10:22 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 1 additional commit.

I ran the additional test (test case 7 as described above) and it behaves the same with or without tiling, so no follow-up issue is needed.

Approved.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Wed Jan 29 21:24:19 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 29 Jan 2020 21:24:19 GMT
Subject: RFR: 8237975: Non-embedded Animations do not play backwards after
 being paused
In-Reply-To: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
Message-ID: <bdYNndm_Wd05vZuxVZ4C5_Qjbjtg7_nmKz-MoWUW1rc=.ed104bb5-dc75-4b8b-bdb8-a86f93f034f2@github.com>

On Tue, 28 Jan 2020 19:19:57 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
> 
> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
> 
> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.

I'll look at it in more detail, but had two questions come up while looking at the fix. One is related to the fix, and one is preexisting.

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/FiniteClipEnvelope.java line 85:

> 84:         if (status != Status.STOPPED) {
> 85:             setInternalCurrentRate((Math.abs(currentRate - this.rate) < EPSILON) ? rate : -rate);
> 86:             deltaTicks = newTicks - Math.round((ticks - deltaTicks) * Math.abs(rate / this.rate));

What are the implications of not calling the existing `setCurrentRate` method for animations that are in the `RUNNING` state? It means that `Animation::setCurrentRate` will no longer be called in that case. Should it be?

Independent of your change, I can't figure out why the existing logic works today, even for animations that are running. The expression `(Math.abs(currentRate - this.rate) < EPSILON) ? rate : -rate` will evaluate either to `rate` or `-rate` depending on whether `currentRate` and `this.rate` are closer to each other than epsilon, irrespective of whether either (or both) of `this.rate` or `currentRate` are positive or negative. I feel I must be missing something.

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



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

From nlisker at openjdk.java.net  Wed Jan 29 22:54:28 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 29 Jan 2020 22:54:28 GMT
Subject: RFR: 8237975: Non-embedded Animations do not play backwards after
 being paused
In-Reply-To: <bdYNndm_Wd05vZuxVZ4C5_Qjbjtg7_nmKz-MoWUW1rc=.ed104bb5-dc75-4b8b-bdb8-a86f93f034f2@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
 <bdYNndm_Wd05vZuxVZ4C5_Qjbjtg7_nmKz-MoWUW1rc=.ed104bb5-dc75-4b8b-bdb8-a86f93f034f2@github.com>
Message-ID: <GnJVnceu3DamebhCp4k-CctrJKzFFu0h_z-D3BrrEa0=.d60c396c-f732-47b8-908f-a6f9f1d2d2ae@github.com>

On Wed, 29 Jan 2020 20:47:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
>> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
>> 
>> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
>> 
>> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.
> 
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/FiniteClipEnvelope.java line 85:
> 
>> 84:         if (status != Status.STOPPED) {
>> 85:             setInternalCurrentRate((Math.abs(currentRate - this.rate) < EPSILON) ? rate : -rate);
>> 86:             deltaTicks = newTicks - Math.round((ticks - deltaTicks) * Math.abs(rate / this.rate));
> 
> What are the implications of not calling the existing `setCurrentRate` method for animations that are in the `RUNNING` state? It means that `Animation::setCurrentRate` will no longer be called in that case. Should it be?
> 
> Independent of your change, I can't figure out why the existing logic works today, even for animations that are running. The expression `(Math.abs(currentRate - this.rate) < EPSILON) ? rate : -rate` will evaluate either to `rate` or `-rate` depending on whether `currentRate` and `this.rate` are closer to each other than epsilon, irrespective of whether either (or both) of `this.rate` or `currentRate` are positive or negative. I feel I must be missing something.

> What are the implications of not calling the existing `setCurrentRate` method for animations that are in the `RUNNING` state? It means that `Animation::setCurrentRate` will no longer be called in that case. Should it be?

The situation is complicated (to put it politely), as you've realized. `currentRate` is actually being set from `Animation#setRate` first, then `ClipEnvelope.setRate` sets it again. I initially removed `currentRate` from `ClipEnvelope` altogether, but that broke embedded animations whose rate is being set by their parent through their `ClipEnvelope` (doing it through `Animation` will throw an exception). So, instead, I added a "backdoor" for the parent to change its child's `ClipEnvelope.currentRate` without changing its `Animation.currentRate`.

The result is that non-embedded animations now work correctly and embedded animations are still broken, but in a slightly different way. Their `Animation.currentRate` is now always 1 instead of either 1 or -1, but this is incorrect anyway if the rate is not 1 or -1.

> Independent of your change, I can't figure out why the existing logic works today, even for animations that are running. The expression `(Math.abs(currentRate - this.rate) < EPSILON) ? rate : -rate` will evaluate either to `rate` or `-rate` depending on whether `currentRate` and `this.rate` are closer to each other than epsilon, irrespective of whether either (or both) of `this.rate` or `currentRate` are positive or negative. I feel I must be missing something.

There's a lot I couldn't figure out in time for 14, especially with regard to embedded animations (have a look at `ParallelTransition.doPlayTo`).

For non-embedded animations, If the animation is `RUNNING`, then:
* If the animation is during a forward cycle then `currentRate == this.rate`, so the current rate is set to the new rate.
* If the animation is during a reverse cycle, then `currentRate == -this.rate`, so the current rate is set to the negative of the new rate (to accommodate the reverse cycle's rule of `currentRate == -rate`).

However, this check is already done in `Animation.rate`'s `invalidate` method, where the cryptic `Math.abs(currentRate - this.rate) < EPSILON` is at least given the name `playingForward`:
if (getStatus() == Status.RUNNING) {                                             
    final double currentRate = getCurrentRate();                                 
    if (Math.abs(currentRate) < EPSILON) {                                       
        doSetCurrentRate(lastPlayedForward ? newRate : -newRate);                
        resumeReceiver();                                                        
    } else {                                                                     
        final boolean playingForward = Math.abs(currentRate - oldRate) < EPSILON; // HERE
        doSetCurrentRate(playingForward ? newRate : -newRate);  // AND HERE
    }                                                                            
}                                                                                
oldRate = newRate;                                                               

For embedded animations this is even worse, since there is an additional rate property kept in the parent animations (`rates[i]`), so the rate is kept in 3 places...

Overall, the animation area will require a soft redesign. That might weed out the bugs in bulk. The more I was working to find a fix the more bugs I found. I turned [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) to an umbrella issue to keep track.

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

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

From arapte at openjdk.java.net  Thu Jan 30 08:15:49 2020
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 30 Jan 2020 08:15:49 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
Message-ID: <NLw9XKNLg-Zx3uWzBwp0MQMGLsfZ5jr3pCBxSUl6obQ=.aff7a503-6ce7-42c6-987e-c7216ff55c26@github.com>

On Thu, 30 Jan 2020 08:15:48 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 1 additional commit.

With my basic testing, the change looks good, scaled up and scaled down snapshots seem correct visually.

After this change the tiled snapshot will be limited by dimensions of the `WritableImage`.
We can not create a `WritableImage` of dimension `(8192 * 3, 8192 * 3)` or greater.
`new WritableImage(8192 * 3, 8192 * 3)`  causes an exception.
java.lang.IllegalArgumentException: capacity < 0: (-1879048192 < 0)
	at java.base/java.nio.Buffer.createCapacityException(Buffer.java:257)
This is an existing behavior of `WritableImage`.
May be we should consider to wrap and re-throw the exception and update the API JavaDoc.
Anyway not a stopper for this PR.
Approving.

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

Marked as reviewed by arapte (Reviewer).

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

From kevin.rushforth at oracle.com  Thu Jan 30 14:01:18 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Jan 2020 06:01:18 -0800
Subject: Should Skara tooling invalidate approvals when new commits are
 pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]
In-Reply-To: <482dd6a0-befd-6c95-e430-fc8789be6fd0@oracle.com>
References: <c8c7a4fe-faca-1afc-d8ff-a59dda0a5497@oracle.com>
 <CA+0ynh896r13RHUUK-TrRYjMSqp0SEdKv-7-cquaWdvJGkKVkQ@mail.gmail.com>
 <CAK7C+XjgQjsVcvFJrBPg5ahqCRP8S9uWQicBVAJcENfkbqJD6A@mail.gmail.com>
 <482dd6a0-befd-6c95-e430-fc8789be6fd0@oracle.com>
Message-ID: <b42b320f-904a-edd3-84d1-085b2aaea5ce@oracle.com>

Hearing no objections, we will enable this for pull requests on the jfx 
repo starting Tuesday, Feb 4.

-- Kevin


On 1/8/2020 11:34 AM, Kevin Rushforth wrote:
> Does anyone strongly feel otherwise? If not, then I'll request the 
> Skara team to enable this feature.
>
> -- Kevin
>
>
> On 1/8/2020 11:26 AM, Johan Vos wrote:
>> I agree. If the fix is trivial, the time for the reviewer will be 
>> really short. The more complex the fix, the more time it will take -- 
>> with the risk of being delayed to the next release.
>> The github interface makes it very easy to inspect the new commit, 
>> hence a typo in javadoc can easily be fixed and re-approved.
>>
>> I think this approach is safer than the approach were "trivial" fixes 
>> don't need re-approval, as that approach leaves more room for 
>> interpretation (and probably even more interactions with the 
>> reviewers ("is this a trivial fix?")).
>>
>> - Johan
>>
>> Op wo 8 jan. 2020 om 19:34 schreef Nir Lisker <nlisker at gmail.com 
>> <mailto:nlisker at gmail.com>>:
>>
>> ??? Looks like an all-or-nothing situation - either any commit requires
>> ??? re-approval or no commit requires re-approval. In this case, I
>> ??? would say
>> ??? that all commits should require re-approval since it's the safer
>> ??? approach.
>> ??? Having the issue stay in approved state after a significant change
>> ??? is much
>> ??? worse than requiring the reviewers to take a look at an 
>> insignificant
>> ??? commit and re-approve. The time is takes for a reviewer to go over a
>> ??? comment or formatting change is short and, I believe, not 
>> intrusive to
>> ??? their workflow.
>>
>> ??? On Tue, Dec 31, 2019 at 7:48 PM Kevin Rushforth
>> ??? <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>> ??? wrote:
>>
>> ??? > Since this isn't directly related to the PR in question, I'm
>> ??? starting a
>> ??? > new thread.
>> ??? >
>> ??? > On 12/20/2019 7:22 PM, Philip Race wrote:
>> ??? > > On 12/20/19, 7:04 PM, Scott Palmer wrote:
>> ??? > >> I'm not sure if I'me supposed to try to integrate now that
>> ??? I've made
>> ??? > >> that 10 ->? 0 change, or if the new change resets the need
>> ??? for review...
>> ??? > >
>> ??? > > It shows ready, which surprises me.
>> ??? > > Still learning skara .. I'd expect any change to reset as how
>> ??? can it
>> ??? > > know if it is
>> ??? > > a? good or insignificant change or not no matter how the 
>> commenter
>> ??? > > characterised the issue ?
>> ??? >
>> ??? > Pushing a new commit doesn't automatically invalidate existing
>> ??? > approvals, although it is highlighted in the "Approvers" section
>> ??? that
>> ??? > the approval was for a prior commit:
>> ??? >
>> ??? >? ? ? Approvers
>> ??? >? ? ? ? ? Phil Race (prr - Reviewer) Note! Review applies to 
>> f846ad6
>> ??? >
>> ??? > I remember bringing this up with the Skara team during my initial
>> ??? > testing, since I also had wondered whether pushing a new commit
>> ??? should
>> ??? > invalidate approvals. The current policy allows for doing
>> ??? trivial fixes
>> ??? > brought up when approving a review (e.g., a change in a comment or
>> ??? > formatting) without requiring all reviewers to re-approve. It
>> ??? matches
>> ??? > current practice for email-based reviews, so I think the current
>> ??? > behavior is a reasonable default.
>> ??? >
>> ??? > They did say that they could implement an optional feature 
>> (i.e., a
>> ??? > project would need to opt-in to this behavior, probably via a
>> ??? > .jcheck/conf property) to invalidate all approvals upon pushing
>> ??? a new
>> ??? > commit, but I don't think an RFE was filed to track it.
>> ??? >
>> ??? > This seems like it could be a valuable feature, although it does
>> ??? come
>> ??? > with a slight cost in terms of timing and flexibility. What do
>> ??? others
>> ??? > think?
>> ??? >
>> ??? > -- Kevin
>> ??? >
>> ??? >
>>
>


From mike at plan99.net  Thu Jan 30 16:29:08 2020
From: mike at plan99.net (Mike Hearn)
Date: Thu, 30 Jan 2020 10:29:08 -0600
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <d21c307a-67e2-6e28-9867-ea2b21d13f3e@bestsolution.at>
References: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>
 <BN8PR21MB1281D717E89FD664B8FA6DED9B0B0@BN8PR21MB1281.namprd21.prod.outlook.com>
 <d21c307a-67e2-6e28-9867-ea2b21d13f3e@bestsolution.at>
Message-ID: <CANEZrP3sixbiNsM5H4BQhfy=yHZ0Cpc=+sCddfVjx9MqPskOvQ@mail.gmail.com>

Yes, a scale transform doesn't affect layout. That's the issue. Browser
zoom scales fonts, images and widgets but in a way that affects layout
bounds, not only render bounds.

As far as I can tell there's no way to do a zoom or scale that affects
layout bounds with the public JavaFX API. Exploring why not and what could
work is how I ended up getting a bit lost in the weeds of all the different
scale factors. It *feels* like one of them should be applicable if only it
was public API. But I can't quite figure out which or how exactly it'd
work. If nobody else has ever examined this task (it seems not) then I
guess I can just compile my own JFX and experiment with forcing the
different factors and ratios to see what happens. I'm not sure the results
would be stable or portable though.




On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> I think that can not work because layouts don't take the scale factor into
> account nor does stuff like ScrollView but i could be wrong.
>
> Tom
>
> On 27.01.20 17:29, David Grieve wrote:
>
> Wouldn't this just be a scale transform?
>
> -----Original Message-----
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev at openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>
> Hello,
>
> A feature I often miss when using non-web GUIs is support for browser
> style zooming. In JavaFX it is quite easy to specify all font sizes in
> terms of "ems", relative sizes ("largest") or percentages and then adjust
> the base font size on a root node inside key handlers. This works OK but
> doesn't do much for images or other controls, and of course most JavaFX GUI
> code specifies sizes in terms of pixels.
>
> There are various scaling factors applied to pixel sizes. There is the
> per-node scaling transform, but this doesn't affect layout so isn't
> comparable to what browsers do. There's a per-screen DPI, there's a
> "platform scale", there's a
> "render scale" and then there's a "ui scale". These seem related to
> hidpi/retina support and are all internal (for the purposes of this
> question I'm happy to modify JavaFX itself).
>
> Render scale seems to affect resolution without affecting positions or
> layout, so that's not quite what I want. UI scale sounds promising but
> isn't documented and I couldn't quite figure it out by reading the code,
> though I could just fiddle with it and see what happens.
>
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting zoom? If not,
> has anyone explored the complexity of the modifications required?
>
> thanks,
> -mike
>
> --
> Tom Schindl, CTO
> BestSolution.at <http://bestsolution.at/> EDV Systemhaus GmbH
> Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From abhinay_agarwal at live.com  Thu Jan 30 16:36:36 2020
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Thu, 30 Jan 2020 16:36:36 +0000
Subject: Windows: Mnemonics Issue
Message-ID: <PS1PR03MB47000D3CB8BAAE566FF47589E7040@PS1PR03MB4700.apcprd03.prod.outlook.com>

On Windows, mnemonics is activated when ALT is pressed. This is true for apps made in JavaFX.

However I have found the following discrepancy between Windows Native Apps and JavaFX apps:

In Windows, pressing any key(not assigned to mnemonics) in combination with ALT doesn't de-activates mnemonics. It is automatically deactivated
when ALT is released. This can be reproduced in Notepad.
However in JavaFX, pressing ALT activates mnemonics. If any key (not assinged to mnemonics) is pressed while ALT is being pressed, it deactivates mnemonics. This can lead to an unwanted state.

This can be tested by the following steps:

1. Open Notepad -> Type ALT + A. Nothing happens. Once ALT is released, mnemonics is de-activated on the MenuBar.
2. Run the attached JavaFX sample. Press ALT -> mnemonics activated. Press 'ALT + A' -> mnemonics activates and then de-activates.
If you continue tapping 'A' (with ALT pressed), we can see that mnemonics are activated and deactivated. If we leave the mnemonics in activated state and try to
enter text 'F' in textfield, it will show the MenuItem(s) in the 'File' Menu.

Sample
=======


import javafx.application.Application;

import javafx.stage.Stage;

import javafx.scene.Scene;

import javafx.scene.control.Menu;

import javafx.scene.control.MenuBar;

import javafx.scene.control.MenuItem;

import javafx.scene.control.TextField;

import javafx.scene.layout.BorderPane;

public class MenuBarMnemonics extends Application {

    @Override

    public void start(Stage primaryStage) {

        BorderPane root = new BorderPane();

        MenuBar b = new MenuBar();

        Menu file = new Menu("_File");

        MenuItem fileTest = new MenuItem("Tes_t");

        file.getItems().add(fileTest);

        b.getMenus().add(file);

        Menu edit = new Menu("_Edit");

        MenuItem editTest = new MenuItem("Te_st");

        edit.getItems().add(editTest);

        b.getMenus().add(edit);

        root.setTop(b);

        root.setCenter(new TextField());

        Scene scene = new Scene(root,400,400);

        primaryStage.setScene(scene);

        primaryStage.show();

    }

}


From kevin.rushforth at oracle.com  Thu Jan 30 16:47:54 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Jan 2020 08:47:54 -0800
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)
Message-ID: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.

This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch events.

The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set of 
touch points), that it would be too risky to change it this late in the 
release.

Since there isn't an easy / safe fix that is feasible for JavaFX 14, I 
wanted to get some input from Mac users on the list. I can think of the 
following possibilities for JavaFX 14:

1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or later) 
-- we could consider a system property to re-enable it, but I don't 
really like that idea, and I'm not sure how useful it would be anyway 
since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the application 
requests them -- this would require new interfaces in Glass, isn't risk 
free, and doesn't solve the dialog problem for those apps that do use touch.

I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to whether 
that would be more of a problem than doing nothing (i.e., option #1). I 
only listed option #3 for completeness, since it doesn't really solve 
the issue.

Whatever we do for 14, the solution for 15 will very likely be to switch 
to tracking per-View (per Window) touch events, either directly, or 
maybe using local event monitoring.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8231513


From mp at jugs.org  Thu Jan 30 16:59:54 2020
From: mp at jugs.org (Michael Paus)
Date: Thu, 30 Jan 2020 17:59:54 +0100
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <CANEZrP3sixbiNsM5H4BQhfy=yHZ0Cpc=+sCddfVjx9MqPskOvQ@mail.gmail.com>
References: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>
 <BN8PR21MB1281D717E89FD664B8FA6DED9B0B0@BN8PR21MB1281.namprd21.prod.outlook.com>
 <d21c307a-67e2-6e28-9867-ea2b21d13f3e@bestsolution.at>
 <CANEZrP3sixbiNsM5H4BQhfy=yHZ0Cpc=+sCddfVjx9MqPskOvQ@mail.gmail.com>
Message-ID: <58d9ddfa-d985-0b07-baac-dc80cb0e6f89@jugs.org>

I am wondering whether this kind of scaling should actually be done on
an application basis. On desktop computers this is normally achieved via
some system setting of the monitor scaling. I think most people just want
a consistent scaling across all applications and so there is just no need
in general for an individual scaling. Just for very specific cases this may
be useful, e.g., to scale the text size of an editor window in Eclipse
where this can be done like in a browser via Cmd+/-. In a browser you
only need this feature because web-sites are so inconsistent in their
styling, which is normally not the case for desktop applications.

Just my two ?ent


Am 30.01.20 um 17:29 schrieb Mike Hearn:
> Yes, a scale transform doesn't affect layout. That's the issue. Browser
> zoom scales fonts, images and widgets but in a way that affects layout
> bounds, not only render bounds.
>
> As far as I can tell there's no way to do a zoom or scale that affects
> layout bounds with the public JavaFX API. Exploring why not and what could
> work is how I ended up getting a bit lost in the weeds of all the different
> scale factors. It *feels* like one of them should be applicable if only it
> was public API. But I can't quite figure out which or how exactly it'd
> work. If nobody else has ever examined this task (it seems not) then I
> guess I can just compile my own JFX and experiment with forcing the
> different factors and ratios to see what happens. I'm not sure the results
> would be stable or portable though.
>
>
>
>
> On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
>
>> I think that can not work because layouts don't take the scale factor into
>> account nor does stuff like ScrollView but i could be wrong.
>>
>> Tom
>>
>> On 27.01.20 17:29, David Grieve wrote:
>>
>> Wouldn't this just be a scale transform?
>>
>> -----Original Message-----
>> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
>> Mike Hearn
>> Sent: Monday, January 27, 2020 11:00 AM
>> To: openjfx-dev at openjdk.java.net
>> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>>
>> Hello,
>>
>> A feature I often miss when using non-web GUIs is support for browser
>> style zooming. In JavaFX it is quite easy to specify all font sizes in
>> terms of "ems", relative sizes ("largest") or percentages and then adjust
>> the base font size on a root node inside key handlers. This works OK but
>> doesn't do much for images or other controls, and of course most JavaFX GUI
>> code specifies sizes in terms of pixels.
>>
>> There are various scaling factors applied to pixel sizes. There is the
>> per-node scaling transform, but this doesn't affect layout so isn't
>> comparable to what browsers do. There's a per-screen DPI, there's a
>> "platform scale", there's a
>> "render scale" and then there's a "ui scale". These seem related to
>> hidpi/retina support and are all internal (for the purposes of this
>> question I'm happy to modify JavaFX itself).
>>
>> Render scale seems to affect resolution without affecting positions or
>> layout, so that's not quite what I want. UI scale sounds promising but
>> isn't documented and I couldn't quite figure it out by reading the code,
>> though I could just fiddle with it and see what happens.
>>
>> It feels like someone probably explored this before now. Is there a way to
>> effectively expand the size of every node without altering the size of the
>> containing viewport, to get browser-style layout affecting zoom? If not,
>> has anyone explored the complexity of the modifications required?
>>
>> thanks,
>> -mike
>>
>> --
>> Tom Schindl, CTO
>> BestSolution.at <http://bestsolution.at/> EDV Systemhaus GmbH
>> Salurnerstrasse 15. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>


From mp at jugs.org  Thu Jan 30 17:31:39 2020
From: mp at jugs.org (Michael Paus)
Date: Thu, 30 Jan 2020 18:31:39 +0100
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina
 (JDK-8231513)
In-Reply-To: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>
References: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>
Message-ID: <3d944f7b-e627-3cd4-408a-d33f1cdbca65@jugs.org>

Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are
working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:
> To: Mac app developers / users
>
> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
> Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
> effect of this bug is that a scary dialog is shown for all users the 
> first time they run a JavaFX application and move the mouse is moved 
> into the JavaFX window. It also is reported to block apps from being 
> accepted in the Apple store.
>
> This bug is caused by a change in macOS 10.15 to require additional 
> permissions for using CGEventTap, which JavaFX uses to track touch 
> events.
>
> The suggested replacement API, 
> NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
> enough (it tracks events delivered to a specific view, whereas the 
> current code is implemented using a global monitor and a global set of 
> touch points), that it would be too risky to change it this late in 
> the release.
>
> Since there isn't an easy / safe fix that is feasible for JavaFX 14, I 
> wanted to get some input from Mac users on the list. I can think of 
> the following possibilities for JavaFX 14:
>
> 1. Do nothing (defer the bug to FX 15)
> 2. Disable touch events completely if running on macOS 10.15 (or 
> later) -- we could consider a system property to re-enable it, but I 
> don't really like that idea, and I'm not sure how useful it would be 
> anyway since setting that flag would cause the scary dialog again.
> 3. Defer enabling of touch events until the first time the application 
> requests them -- this would require new interfaces in Glass, isn't 
> risk free, and doesn't solve the dialog problem for those apps that do 
> use touch.
>
> I'm leaning towards option #2 (without the system property to force 
> enable it), but wanted to get a sense from app developers as to 
> whether that would be more of a problem than doing nothing (i.e., 
> option #1). I only listed option #3 for completeness, since it doesn't 
> really solve the issue.
>
> Whatever we do for 14, the solution for 15 will very likely be to 
> switch to tracking per-View (per Window) touch events, either 
> directly, or maybe using local event monitoring.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231513
>


From sebastian.stenzel at gmail.com  Thu Jan 30 17:32:33 2020
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Thu, 30 Jan 2020 18:32:33 +0100
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina
 (JDK-8231513)
In-Reply-To: <mailman.4475.1580403601.14600.openjfx-dev@openjdk.java.net>
References: <mailman.4475.1580403601.14600.openjfx-dev@openjdk.java.net>
Message-ID: <63923999-F57B-4AD0-8EB7-32EE73372BFD@gmail.com>



> To: Mac app developers / users
> 
> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, NSEvent::addLocalMonitorForEventsMatchingMask, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.
> 
> Since there isn't an easy / safe fix that is feasible for JavaFX 14, I wanted to get some input from Mac users on the list. I can think of the following possibilities for JavaFX 14:
> 
> 1. Do nothing (defer the bug to FX 15)
> 2. Disable touch events completely if running on macOS 10.15 (or later) -- we could consider a system property to re-enable it, but I don't really like that idea, and I'm not sure how useful it would be anyway since setting that flag would cause the scary dialog again.
> 3. Defer enabling of touch events until the first time the application requests them -- this would require new interfaces in Glass, isn't risk free, and doesn't solve the dialog problem for those apps that do use touch.
> 
> I'm leaning towards option #2 (without the system property to force enable it), but wanted to get a sense from app developers as to whether that would be more of a problem than doing nothing (i.e., option #1). I only listed option #3 for completeness, since it doesn't really solve the issue.
> 
> Whatever we do for 14, the solution for 15 will very likely be to switch to tracking per-View (per Window) touch events, either directly, or maybe using local event monitoring.
> 
> -- Kevin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8231513 <https://bugs.openjdk.java.net/browse/JDK-8231513>
I'd also vote for #2 as a quickly available workaround (not as a long-term fix, though). Here are my thoughts:

Are there any (non-hackintosh) devices running macOS that have touch screens at all? Recent MacBooks have this thing called Touch Bar, which caused problems with JavaFX apps in the past (touching it crashed the application - is this related?). I'm not even sure why the touch event handling exists on macOS in the first place. Is it only the attempt to implement a Glass API that is intended for different device classes?

Maybe touch events are facilitated by applications that register events on third party devices like graphics tablets. If there are applications out there using it, we should have some flag to reenable it (despite the "scary dialog"). Otherwise I think it is fair to just disable it all together.

From kevin.rushforth at oracle.com  Thu Jan 30 18:28:16 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Jan 2020 10:28:16 -0800
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina
 (JDK-8231513)
In-Reply-To: <3d944f7b-e627-3cd4-408a-d33f1cdbca65@jugs.org>
References: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>
 <3d944f7b-e627-3cd4-408a-d33f1cdbca65@jugs.org>
Message-ID: <af4fb2bc-4d9d-9ad4-173e-42bd2cfd1c11@oracle.com>

This affects TouchEvents generated via low-level native touch events, 
including those generated by a trackpad. GestureEvents still work. In 
particular, the HelloGestures app still works: even with low-level touch 
events disabled, I can use the trackpad to rotate and zoom and the app 
picks it up fine.

Mouse events, including trackpad scrolling events, are not affected at 
all by this.

-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
> Just to clarify the implications of this issue: Are you only talking 
> about the JavaFX TouchEvents
> or would disabling them also affect all GestureEvents and synthesized 
> MouseEvents when you are
> working with a trackpad?
>
> Am 30.01.20 um 17:47 schrieb Kevin Rushforth:
>> To: Mac app developers / users
>>
>> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
>> Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
>> effect of this bug is that a scary dialog is shown for all users the 
>> first time they run a JavaFX application and move the mouse is moved 
>> into the JavaFX window. It also is reported to block apps from being 
>> accepted in the Apple store.
>>
>> This bug is caused by a change in macOS 10.15 to require additional 
>> permissions for using CGEventTap, which JavaFX uses to track touch 
>> events.
>>
>> The suggested replacement API, 
>> NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
>> enough (it tracks events delivered to a specific view, whereas the 
>> current code is implemented using a global monitor and a global set 
>> of touch points), that it would be too risky to change it this late 
>> in the release.
>>
>> Since there isn't an easy / safe fix that is feasible for JavaFX 14, 
>> I wanted to get some input from Mac users on the list. I can think of 
>> the following possibilities for JavaFX 14:
>>
>> 1. Do nothing (defer the bug to FX 15)
>> 2. Disable touch events completely if running on macOS 10.15 (or 
>> later) -- we could consider a system property to re-enable it, but I 
>> don't really like that idea, and I'm not sure how useful it would be 
>> anyway since setting that flag would cause the scary dialog again.
>> 3. Defer enabling of touch events until the first time the 
>> application requests them -- this would require new interfaces in 
>> Glass, isn't risk free, and doesn't solve the dialog problem for 
>> those apps that do use touch.
>>
>> I'm leaning towards option #2 (without the system property to force 
>> enable it), but wanted to get a sense from app developers as to 
>> whether that would be more of a problem than doing nothing (i.e., 
>> option #1). I only listed option #3 for completeness, since it 
>> doesn't really solve the issue.
>>
>> Whatever we do for 14, the solution for 15 will very likely be to 
>> switch to tracking per-View (per Window) touch events, either 
>> directly, or maybe using local event monitoring.
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231513
>>
>


From mp at jugs.org  Thu Jan 30 18:55:23 2020
From: mp at jugs.org (Michael Paus)
Date: Thu, 30 Jan 2020 19:55:23 +0100
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina
 (JDK-8231513)
In-Reply-To: <af4fb2bc-4d9d-9ad4-173e-42bd2cfd1c11@oracle.com>
References: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>
 <3d944f7b-e627-3cd4-408a-d33f1cdbca65@jugs.org>
 <af4fb2bc-4d9d-9ad4-173e-42bd2cfd1c11@oracle.com>
Message-ID: <6d10efd4-82ab-29c3-908e-490a42d54f81@jugs.org>

In this case I would also vote for #2. Your comment astonishes me 
nevertheless because
I have never received any JavaFX TouchEvents on my Mac, so I won't miss 
them. As far as
I know they are only generated by real touch screens but NOT by track 
pads, or have I
missed something here? This is also consistent with the comment from 
Sebastian.
I am not aware of any Mac which has a touch screen, so it is quite 
unlikely that
someone has ever used them.

Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
> This affects TouchEvents generated via low-level native touch events, 
> including those generated by a trackpad. GestureEvents still work. In 
> particular, the HelloGestures app still works: even with low-level 
> touch events disabled, I can use the trackpad to rotate and zoom and 
> the app picks it up fine.
>
> Mouse events, including trackpad scrolling events, are not affected at 
> all by this.
>
> -- Kevin
>
>
> On 1/30/2020 9:31 AM, Michael Paus wrote:
>> Just to clarify the implications of this issue: Are you only talking 
>> about the JavaFX TouchEvents
>> or would disabling them also affect all GestureEvents and synthesized 
>> MouseEvents when you are
>> working with a trackpad?
>>
>> Am 30.01.20 um 17:47 schrieb Kevin Rushforth:
>>> To: Mac app developers / users
>>>
>>> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
>>> Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
>>> The effect of this bug is that a scary dialog is shown for all users 
>>> the first time they run a JavaFX application and move the mouse is 
>>> moved into the JavaFX window. It also is reported to block apps from 
>>> being accepted in the Apple store.
>>>
>>> This bug is caused by a change in macOS 10.15 to require additional 
>>> permissions for using CGEventTap, which JavaFX uses to track touch 
>>> events.
>>>
>>> The suggested replacement API, 
>>> NSEvent::addLocalMonitorForEventsMatchingMask, works just 
>>> differently enough (it tracks events delivered to a specific view, 
>>> whereas the current code is implemented using a global monitor and a 
>>> global set of touch points), that it would be too risky to change it 
>>> this late in the release.
>>>
>>> Since there isn't an easy / safe fix that is feasible for JavaFX 14, 
>>> I wanted to get some input from Mac users on the list. I can think 
>>> of the following possibilities for JavaFX 14:
>>>
>>> 1. Do nothing (defer the bug to FX 15)
>>> 2. Disable touch events completely if running on macOS 10.15 (or 
>>> later) -- we could consider a system property to re-enable it, but I 
>>> don't really like that idea, and I'm not sure how useful it would be 
>>> anyway since setting that flag would cause the scary dialog again.
>>> 3. Defer enabling of touch events until the first time the 
>>> application requests them -- this would require new interfaces in 
>>> Glass, isn't risk free, and doesn't solve the dialog problem for 
>>> those apps that do use touch.
>>>
>>> I'm leaning towards option #2 (without the system property to force 
>>> enable it), but wanted to get a sense from app developers as to 
>>> whether that would be more of a problem than doing nothing (i.e., 
>>> option #1). I only listed option #3 for completeness, since it 
>>> doesn't really solve the issue.
>>>
>>> Whatever we do for 14, the solution for 15 will very likely be to 
>>> switch to tracking per-View (per Window) touch events, either 
>>> directly, or maybe using local event monitoring.
>>>
>>> -- Kevin
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231513
>>>
>>
>


From mblaesing at doppel-helix.eu  Thu Jan 30 19:06:26 2020
From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=)
Date: Thu, 30 Jan 2020 20:06:26 +0100
Subject: How to build standalone openJFX modules for uploading to a
 local maven repository
In-Reply-To: <078F2BB3-4A70-49F3-90ED-9FA9A613D06B@gmail.com>
References: <078F2BB3-4A70-49F3-90ED-9FA9A613D06B@gmail.com>
Message-ID: <b9d32cbf632c19d1a0b85ccc689a923d6c352807.camel@doppel-helix.eu>

Hi Danny,

Am Dienstag, den 28.01.2020, 09:50 +0000 schrieb Danny Gonzalez:
> We have a java 11 project that uses maven to pull in openJFX
> modules  i.e. javafx-controls, javafx-web, javafx-swing.
> 
> What we would like to do is build our own versions of these openJFX
> modules for use as maven dependencies which use a fork of openJFX
> (which we build locally to fix up some bugs).
> 
> I can?t however see an obvious way of building these openJFX
> standalone modules for deploying in our local maven repository in the
> same way that they were originally built for uploading into maven
> central.
> 
> Is this documented anywhere?
> 

I would have a look at the publishMaven* tasks:

> bash gradlew tasks

[...]
Publishing tasks
----------------
[...]
publishMavenPublicationToMavenRepository - Publishes Maven publication 'maven' to Maven repository 'maven'.
publishToMavenLocal - Publishes all Maven publications produced by this project to the local Maven cache.
[...]

If I remember correctly, these tasks required a prior full build.

HTH

Matthias


From kevin.rushforth at oracle.com  Thu Jan 30 19:52:47 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Jan 2020 11:52:47 -0800
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina
 (JDK-8231513)
In-Reply-To: <6d10efd4-82ab-29c3-908e-490a42d54f81@jugs.org>
References: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>
 <3d944f7b-e627-3cd4-408a-d33f1cdbca65@jugs.org>
 <af4fb2bc-4d9d-9ad4-173e-42bd2cfd1c11@oracle.com>
 <6d10efd4-82ab-29c3-908e-490a42d54f81@jugs.org>
Message-ID: <1f04c9e5-081b-1a83-bb0c-fb067a8336fa@oracle.com>

Yeah, I was surprised, too. I can see the low level touch events being 
generated and passed up to the Java code, but I haven't actually 
verified yet that it turns them into JavaFX TouchEvents that get 
delivered to an application (I'll try that this afternoon).

-- Kevin


On 1/30/2020 10:55 AM, Michael Paus wrote:
> In this case I would also vote for #2. Your comment astonishes me 
> nevertheless because
> I have never received any JavaFX TouchEvents on my Mac, so I won't 
> miss them. As far as
> I know they are only generated by real touch screens but NOT by track 
> pads, or have I
> missed something here? This is also consistent with the comment from 
> Sebastian.
> I am not aware of any Mac which has a touch screen, so it is quite 
> unlikely that
> someone has ever used them.
>
> Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
>> This affects TouchEvents generated via low-level native touch events, 
>> including those generated by a trackpad. GestureEvents still work. In 
>> particular, the HelloGestures app still works: even with low-level 
>> touch events disabled, I can use the trackpad to rotate and zoom and 
>> the app picks it up fine.
>>
>> Mouse events, including trackpad scrolling events, are not affected 
>> at all by this.
>>
>> -- Kevin
>>
>>
>> On 1/30/2020 9:31 AM, Michael Paus wrote:
>>> Just to clarify the implications of this issue: Are you only talking 
>>> about the JavaFX TouchEvents
>>> or would disabling them also affect all GestureEvents and 
>>> synthesized MouseEvents when you are
>>> working with a trackpad?
>>>
>>> Am 30.01.20 um 17:47 schrieb Kevin Rushforth:
>>>> To: Mac app developers / users
>>>>
>>>> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
>>>> Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
>>>> The effect of this bug is that a scary dialog is shown for all 
>>>> users the first time they run a JavaFX application and move the 
>>>> mouse is moved into the JavaFX window. It also is reported to block 
>>>> apps from being accepted in the Apple store.
>>>>
>>>> This bug is caused by a change in macOS 10.15 to require additional 
>>>> permissions for using CGEventTap, which JavaFX uses to track touch 
>>>> events.
>>>>
>>>> The suggested replacement API, 
>>>> NSEvent::addLocalMonitorForEventsMatchingMask, works just 
>>>> differently enough (it tracks events delivered to a specific view, 
>>>> whereas the current code is implemented using a global monitor and 
>>>> a global set of touch points), that it would be too risky to change 
>>>> it this late in the release.
>>>>
>>>> Since there isn't an easy / safe fix that is feasible for JavaFX 
>>>> 14, I wanted to get some input from Mac users on the list. I can 
>>>> think of the following possibilities for JavaFX 14:
>>>>
>>>> 1. Do nothing (defer the bug to FX 15)
>>>> 2. Disable touch events completely if running on macOS 10.15 (or 
>>>> later) -- we could consider a system property to re-enable it, but 
>>>> I don't really like that idea, and I'm not sure how useful it would 
>>>> be anyway since setting that flag would cause the scary dialog again.
>>>> 3. Defer enabling of touch events until the first time the 
>>>> application requests them -- this would require new interfaces in 
>>>> Glass, isn't risk free, and doesn't solve the dialog problem for 
>>>> those apps that do use touch.
>>>>
>>>> I'm leaning towards option #2 (without the system property to force 
>>>> enable it), but wanted to get a sense from app developers as to 
>>>> whether that would be more of a problem than doing nothing (i.e., 
>>>> option #1). I only listed option #3 for completeness, since it 
>>>> doesn't really solve the issue.
>>>>
>>>> Whatever we do for 14, the solution for 15 will very likely be to 
>>>> switch to tracking per-View (per Window) touch events, either 
>>>> directly, or maybe using local event monitoring.
>>>>
>>>> -- Kevin
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231513
>>>>
>>>
>>
>


From kevin.rushforth at oracle.com  Thu Jan 30 21:35:06 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Jan 2020 13:35:06 -0800
Subject: Scary keystroke logging dialog on macOS 10.15 Catalina
 (JDK-8231513)
In-Reply-To: <1f04c9e5-081b-1a83-bb0c-fb067a8336fa@oracle.com>
References: <c39e76cf-53bd-f148-adfc-a18f38c8c564@oracle.com>
 <3d944f7b-e627-3cd4-408a-d33f1cdbca65@jugs.org>
 <af4fb2bc-4d9d-9ad4-173e-42bd2cfd1c11@oracle.com>
 <6d10efd4-82ab-29c3-908e-490a42d54f81@jugs.org>
 <1f04c9e5-081b-1a83-bb0c-fb067a8336fa@oracle.com>
Message-ID: <5787db9b-e3f2-a131-e531-2a27cebadf3e@oracle.com>

My obvious attempt failed to get any touch events delivered to the app. 
There is also code in GestureRecognizers (internal to glass) to register 
listeners for touch events that will then in some cases be turned into 
gestures, but it's disabled by default.

So it really does look like we are generating these low level macOS 
events for no purpose other than to cause the warning dialog on Catalina.

I'll do some more testing and will likely send out a PR for review to 
disable the low-level touch events on macOS 10.15 or later (option #2 
below). I'll also file a follow-up issue for 15 to fix it.

-- Kevin


On 1/30/2020 11:52 AM, Kevin Rushforth wrote:
> Yeah, I was surprised, too. I can see the low level touch events being 
> generated and passed up to the Java code, but I haven't actually 
> verified yet that it turns them into JavaFX TouchEvents that get 
> delivered to an application (I'll try that this afternoon).
>
> -- Kevin
>
>
> On 1/30/2020 10:55 AM, Michael Paus wrote:
>> In this case I would also vote for #2. Your comment astonishes me 
>> nevertheless because
>> I have never received any JavaFX TouchEvents on my Mac, so I won't 
>> miss them. As far as
>> I know they are only generated by real touch screens but NOT by track 
>> pads, or have I
>> missed something here? This is also consistent with the comment from 
>> Sebastian.
>> I am not aware of any Mac which has a touch screen, so it is quite 
>> unlikely that
>> someone has ever used them.
>>
>> Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
>>> This affects TouchEvents generated via low-level native touch 
>>> events, including those generated by a trackpad. GestureEvents still 
>>> work. In particular, the HelloGestures app still works: even with 
>>> low-level touch events disabled, I can use the trackpad to rotate 
>>> and zoom and the app picks it up fine.
>>>
>>> Mouse events, including trackpad scrolling events, are not affected 
>>> at all by this.
>>>
>>> -- Kevin
>>>
>>>
>>> On 1/30/2020 9:31 AM, Michael Paus wrote:
>>>> Just to clarify the implications of this issue: Are you only 
>>>> talking about the JavaFX TouchEvents
>>>> or would disabling them also affect all GestureEvents and 
>>>> synthesized MouseEvents when you are
>>>> working with a trackpad?
>>>>
>>>> Am 30.01.20 um 17:47 schrieb Kevin Rushforth:
>>>>> To: Mac app developers / users
>>>>>
>>>>> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
>>>>> Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
>>>>> The effect of this bug is that a scary dialog is shown for all 
>>>>> users the first time they run a JavaFX application and move the 
>>>>> mouse is moved into the JavaFX window. It also is reported to 
>>>>> block apps from being accepted in the Apple store.
>>>>>
>>>>> This bug is caused by a change in macOS 10.15 to require 
>>>>> additional permissions for using CGEventTap, which JavaFX uses to 
>>>>> track touch events.
>>>>>
>>>>> The suggested replacement API, 
>>>>> NSEvent::addLocalMonitorForEventsMatchingMask, works just 
>>>>> differently enough (it tracks events delivered to a specific view, 
>>>>> whereas the current code is implemented using a global monitor and 
>>>>> a global set of touch points), that it would be too risky to 
>>>>> change it this late in the release.
>>>>>
>>>>> Since there isn't an easy / safe fix that is feasible for JavaFX 
>>>>> 14, I wanted to get some input from Mac users on the list. I can 
>>>>> think of the following possibilities for JavaFX 14:
>>>>>
>>>>> 1. Do nothing (defer the bug to FX 15)
>>>>> 2. Disable touch events completely if running on macOS 10.15 (or 
>>>>> later) -- we could consider a system property to re-enable it, but 
>>>>> I don't really like that idea, and I'm not sure how useful it 
>>>>> would be anyway since setting that flag would cause the scary 
>>>>> dialog again.
>>>>> 3. Defer enabling of touch events until the first time the 
>>>>> application requests them -- this would require new interfaces in 
>>>>> Glass, isn't risk free, and doesn't solve the dialog problem for 
>>>>> those apps that do use touch.
>>>>>
>>>>> I'm leaning towards option #2 (without the system property to 
>>>>> force enable it), but wanted to get a sense from app developers as 
>>>>> to whether that would be more of a problem than doing nothing 
>>>>> (i.e., option #1). I only listed option #3 for completeness, since 
>>>>> it doesn't really solve the issue.
>>>>>
>>>>> Whatever we do for 14, the solution for 15 will very likely be to 
>>>>> switch to tracking per-View (per Window) touch events, either 
>>>>> directly, or maybe using local event monitoring.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231513
>>>>>
>>>>
>>>
>>
>


From mike at plan99.net  Thu Jan 30 23:33:23 2020
From: mike at plan99.net (Mike Hearn)
Date: Thu, 30 Jan 2020 15:33:23 -0800
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
In-Reply-To: <58d9ddfa-d985-0b07-baac-dc80cb0e6f89@jugs.org>
References: <CANEZrP2diEVJoBL8iwoqTMcq+RLAd1b=H5n-cSYkc9HW2jZJxA@mail.gmail.com>
 <BN8PR21MB1281D717E89FD664B8FA6DED9B0B0@BN8PR21MB1281.namprd21.prod.outlook.com>
 <d21c307a-67e2-6e28-9867-ea2b21d13f3e@bestsolution.at>
 <CANEZrP3sixbiNsM5H4BQhfy=yHZ0Cpc=+sCddfVjx9MqPskOvQ@mail.gmail.com>
 <58d9ddfa-d985-0b07-baac-dc80cb0e6f89@jugs.org>
Message-ID: <CANEZrP1CpmEGrKjU-+f-cB0CmF9X=xY6A9f5nambXR98cpP5gg@mail.gmail.com>

I'm afraid I disagree. My eyesight isn't great and I like to zoom web apps
to sizes that most designers would consider wrong/bad/absurd, at least when
possible. How far I can go depends a lot on the app. Many modern desktop
apps feel far too dense and with fonts that are uncomfortably small for me.
I much prefer desktop/JavaFX apps for various reasons, but in this regard
the web wins - I can blow the sizes up nice and big, and things mostly just
work. Hence my interest in replicating this feature.

It's annoying because it feels like it's surely possible and even easy, but
that the knowledge of how to do it probably only exists in the heads of
five people. JavaFX can scale widgets to handle variable dpi, scale
transforms and other features. This one doesn't seem like a stretch. I'd
rather get an authoritative tip before diving into Glass to try and reverse
engineer it all from the code.




On Thu, Jan 30, 2020 at 16:59:54, Michael Paus <mp at jugs.org> wrote:

> I am wondering whether this kind of scaling should actually be done on an
> application basis. On desktop computers this is normally achieved via some
> system setting of the monitor scaling. I think most people just want a
> consistent scaling across all applications and so there is just no need in
> general for an individual scaling. Just for very specific cases this may be
> useful, e.g., to scale the text size of an editor window in Eclipse where
> this can be done like in a browser via Cmd+/-. In a browser you only need
> this feature because web-sites are so inconsistent in their styling, which
> is normally not the case for desktop applications.
>
> Just my two ?ent
>
> Am 30.01.20 um 17:29 schrieb Mike Hearn:
>
> Yes, a scale transform doesn't affect layout. That's the issue. Browser
> zoom scales fonts, images and widgets but in a way that affects layout
> bounds, not only render bounds.
>
> As far as I can tell there's no way to do a zoom or scale that affects
> layout bounds with the public JavaFX API. Exploring why not and what could
> work is how I ended up getting a bit lost in the weeds of all the different
> scale factors. It *feels* like one of them should be applicable if only it
> was public API. But I can't quite figure out which or how exactly it'd
> work. If nobody else has ever examined this task (it seems not) then I
> guess I can just compile my own JFX and experiment with forcing the
> different factors and ratios to see what happens. I'm not sure the results
> would be stable or portable though.
>
> On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
>
> I think that can not work because layouts don't take the scale factor into
> account nor does stuff like ScrollView but i could be wrong.
>
> Tom
>
> On 27.01.20 17:29, David Grieve wrote:
>
> Wouldn't this just be a scale transform?
>
> -----Original Message-----
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev at openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>
> Hello,
>
> A feature I often miss when using non-web GUIs is support for browser
> style zooming. In JavaFX it is quite easy to specify all font sizes in
> terms of "ems", relative sizes ("largest") or percentages and then adjust
> the base font size on a root node inside key handlers. This works OK but
> doesn't do much for images or other controls, and of course most JavaFX GUI
> code specifies sizes in terms of pixels.
>
> There are various scaling factors applied to pixel sizes. There is the
> per-node scaling transform, but this doesn't affect layout so isn't
> comparable to what browsers do. There's a per-screen DPI, there's a
> "platform scale", there's a
> "render scale" and then there's a "ui scale". These seem related to
> hidpi/retina support and are all internal (for the purposes of this
> question I'm happy to modify JavaFX itself).
>
> Render scale seems to affect resolution without affecting positions or
> layout, so that's not quite what I want. UI scale sounds promising but
> isn't documented and I couldn't quite figure it out by reading the code,
> though I could just fiddle with it and see what happens.
>
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting zoom? If not,
> has anyone explored the complexity of the modifications required?
>
> thanks,
> -mike
>
> --
> Tom Schindl, CTO
> BestSolution.at <http://bestsolution.at/> <http://bestsolution.at/> EDV
> Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>

From kevin.rushforth at oracle.com  Thu Jan 30 23:59:19 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Jan 2020 15:59:19 -0800
Subject: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15
 (Catalina)
Message-ID: <aac8386f-f7a3-fbdc-75c8-f50de0c64aa4@oracle.com>

The Skara bot isn't sending email at the moment, so here is an RFR for 
jfx14:

PR: https://github.com/openjdk/jfx/pull/102
JBS: https://bugs.openjdk.java.net/browse/JDK-8231513

This is a fix for 
[JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to 
disable the use of `CGEventTap` when running on macOS 10.15 or later.

The effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.

This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch events.

The suggested replacement API, 
`NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set of 
touch points), that it would be too risky to change it this late in the 
release.

For openjfx14, I am proposing to disable touch events completely if 
running on macOS 10.15 (or later). This will disable the tracking of 
native touch events, but those events are not used by default on macOS 
anyway. For Mac systems with a trackpad we instead rely on macOS to do 
the gesture recognition by default, and this fix does not intefere with 
that functionality.

I have verified that this avoids the dialog on macOS 10.15 and that the 
HelloGestures program still runs correctly and still recognizes trackpad 
gestures such as zoom and rotate. I also verified that the changes don't 
affect macOS 10.14 or earlier (the Event Tap code is still enabled on 
those older OS versions).

See [this 
thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) 
on openjfx-dev for more discussion.

-- Kevin


From kcr at openjdk.java.net  Fri Jan 31 00:55:00 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 00:55:00 GMT
Subject: RFR: 8237782: Only read advances up to the minimum of the
 numHorMetrics or the available font data.
In-Reply-To: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>
References: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>
Message-ID: <7BJaFUQM9i2-e8HK8koLP_k-5uX5gVVeszpIrWWg5WM=.c63f40e7-db04-46e1-9438-99878811dbfc@github.com>

On Fri, 24 Jan 2020 17:08:42 GMT, Phil Race <prr at openjdk.org> wrote:

> ? the available font data.

Looks like GitHub truncated your title, so I fixed it to match the JBS title.

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

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

From kcr at openjdk.java.net  Fri Jan 31 06:47:30 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 06:47:30 GMT
Subject: [Rev 01] RFR: 8237944: webview native cl "-m32" unknown option
 for windows 32-bit build
In-Reply-To: <0qs2P4MB966ffrrY4YPBACMDPo0wT4P2SxAwdVW3roM=.801906c9-d00a-4511-80a9-2592470495ff@github.com>
References: <iywuRMRJW-xiYQMqbvFd-ethmiyEnGMbQwW09I0dV_E=.3f1a8337-4e5f-4db4-b629-c720b34d919f@github.com>
 <YZIvXzwJjZF7SuD0OWhkl3X48VkSl7C7-EZ1Y-_lx0g=.ca2a6438-a932-4a19-ba07-0d29b664db6a@github.com>
 <65dwSJk845x28C1G22a0UOWOS0Q6aukdc2YC4xQak9M=.1be4ca90-1abc-42d5-a42d-c60eec747072@github.com>
 <0qs2P4MB966ffrrY4YPBACMDPo0wT4P2SxAwdVW3roM=.801906c9-d00a-4511-80a9-2592470495ff@github.com>
Message-ID: <J2H_T6ekifN7gMFeqZd6VXi8BXzRJlFBgnnIE7CJqRc=.e291006e-d8d3-44ff-9856-fb32c08eaa30@github.com>

On Wed, 29 Jan 2020 15:36:52 GMT, Guru Hb <ghb at openjdk.org> wrote:

>> Marked as reviewed by kcr (Lead).
> 
>> the -m32 option seems to be ignored by the compiler:
>> cl : Command line warning D9002 : ignoring unknown option '-m32'
>> 
>> However, I agree it is better to conditionally remove it.
> "-m32" required for compiling other ports of webkit (WebkitGTK, WPE) and for our platform I haven't tested this feature (i.e cross compiling on a 64 bit Linux).

@guruhb this is ready to integrate unless @johanvos wants to review it.

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

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

From kcr at openjdk.java.net  Fri Jan 31 06:50:26 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 06:50:26 GMT
Subject: RFR: 8237975: Non-embedded Animations do not play backwards after
 being paused
In-Reply-To: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
Message-ID: <PqG0VrlCrO7hVXZ5ZmOijsXJ0ahCJZrbYQxL_wkdyQE=.017b459f-a2e1-4066-8b5a-9a9cc24193af@github.com>

On Tue, 28 Jan 2020 19:19:57 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
> 
> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
> 
> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.

The fix looks fine, and all my testing looks good, too. I don't have a good recommendation for the test...I'd go with whatever is easiest for jfx14 and address it more completely in 15 when you address some of the design issues you raised.

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



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

From kcr at openjdk.java.net  Fri Jan 31 06:51:37 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 06:51:37 GMT
Subject: RFR: 8237770: Error creating fragment phong shader on iOS
In-Reply-To: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>
References: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>
Message-ID: <fUAP9OHvEXqFcPxZixiitGg7qj9rtsW1LJJ6U-RL_x8=.3241dc5e-e85b-4a63-b9dc-4176122d5488@github.com>

On Fri, 24 Jan 2020 11:31:02 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR defines a pre-processor in the phong frag files to avoid inline declaration of #extension when several frags are combined that leads to the error:
> 
> syntax error: #extension must always be before any non-preprocessor tokens

I verified that this works correctly. I have a minor style comment for you to consider.

modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/diffuse_color.frag line 32:

> 31: #extension GL_OES_standard_derivatives : enable
> 32: #define EXTENSION_APPLIED
> 33: #endif

Usual practice is to put the `#define` right after the `#ifndef`, but I don't have a strong opinion about that.

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



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

From kcr at openjdk.java.net  Fri Jan 31 06:57:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 06:57:02 GMT
Subject: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15
 (Catalina)
Message-ID: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>

This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later.

The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.

This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.

The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.

For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality.

I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions).

See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion.

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

Commits:
 - d6109fb1: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)

Changes: https://git.openjdk.java.net/jfx/pull/102/files
 Webrev: https://webrevs.openjdk.java.net/jfx/102/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231513
  Stats: 71 lines in 1 file changed: 26 ins; 6 del; 39 mod
  Patch: https://git.openjdk.java.net/jfx/pull/102.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/102/head:pull/102

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

From prr at openjdk.java.net  Fri Jan 31 06:57:02 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 31 Jan 2020 06:57:02 GMT
Subject: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS
 10.15 (Catalina)
In-Reply-To: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
References: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
Message-ID: <qbr2CTK9I8xZRPmSIg6F_JwYdLuLj0t2T59y1k-V7Y4=.28e1a2c0-b604-4b5d-9fcc-f9ff7575cb97@github.com>

On Thu, 30 Jan 2020 23:07:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later.
> 
> The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.
> 
> For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality.
> 
> I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions).
> 
> See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion.

Looks OK to me.

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

Marked as reviewed by prr (Reviewer).

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

From kcr at openjdk.java.net  Fri Jan 31 06:57:03 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 06:57:03 GMT
Subject: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS
 10.15 (Catalina)
In-Reply-To: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
References: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
Message-ID: <5-tjj7j1bLH4u359G6jDtCCHYw6N8bdlknfg9OizYJ0=.6e626fd7-0740-4706-bdd5-2521d468b25e@github.com>

On Thu, 30 Jan 2020 23:07:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later.
> 
> The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.
> 
> For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality.
> 
> I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions).
> 
> See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion.

@arapte can you be one of the reviewers?

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

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

From jvos at openjdk.java.net  Fri Jan 31 09:18:14 2020
From: jvos at openjdk.java.net (Johan Vos)
Date: Fri, 31 Jan 2020 09:18:14 GMT
Subject: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS
 10.15 (Catalina)
In-Reply-To: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
References: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
Message-ID: <cglUYmaKQhRM77kooQqGqTjx5B7cPRPBDQDw1GQcjME=.efe7ef6f-aefe-4d73-a5b7-fd5a19ffe543@github.com>

On Thu, 30 Jan 2020 23:07:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later.
> 
> The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.
> 
> For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality.
> 
> I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions).
> 
> See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion.

modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m line 179:

> 178: {
> 179:     BOOL useEventTap = YES;
> 180:     if (@available(macOS 10.15, *)) {

I think that if you make useEventTap static, you don't need the additional tests in the other functions.
init is always the first one to be called.

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 31 11:16:34 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 31 Jan 2020 11:16:34 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <NLw9XKNLg-Zx3uWzBwp0MQMGLsfZ5jr3pCBxSUl6obQ=.aff7a503-6ce7-42c6-987e-c7216ff55c26@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
 <NLw9XKNLg-Zx3uWzBwp0MQMGLsfZ5jr3pCBxSUl6obQ=.aff7a503-6ce7-42c6-987e-c7216ff55c26@github.com>
Message-ID: <eNwJAtgcswYY4h8bPdKv680fmG8sGFqbcZlcwM_OZQo=.5aeef1a0-dead-4a91-91f4-d870da0c73ba@github.com>

On Thu, 30 Jan 2020 08:15:39 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> With my basic testing, the change looks good, scaled up and scaled down snapshots seem correct visually.
> 
> After this change the tiled snapshot will be limited by dimensions of the `WritableImage`.
> We can not create a `WritableImage` of dimension `(8192 * 3, 8192 * 3)` or greater.
> `new WritableImage(8192 * 3, 8192 * 3)`  causes an exception.
> java.lang.IllegalArgumentException: capacity < 0: (-1879048192 < 0)
> 	at java.base/java.nio.Buffer.createCapacityException(Buffer.java:257)
> This is an existing behavior of `WritableImage`.
> May be we should consider to wrap and re-throw the exception and update the API JavaDoc.
> Anyway not a stopper for this PR.
> Approving.

Since @kevinrushforth and @arapte have completed their review, is this ready to integrate?
I'm a little confused by the fact this has both `rfr` and `ready` labels attached; is this an expected behaviour?

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

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

From kcr at openjdk.java.net  Fri Jan 31 13:02:07 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 13:02:07 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <eNwJAtgcswYY4h8bPdKv680fmG8sGFqbcZlcwM_OZQo=.5aeef1a0-dead-4a91-91f4-d870da0c73ba@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
 <NLw9XKNLg-Zx3uWzBwp0MQMGLsfZ5jr3pCBxSUl6obQ=.aff7a503-6ce7-42c6-987e-c7216ff55c26@github.com>
 <eNwJAtgcswYY4h8bPdKv680fmG8sGFqbcZlcwM_OZQo=.5aeef1a0-dead-4a91-91f4-d870da0c73ba@github.com>
Message-ID: <aZynq4ZPtVLfvGJsHhaOS3CAOXGydbxegNZFUZIPC58=.d24712b2-946a-48f4-9f96-42d8eddf988d@github.com>

On Fri, 31 Jan 2020 11:16:22 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> With my basic testing, the change looks good, scaled up and scaled down snapshots seem correct visually.
>> 
>> After this change the tiled snapshot will be limited by dimensions of the `WritableImage`.
>> We can not create a `WritableImage` of dimension `(8192 * 3, 8192 * 3)` or greater.
>> `new WritableImage(8192 * 3, 8192 * 3)`  causes an exception.
>> java.lang.IllegalArgumentException: capacity < 0: (-1879048192 < 0)
>> 	at java.base/java.nio.Buffer.createCapacityException(Buffer.java:257)
>> This is an existing behavior of `WritableImage`.
>> May be we should consider to wrap and re-throw the exception and update the API JavaDoc.
>> Anyway not a stopper for this PR.
>> Approving.
> 
> Since @kevinrushforth and @arapte have completed their review, is this ready to integrate?
> I'm a little confused by the fact this has both `rfr` and `ready` labels attached; is this an expected behaviour?

Yes, this is ready for you to integrate. The `rfr` label is intentionally left there, since there might be review comments or questions that are still being addressed. In this case, there are no outstanding questions, so go ahead and integrate it. Either @arapte or I will sponsor it.

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

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Jan 31 13:26:23 2020
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 31 Jan 2020 13:26:23 GMT
Subject: [Rev 04] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <aZynq4ZPtVLfvGJsHhaOS3CAOXGydbxegNZFUZIPC58=.d24712b2-946a-48f4-9f96-42d8eddf988d@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <E7CbU07bVlSEN007PRCpA59oGnoFBLIpRfiK6aAyCqU=.3813bd7c-04e7-4d50-a0a9-ff60d4d15b5e@github.com>
 <NLw9XKNLg-Zx3uWzBwp0MQMGLsfZ5jr3pCBxSUl6obQ=.aff7a503-6ce7-42c6-987e-c7216ff55c26@github.com>
 <eNwJAtgcswYY4h8bPdKv680fmG8sGFqbcZlcwM_OZQo=.5aeef1a0-dead-4a91-91f4-d870da0c73ba@github.com>
 <aZynq4ZPtVLfvGJsHhaOS3CAOXGydbxegNZFUZIPC58=.d24712b2-946a-48f4-9f96-42d8eddf988d@github.com>
Message-ID: <1vot9l80mYw0wbGr5N-0rVVgJiFvIwwWypKP1Qpyh-c=.24cd2999-2170-42d8-9a73-559ddb36924a@github.com>

On Fri, 31 Jan 2020 13:01:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Since @kevinrushforth and @arapte have completed their review, is this ready to integrate?
>> I'm a little confused by the fact this has both `rfr` and `ready` labels attached; is this an expected behaviour?
> 
> Yes, this is ready for you to integrate. The `rfr` label is intentionally left there, since there might be review comments or questions that are still being addressed. In this case, there are no outstanding questions, so go ahead and integrate it. Either @arapte or I will sponsor it.

Ok, thank you for the clarification.

/integrate

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

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

From kcr at openjdk.java.net  Fri Jan 31 14:35:12 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 14:35:12 GMT
Subject: RFR: 8237782: Only read advances up to the minimum of the
 numHorMetrics or the available font data.
In-Reply-To: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>
References: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>
Message-ID: <001lCSHgd-ICG_1RNUaBXTqSlgqWWNVSdaOfeRGUalc=.289fdde6-a7d3-4608-a5af-6088e6f2284b@github.com>

On Fri, 24 Jan 2020 17:08:42 GMT, Phil Race <prr at openjdk.org> wrote:

> ? the available font data.

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Fri Jan 31 14:35:28 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 14:35:28 GMT
Subject: RFR: 8237833: Check glyph size before adding to glyph texture
 cache
In-Reply-To: <fLtWIZGn9W-SHGPMd4XirEColcnfGRWA1q7XKV9M_Gk=.267b0073-a3ae-4eba-9a05-f02ed376ccdd@github.com>
References: <fLtWIZGn9W-SHGPMd4XirEColcnfGRWA1q7XKV9M_Gk=.267b0073-a3ae-4eba-9a05-f02ed376ccdd@github.com>
Message-ID: <PXzgg17yre9ihnifxAOd5bE9frWqF77On0rqb4Y12bE=.3661de0a-d420-4f9a-b4ee-946086cf436b@github.com>

On Fri, 24 Jan 2020 21:05:49 GMT, Phil Race <prr at openjdk.org> wrote:

> Check if the glyph will fit before trying to cache it.

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Fri Jan 31 14:36:31 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 14:36:31 GMT
Subject: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS
 10.15 (Catalina)
In-Reply-To: <cglUYmaKQhRM77kooQqGqTjx5B7cPRPBDQDw1GQcjME=.efe7ef6f-aefe-4d73-a5b7-fd5a19ffe543@github.com>
References: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
 <cglUYmaKQhRM77kooQqGqTjx5B7cPRPBDQDw1GQcjME=.efe7ef6f-aefe-4d73-a5b7-fd5a19ffe543@github.com>
Message-ID: <iwq84WXUS8dZuqD39RR2Ple1OUKgX8741CNKhfnhhMg=.833961b7-0aff-46bd-97ad-ed5be2cab7c4@github.com>

On Fri, 31 Jan 2020 09:17:59 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later.
>> 
>> The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.
>> 
>> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.
>> 
>> The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.
>> 
>> For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality.
>> 
>> I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions).
>> 
>> See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion.
> 
> modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m line 179:
> 
>> 178: {
>> 179:     BOOL useEventTap = YES;
>> 180:     if (@available(macOS 10.15, *)) {
> 
> I think that if you make useEventTap static, you don't need the additional tests in the other functions.
> init is always the first one to be called.

OK, I'll push an update for this.

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

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

From Rony.Flatscher at wu.ac.at  Fri Jan 31 15:28:32 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Fri, 31 Jan 2020 16:28:32 +0100
Subject: Question ad creating a testcase that needs a jar on class- or module
 path
Message-ID: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at>

How would one go about creating a testcase that needs a jar-file either on the class- or module path?

Are there any test units that would demonstrate how to do it? If not, what approach would you
suggest (and if so, are there any samples already somewhere to study)?

---

Background: for creating a testcase using a pseudo script engine ("RgfPseudoScriptEngine") that logs
its invocations with the script context Bindings for each invocation and which then will be analyzed
and used for the test assertions, there is a need to have the pseudo script engine made available
via the Java scripting framework.

There is a jar-file (that includes the sources as well) with the necessary definitions:

  * via class path: "META-INF/services/javax.script.ScriptEngineFactory" entry:

    rgf.scriptEngine.RgfPseudoScriptEngineFactory

  * via module path which will use the information in "module-info.java":

    module rgf.scriptEngine {
        requires java.scripting;
        provides javax.script.ScriptEngineFactory with rgf.scriptEngine.RgfPseudoScriptEngineFactory;
        exports rgf.scriptEngine;           
    }

TIA,

---rony


From kevin.rushforth at oracle.com  Fri Jan 31 15:35:40 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 31 Jan 2020 07:35:40 -0800
Subject: Question ad creating a testcase that needs a jar on class- or
 module path
In-Reply-To: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at>
References: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at>
Message-ID: <bb2c4292-b679-9601-e6b7-f41e5c9c1586@oracle.com>

Take a look at the JarLauncherTest in the tests/system dir. There is 
some (ugly) build logic in build.gradle to support it.

-- Kevin

On 1/31/2020 7:28 AM, Rony G. Flatscher wrote:
> How would one go about creating a testcase that needs a jar-file either on the class- or module path?
>
> Are there any test units that would demonstrate how to do it? If not, what approach would you
> suggest (and if so, are there any samples already somewhere to study)?
>
> ---
>
> Background: for creating a testcase using a pseudo script engine ("RgfPseudoScriptEngine") that logs
> its invocations with the script context Bindings for each invocation and which then will be analyzed
> and used for the test assertions, there is a need to have the pseudo script engine made available
> via the Java scripting framework.
>
> There is a jar-file (that includes the sources as well) with the necessary definitions:
>
>    * via class path: "META-INF/services/javax.script.ScriptEngineFactory" entry:
>
>      rgf.scriptEngine.RgfPseudoScriptEngineFactory
>
>    * via module path which will use the information in "module-info.java":
>
>      module rgf.scriptEngine {
>          requires java.scripting;
>          provides javax.script.ScriptEngineFactory with rgf.scriptEngine.RgfPseudoScriptEngineFactory;
>          exports rgf.scriptEngine;
>      }
>
> TIA,
>
> ---rony
>


From kevin.rushforth at oracle.com  Fri Jan 31 15:38:35 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 31 Jan 2020 07:38:35 -0800
Subject: Question ad creating a testcase that needs a jar on class- or
 module path
In-Reply-To: <bb2c4292-b679-9601-e6b7-f41e5c9c1586@oracle.com>
References: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at>
 <bb2c4292-b679-9601-e6b7-f41e5c9c1586@oracle.com>
Message-ID: <40571aa5-a667-d279-c410-ecb4648a9629@oracle.com>

And if you need a modular jar, you might look at ModuleLauncherTest instead.

-- Kevin


On 1/31/2020 7:35 AM, Kevin Rushforth wrote:
> Take a look at the JarLauncherTest in the tests/system dir. There is 
> some (ugly) build logic in build.gradle to support it.
>
> -- Kevin
>
> On 1/31/2020 7:28 AM, Rony G. Flatscher wrote:
>> How would one go about creating a testcase that needs a jar-file 
>> either on the class- or module path?
>>
>> Are there any test units that would demonstrate how to do it? If not, 
>> what approach would you
>> suggest (and if so, are there any samples already somewhere to study)?
>>
>> ---
>>
>> Background: for creating a testcase using a pseudo script engine 
>> ("RgfPseudoScriptEngine") that logs
>> its invocations with the script context Bindings for each invocation 
>> and which then will be analyzed
>> and used for the test assertions, there is a need to have the pseudo 
>> script engine made available
>> via the Java scripting framework.
>>
>> There is a jar-file (that includes the sources as well) with the 
>> necessary definitions:
>>
>> ?? * via class path: 
>> "META-INF/services/javax.script.ScriptEngineFactory" entry:
>>
>> ???? rgf.scriptEngine.RgfPseudoScriptEngineFactory
>>
>> ?? * via module path which will use the information in 
>> "module-info.java":
>>
>> ???? module rgf.scriptEngine {
>> ???????? requires java.scripting;
>> ???????? provides javax.script.ScriptEngineFactory with 
>> rgf.scriptEngine.RgfPseudoScriptEngineFactory;
>> ???????? exports rgf.scriptEngine;
>> ???? }
>>
>> TIA,
>>
>> ---rony
>>
>


From kcr at openjdk.java.net  Fri Jan 31 15:47:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 15:47:06 GMT
Subject: [Integrated] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <31341f30-3c74-41f4-af60-69fe817aa1b4@openjdk.org>

Changeset: 1823f6ec
Author:    Frederic Thevenet <thevenet.fred at free.fr>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-31 14:11:47 +0000
URL:       https://git.openjdk.java.net/jfx/commit/1823f6ec

8088198: Exception thrown from snapshot if dimensions are larger than max texture size

Reviewed-by: arapte, kcr

! modules/javafx.graphics/src/main/java/javafx/scene/Scene.java
! tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java

From jpereda at openjdk.java.net  Fri Jan 31 16:32:33 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 31 Jan 2020 16:32:33 GMT
Subject: [Rev 01] RFR: 8237770: Error creating fragment phong shader on iOS
In-Reply-To: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>
References: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>
Message-ID: <orFI-0fjiN97TVYnfWww6OIbvh4ri-x22gLqt5RIGCQ=.f34ab076-9bb2-4568-838c-1f6caad861c3@github.com>

> This PR defines a pre-processor in the phong frag files to avoid inline declaration of #extension when several frags are combined that leads to the error:
> 
> syntax error: #extension must always be before any non-preprocessor tokens

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 81338e6c: Apply #define right after #ifndef

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/93/files
  - new: https://git.openjdk.java.net/jfx/pull/93/files/14ccbe6a..81338e6c

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

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

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

From jpereda at openjdk.java.net  Fri Jan 31 16:32:45 2020
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Fri, 31 Jan 2020 16:32:45 GMT
Subject: [Rev 01] RFR: 8237770: Error creating fragment phong shader on iOS
In-Reply-To: <fUAP9OHvEXqFcPxZixiitGg7qj9rtsW1LJJ6U-RL_x8=.3241dc5e-e85b-4a63-b9dc-4176122d5488@github.com>
References: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>
 <fUAP9OHvEXqFcPxZixiitGg7qj9rtsW1LJJ6U-RL_x8=.3241dc5e-e85b-4a63-b9dc-4176122d5488@github.com>
Message-ID: <A_BVVqbgj3vYFlYyCl6ZNJZbqj4dDEwXxGl_r8n3z7k=.d092c089-18f7-4a30-9f15-944c6a3dfed8@github.com>

On Fri, 31 Jan 2020 00:51:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/diffuse_color.frag line 32:
> 
>> 31: #extension GL_OES_standard_derivatives : enable
>> 32: #define EXTENSION_APPLIED
>> 33: #endif
> 
> Usual practice is to put the `#define` right after the `#ifndef`, but I don't have a strong opinion about that.

Makes sense, I've applied the change

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

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

From kcr at openjdk.java.net  Fri Jan 31 16:52:15 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 16:52:15 GMT
Subject: [Integrated] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <6edd2518-d7e5-4c9e-ab49-2d2dc92a5dc3@openjdk.org>

Changeset: 1823f6ec
Author:    Frederic Thevenet <thevenet.fred at free.fr>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2020-01-31 14:11:47 +0000
URL:       https://git.openjdk.java.net/jfx/commit/1823f6ec

8088198: Exception thrown from snapshot if dimensions are larger than max texture size

Reviewed-by: arapte, kcr

! modules/javafx.graphics/src/main/java/javafx/scene/Scene.java
! tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java

From nlisker at openjdk.java.net  Fri Jan 31 18:19:27 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 31 Jan 2020 18:19:27 GMT
Subject: [Rev 01] RFR: 8237975: Non-embedded Animations do not play
 backwards after being paused
In-Reply-To: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
Message-ID: <74uIjcC3pLjZJJjBgq_mf7eywW9_eAXoPF73avEaBds=.5bf0ac5b-3725-4e6b-8e09-781463a9a689@github.com>

> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
> 
> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
> 
> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 317261e6: Implemented test

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/98/files
  - new: https://git.openjdk.java.net/jfx/pull/98/files/54ee486d..317261e6

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

  Stats: 19 lines in 3 files changed: 14 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/98.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/98/head:pull/98

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

From nlisker at openjdk.java.net  Fri Jan 31 18:19:28 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 31 Jan 2020 18:19:28 GMT
Subject: [Rev 01] RFR: 8237975: Non-embedded Animations do not play
 backwards after being paused
In-Reply-To: <PqG0VrlCrO7hVXZ5ZmOijsXJ0ahCJZrbYQxL_wkdyQE=.017b459f-a2e1-4066-8b5a-9a9cc24193af@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
 <PqG0VrlCrO7hVXZ5ZmOijsXJ0ahCJZrbYQxL_wkdyQE=.017b459f-a2e1-4066-8b5a-9a9cc24193af@github.com>
Message-ID: <geX_hFOp0bTJrNi2dnmLNg1NWQYGVigajF2pup8m_Tc=.c2fdc0fe-80af-4049-903c-fdb5eb08b510@github.com>

On Fri, 31 Jan 2020 00:31:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix looks fine, and all my testing looks good, too. I don't have a good recommendation for the test...I'd go with whatever is easiest for jfx14 and address it more completely in 15 when you address some of the design issues you raised.

The concept test is now realized. Note that I test on `SingleLoopClipEnvelope` only, but it is the exact same logic in the other 2 (that piece of code should have been pulled out to `ClipEnvelope`, but it will wait for the redesign).

Without the patch the test fails with the value of 5 instead of 3 because the current rate is not updated to be negative: 4 + 5 * (+0.2) = 5

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

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

From prr at openjdk.java.net  Fri Jan 31 18:23:01 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 31 Jan 2020 18:23:01 GMT
Subject: [Integrated] RFR: 8237833: Check glyph size before adding to
 glyph texture cache
In-Reply-To: <fLtWIZGn9W-SHGPMd4XirEColcnfGRWA1q7XKV9M_Gk=.267b0073-a3ae-4eba-9a05-f02ed376ccdd@github.com>
References: <fLtWIZGn9W-SHGPMd4XirEColcnfGRWA1q7XKV9M_Gk=.267b0073-a3ae-4eba-9a05-f02ed376ccdd@github.com>
Message-ID: <9c7ea5e0-364f-4f07-8b49-c74edc62cba5@openjdk.org>

Changeset: d05e8fc4
Author:    Phil Race <prr at openjdk.org>
Date:      2020-01-31 18:21:51 +0000
URL:       https://git.openjdk.java.net/jfx/commit/d05e8fc4

8237833: Check glyph size before adding to glyph texture cache

Reviewed-by: kcr

! modules/javafx.graphics/src/main/java/com/sun/prism/impl/GlyphCache.java

From prr at openjdk.java.net  Fri Jan 31 18:24:00 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 31 Jan 2020 18:24:00 GMT
Subject: [Integrated] RFR: 8237782: Only read advances up to the minimum
 of the numHorMetrics =?UTF-8?B?b3LigKY=?=
In-Reply-To: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>
References: <bIjEKBRoLtbjT13L-5jdlYmgh0_rUgyw2Ba76RLE65Q=.cea1917f-0b75-415f-ae31-d71ae0a5cbd6@github.com>
Message-ID: <a28ada70-08e7-4c77-ae82-dfeff7e8ad0f@openjdk.org>

Changeset: 95bf2c00
Author:    Phil Race <prr at openjdk.org>
Date:      2020-01-31 18:22:52 +0000
URL:       https://git.openjdk.java.net/jfx/commit/95bf2c00

8237782: Only read advances up to the minimum of the numHorMetrics or the available font data.

Reviewed-by: kcr

! modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java

From kcr at openjdk.java.net  Fri Jan 31 18:42:07 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 18:42:07 GMT
Subject: [Rev 01] RFR: 8237975: Non-embedded Animations do not play
 backwards after being paused
In-Reply-To: <74uIjcC3pLjZJJjBgq_mf7eywW9_eAXoPF73avEaBds=.5bf0ac5b-3725-4e6b-8e09-781463a9a689@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
 <74uIjcC3pLjZJJjBgq_mf7eywW9_eAXoPF73avEaBds=.5bf0ac5b-3725-4e6b-8e09-781463a9a689@github.com>
Message-ID: <20nG0DrNyoVC1h5Xi5-x2FPNydxxLIV_cmX2UWc7g3E=.983c76cb-5d4c-4b52-af10-3d944790d057@github.com>

On Fri, 31 Jan 2020 18:42:06 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter.
>> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it.
>> 
>> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior.
>> 
>> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc.
> 
> The pull request has been updated with 1 additional commit.

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Fri Jan 31 19:01:43 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 19:01:43 GMT
Subject: [Rev 01] RFR: 8231513: JavaFX cause Keystroke Receiving prompt on
 MacOS 10.15 (Catalina)
In-Reply-To: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
References: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
Message-ID: <Q1td7PZ5VKjEWSkAuSiun8Ynt3ShCPlx1lOyywzIl2g=.05f6273d-7467-4fb2-a607-33c27217ba7e@github.com>

> This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later.
> 
> The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release.
> 
> For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality.
> 
> I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions).
> 
> See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 526f3bf5: make useEventTap static

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/102/files
  - new: https://git.openjdk.java.net/jfx/pull/102/files/d6109fb1..526f3bf5

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

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

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

From kcr at openjdk.java.net  Fri Jan 31 19:01:43 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 19:01:43 GMT
Subject: [Rev 01] RFR: 8231513: JavaFX cause Keystroke Receiving prompt on
 MacOS 10.15 (Catalina)
In-Reply-To: <qbr2CTK9I8xZRPmSIg6F_JwYdLuLj0t2T59y1k-V7Y4=.28e1a2c0-b604-4b5d-9fcc-f9ff7575cb97@github.com>
References: <SC6-JWD1Vvw3Q4iOdj9sIF9M-IKMAjjOap9irQMOwrk=.10fce3df-a16e-4612-87aa-f6e4eb338369@github.com>
 <qbr2CTK9I8xZRPmSIg6F_JwYdLuLj0t2T59y1k-V7Y4=.28e1a2c0-b604-4b5d-9fcc-f9ff7575cb97@github.com>
Message-ID: <FfXeR0_WHH5bLHfaPzuxfYwvDCH3v6eubMS4dmhWKjA=.2f64ba86-3876-425b-a9d6-4ab705e353de@github.com>

On Fri, 31 Jan 2020 00:44:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Looks OK to me.

Pushed a fix to address the review comments.

@rwestberg for some reason the above commit didn't send an RFR reply to openjfx-dev nor did it produce a new webrev (it did rerun jcheck as expected).

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

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

From kcr at openjdk.java.net  Fri Jan 31 23:49:21 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 23:49:21 GMT
Subject: [Rev 01] RFR: 8237770: Error creating fragment phong shader on iOS
In-Reply-To: <orFI-0fjiN97TVYnfWww6OIbvh4ri-x22gLqt5RIGCQ=.f34ab076-9bb2-4568-838c-1f6caad861c3@github.com>
References: <tJjxjPuRo_VXqSAr9kISKDzQuxBiZ64ASba4S5KkoDU=.365b13cd-2fec-43d9-8bf1-df7bc3cc440c@github.com>
 <orFI-0fjiN97TVYnfWww6OIbvh4ri-x22gLqt5RIGCQ=.f34ab076-9bb2-4568-838c-1f6caad861c3@github.com>
Message-ID: <xlER81ZptjKL20CwlKpaABoPJNQe_8hoixfWuIe_XY8=.a55727d5-fcfa-4cfb-b46d-6b6f3071e29b@github.com>

On Fri, 31 Jan 2020 23:49:21 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR defines a pre-processor in the phong frag files to avoid inline declaration of #extension when several frags are combined that leads to the error:
>> 
>> syntax error: #extension must always be before any non-preprocessor tokens
> 
> The pull request has been updated with 1 additional commit.

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Fri Jan 31 23:54:28 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 31 Jan 2020 23:54:28 GMT
Subject: [Rev 01] RFR: 8237975: Non-embedded Animations do not play
 backwards after being paused
In-Reply-To: <20nG0DrNyoVC1h5Xi5-x2FPNydxxLIV_cmX2UWc7g3E=.983c76cb-5d4c-4b52-af10-3d944790d057@github.com>
References: <c2txIplp3SjPFy62RIr2s3U-tbrRgSKxve4o715XbzQ=.8dc0fd39-69a3-4172-a688-04e07700f41b@github.com>
 <74uIjcC3pLjZJJjBgq_mf7eywW9_eAXoPF73avEaBds=.5bf0ac5b-3725-4e6b-8e09-781463a9a689@github.com>
 <20nG0DrNyoVC1h5Xi5-x2FPNydxxLIV_cmX2UWc7g3E=.983c76cb-5d4c-4b52-af10-3d944790d057@github.com>
Message-ID: <P-Kc8OHILnL4cJP5DtOPeAiTfLuTZ0TIrTk1WLId30M=.4775349e-4154-4214-bc54-cd7147d9cf33@github.com>

On Fri, 31 Jan 2020 18:41:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Looks good.

@arapte can you be the second reviewer for this?

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

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